Hi, Volker.
Sorry for the delay. I agree that the old implementation isn't quite correct.
I can't see us potentially having a JCP MR for a security or patch release
(9.0.0.X and 9.0.X respectively).
I could see a MR for an very unusual minor release (9.X). If we had an MR
there's no guarantee that we'd need to change the java.specification.version
system property. However, in the event that we did need to change the
java.specification.version, it should match that release's $MAJOR.$MINOR, even
if it meant that we had a sequence of specification version numbers with gaps.
As an example, let's say that JDK 9 is released via umbrella JSR with
java.specification.value of "9". The system property would remain at "9" for
all releases regardless of type until we choose to have a MR. Should that MR
occur while we're working on minor release 9.3.X and there is a need to change
the value of java.specification.value, it would become "9.3" and would remain
so in every release until the next MR.
While we haven't changed the system property recently, I think that we need to
future-proof ourselves a little bit for MRs as described above.
Assuming that we change the syntax of java.specification.version to
$MAJOR.$MINOR (zeros truncated, value dependent on JCP) then we need to make a
similar change to the syntax of java.vm.specification.version. [ Note that in
the current implementation, I believe that the values of
java.specification.version and java.vm.specification.version are tied to each
other. ]
Changing the syntax of java{.vm}?specification.version requires a CCC which I
will file once we have agreement on the necessary changes.
Regards,
Iris
-----Original Message-----
From: Volker Simonis [mailto:volker.simo...@gmail.com]
Sent: Tuesday, April 05, 2016 10:26 AM
To: Java Core Libs
Cc: verona-...@openjdk.java.net
Subject: Re: RFR(XXS): 8149519: Investigate implementation of
java.specification.version
Hi,
can somebody please review this trivial change?
Regards,
Volker
On Mon, Apr 4, 2016 at 6:47 PM, Volker Simonis <volker.simo...@gmail.com> wrote:
> Hi,
>
> can I please have a review for this small fix:
>
> http://cr.openjdk.java.net/~simonis/webrevs/2016/8149519
> https://bugs.openjdk.java.net/browse/JDK-8149519
>
> Currently the value of the java.specification.version property comes
> from VERSION_SPECIFICATION in common/autoconf/spec.gmk.in. It is
> currently set to VERSION_NUMBER which is the same value which is also
> used for the java.version property.
>
> This is a bad idea, because VERSION_NUMBER is a dot separated sequence
> of numbers (e.g. 9.0.1) which is expected to change frequently (i.e.
> for every build and/or update version). If we are configuring with
> "--with-version-patch=1" for example, VERSION_NUMBER and java.version
> will be "9.0.0.1". But it makes no sense that VERSION_SPECIFICATION
> and java.specification.version have the same, dotted value. And it
> breaks a lot of legacy applications which parse
> java.specification.version as a float number. That code would still
> work if java.specification.version would be a concrete number (e.g.
> '9' or '10').
>
> I suggest to set VERSION_SPECIFICATION to VERSION_MAJOR in
> common/autoconf/spec.gmk.in. This should be the "right value" until we
> get a specification change during a major release which hasn't
> happened for quite some time now.
>
> Regards,
> Volker
