Refactoring the Library API

[Mark Reinhold]

> Date: Wed, 06 May 2009 09:50:25 -0700
> From: jonathan.gibbons at sun.com

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

If you can implement the ModuleInfo interface then no conversion should
be necessary, but I can believe there might be reasons why you can't or
don't want to do that.

> --Note: annotations cannot be evaluated and made available at this
> stage in the compile pipeline.

Understood.

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

Yes, this aligns with what I've been thinking.  In fact it might be
possible for me to hack up a simple but good-enough implementation fairly
quickly.  I'll look at that as soon as I finish rewhacking the launcher
to understand modules.

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

Agreed.

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

What we have now appears to be enough to compute a decent compile-time
approximation to the run-time context graph.  We do, however, need some
practical experience with it.

If we need a better approximation, then I see only two ways to add actual
package information to module-info class files:

  - Have the compiler record member packages in module-info.class.

  - Extend the module compilation-unit syntax and require developers
    to declare member packages.

I see lots of problems with both alternatives.  Let's hope that the
simple approximation works well enough.

- Mark