Multiple versions of a non-exported dependency
Alan.Bateman at oracle.com
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  and also in the Advanced
Modularity talks at JavaOne and Devoxx last year .
More information about the jigsaw-dev