Module-system requirements

[Tim Boudreau]

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

-Tim