Multiple versions of a non-exported dependency

[Richard Opalka]

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