rfscholte at apache.org
Tue Jul 18 20:12:23 UTC 2017
For several plugins we need to compare the Java version. That's not always
the Runtime used by Maven, but another (often older) installed JRE/JDK,
e.g. by calling javadoc -J-version or java -version and parsing its output.
If would help us if we could implement our own parsing strategy and get a
Runtime.Version for comparison. All currently exposed segments won't help
here and as said I wonder where these are actually used apart from the
Otherwise we're reinventing/reimplementing the comparison algorithm of
On Tue, 11 Jul 2017 19:27:02 +0200, <mark.reinhold at oracle.com> wrote:
> 2017/7/8 10:44:11 -0700, Remi Forax <forax at univ-mlv.fr>:
>> 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.
> Right, and it's more abstract than `Runtime.Version` for exactly the
> reasons that Robert mentioned.
>> 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'd have to hack the JDK build system pretty heavily in order to use
> a version string that's not parseable as a `Runtime.Version`. I'm not
> sure why anyone would do that.
>> 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.
> The build system ensures that the version strings of all modules, and of
> the JDK itself, are the same even though module versions are represented
> as instances of `ModuleDescriptor.Version` and the platform version is
> represented as a `Runtime.Version`.
> - Mark
More information about the jpms-spec-observers