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/
