On 09/01/2016 03:59 PM, Alan Bateman wrote:
The issue is of course that there is lot more in picture, esp. when
you have the unnamed module (= class path) reading all modules, also
automatic modules that bridge to the class path (and so read the
unnamed module). Then add upgradable modules into the picture, ... and
you will quickly start to see there is a lot more to this, not to mind
the risk of circular delegation.
Trying not to hijack this thread (and yes I am aware it is maybe too
late for Jigsaw project to change it) but I'd like to share one idea.
What if Jigsaw would work like this?
- [A] Non-platform explicit modules (specified on --module-path) would
support versions with loaders-per-module
- [B] Version should be optional literal in module-info.java when
declaring module dependencies for such modules
- [C] UNNAMED classpath module shouldn't see non-platform explicit
modules by default
(users might use -XaddExports to export them explicitly with risk
for split-package issue and other issues)
Further I can't see the real benefit of automatic modules (they read
UNNAMED module(s) and all other explicit modules).
I am aware of two real world usecases it might solve:
1) to workaround licensing issues of dead java projects (where
consumers are disallowed to change them in any way)
2) automatic module placed on --upgrade-module-path (to allow smooth
migration for EE APIs without need to define module-info.class for them)
Considering 1) (i.e. dead wrong licensed projects should die) and 2)
here's final proposal point:
- [D] automatic modules would be supported only in
--upgrade-module-path universe without possibility to read UNNAMED modules.
Since upgradeable modules replace platform modules UNNAMED
classpath module would have to read/see them.
Richard
