Multiple versions of a non-exported dependency

[Richard Opalka]

On 09/01/2016 06:58 PM, Alan Bateman wrote:
> On 01/09/2016 17:34, Richard Opalka wrote:
> 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/
Yes, I'm familiar and aware of these. What I meant is:

Is the benefit of incremental migration (automatic modules provide) that 
valuable?
What's bad with "modularize all or nothing" kind of migration?
There would be no need for bridges to the classpath if automatic modules 
would disappear.

Richard