Request for Review: Java SE 8 Compact Profiles

[David Holmes]

I have updated webrevs:

http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.top/

http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.jdk/

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.

Thanks,
David

On 4/01/2013 1:35 PM, David Holmes wrote:
> 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
>>>