Request for Review: Java SE 8 Compact Profiles

[David Holmes]

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
>>