Module-system requirements

[David M. Lloyd]

On 02/16/2015 02:32 PM, Tim Boudreau wrote:
>>
>>
>>> 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.
>>
>
> I'm not sure it does help with that.  I'm sure in this JSR there will be
> lots of different problems that each of us thinks of as The Most Important
> Problem to Solve.
>
> The idea I was trying to get across is that, if you want to partition the
> world up into modules and do that in a compatible way, then start by
> modularizing the JDK, and giving *it* a new way to link.  At the
> application layer, keep the default behavior by treating everything linked
> the traditional way as, for the purposes of the framework, a single large
> "default" module where all the old rules apply.  As libraries modularize,
> at their own pace, they move out of that "default' module and become
> modules in their own right, and new linking rules apply.
>
> That's not a model for how to access newly hidden code - that's a
> negotiation between the user of that hidden code and its owner (though it
> might be facilitated by the JDK and everything else being modularized into
> more, smaller modules).  It's just a way to compatibly evolve toward a
> modular universe as opposed to trying to carve up the existing universe
> into modules in a way that doesn't break stuff, which is probably
> impossible.

I don't think this is impossible at all, depending on how much the rules 
change in the final implementation.  Our WildFly environment is a JBoss 
Modules based modular environment of over 300 modules, many of which are 
outside projects, and nearly 100% of that code worked fine without any 
changes (the changes that were required were generally trivial and most 
were contributed back upstream AFAIK).

So having *a* modular environment which is largely compatible with 
today's world is clearly possible, it's just a question of how much we 
want/need to change things to meet these requirements.

Incidentally, I added on a mechanism to JBoss Modules near the beginning 
to let you run a "-jar my.jar" file (with Class-Path support) as well as 
to set up a -classpath and run a main class just like you do today. 
Both of these mechanisms work, coincidentally, by assembling the "class 
path" into a module, but also allowing that module to express direct 
dependencies on modules in the module path, by using a simple 
-dependencies switch (in the -classpath case) or a "Dependencies:" 
MANIFEST.MF header (in the -jar case).  This works quite well as a 
bridge between worlds in our case.

The way it worked out was quite elegant actually.  Since we have a 
module loader concept (probably roughly equivalent to the 
"configuration" concept in the current requirements document), and a 
boot module loader (which equals the flat file system module image), 
this was achieved by simply adding another module loader for the target 
JAR or class path, with a resource root per class path item (simulating 
a localized flat classpath).  In this way the isolated classpath module 
can link against modules from the boot module loader using the 
dependency constructs, without actually polluting that module space in 
any way (i.e. dependencies cannot go the other direction to the class 
path).  Setting the TCCL to the application class path module ties up 
the picture and allows almost all of your normal class loader constructs 
to function as they always have.

-- 
- DML