Module-system requirements

[Remi Forax]

On 03/11/2015 02:23 PM, David M. Lloyd wrote:
> On 03/09/2015 03:56 PM, mark.reinhold at oracle.com wrote:
>> 2015/2/15 10:12 -0800, Tim Boudreau <niftiness at gmail.com>:
>>> mark.reinhold at oracle.com:
>>>> As I wrote in my reply to David, I think resources (in the traditional
>>>> ClassLoader::getResource sense) should be treated as being strictly
>>>> internal to modules.  ...
>>>
>>> There's a common case that I'd like to understand how you solve 
>>> without at
>>> least META-INF or its equivalent visible to other modules: It's fairly
>>> common to see applications that dynamically compose things they find 
>>> on the
>>> classpath.  Spring and a few other things accomplish this through
>>> classpath-scanning, which is a fairly horrible pattern (you can wind up
>>> visiting every class on the classpath, or a large subset, just to 
>>> look for
>>> a runtime annotation that is not there for the vast majority).
>>>
>>> An alternative approach I've used many times, which I think a few
>>> frameworks do as well (dagger?) is:  Write an annotation processor that
>>> generates a flat file in META-INF that lists the classes that have the
>>> annotation in question;  runtime code loads all such files on the 
>>> classpath
>>> and uses that to initialize things that should be present at 
>>> runtime.  It's
>>> really the same pattern as ServiceLoader.
>>>
>>> Is it safe to assume that, whatever happens, that approach will 
>>> still work,
>>> whether by special-casing META-INF/** or some equivalent?
>>
>> For JAR files on the legacy class path that approach will, of course,
>> continue to work.
>>
>> I don't expect actual modules to be on the class path (about which more
>> below), which raises a question: Will a framework such as Spring need to
>> discover the classes bearing certain annotations in modules that aren't
>> yet configured and loaded, or in loaded modules, or both?  In the former
>> case it would inspect module artifacts, while in the latter it would
>> inspect some reflective run-time representation of a loaded module, 
>> since
>> the original module artifact might not be available.
>>
>> Either way, this use case suggests a new requirement for the Development
>> section:
>>
>>    - _Annotation digests_ --- When packaging a module into an 
>> artifact it
>>      must be possible to augment its definition with a summary of all of
>>      the type- and package-level annotations that are present in the
>>      module, together with an indication of the types and packages to
>>      which each annotation applies.  This digest must be easily readable
>>      from module artifacts, and at run time those parts of it related to
>>      annotations retained for run time must be available through an
>>      appropriate reflective API.
>>
>> Comments?
>
> If we're looking to extend this into the domain of Java EE annotations 
> (for example), we'd also have to add method and field annotations to 
> the list.  And SE 8 type annotations might add some strange color to 
> this as well.

Why do that when packaging a module and not when you install a module ?

I really think we need a way to do some actions when modules are installed
(and before being transformed on an image),
either some global action on all modules like crawling for annotations
or on the module that contains the code that does the action
(or maybe both).

Rémi