Multiple versions of a non-exported dependency
ropalka at redhat.com
Thu Sep 1 21:02:04 UTC 2016
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
> Since upgradeable modules replace platform modules UNNAMED
> classpath module would have to read/see them.
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
* 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
* 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
More information about the jigsaw-dev