Hello,
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
profiles repos.
/Erik
On 2012-12-21 07:18, David Holmes wrote:
The Java SE 8 Compact Profiles:
http://openjdk.java.net/jeps/161
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
(profile-includes.txt)
- which packages/classes are in rt.jar/resources.jar
(profile-rtjar-includes.txt)
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.
webrevs:
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
responses.
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.
Thanks,
David Holmes
