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