Issue with detecting if it's a platform context

[Mandy Chung]

Mark,

I made a couple of minor changes in jigsaw for the reorg of the platform 
modules [1].  This webrev includes all org.openjdk.jigsaw.* class 
changes separating from the classanalyzer and modules.config change.

   http://cr.openjdk.java.net/~mchung/jigsaw/platform-modules/jigsaw/

Two problems:
1. All jdk modules now have the "jdk." and "sun." prefix.  Only some of 
them need to be loaded by the BootLoader (i.e. classes from rt.jar and 
those are connected with the jdk.boot module (i.e. requires local jdk.boot).

The Platform.isPlatformModuleName method currently uses the prefix of 
the module names to determine if it's a platform module and the platform 
modules will be loaded by BootLoader.  For example, jdk.jps is a tool 
that requires jdk.base and jdk.jvmstat and jdk.jps and jdk.jvmstat 
modules can be loaded by the module loader.  This check should be 
revised.  In theory, it should be okay to continue using BootLoader to 
load all jdk.* modules.  This uncovers a problem with the current 
temporary solution that the BootLoader delegates to the VM built-in 
loader to loader classes.  The VM has an optimization to load a class 
directly in the VM (skipping calling out to Java) if the initiating 
class loader is null.  When a class sun.tools.jps.Jps in the jdk.jps 
module is loaded by the null loader , sun.tools.jps.Jps requests to 
resolve a class in jdk.jvmstat and thus the VM attempts to load the 
jvmstat class directly using the null loader.  Since jdk.jvmstat and 
jdk.jps are in two different contexts and jdk.jvmstat module is not 
loaded yet, the VM fails to find the jvmstat class.

I added a Platform.isBootContext method and the LoaderPool will create a 
BootLoader only if it's a boot context (yet another temporary 
solution).   Since this is evolving, we will implement the long-term 
solution for the detection if it's a platform context and loading of 
platform modules.  I leave the isPlatformContext as it is as you 
probably have made some change in the config/context.

Does this approach sound reasonable (BootLoader only loads modules that 
strongly connected with jdk.boot)?

2. The optional modules are not linked and recorded in the config.  The 
fix is to skip the optional modules in the Resolver only if it doesn't 
exist.

Thanks
Mandy

[1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2010-May/000944.html