On 26/09/2016 18:19, Martin Lehmann wrote:
Hi all,
the new #VersionsInModuleNames seems to be active in JDK9 b136 already.
Switching to b136 breaks the build in one of our examples of our Java9
Jigsaw example suite, cf Github:
https://github.com/accso/java9-jigsaw-examples/tree/master/jigsaw-examples/e
xample_automatic-module-logging
In this example we are using the automatic module which is taken from the
JAR file slf4j-jdk14-1.7.12.jar . This JAR had been taken from Maven
central, cf
https://search.maven.org/#artifactdetails%7Corg.slf4j%7Cslf4j-jdk14%7C1.7.21
%7Cjar
Its Maven POM file says:
<groupId>org.slf4j</groupId>
<artifactId>slf4j-jdk14</artifactId>
<version>1.7.21</version>
Unfortunately, the version name which is automatically detected and taken
from the Jigsaw module name is "14-1.7.21".
So instead of calling the main class (as done with b127 ff) as follows:
$JAVA_HOME/bin/java --module-path mlib:amlib --add-modules slf4j.jdk14 -m
modmain/pkgmain.Main
we now have to run the thing with:
$JAVA_HOME/bin/java --module-path mlib:amlib --add-modules slf4j.jdk -m
modmain/pkgmain.Main
This seems like an implementation bug by cutting off too much of the suffix
string.
(The #VersionsInModuleNames proposal is not in jdk-9+136 so I assume you
have a Jigsaw EA build. `java -version` will confirm).
With the proposal then the trailing digits are dropped from the
candidate module name and so "slf4j.jdk" (with version "1.7.21") is what
you would see. With the original scheme it would be " slf4j.jdk14" with
version "1.7.21". If you think there are good reasons to not drop the
trailing digits from the name then it's probably best to write them up
for jpms-spec-comments.
In passing, I'm curious why --add-modules is used in the above. It
suggests that nobody requires it. Is this just a service provider? Does
it work when on the class path, leaving the rest on the module path?
-Alan.
