[rfc] make test ignored or valid only for specific JDK

[Jonathan Gibbons]

The current behavior of the jdk.version has been to return  1.major for 
existing releases, with the proposal to go to something beginning with 9 
for JDK 9 onwards.

I don't think it is right to renumber releases in hindsight. jdk.version 
should stay "reasonably close" to the beginning of the string obtained 
from "java -version".

So that means we have the following possibilities:
1. only allow one dot, and treat these numbers as floating point. That's 
pretty hacky.
2. introduce "version types" into the @requires expression engine, and 
make the relation operators polymorphic

-- Jon

On 04/09/2015 12:53 AM, Jiri Vanek wrote:
> ping?
>
> If the most simple way is the way to go, then - as your initial impl 
> is based on jdk9, so it expect one number on each side, then simple 
> extending  for backward ocmpatibility to change 1.{8,7,6,5}.whatever  
> to simple number should be right thing to do an easy way to go.
>
> Any more granular thoughts may come in later.
>
> Can I proceed with this patch?
>
>
> Thank you,
>   J.
>
> On 04/02/2015 01:12 PM, Jiri Vanek wrote:
>> One more hint.
>>
>> When I originally read
>>
>>  > 4. @requires. This is a relatively new feature. You can put a 
>> declarative tag in a test description
>>  > of the form "@requires expr" where there is a variety of 
>> terminals, of which jdk.version is but
>>  > one.   So you could add a line like
>>  >      @requires  jdk.version <=1.6 || jdk.version >1.7 || 
>> jdk.version = "1.4.2"
>>  > Not as compact as your proposal, but it exists today.
>>
>> It seemed to me that full version sort is included.
>>
>> so eg  1.4.2 < 1.8 < 9 < 9.2
>> but also 1.7.0_20 < 1.7.0_40
>>
>>
>> Also my original impression from jep was, that backward compatibility 
>> returnnig 1.9.0_X will be
>> preserved.
>>
>> Currently I do not need this, but my colleague mentioned cases where 
>> it can be useful.
>> Eg nimbus  was introduced in uSomething. So any tests to nimbus would 
>> have @requires >=
>> 1.7.0_Something (instead of programmed failback "if no nimbus then 
>> exit 0" :)
>>
>> Maybe it is really not needed, but when such an nice feature started 
>> to exists, it would be nice to
>> have it as capable as possible.
>>
>> J.
>>
>> On 04/02/2015 11:19 AM, Jiri Vanek wrote:
>>> On 04/01/2015 08:32 PM, Jonathan Gibbons wrote:
>>>>
>>>> On 04/01/2015 10:34 AM, Jiri Vanek wrote:
>>>>>>
>>>>>>   * @requires jdk.version <= 7
>>>>>> leads to
>>>>>> test result: Error. Error evaluating expression: invalid numeric 
>>>>>> value: 1.8
>>>>>>
>>>>>> Is it expected bahviour? I tried also with various 
>>>>>> spaces/nospace....
>>>>>>
>>>>>>
>>>>> ping? Is it expected? If not, I will provide you a fix.
>>>>>
>>>>> J.
>>>>
>>>> With hindsight, I can see that this is to be expected, which is not 
>>>> to say that it is good.
>>>>
>>>> Going forward, I'm not sure what the correct fix will be, 
>>>> especially given the upcoming JEP for
>>>> semantic versioning.
>>>> http://openjdk.java.net/jeps/223
>>>
>>> Yes, I'm aware of this jep.
>>>>
>>>> Before you provide a fix, I'd be interested to hear suggestions on 
>>>> what the fix should be.  One
>>>> solution is that we should just allow numbers to be represented as 
>>>> Double as well as Long. A
>>>> different solution would be to introduce a "version" type somehow.
>>>
>>> When I saw the behavior, And realized that jep 233 was target, I was 
>>> thinking  that
>>>  >>>   * @requires jdk.version <= 7
>>>  >>> leads to
>>>  >>> test result: Error. Error evaluating expression: invalid 
>>> numeric value: 1.8
>>>
>>> Is correct way to do. And so, if this Error is hit,  try to remove 
>>> leading 1. and strip all behind
>>> next dot including that dot.
>>>
>>> For jdk9+ single number is expected.
>>>
>>> Otherwise the qeustion is a bit different. What is expected from 
>>> "jdk.version" Only mayor number
>>> like 1.4.2, 1.7.0, 1.8.0, 9, 10, or more detailed version?
>>>
>>> I would vote for that simple approach, but probably only because it 
>>> suits my needs now.
>>> Cases like 1.4.2 in past 1.4.0 may be expected... But still, non of 
>>> those should causes compilation
>>> incompatibility.
>>>
>>>
>>> Thank you very much for cooperation!
>>>   J.
>>
>>
>