forax at univ-mlv.fr
Sat Jul 8 17:44:11 UTC 2017
this is the JDK version as specified by JEP 223 , this is not an artifact version, this is the JDK (as a whole) version.
The ModuleDescriptor.Version  is the module version, something like your artifact version.
The JDK version is loosely related to a module version because they some version components like starting with 9.
That's said, i'm not sure the JDK version is something that should be checked/compared in the code, after all people can build there own JDK with their own version.
You can use the java.base version instead, there is a signing mechanism (the module hashes) that ensures that the jdk modules and the java.base module are compatible.
  http://openjdk.java.net/jeps/223
----- Mail original -----
> De: "Robert Scholte" <rfscholte at apache.org>
> À: jpms-spec-experts at openjdk.java.net
> Envoyé: Samedi 8 Juillet 2017 18:59:54
> Objet: Runtime.Version
> I'm kind of surprised by the number of methods of Runtime.Version:
> Based on my experience with versions I would advice to reduce the number
> of methods.
> With Maven we had this interface:
> However, in the end all those separate segments didn't add a thing and are
> actually causing unnecessary complex code in case we were doing other
> implementations with ArtifactVersion. ArtifactVersion is quite an
> important interface in our code, so there's no simple solution to simplify
> this mistake.
> I'm really pleased that for Aether (which is now back at Maven as Artifact
> Resolver) it is all reduced to this:
> This is all we need: parsing + comparing (+ #toString()). If none of the
> additional methods of Runtime.Version is used *yet*, you should consider
> to remove them.
More information about the jpms-spec-observers