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

[Kelly O'Hair]

On Apr 1, 2010, at 10:14 AM, Jonathan Gibbons wrote:

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

At this point, I tend to agree. I will try and look into this.

-kto

>
> -- Jon