Request for Review: Java SE 8 Compact Profiles
erik.joelsson at oracle.com
Wed Jan 9 13:04:09 UTC 2013
Looks good to me now.
On 2013-01-08 09:02, David Holmes wrote:
> I have updated webrevs:
> I've addressed the minor suggestions that have been given by Kelly and
> Erik eg:
> - better comment on the jarreorder change (and a CR to follow up)
> - the de-beaned classes now go to the images output directory not JDK
> (thanks to Alan)
> The major change is that I no longer use the profiles files to define
> the contents of a full JRE. So the file lists that had moved to
> Profiles.gmk have moved back to Images.gmk and are not used when
> creating a profile image. This means that the only change for
> non-profiles builds (outside the Version.java modifications) is in how
> the list of JARS to build is put together.
> I've also integrated this with latest jdk8/build changes including all
> the UNSIGNED jar updates - which fit in quite nicely.
> One thing to note that I didn't mention originally, the change to
> makefiles/GensrcX11Wrappers.gmk is a hack to make cross-compilation
> work. The real fix is languishing in the build-infra forest and needs
> to get moved into jdk8/build ASAP.
> On 4/01/2013 1:35 PM, David Holmes wrote:
>> Hi Erik,
>> On 4/01/2013 12:15 AM, Erik Joelsson wrote:
>>> Sorry for taking so long responding to this. Here are my thoughts on
>> Thanks for getting to it, I know you have a lot on your plate at the
>>> 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
>>> 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
>>> 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
>>> 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.)
>>> 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:
>>>> 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