Multiple versions of a non-exported dependency

[Richard Opalka]

On 09/02/2016 10:27 AM, Alan Bateman wrote:
> On 01/09/2016 21:04, cowwoc wrote:
>
>> Another possibility (not saying it's better, just putting it out there)
>> is to do the following:
>>
>>   1. Provide a tool like "javah" that would generate module-info.java 
>> for
>>      non-modularized JAR files.
>>
>>
> Look at `jdeps --gen-module-info ..`. It's a starting point to create 
> a source file that is easy to edit (see the slide decks).
>
> It's not difficult to write your own ModuleFinder that reads the 
> module declaration from elsewhere if you really want. If you are 
> willing to write a module declaration for each of the 100 JAR files on 
> your class path then more power to you. To be honest, the feedback 
> over the years has almost always been that developers don't want to 
> take responsibility for libraries maintained by others. This usually 
> means they won't want to write/maintain the module declaration for 
> libraries that they won't own, or they don't know enough about the 
> code in these components to be confident that the module declaration 
> is correct.
>
> -Alan
Seems the main reason why automatic modules need to see the classpath 
UNNAMED module
is there might be conflicting packages on that classpath which 
modularization would be non trivial
(would require custom ModuleFinders, Layers and ClassLoader factories).
Yes, automatic modules help in such scenarios.

Will Java support classpath forever or there are plans to remove it?
Asking because if classpath would be removed some time in the future
such compromise (automatic modules) is just short term win affecting
many key design decisions.

Richard