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

Sat Apr 11 01:26:05 UTC 2015

Jiri,

How about a variant of 0, which is to define a new property, perhaps 
called "jdk.version.major" or something like that, which is defined to 
be a simple integer, for easy use with the existing comparison 
mechanism.  That leaves open the use for jdk.version to be a more 
detailed string, with potentially the possibility of doing version 
comparisons later on, if that should prove necessary.

-- Jon

On 04/10/2015 03:11 AM, Jiri Vanek wrote:
> On 04/09/2015 05:30 PM, Jonathan Gibbons wrote:
>> 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.
>>
>
> 0. Yes. Thats definitely the right thing to do.
>
> So why not to "just keep backward compatibility for jdk5-8" ? If 
> returned version would match 1.{5,6,7,8}.X consider it as 5,6,7 or 8?
>
> The touch in code will be minimalist, we will be in safe integers,
>
>> 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.
>
> I like this:) But yes.. it is hacky :(  And you will still need handle 
> other possible dots after first (eg removal of all no digit chars?)
>
> Although it may be pretty powerfull at the end, it may be confusing 
> even misleading
> (eg 1.7.a5 will suddenly be lower hiogher then 1.7.b4 and many similar 
> and much less visible)
>
>> 2. introduce "version types" into the @requires expression engine, 
>> and make the relation operators
>> polymorphic
>
>
> Well this may be pretty cool, and will solve the issue with jtregs 
> testing features like nimbus (mentioned somewhere in this thread..)
>
>
> So long story short.  I vote for *0* for it simplicity. But if you 
> think 2 is worthy of effort then why not . But design will need much 
> more thinking then I originally hoped to sacrifice. But I think it is 
> not worthy.
>
>
> Also I guess I can not have final word as you are an guru here. So 
> whatever you suppose is good, I can start to work on it.
>
> Thanx!
>
>   J.
>>
>> -- 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.
>>>>
>>>>
>>>
>>
>