Multiple versions of a non-exported dependency

Alan Bateman Alan.Bateman at
Thu Sep 1 16:58:32 UTC 2016

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].



More information about the jigsaw-dev mailing list