javac issues with proposed API

[Mark Reinhold]

> Date: Thu, 12 Feb 2009 16:28:55 -0800
> From: jonathan.gibbons at sun.com

> I am uncovering issues with the proposed new API as it pertains to javac.
> Some of this we sensed before, but we can start to be more specific.
> 
> 1. ModuleInfo
> 
> ModuleInfo extends java.lang.reflect.AnnotatedElement. While this is
> acceptable for runtime access, it is not acceptable for javac. Rightly
> or wrongly, annotations potentially involve Class<?> items, and javac
> does not want to load any classes into any class loader in order to access
> a ModuleInfo which might have such an annotation.  This is why the
> JSR 269 API mirrors rather than reuses the java.lang.reflect hierarchy.

Good point.  I don't see a fundamental reason why ModuleInfo needs to
implement AnnotatedElement; java.lang.reflect.Module can do that on its
own.  I'll change this in my prototype.

ModuleInfo, by the way, is now an interface; we'll see if that sticks.

> 2. ModuleLibrary.findModule
> 
> This is commented as "for javac", but javac is going to need something
> more. The method seems to assume that the module library has complete
> knowledge of the available modules, which may not be true if some
> module-info files are being provided on the command line. This is where
> we need the beginning of the "module info graph" we have talked about
> on and off.
> 
> Either we need to be able to query the module library to get candidate
> module-info files for any given module name, so that we can build the
> module info graph externally to the library, or we will need to pass in to
> the module library information about modules being compiled so that the
> library can take it into account as part of the findModule call.  In effect,
> this latter case corresponds to reifying the module info graph inside the
> module library implementation.

I'd prefer to keep the ModuleLibrary abstraction simple, leaving graph
construction and consideration of modules named on a tool's command line
to higher levels.

> In either case, javac will have to communicate with the module library
> using some sort of module info, which ties this issue to the earlier issue
> about ModuleInfo.

Do you really mean ModuleInfos, or are ModuleIds sufficient?  If what you
want is

    public ModuleInfo
        findModuleInfo(ModuleQuery mq, AgePolicy ap, FormPolicy fp,
                       ModuleInfoFilter midf);

then that can be arranged.  Such a method could, alternatively, return a
Set<ModuleInfo> if you'd prefer that.

> As a general observation, you could draw an analogy with the need for
> the JigsawModuleClassLoader.defineClass(Module , ...) method.  That is
> the means by which the runtime becomes aware of new modules in the
> system, such that ModuleLibrary.findModule can give the correct response.
> There is currently no such equivalent call for the compiler to use.

Good analogy, but I still think that method belongs on a higher-level
ModuleInfoGraph (or some such) abstraction.

- Mark