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

[Jiri Vanek]

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.
>
>