Multiple versions of a non-exported dependency

[Alan Bateman]

On 01/09/2016 17:34, Richard Opalka wrote:

>
>  - [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)
That is how it works, except you use --add-modules to ensure that any 
needed modules on the module path are resolved.

>
> 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)
Automatic modules facilitate top-level migration, you can migrate to 
modules without waiting for everything that you transitively depend to 
migrate. They also allow bridging to the class path - say where you move 
just your direct dependences while leaving the rest on the class path. 
The topic is covered in the STOMS [1] and also in the Advanced 
Modularity talks at JavaOne and Devoxx last year [2].

-Alan

[1] http://openjdk.java.net/projects/jigsaw/spec/sotms/
[1] http://openjdk.java.net/projects/jigsaw/talks/