RFR: Post-modules and module images build in new buildsystem

[Erik Joelsson]

On 2013-03-21 14:02, Alan Bateman wrote:
> On 21/03/2013 10:58, Erik Joelsson wrote:
>> I have converted the post modularization step from the old build 
>> system to the new build system in jigsaw.
>>
>> http://cr.openjdk.java.net/~erikj/jigsaw/webrev.post-modules.01/
>>
>> The images target will now produce the same module and base images as 
>> the old build. The legacy images can still be built using the new 
>> target "legacy-images". All the post modularization steps happen in 
>> the target "post-modules". I have verified the build manually on 
>> linux, windows, solaris and mac and also run it successfully through 
>> jprt (with a limited set of tests). I've compared the contents of the 
>> built modules with the old build (see below for differences).
> This is great as we need to get moved off the old build system - thank 
> you!
>
> I haven't looked through all the changes yet but it may be that we 
> just bring these in now so that we can switch to the new build. Mandy 
> - do you agree? Mandy might wonder about the class analyzer skipping 
> _the files but I think that is fine for now.
I'm open to suggestions here, but in the new build, files starting with 
_the are touch files and similar, just handling book keeping for make, 
that shouldn't be put in the product.
>
> Do you forsee any issues or complications with future merges? It's 
> possible we might be using post-modules for some time.
>
I'm trying my best to keep changes small to not complicate merges 
unnecessarily, but I suspect some of this could get hairy down the road.

/Erik
>>
>> Known issues:
>>
>> * Fastdebug fails, both in old and new build, when running the newly 
>> built rmic at the end of the jdk target.
> I think that's okay as in general, we need to get the rmic usage fixed 
> in the build anyway.
>
>> * No fast incremental support in the post-modules or images targets. 
>> Trying to fix that instead of working on a real modular build seems 
>> like a waste of time.
> I agree.
>
>> * The following differences with the old build have been observed:
>>   * Debug info files (*.diz) from hotspot, but not from the jdk, are 
>> included in the modules in the old build. I chose to treat all *.diz 
>> files the same and chose to exclude them for now.
> We haven't fully explored debug modules so this will need to be 
> re-examined anyway. A possible approach is that there is a -debug 
> module for each JDK module with native code.
>
>>   * The swingbeans (dt.jar) are generated during images creation in 
>> the old build, but in the new build those classes are compiled with 
>> the rest, making them available to the modularization. This makes 
>> them present in the jdk.desktop module in the new build.
> This is okay too as this needs to be re-examined and dt.jar eliminated.
>
>>   * Similarly META-INF/services/com.sun.tools.xjc.Plugin is generated 
>> earlier in the new build and is now present in jdk.tools.jaxws.
> It's good to have this fixed. We have the "provides service" right and 
> not clear, without digging, why the legacy configuration file was 
> missed in the old build.
>
>>   * sun/text/resources/th/BreakIteratorRules_th.class is showing up 
>> in sun.localedata.
> That seems right.
>
> -Alan.