Module-system requirements

[mark.reinhold at oracle.com]

2015/2/16 12:32 -0800, Tim Boudreau <niftiness at gmail.com>:
> tim_ellison at uk.ibm.com:
>> Tim Boudreau <niftiness at gmail.com>:
>>> 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
>>> as expected)
>> 
>> 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 don't think it does -- treating the content of the class path as a
module is just a convenient (maybe even elegant) way to relate legacy,
non-modular code to modular code.

>                                       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.

No doubt ...

> 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.

Yes -- this is roughly the migration strategy I have in mind.

- Mark