Multiple versions of a non-exported dependency
ropalka at redhat.com
Thu Sep 1 16:34:45 UTC 2016
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.
More information about the jigsaw-dev