Feedback on the New Build System

Erik Joelsson erik.joelsson at
Thu Mar 14 09:11:27 UTC 2013

Hello Andrew,

Thanks for the feedback! Adding in my view of things below.

On 2013-03-13 17:16, Andrew Hughes wrote:
> I've just got my first build out of the new system using the main jdk8/jdk8 tree (b80) and
> so thought it was worth giving some feedback on the problems encountered and issues
> with the end result:
> 1.  It took some time to work out how to get back to the usual 'noisy' build as the
> default seems to subdue all the useful output.  VERBOSE=true broke the build when
> it tried to use 'true' as a Makefile target.  It turns out the solution is the rather
> non-obvious VERBOSE= .  Could we not have this documented somewhere and perhaps have
> verbosity as a configure option?  After grepping around, it's not very obvious to me
> where it gets set.
As already pointed out, the preferred way is to use 
LOG=warn/info/debug/trace, where "debug" best matches what the old build 
did. I don't recommend trace for normal use. The default level tries to 
keep the user informed about what is happening without information 
overload. It also makes warning messages stand out more in the hope that 
it annoys someone enough to go fix them. I agree that adding a configure 
option for changing the default is a good idea and would welcome such a 
patch. Internally we encourage using "debug" for nightly/remote builds.

The build output is also saved to build.log in the configure directory 
as David said.
> 2.  One of the javac calls in the jdk tree fails with:
> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/ error: package sun.util.locale.provider does not exist
> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/ error: package sun.util.locale.provider does not exist
> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/share/classes/javax/swing/ error: package sun.util.locale.provider does not exist
> This package is in the jdk8 tree but not in the build JDK (7).  Oddly, the build
> continues despite this error and the final rt.jar does include JSpinner.
It's actually not javac, but probably javadoc as David said, and is part 
of java source generation. I'm guessing it's the swing beans (dt.jar) 
that previously were generated at image creation time. It seems harmless 
though, but perhaps it needs to be investigated.
> 3.  -Werror is set for the SCTP native code causing the build to fail:
> Lots of stuff like:
> /home/andrew/projects/openjdk/upstream/jdk8/jdk/src/solaris/native/sun/nio/ch/sctp/SctpChannelImpl.c:88:24: error: unused parameter 'klass' [-Werror=unused-parameter]
> as -Werror is passed and -Wno-unused doesn't seem to turn these off.  SCTP_WERROR=
> worked around it (perhaps this should at least be WARNINGS_ARE_ERRORS to match HotSpot?)
> Do we have a preferred way to fix these errors?  I know about __unused__ but I believe this
> is GCC-specific and I wouldn't want to break the build on other platforms (Solaris, MacOS X, BSD).
This I have not noticed. Is it specific to some GCC version?
> 4.  It's odd that the default 'make' no longer means 'make all' and 'make' on its own doesn't produce
> a JDK image to use.  This will be confusing for newcomers who miss that important 'all' word or people
> like me who go by the usual presumption that the default argument to make is 'all', but appears to have
> been subverted here.
I can agree that it's a bit odd. It was done this way early on to reduce 
build times for the average developer who usually isn't interested in 
images and certainly not docs. For openjdk, we have "default" which 
translates to "jdk" and "all" which translates to "images docs". One 
could argue that the developer wanting to save time could type "make 
jdk" instead, but then, the developer wanting save time probably just 
wants to type "make".

The root Makefile is still the old build, but the first thing it does is 
calling NewMakefile.gmk unless NEWBUILD=false is set. When we finally 
remove the old build system, NewMakefile.gmk will replace Makefile in 
the root.
> 5.  The final image produces:
> openjdk version "1.8.0-internal"
> from -version.  I can't remember whether or not the internal was there before and we suppressed it in IcedTea,
> but we've definitely always had 'java version' and not having this will break numerous applications (possibly
> including the JDK build, as I know at least the old one used to check the version).
AFAIK this is the same with the old build. We have certainly not tried 
to change it. If you need additional configure logic to change or remove 
that string that isn't already there, that shouldn't be a problem.


More information about the build-dev mailing list