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

Fri Apr 17 00:55:25 UTC 2015

Jiri,

I have pushed your fix, together with an update to the tag spec, but 
without the change to build.xml.
http://hg.openjdk.java.net/code-tools/jtreg/rev/7906b5ebfc75

I had intended to push your fix to build.xml separately, but when I went 
to test it, it seems the build.xml file has suffered a fair amount of 
bitrot and requires more remedial action than your relatively simple 
fix.    Since the makefile is the preferred way to build, fixing up the 
Ant file is low priority.

-- Jon

On 04/16/2015 12:16 AM, Jiri Vanek wrote:
> 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.
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>>
>>>
>>
>