Hi Erik,
On 4/01/2013 12:15 AM, Erik Joelsson wrote:
Hello,
Sorry for taking so long responding to this. Here are my thoughts on
it.
Thanks for getting to it, I know you have a lot on your plate at the
moment.
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.
It will definitely not happen at this point. :) There is simply no time
to redesign everything. I have an update in the pipeline that constrains
my changes further so that they do not affect which files are
included/excluded in a full JRE. This was needed because the existing
lists only work for linux/solaris at this point (but unsupported on
solaris) and failed to produce correct JREs on windows and OSX due to
difference in the path locations. I hope to post an updated webrev later
today, or else over the weekend.
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.
I may have to limit this to the "at least move the output to images" -
at least for now - though I need all .class files in one place to
package them into a jar file. Given the way the build is defined to
build the world then package up jars and images based on the image
contents, I was constraining myself to only affecting those two aspects.
As you indicated to handle this in CompileJavaClasses the whole profile
notion has to propagate through the build system into areas that really
don't care about profiles or 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.
It is used in the jdk/make/closed repo for other build targets based on
Profiles (ie the SE embedded profile images). I'm not sure how I could
move it though as if it were in a closed BuildJdk.gmk then it would need
to augment an open BuildJdk.gmk target - and hence the :: would simply
move from one place to another. If this were only for embedded it might
be doable through a new target, but there are other factors at play.
(And in many ways the :: is a much simpler way of augmenting
pre-existing targets.)
Thanks,
David
/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
