Request for Review: Java SE 8 Compact Profiles

[Jonathan Gibbons]

Note that the changes for profiles to javac and CreateSymbols currently 
consume directly the file makefiles/profile-rtjar-includes.txt. If we 
change how images are assembled, going to include lists rather than 
exclude lists, we we have to rework the corresponding 
javac/CreateSymbols changes. I'm not saying we shouldn't do the change; 
I'm just saying we need to take that into account.  To mitigate that, I 
half-anticipated this, and the code is designed to support multiple 
input file formats, so coping with another format should be relatively 
straightforward.

-- Jon


On 01/03/2013 06:15 AM, Erik Joelsson wrote:
> 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
>>