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

[Jiri Vanek]

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.