Request for Review: Java SE 8 Compact Profiles

Wed Jan 9 03:06:24 UTC 2013

On 9/01/2013 8:23 AM, Kelly O'Hair wrote:
>
> On Jan 8, 2013, at 12:02 AM, David Holmes wrote:
>
>> I have updated webrevs:
>>
>> http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.top/
>>
>> http://cr.openjdk.java.net/~dholmes/8004265.v2/webrev.jdk/
>
> They look ok to me.

Thanks.

>>
>> 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.
>
> Is this the Issue:
>     JDK-8003958 build-infra: Cross-compilation of sizers utility has been broken
>
> ???

Yes.

David
-----

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