Refactoring the Library API

[Jonathan Gibbons]

Mark,

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  
effectively
defined as the set of modules for all compilation units on the command  
line.

b) the set of all modules on the various compilation paths, meaning  
whatever
is the active combination of sourcepath, classpath and modulepath.

This information is all available in javac's representation of module- 
info.
I fully expect to have to convert that info into whatever module-info  
form
is required by Jigsaw.
--Note, I'll just convert it while accessing Jigsaw; I do not expect  
to change
javac's internal representation for a number of design and  
bootstrapping reasons.
--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  
able to
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  
that javac
could determine the set of classes or packages in each module. However,
that would be such a startup overhead for the compiler that while  
technically
possible, I don't think it would be a good design choice for Jigsaw.  
It would
be much better, IMO, if all the information necessary to evaluate a  
module
dependency graph was directly available in the module-info files  
themselves.

-- Jon


On May 6, 2009, at 9:19 AM, Mark Reinhold wrote:

> The current Library class is definitely file-centric, and I fully  
> expect
> that we'll need to refactor it, possibly dramatically, in order to  
> hook
> 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  
> are
> easy to implement in javac.  The last, as you point out, is  
> impossible.
>
> The Library.listClasses method is invoked only in phases 3 and 4 of  
> the
> 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  
> to
> 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  
> will
> 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  
> might
> still have snapped, but at least we're making progress.
>
> - Mark