#VersionsInModuleNames

[Alan Bateman]

On 15/03/2017 17:09, Stephen Colebourne wrote:

> :
> The proposal above only applies at runtime, not when authoring. Given a module:
>
> module foo {
>    requires bar;
> }
>
> Then the proposal says the requires clause can be satisfied in one of
> three ways.
> 1) a real module on the module path named "bar"
> 2) a jar file on the module path of any filename with a "Module-Name:
> bar" MANIFEST
> 3) a jar file on the module path with filename "bar.jar"
>
> A developer or build system that downloads bar-1.2.jar from Maven
> Central would have to rename it to put it on the module path.
>
> Reading your response, I can only assume that you are thinknig of a
> case where a developer simply moves from the classpath to the module
> path for their whole application without writring any module-info
> files. That seems like a daft use case to me - just stick with the
> classpath. The use case that automatic modules are supposed to handle
> is where your application or library is modularized, and depends
> directly or indirectly on a jar file that has not yet been
> modularized. In this use case, renaming the jar file to match the
> module name is perfectly reasonable.
This is the consumer choosing a module name for a library that they 
don't maintain and renaming that library to match (you are writing the 
`requires X` before X exists). All I'm saying is that the library 
maintainer should be the one that chooses the module name. In its 
absence then deriving the name from from the library gives you a stable 
name in the short term.

As regarding someone moving all JAR files from the class path to the 
module path then I wasn't specifically thinking about that but I'm sure 
people will try this. Split package issues is probably the biggest 
concern with doing that.

-Alan