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

Thu Apr 16 07:16:06 UTC 2015

On 04/15/2015 06:51 PM, Jonathan Gibbons wrote:
> Jiri,
>
> Thanks.
>
> On the build.xml, I note that "make" is the preferred way to build and test jtreg; the Ant file is

Yes. I understand it.
> provided as a convenience for use while working in an IDE like NetBeans. It was not practical to
And it is very cool :)

> port all the tests from the "make" world into the Ant world, and so "make" remains the definitive

Sure.
> build tool.  Looking at your build change, while jh.jar is required, it is normally pulled in
> because of a Class-Path reference in javatest.jar, but perhaps you don't have that reference in your
> build of javatest.jar.

Thats weird. It have:

  unzip -p /opt/jtharness/4.3/lib/javatest.jar META-INF/MANIFEST.MF | grep Class-Path
Class-Path: jh.jar

Is the change acceptable (no meter of build.xml hunk)? If so, when it can be expected to be seen in 
jenkins build?

J

>
> -- Jon
>
> On 04/15/2015 08:40 AM, Jiri Vanek wrote:
>> 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.
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>