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.

Please fix the implementation and also please consider to skip this feature
completely: Frankly, the whole idea of trying to smart detecting and
removals of version strings feels totally wrong to me. I understand the
concerns not to let version numbering slip into module names. But this
should not be done via some magic implementation but via good arguments ,
use case examples, patterns, good namin conventions. Note: If someone really
wants to put in his/her versions into the module names, he/she always will
find a way (like by using the number in the middle or as a prefix or ...).
How could you really prevent that (and why would you)?.

Thanks in advance,
Martin


Reply via email to