RFR(XXS): 8149519: Investigate implementation of java.specification.version

[Iris Clark]

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.simonis at gmail.com] 
Sent: Tuesday, April 05, 2016 10:26 AM
To: Java Core Libs
Cc: verona-dev at 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.simonis at 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