Request for Review: Java SE 8 Compact Profiles
erik.joelsson at oracle.com
Thu Jan 3 14:15:45 UTC 2013
Sorry for taking so long responding to this. Here are my thoughts on it.
I like the idea of defined sets of files for each type of image. The
current Images.gmk works with excludes, because that's how it used to
work, but I would be happy to change to an include based process. Then
we wouldn't need to convert include lists to exclude lists. I'm not
saying this must happen at this point though.
I would prefer if java class generation, compilation and also class
patching would not be happening inside CreateJars.gmk. Especially since
they emit files into the jdk output dir. For Version.java, I would break
it out of GensrcMisc.gmk to GensrcVersion.gmk and handle all the
variants of Version.java there. I would do the compilation in
CompileJavaClasses.gmk. For the patching, this would be a new concept
and has to happen after compilation and not in the same make invocation.
Leaving patching in images could be ok even if I would prefer not to.
But if it stays, the output needs to be in images and not jdk. The
drawback of all this is of course that these things will get built
regardless of if you intend to build profiles or not, but I don't think
they take long enough to matter. If you don't agree, then please at
least move the output to images.
For the images:: rule in common/makefiles/Main.gmk, do you actually need
to add things there that don't fit better in a closed version of
jdk/makefiles/BuildJdk.gmk? I can't find any use of it in the current
On 2012-12-21 07:18, David Holmes wrote:
> The Java SE 8 Compact Profiles:
> provides for subsetting of the Java SE 8 platform. While the
> specification covers the platform, we are only providing a reference
> implementation on Linux x86 at this time.
> This work is covered by a number of CRs due to there being a need for
> a number of CC requests to modifying existing specifications
> 8004265: Add build support for Compact Profiles
> 8004502: Compact Profiles contents
> 8003255: (profiles) Update JAR file specification to support profiles
> 8003256: (profiles) Add support for profile identification
> 8004931: add/removePropertyChangeListener should not exist in subset
> Profiles of Java SE
> The changes primarily involve the build, as you would imagine, the
> compact profiles define:
> - which files (binaries, jars, native libs) are in a JRE
> - which packages/classes are in rt.jar/resources.jar
> But there are additional source changes:
> - to support reporting the profile name as part of version information
> - to test the versioning and tool changes
> and also changes to java, javac and jar so that you can indicate which
> profile you are targeting, and have javac make sure you don't use an
> API that won't be present; and which profile you need to run (listed
> in your executable jar) so the launcher can reject it if it isn't the
> right profile. The launcher and jar changes are included in this
> webrev, while the javac changes are being integrated separately (plus
> some related javadoc changes).
> Only the new build system is supported for building profiles.
> top-level repo: http://cr.openjdk.java.net/~dholmes/8004265/webrev.top/
> The main change is to simply add profiles and profiles-only as top
> level make targets (similar to images). There is also a change to
> remove the hardcoded version information (though this may be handled
> by a separate CR).
> jdk repo: http://cr.openjdk.java.net/~dholmes/8004265/webrev.jdk/
> The overall build changes expand on the pre-existing definitions
> whereby a JRE is a JDK with things take out. So a compact JRE is then
> a JRE with additional things taken out. There are three compact
> profiles (compact1 being the smallest) and a full JRE. For internal
> build purposes these are referred to as PROFILE_1 etc, with a full JRE
> being represented by PROFILE_4 when needed. The specification for
> profiles indicates what is included in each profile, but the build
> rules then invert this to obtain a set of exclusions for each profile:
> the exclusions of a given profile is the set of inclusions of all
> larger profiles and the JRE (and of course the JDK).
> Please note I only expect build folks to look at build changes and
> core-libs to look at src/test changes (all of which have been
> developed by Alan Bateman) and there is no need to cross-post your
> Like many I am about to head for Xmas break but I will continue to
> monitor email and deal with changes as needed. This is needed for M6
> and we need to be ready to push in early January.
> David Holmes
More information about the build-dev