Remi Forax forax at
Sat Jul 8 17:44:11 UTC 2017

Hi Robert,
this is the JDK version as specified by JEP 223 [1], this is not an artifact version, this is the JDK (as a whole) version.

The ModuleDescriptor.Version [2] 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.


[1] [1]

----- Mail original -----
> De: "Robert Scholte" <rfscholte at>
> À: jpms-spec-experts at
> Envoyé: Samedi 8 Juillet 2017 18:59:54
> Objet: Runtime.Version

> Hi,
> 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.
> thanks,
> Robert

More information about the jpms-spec-observers mailing list