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

Wed Apr 15 15:40:20 UTC 2015

Hi Jonatan.

So here you have pacth with this functionality. Tested on jdk 7 and 8 and works fine.

The change was really minimalistical - your engine eems to be prepared for it! Grate:)

You may note one change in build.xml - feel free to discard it, but I was not able to build without it.

Thanx!

  J.

On 04/11/2015 03:26 AM, Jonathan Gibbons wrote:
> 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.
>>>>>
>>>>>
>>>>
>>>
>>
>

-------------- next part --------------
A non-text attachment was scrubbed...
Name: jdk.version.major.patch
Type: text/x-patch
Size: 1848 bytes
Desc: not available
URL: <http://mail.openjdk.java.net/pipermail/jtreg-dev/attachments/20150415/c311d150/jdk.version.major.patch>