Path-based configurations, catalogs, and multiple roots

Jonathan Gibbons Jonathan.Gibbons at Sun.COM
Fri Nov 6 09:42:16 PST 2009


Just checking in advance:

-L ...

What should that identify? A single file system item?  A path (list of 
file system items)? Any constraints (extension? directory?)

-- Jon



Mark Reinhold wrote:
> I've finished and pushed a first cut of the big refactoring and
> elaboration required for Jon's javac work.  High-level summary:
>
>   - Refactored the Resolver class into four classes:
>
>       Resolver       - Module-version resolution (phase 1)
>       ContextBuilder - Context construction (2)
>       Linker         - Identify local and remote suppliers (3 & 4)
>       Configurator   - Ties them all together
>
>   - Introduced a PathContext class for path-based configurations,
>     which is what the compiler will use, along with a PathLinker
>     for path-based versions of phases 3 and 4 and a second entry
>     point in Configurator for creating path-based Configurations.
>
>   - Generalized the Library class into a new Catalog class, which
>     is what the compiler should extend in order to hook up to the
>     module system.
>
>   - Generalized the Resolver to start from multiple ModuleIdQuery
>     roots, rather than just one.
>
> In order to hook up to Jigsaw the compiler should define its own
> subclass of the Catalog class:
>
>     class CompilerCatalog extends Catalog {
>         Catalog parent() {
>             // Return Library.openSystemLibrary(), or else the result
>             // of opening whatever library was specified with -L on
>             // the javac command line
>         }
>         // Define remaining abstract methods in Catalog:
>         //   String name()
>         //   void gatherLocalModuleIds(String moduleName,
>         //                             Set<ModuleId> mids)
>         //   ModuleInfo readLocalModuleInfo(ModuleId mid)
>     }
>
> Then it can do something like this:
>
>     Catalog cat = new CompilerCatalog(...);
>     Configuration<PathContext> cf
>         = Configurator.configurePaths(cat, rootModuleIdQueries);
>
> After which:
>
>     - cf.roots() is the set of root ModuleIds,
>
>     - cf.contexts() is the set of configured PathContexts,
>
>     - cf.getContext gets a context by name,
>
>     - cf.findContextForModuleName finds a context for a module
>       name, returning null if not found, and
>
>     - cf.getContextForModuleName gets a context for a module
>       name, throwing IllegalArgumentException if not found.
>
> For each PathContext pcx in cf.contexts():
>
>     - pcx.localPath() is a list of the ids of the modules local
>       to this context, in search order (a "micro class path"), and
>
>     - pcx.remoteContexts() is a set of the other contexts which
>       supply definitions to this context.
>
> If a type is not found in the local path of the current context then
> search the local paths (in their search order) of the remote contexts
> (in any order).  If a type is defined in more than one remote context
> then an error should be reported.
>
> Updated javadoc: http://cr.openjdk.java.net/~mr/jigsaw/api
>
> - Mark
>   




More information about the jigsaw-dev mailing list