hooking javac up to the module library
Mark Reinhold
mr at sun.com
Tue Oct 27 13:28:39 PDT 2009
> 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
More information about the jigsaw-dev
mailing list