#VersionsInModuleNames too restrictive (cuts of too much)
Alan.Bateman at oracle.com
Mon Sep 26 17:47:46 UTC 2016
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:
> 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
> Its Maven POM file says:
> 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
> we now have to run the thing with:
> $JAVA_HOME/bin/java --module-path mlib:amlib --add-modules slf4j.jdk -m
> This seems like an implementation bug by cutting off too much of the suffix
(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
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?
More information about the jigsaw-dev