javac issues with proposed API

[Jonathan Gibbons]

I agree with keeping the ModuleLibrary abstraction simple, as an API 
onto the bits on disk,
out of which we can build such higher abstractions as necessary.  In 
what I've been considering
so far, I think you need the general ability to get a set of ModuleInfo 
for any given
module name.   This could either be done by getting a set of ModuleIds 
and then being able
to map any ModuleId to its ModuleInfo, or by getting the set of 
ModuleInfo directly.
Being able to filter the set may be an optional but useful performance 
tweak.

-- Jon




Mark Reinhold wrote:
>> 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
>