Multiple versions of a non-exported dependency

[Richard Opalka]

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