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

[Kelly O'Hair]

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