hooking javac up to the module library

[Mark Reinhold]

> Date: Wed, 21 Oct 2009 13:51:27 -0700
> From: jonathan.gibbons at sun.com

> When you get around to refactoring Resolver, here are some considerations from
> javac that it might help to be aware of.
> 
> 1) javac needs to be able to resolve multiple roots together, not just one.
> The set of roots is derived from all the files on the command line.
> 
> 2) javac has its own collection of modules to take into account, in addition to
> any modules in the library. These modules come from the command line and from
> the module path given on the command line.
> 
> 3) for each module, javac needs to be able to determine the corresponding
> ordered set of visible modules.

Thanks.  Here's what I'm thinking.

For (1), add a second static Resolver.create method which takes a
collection of root ModuleIdQuery objects.  Straightforward.

For (2), as discussed some months ago, define a much narrower form of
the Library abstract class which declares just the methods needed by the
(compile-time) resolver, something like:

    List<ModuleId> findModuleIds(String moduleName);
    ModuleInfo findModuleInfo(ModuleId mid);

You can then extend this with an adaptor class which hooks up to javac's
internal plumbing.

For (3), refactor the Resolver, Configuration, and Context classes so
that both compile-time and install-time configurations can be computed.
A compile-time configuration would have a set of contexts and a map from
module names to contexts.  Each context would have a list of module ids,
ordered according to their visibility as determined by the resolver, for
use by javac in its class-path-like lookup machinery.

Make sense?

- Mark