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

Jiri Vanek jvanek at redhat.com
Fri Apr 17 13:42:45 UTC 2015 

On 04/17/2015 02:55 AM, Jonathan Gibbons wrote:
> 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

ty!
>
> 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.
The {jh} would not hurt and will make life of some individuals easier, but I understand.


One Issue anyway - it seems that yours jenkins build is wrongly configured:
Look to the:
https://adopt-openjdk.ci.cloudbees.com/job/jtreg/265/
It is now latest build. It clearly says that it was started by scm change, last change is the jdk.version.major balkablalal

But - downlod the jar and you will find my changeset missing.
Lookig to the output: https://adopt-openjdk.ci.cloudbees.com/job/jtreg/265/consoleText

It clearly says:
$ hg clone --rev default --noupdate http://hg.openjdk.java.net/code-tools/jtreg /scratch/jenkins/workspace/jtreg
adding changesets
adding manifests
adding file changes
added 157 changesets with 1542 changes to 650 files
[jtreg] $ hg update --rev default
623 files updated, 0 files merged, 0 files removed, 0 files unresolved
[jtreg] $ hg log --rev . --template {node}
[jtreg] $ hg log --rev . --template {rev}
[jtreg] $ hg log --rev e88738b571dee0fb28e40ef14260b78fa267e4f3
changeset:   155:e88738b571de
user:        jjg
date:        Mon Mar 30 17:56:11 2015 -0700
summary:     Improved asmtools handling


Which is the my_comit-1. And is Also a bit surprising. Because my Changeset had id 156. The clone cloned 157 chnagesets but as tip was used 155.

So maybe there is -2 instead -1 somewhere :))

Nope, joking... If you may fix/reschedule whatever I will be glad. I do not wont to upload on my machines my self built version.


TY and sorry if I'm wrong...

J.


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

More information about the jtreg-dev mailing list