Issue with detecting if it's a platform context

[mark.reinhold at oracle.com]

> Date: Thu, 20 May 2010 12:40:29 -0700
> From: mandy.chung at oracle.com

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

That's fine.

>                                                                        I leave
> the isPlatformContext as it is as you probably have made some change in the
> config/context.

Yes; isPlatformContext is used elsewhere, at least for now.

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

Yes.

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

The resolver fix for optional modules needs adjustment.  You've got
the right idea in moving the Modifier.OPTIONAL test further down in
the resolve(int, Choice) method.  Placing it at the end of the method,
however, means that the resolver will consider remote, not-yet-installed
modules as candidates for satisfying optional dependences, and that's
not the right thing.  The OPTIONAL test should be placed just before the
section that checks remote repositories.  I'd also change the comment to
say "Don't fail; it's just an optional dependence".

Oh, and please extend the _Configurator test to check that optional
dependences now work correctly.  There are a couple of commented-out
tests which can serve as a starting point.

- Mark