[prev in list] [next in list] [prev in thread] [next in thread] 

List:       openjdk-jigsaw-dev
Subject:    jdk modules running on jigsaw!
From:       Mandy.Chung () Sun ! COM (Mandy Chung)
Date:       2010-01-28 1:36:15
Message-ID: 4B60EA0F.7090801 () Sun ! com
[Download RAW message or body]

Status update:

I now have the jdk modules installed and running.  9 of the 10 jigsaw 
jtreg tests passed on linux.  I'm lookiing into the library.sh failure. 
  I need to fix the jigsaw jtreg tests to run on other platforms.  Also, 
I'm running the jdk jtreg tests (in legacy mode) with the full jdk 
module image and so far so good.

Here is the summary of what I have done.

1.  jdk.boot at 7-ea is hardcoded in the VM bootclasspath as the current 
workaround for bootstrapping.   I added a jdk.boot  module for now.

2. modules.config and modules.group define how the "private" jdk modules 
are defined.   The resulting modules are private and they only permit 
the public jdk modules to use.   The public jdk modules don't have any 
permits rule.

When a module has a local dependency on another module, the requesting 
module would need to be explicitly permitted in its dependence which 
would become a private module since any other module not specified in 
its permits rule can't depend on it.

I currently name the private jdk modules to start with "sun."  prefix 
whereas the names of the public jdk modules start with the "jdk." 
prefix.  E.g. sun.logging is the private module and jdk.logging is the 
public module.

2. The "modules" make target will create 4 new images:
     jdk-base-image, jre-base-image, jdk-module-image and jre-module-image

I currently put them under the <outputdir> directory.  jre-base-image 
contains the base module.  jdk-base-image contains the base module and 
the javac modules + its dependencies).

jdk-module-image is the full jdk image with all jdk modules installed 
whereas jre-module-image is the full jre image minus the tools installed.

3. The jdk tools except javac are converted to run in the module mode. 
I added a temporary solution in java.c to determine if the java home is 
a module image and set it to run module mode.

When javac running in module mode, it doesn't find the jdk modules other 
than the ones in its context and so compilation will fail if the source 
file imports classes in other modules.   I believe Jon already has the 
change ready in javac to use the jigsaw module resolver.   Just waiting 
for my change to go in.

4. Legacy mode - I also modified the launcher to set the bootclasspath 
to the jigsaw module library (i.e. lib/modules/*/7-ea/classes + 
lib/modules/*/7-ea/resources) if the java home is a module image.

5.  One open question is what the default platform module should be.

jdk at 7-ea is the current default platform module and I assume it's full 
jdk.  The jdk-base-image only has jdk.base module installed.  Unless the 
module-info of an application requires jdk.base at 7-ea, the default 
platform module will be added to its dependence.  It means that an 
application whose module-info compiled with the default platform module 
can't be deployed on the jdk-base-image since jdk at 7-ea is not installed 
even if it doesn't depend on any other jdk module.  I think making the 
default to the jdk.base module would help the developers be cautious of 
what jdk modules their module should require and think through this kind 
of deployment issue during development.

I have a whole day meeting tomorrow.  I hope that I can clean up the 
changes and get the webrev ready by next Monday.

Mandy

[prev in list] [next in list] [prev in thread] [next in thread]