Module-system requirements

[Tim Ellison]

Tim Boudreau <niftiness at gmail.com> wrote on 16/02/2015 06:12:18:
> 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.  If a module needs to make the information in one
> of its resources available to other modules then it should do so via a
> properly-exported class, or a service provider.  Just because JAR files
> are miniature filesystems which anybody can dissect doesn't mean that we
> need to conceive of Java modules in the same way.
> 
> 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?
> 
> Having said that, I do agree that the module system must provide some
> kind of escape hatch or "promiscuous mode", as you call it, so here's
> a stab at an additional requirement for the "Modularizing Java SE"
> section:
> 
>   - _Overrideable encapsulation_ --- It must be possible to force a
>     module to export one or more of its packages to all other modules,
>     or to some specific modules, even if its definition does not do so.
> 
> One sort of low-hanging-fruit approach to this would be:
>  - Modules do not use the traditional $CLASSPATH
>  - The contents of $CLASSPATH are treated by the system as a single 
> module (so everything can see each other, and legacy code behaves 
asexpected)

Mark's new requirement would do it - though I had to swallow hard after 
reading the definition, as I heard all the safety-catches being clicked 
off.

I'm struggling to see how treating the contents of the classpath as a 
single module would help here?  The problem is with platform modules 
hiding previously accessible code.

Regards,
Tim

Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 
741598. 
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU