Refactoring the Library API
Jonathan.Gibbons at Sun.COM
Wed May 6 09:50:25 PDT 2009
Thanks for the update.
On the javac side, javac is at the point where it now computes
a) the set of "root modules" (plural) for this compilation. This is
defined as the set of modules for all compilation units on the command
b) the set of all modules on the various compilation paths, meaning
is the active combination of sourcepath, classpath and modulepath.
This information is all available in javac's representation of module-
I fully expect to have to convert that info into whatever module-info
is required by Jigsaw.
--Note, I'll just convert it while accessing Jigsaw; I do not expect
javac's internal representation for a number of design and
--Note: annotations cannot be evaluated and made available at this
stage in the compile pipeline.
javac's expectation is that after interacting with Jigsaw it will be
determine one or perhaps both of the following:
i) a map identifying the visible modules for each module.
ii) an ordering of the values in that map, such that the modules define
a new sort of path to be used internally in javac.
With a call back system and sufficient abstraction, it is possible
could determine the set of classes or packages in each module. However,
that would be such a startup overhead for the compiler that while
possible, I don't think it would be a good design choice for Jigsaw.
be much better, IMO, if all the information necessary to evaluate a
dependency graph was directly available in the module-info files
On May 6, 2009, at 9:19 AM, Mark Reinhold wrote:
> The current Library class is definitely file-centric, and I fully
> that we'll need to refactor it, possibly dramatically, in order to
> up javac.
> The resolver currently needs just three of the Library methods:
> - List<ModuleId> findModuleIds(String moduleName)
> - ModuleInfo readModuleInfo(ModuleId mid)
> - List<String> listClasses(ModuleId mid, boolean all)
> My understanding from our previous discussions is that the first two
> easy to implement in javac. The last, as you point out, is
> The Library.listClasses method is invoked only in phases 3 and 4 of
> resolution algorithm. It won't be used by the alternate compile-time
> version of phase 3 (still to be written). It's used in phase 4 only
> compute the set of packages defined in, and exported from, a context.
> The compiler can't provide a list of packages up-front either, so it
> seems that we'll also need an alternate version of phase 4 which, like
> the alternate phase 3, computes a compile-time approximation of the
> eventual run-time result. That approximation will most likely be, for
> each context, its set of remote supplier contexts; finding a class
> involve walking the context graph.
> The eventual minimal "Library" API can declare just the
> findModuleIds and
> readModuleInfo methods. It probably makes sense to have that be an
> interface so that you can implement whatever JavaFileManager
> plumbing is
> needed in the compiler. We should think of a better name for it, too;
> maybe "ModuleInfoSet" or some such?
> These are nontrivial changes, and the elastic on the stretch goal
> still have snapped, but at least we're making progress.
> - Mark
More information about the jigsaw-dev