Use jdk-module-image as boot jdk (modules build + SKIP_BOOT_CYCLE=false)

[Jonathan Gibbons]

Kelly O'Hair wrote:
>
> On Mar 31, 2010, at 4:15 PM, Mandy Chung wrote:
>
>> Kelly, Alan, Karen,
>>
>> Jon and I have been discussing the testing for the new javac change 
>> and modules image.   Building JDK itself is one the the simplest and 
>> most effective tests that Jon typically uses to validate javac 
>> changes (by building JDK with SKIP_BOOT_CYCLE=false).
>>
>> Currently, "make SKIP_BOOT_CYCLE=false all" will first build a legacy 
>> jdk image and set it as the ALT_BOOTDIR to rebuild the jdk.  As Jon 
>> suggests, for modules build, SKIP_BOOT_CYCLE=false should use the 
>> jdk-module-image as the ALT_BOOTDIR to rebuild the jdk modules.
>>
>> This fix makes changes in the top level repo, jdk, hotspot, and corba 
>> repository as follows:
>>
>> 1. 
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/top-repo
>>
>>  - Set JDK_IMAGE_NAME to j2sdk-image for legacy image build or
>>    jdk-module-image for modules image build.
>>  - not to create j2sdk-image for modules build (a bug Jon reported)
>>
>> 2. http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/jdk
>>
>>  - minor cleanup such as using absolute path of the modules directory
>>  - Add OTHER_JAVAHFLAGS that will be used to set classpath
>>    to look up pkcs11 and mscapi classes from a temp directory
>>  - Add the logics to import from the modules instead of rt.jar and 
>> resources.jar
>>    Eventually we should import modules instead of copying in the 
>> classes.
>>  - eliminate the second build of the make/modules/Makefile
>>    Modules.gmk to invoke make/modules/Makefile build was needed
>>    so as to make sure the jdk modules in the "modules" directory
>>    are up-to-date.  However, this is only needed for jdk developers who
>>    is doing incremental builds after the jdk is modularized.  Like 
>> the images
>>    build taking the current content from the "classes" directory, it 
>> will just
>>    take the current content in the "modules" directory to build the 
>> modules
>>    images.  For incremental builds, the jdk developers need to make
>>    sure the jdk modules are up-to-date.  I'll also come up with some
>>    better way to make our life easier in updating the jdk-module-image.
>>
>> 3. 
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/corba/
>>
>>   - corba, for some reason, links with libjvm.so and libjava.so.      
>> The fix is to include the new library path of the jdk-module-image.
>>     This will need to change when we move the native libraries to
>>     the module content.
>>
>> 4. 
>> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/
>>
>>   - The makefile checks if the tools.jar exists for building SA.  In 
>> the modular
>>     world, it no longer has the tools.jar.
>>
>
> In both:
>
> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/linux/vm/os_linux.cpp.sdiff.html 
>
>
> http://cr.openjdk.java.net/~mchung/jigsaw/bootdir-modules-image/hotspot/src/os/solaris/vm/os_solaris.cpp.sdiff.html 
>
>
> I'm concerned that the 'buf' character array might overflow.
> Just asking, I didn;t have the time to walk through all of this.
>
>> An open issue:  the jaxp and jaxws build may download the source 
>> bundles.
>> With using jdk-module-image as the boot jdk, jaxp and jaxws build will
>> set ANT_JAVA_HOME to the jdk-module-image that will fail the download
>> as security/crypto support in the modules image is an open issue.
>>
>> Caused by: java.lang.SecurityException: Can not initialize 
>> cryptographic mechanism^M
>>       at javax.crypto.JceSecurity.<clinit>(JceSecurity.java:86)^M
>>
>> I'd like to push this set of changes in jigsaw althought there is the 
>> jaxp and jaxws
>> bundle download issue.  As long as there is a local downloaded copy 
>> of the
>> jaxp/jaxws bundle, it will build fine.
>
> Inside SWAN, it should find the jaxp/jaxws bundles in 
> /java/devtools/share/jdk7-drops,
> and with JPRT, I think it should find these copies from my 
> /java/devtools copy at
> /opt/jprt/slashjava/devtools/share/jdk7-drops
>
> How these source drop bundles are found is a continued issue for me, 
> and when it
> goes wrong, like Rama found out recently, and the ant script trys to 
> download from
> some foreign http: download site, the ant scripts seem to seize up on 
> the JPRT clients
> and all hell breaks loose. :^(    Just a warning, but your builds 
> should be ok.
>
> -kto
>
>>
>> Thanks
>> Mandy
>


Kelly,

Would it possible to specify that the makefiles should never do this 
sort of downloading?  If the user believes that the build should have 
access to locally installed bundles, it would be better for the makefile 
to fail, reporting that the assumption is incorrect, instead of having 
the makefiles struggle gamely on, trying to find the bundles wherever it 
can.

I'm not saying it should never attempt to locate them; I'm just 
suggesting it should be possible to disable this behavior.

-- Jon