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
