Reformulating the idea to make it more clear:
On 09/01/2016 06:34 PM, Richard Opalka wrote:
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
In order for Jigsaw to support multiple module versions
(not saying it should do so, just reasoning about it)
the following steps would be necessary:
* Disconnect Modularized world from Classpath world (eliminate
automatic modules)
* All platform provided modules would be "unversioned" and unique
(they'd have implicit platform version, e.g. 9-ea)
* Separate graphs of "user provided explicit modules universe"
(provided via --module-path option) from "platform modules universe"
(provided in JDK image)
* User provided explicit modules would support multiple versions via
loader-per-module (including explicit module version string in
module-info.java)
* Update module-info.java format to allow both to specify explicit
module version and to allow dependencies on explicit module versions
(e.g. "requires module.foo 1.0)
* "requires public" would be disallowed for explicitly versioned modules
* Update module graph mapping to the VM to take module version string
into account
Richard
