Refactoring the Library API
mr at sun.com
Thu May 7 12:50:36 PDT 2009
> 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
> 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.
> 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.
> 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.
More information about the jigsaw-dev