[rfc] make test ignored or valid only for specific JDK
Jonathan Gibbons
jonathan.gibbons at oracle.com
Fri Apr 17 15:52:31 UTC 2015
Jiri,
The Ant file should be updated, but in its current form, I can't test
the edit because of other issues. Frankly, I'm surprised that you can
build with the Ant file, if you are using the same version, in the tip
of the code-tools/jtreg repo.
The "jenkins build" is configured and managed by the Adopt OpenJDK group.
-- Jon
On 04/17/2015 06:42 AM, Jiri Vanek wrote:
> 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