From volker.simonis at gmail.com  Mon Jun  6 18:29:06 2016
From: volker.simonis at gmail.com (Volker Simonis)
Date: Mon, 6 Jun 2016 20:29:06 +0200
Subject: Status of jtreg build
In-Reply-To: <570E6A79.8050701@oracle.com>
References: <CAP_pwnXOc0vfk6bMEoAu9X9D_Bcd-vg+T_TYyocKeCE1s3NFww@mail.gmail.com>
	<570D648A.5020301@oracle.com>
	<CA+kOe08Df0Dctxz9uWxoNpz2prqqyqmapuZOUG0ekDeWeXg_UQ@mail.gmail.com>
	<CA+3eh11DB7ppJbtet5EooqA8XvGKtkT7-JOSZPp1GpGEaHeqzg@mail.gmail.com>
	<CA+kOe09xmZtSvAPka6ioSpTVcajQXsTc7rNJd9YnAU+CtHF3Sg@mail.gmail.com>
	<570E6A79.8050701@oracle.com>
Message-ID: <CA+3eh12c6q+67ifJtP2R+SMhxriED1BPB4+1R=VQrO9PqdBanw@mail.gmail.com>

I did run into this problem again today. I solved it by simply merging
jcommander.jar and testng.jar into a new, single jar which I feed into
the jtreg build with the TESTNG_JAR=testng-6.9.10_jcommander-1.48.jar
option. It's a hack but it works :)

I also found that we already have a bug covering this issue:

CODETOOLS-7901684: Some tests fail with
java.lang.NoClassDefFoundError:
com/beust/jcommander/ParameterException
https://bugs.openjdk.java.net/browse/CODETOOLS-7901684

Maybe we should really fix this in the build? I think that meanwhile
building jtreg has unnecessarily become a kind of rocket-since...

Regards,
Volker


On Wed, Apr 13, 2016 at 5:49 PM, Jonathan Gibbons
<jonathan.gibbons at oracle.com> wrote:
> Well, that part of the jtreg build system was written when TestNG
> came as a single jar and predates its Mavenisation.
>
> jtreg would probably work if you had separate jcommander.jar and testng.jar
> and put jcommander.jar on the Class-Path in the testng.jar manifest.
> Hmm, that may not work for those tests (like some of the streams tests)
> which need testng.jar on th bootclasspath.   (IIRC, Class-Path is not
> honored for
> jars on the bcp.)
>
> -- Jon
>
>
>
>
> On 04/13/2016 08:26 AM, Martin Buchholz wrote:
>>
>> Maven likes to have as many jar files as possible, so jcommander and
>> testng are separated.
>> But jtreg thinks testng.jar should contain jcommander, so I ended up
>> having to build testng-jar-all
>>
>> (jtreg should probably switch to maven's view of the world and take
>> jcommander as another dependency)
>>
>> Hacky build script snippet:
>>
>> # --- testng ---
>> # Build "fat" testng.jar (incorporating jcommander) from source.
>> # No one seems to distribute such fat testng jars anymore.
>> rm -rf testng testng-*
>> wget -qOtestng.zip
>> https://github.com/cbeust/testng/archive/testng-6.8.5.zip
>> unzip -q testng.zip
>> rm testng.zip
>> mv testng-* testng
>> (
>>    export JAVA_HOME="$HOME/jdk/jdk6"
>>    export PATH=$JAVA_HOME/bin:$PATH
>>    cd testng &&
>>    mkdir -p ~/.ant/lib &&
>>    cp ivy-2.1.0.jar ~/.ant/lib/. &&
>>    ant clean compile copy-resources testng-jar-all &&
>>    rm ~/.ant/lib/ivy-2.1.0.jar
>> )
>> TESTNG_HOME="$ROOT/testng"
>> TESTNG_JAR=$(find "$ROOT/testng/target/" -name "testng*jar")
>>
>> On Tue, Apr 12, 2016 at 11:53 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>>
>>>
>>> On Tue, Apr 12, 2016 at 11:28 PM, Martin Buchholz <martinrb at google.com>
>>> wrote:
>>>>
>>>> jtreg build on
>>>> https://adopt-openjdk.ci.cloudbees.com/
>>>> is broken, as is its dependency asmtools
>>>> The jtreg-4.2 build they advertise was created before there was any 4.2
>>>> tag.
>>>> They seem to be missing testng as a dependency.
>>>> The project does keep trying (and failing) to build, however.
>>>>
>>>> I tried and failed to find on the Net the "full" testng-6.8.zip that
>>>> used to be distributed on testng.org.
>>>>
>>> That seems true, but I think all you needed from the "full"
>>> testng-6.8.zip
>>> was the LICENSE file. See jtreg/make/jtreg.gmk
>>>
>>> $(JTREG_IMAGEDIR)/legal/testng/LICENSE.txt: $(call
>>> PosixPath,$(TESTNG_HOME)/LICENSE.txt)
>>>          $(MKDIR) -p $(@D)
>>>          $(CAT) $(TESTNG_HOME)/LICENSE.txt >> $@
>>>
>>> The testng jar file is specified by TESTNG_JAR anyway. So I think you can
>>> download the jar from
>>>
>>> http://mvnrepository.com/artifact/org.testng/testng/6.8 or
>>> http://mvnrepository.com/artifact/org.testng/testng/6.8.5
>>>
>>> because http://openjdk.java.net/jtreg/build.html now recommends 6.8.5 and
>>> get the license file from:
>>>
>>> https://github.com/cbeust/testng
>>>
>>>> On Tue, Apr 12, 2016 at 2:11 PM, Jonathan Gibbons
>>>> <jonathan.gibbons at oracle.com> wrote:
>>>>>
>>>>>
>>>>> On 04/11/2016 11:06 AM, Carsten Varming wrote:
>>>>>>
>>>>>> Dear jtreg devs,
>>>>>>
>>>>>> I wanted to download jtreg to run JDK9 hotspot regression tests, but I
>>>>>> have been unsuccessful so far. Perhaps you know what I need to do to
>>>>>> get
>>>>>> going.
>>>>>>
>>>>>> The hotspot regression tests need at least jtreg 4.2 b01. When I
>>>>>> downloaded the latest build published at
>>>>>> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/ (4.2.0-tip, from
>>>>>> build
>>>>>> 496) and tried the hotspot regression tests I got:
>>>>>>
>>>>>> Error: Unexpected exception occurred! java.lang.NumberFormatException:
>>>>>> For
>>>>>> input string: "ip"
>>>>>> java.lang.NumberFormatException: For input string: "ip"
>>>>>>          at
>>>>>>
>>>>>>
>>>>>> java.lang.NumberFormatException.forInputString(java.base at 9-internal/NumberFormatException.java:65)
>>>>>>          at
>>>>>> java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:695)
>>>>>>          at
>>>>>> java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:813)
>>>>>>          at
>>>>>> com.sun.javatest.regtest.Version.getBuild(Version.java:186)
>>>>>>          at
>>>>>> com.sun.javatest.regtest.Version.compareTo(Version.java:168)
>>>>>>          at com.sun.javatest.regtest.Main.run(Main.java:1091)
>>>>>>          at com.sun.javatest.regtest.Main.run(Main.java:1037)
>>>>>>          at com.sun.javatest.regtest.Main.main(Main.java:951)
>>>>>>
>>>>>> I suspect the check against "requiredVersion=4.2 b01" from TEST.ROOT
>>>>>>
>>>>>>
>>>>>> (http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/1c08ca66db33/test/TEST.ROOT)
>>>>>> went wrong. I suspect "build = manifest.getProperty("jtreg-Build");"
>>>>>> in
>>>>>>
>>>>>>
>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/6bfef17a03d5/src/share/classes/com/sun/javatest/regtest/Version.java
>>>>>> sets Version.build to "tip" and Version.getBuild tries to parse "ip"
>>>>>> as
>>>>>> a
>>>>>> number. :(
>>>>>>
>>>>>> I tried to get past this problem by changing the required jtreg
>>>>>> version
>>>>>> to
>>>>>> 4.1 b01. That gets the tests running, but a third of them fail with a
>>>>>> class
>>>>>> loading problem: A ClassFormatError is thrown with "Truncated class
>>>>>> file".
>>>>>> This seems to be due to a missing
>>>>>> java/lang/reflect/JTRegModuleHelper.class.
>>>>>> I suspect that this requirement was introduced with the module system
>>>>>> that
>>>>>> was integrated a few weeks ago.
>>>>>>
>>>>>> So, how do I get a version of jtreg that works with the latest JDK9?
>>>>>>
>>>>>> BTW. It looks like the jtreg build
>>>>>> (https://adopt-openjdk.ci.cloudbees.com/job/jtreg/) is failing because
>>>>>> of a
>>>>>> missing dependency on testng.
>>>>>>
>>>>>> Help much appreaciated,
>>>>>> Carsten
>>>>>
>>>>>
>>>>> The version of jtreg available on cloudbees.com has the following entry
>>>>> in
>>>>> its MANIFEST.MF,
>>>>>
>>>>>      jtreg-Build: tip
>>>>>
>>>>> and jtreg is naively assuming it to be of the form
>>>>>      jtreg-Build: b<integer>
>>>>>
>>>>> I can make jtreg be more tolerant, but I also also note that the binary
>>>>> is
>>>>> missing lib/asmtools.jar, which is required by some tests.  The
>>>>> contents
>>>>> of
>>>>> the tar bundle are all dated 25 January 2016, 10:47 which is somewhat
>>>>> suspicious.
>>>>>
>>>>> -- Jon
>>>
>>>
>

From Leonid.Mesnik at oracle.com  Tue Jun  7 09:34:56 2016
From: Leonid.Mesnik at oracle.com (Leonid Mesnik)
Date: Tue, 7 Jun 2016 12:34:56 +0300
Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32
In-Reply-To: <a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
References: <5746FDF3.3030102@oracle.com>
	<a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
Message-ID: <57569540.9010106@oracle.com>

Hi

Added jtreg-use at openjdk.java.net

I think that you are right. Here is the documentation:
http://openjdk.java.net/jtreg/tag-spec.html


"@requires <expression>

    Express a dependence on characteristics of the system being tested.
    Some harnesses allow tests to be selected according to the
    characteristics of the system being tested. The expression may be
    composed of the following elements:"

"os.arch The operating system architecture, as given by the 
corresponding system property."

So user could expect to have "os.arch" of tested VM.

If filed jtreg issues for this:

 1. CODETOOLS-7901695
    <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
    value 'os.arch' property of JDK which executed JDK and not of tested JDK


Following fix could be used as a temporary workaround while jtreg fix is 
not ready.  Does it make a sense? I this case it is needed to change 
linux-arm64 back to linux-aarch64 to minimize changes.

Leonid

On 31.05.2016 04:26, David Holmes wrote:
> Hi Leonid,
>
> This really strikes me as as a jtreg problem that should be fixed in 
> jtreg. When writing an @requires clause in a test the test writer 
> should not have to be thinking "oh wait! Is this going to query the VM 
> running jtreg or the VM running the test?". It should obviously be the 
> VM running the test.
>
> That said we also seem to have a problem with the definition of os.arch:
>
> os.arch     Operating system architecture
>
> if it is returning the build architecture of the VM and not the OS it 
> is running on. That in itself argues for two distinct properties.
>
> David
>
> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>> Hi
>>
>> Could you please review following fix:
>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>> for bug
>> https://bugs.openjdk.java.net/browse/JDK-8157831
>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>
>> The property "os.name" which was used to filter tests depends on the
>> arch of jdk which is used to run jtreg. It might differ from arch of
>> tested jdk.
>> This fix introduce new property "vm.arch" which depends on the arch of
>> tested jdk and could be used to filter tests with @requires.
>>
>> I verified that tests are filtered where it is expected.
>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot
>> testing.
>>
>> Leonid
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20160607/496092c5/attachment.html>

From jonathan.gibbons at oracle.com  Wed Jun  8 15:58:16 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Wed, 08 Jun 2016 08:58:16 -0700
Subject: Status of jtreg build
In-Reply-To: <CA+3eh12c6q+67ifJtP2R+SMhxriED1BPB4+1R=VQrO9PqdBanw@mail.gmail.com>
References: <CAP_pwnXOc0vfk6bMEoAu9X9D_Bcd-vg+T_TYyocKeCE1s3NFww@mail.gmail.com>
	<570D648A.5020301@oracle.com>
	<CA+kOe08Df0Dctxz9uWxoNpz2prqqyqmapuZOUG0ekDeWeXg_UQ@mail.gmail.com>
	<CA+3eh11DB7ppJbtet5EooqA8XvGKtkT7-JOSZPp1GpGEaHeqzg@mail.gmail.com>
	<CA+kOe09xmZtSvAPka6ioSpTVcajQXsTc7rNJd9YnAU+CtHF3Sg@mail.gmail.com>
	<570E6A79.8050701@oracle.com>
	<CA+3eh12c6q+67ifJtP2R+SMhxriED1BPB4+1R=VQrO9PqdBanw@mail.gmail.com>
Message-ID: <57584098.9090503@oracle.com>

Yes, this needs to be fixed.

I apologize for the apparent rocket science; I have been trying to 
simplify the build lately, but the split between TestNG and JCommander 
has yet to be taken into account. I would like to make jtreg accept the 
standard jar-files as-is, but that will require jtreg source code changes.

-- Jon


On 06/06/2016 11:29 AM, Volker Simonis wrote:
> I did run into this problem again today. I solved it by simply merging
> jcommander.jar and testng.jar into a new, single jar which I feed into
> the jtreg build with the TESTNG_JAR=testng-6.9.10_jcommander-1.48.jar
> option. It's a hack but it works :)
>
> I also found that we already have a bug covering this issue:
>
> CODETOOLS-7901684: Some tests fail with
> java.lang.NoClassDefFoundError:
> com/beust/jcommander/ParameterException
> https://bugs.openjdk.java.net/browse/CODETOOLS-7901684
>
> Maybe we should really fix this in the build? I think that meanwhile
> building jtreg has unnecessarily become a kind of rocket-since...
>
> Regards,
> Volker
>
>
> On Wed, Apr 13, 2016 at 5:49 PM, Jonathan Gibbons
> <jonathan.gibbons at oracle.com> wrote:
>> Well, that part of the jtreg build system was written when TestNG
>> came as a single jar and predates its Mavenisation.
>>
>> jtreg would probably work if you had separate jcommander.jar and testng.jar
>> and put jcommander.jar on the Class-Path in the testng.jar manifest.
>> Hmm, that may not work for those tests (like some of the streams tests)
>> which need testng.jar on th bootclasspath.   (IIRC, Class-Path is not
>> honored for
>> jars on the bcp.)
>>
>> -- Jon
>>
>>
>>
>>
>> On 04/13/2016 08:26 AM, Martin Buchholz wrote:
>>> Maven likes to have as many jar files as possible, so jcommander and
>>> testng are separated.
>>> But jtreg thinks testng.jar should contain jcommander, so I ended up
>>> having to build testng-jar-all
>>>
>>> (jtreg should probably switch to maven's view of the world and take
>>> jcommander as another dependency)
>>>
>>> Hacky build script snippet:
>>>
>>> # --- testng ---
>>> # Build "fat" testng.jar (incorporating jcommander) from source.
>>> # No one seems to distribute such fat testng jars anymore.
>>> rm -rf testng testng-*
>>> wget -qOtestng.zip
>>> https://github.com/cbeust/testng/archive/testng-6.8.5.zip
>>> unzip -q testng.zip
>>> rm testng.zip
>>> mv testng-* testng
>>> (
>>>     export JAVA_HOME="$HOME/jdk/jdk6"
>>>     export PATH=$JAVA_HOME/bin:$PATH
>>>     cd testng &&
>>>     mkdir -p ~/.ant/lib &&
>>>     cp ivy-2.1.0.jar ~/.ant/lib/. &&
>>>     ant clean compile copy-resources testng-jar-all &&
>>>     rm ~/.ant/lib/ivy-2.1.0.jar
>>> )
>>> TESTNG_HOME="$ROOT/testng"
>>> TESTNG_JAR=$(find "$ROOT/testng/target/" -name "testng*jar")
>>>
>>> On Tue, Apr 12, 2016 at 11:53 PM, Volker Simonis
>>> <volker.simonis at gmail.com> wrote:
>>>>
>>>> On Tue, Apr 12, 2016 at 11:28 PM, Martin Buchholz <martinrb at google.com>
>>>> wrote:
>>>>> jtreg build on
>>>>> https://adopt-openjdk.ci.cloudbees.com/
>>>>> is broken, as is its dependency asmtools
>>>>> The jtreg-4.2 build they advertise was created before there was any 4.2
>>>>> tag.
>>>>> They seem to be missing testng as a dependency.
>>>>> The project does keep trying (and failing) to build, however.
>>>>>
>>>>> I tried and failed to find on the Net the "full" testng-6.8.zip that
>>>>> used to be distributed on testng.org.
>>>>>
>>>> That seems true, but I think all you needed from the "full"
>>>> testng-6.8.zip
>>>> was the LICENSE file. See jtreg/make/jtreg.gmk
>>>>
>>>> $(JTREG_IMAGEDIR)/legal/testng/LICENSE.txt: $(call
>>>> PosixPath,$(TESTNG_HOME)/LICENSE.txt)
>>>>           $(MKDIR) -p $(@D)
>>>>           $(CAT) $(TESTNG_HOME)/LICENSE.txt >> $@
>>>>
>>>> The testng jar file is specified by TESTNG_JAR anyway. So I think you can
>>>> download the jar from
>>>>
>>>> http://mvnrepository.com/artifact/org.testng/testng/6.8 or
>>>> http://mvnrepository.com/artifact/org.testng/testng/6.8.5
>>>>
>>>> because http://openjdk.java.net/jtreg/build.html now recommends 6.8.5 and
>>>> get the license file from:
>>>>
>>>> https://github.com/cbeust/testng
>>>>
>>>>> On Tue, Apr 12, 2016 at 2:11 PM, Jonathan Gibbons
>>>>> <jonathan.gibbons at oracle.com> wrote:
>>>>>>
>>>>>> On 04/11/2016 11:06 AM, Carsten Varming wrote:
>>>>>>> Dear jtreg devs,
>>>>>>>
>>>>>>> I wanted to download jtreg to run JDK9 hotspot regression tests, but I
>>>>>>> have been unsuccessful so far. Perhaps you know what I need to do to
>>>>>>> get
>>>>>>> going.
>>>>>>>
>>>>>>> The hotspot regression tests need at least jtreg 4.2 b01. When I
>>>>>>> downloaded the latest build published at
>>>>>>> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/ (4.2.0-tip, from
>>>>>>> build
>>>>>>> 496) and tried the hotspot regression tests I got:
>>>>>>>
>>>>>>> Error: Unexpected exception occurred! java.lang.NumberFormatException:
>>>>>>> For
>>>>>>> input string: "ip"
>>>>>>> java.lang.NumberFormatException: For input string: "ip"
>>>>>>>           at
>>>>>>>
>>>>>>>
>>>>>>> java.lang.NumberFormatException.forInputString(java.base at 9-internal/NumberFormatException.java:65)
>>>>>>>           at
>>>>>>> java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:695)
>>>>>>>           at
>>>>>>> java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:813)
>>>>>>>           at
>>>>>>> com.sun.javatest.regtest.Version.getBuild(Version.java:186)
>>>>>>>           at
>>>>>>> com.sun.javatest.regtest.Version.compareTo(Version.java:168)
>>>>>>>           at com.sun.javatest.regtest.Main.run(Main.java:1091)
>>>>>>>           at com.sun.javatest.regtest.Main.run(Main.java:1037)
>>>>>>>           at com.sun.javatest.regtest.Main.main(Main.java:951)
>>>>>>>
>>>>>>> I suspect the check against "requiredVersion=4.2 b01" from TEST.ROOT
>>>>>>>
>>>>>>>
>>>>>>> (http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/1c08ca66db33/test/TEST.ROOT)
>>>>>>> went wrong. I suspect "build = manifest.getProperty("jtreg-Build");"
>>>>>>> in
>>>>>>>
>>>>>>>
>>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/6bfef17a03d5/src/share/classes/com/sun/javatest/regtest/Version.java
>>>>>>> sets Version.build to "tip" and Version.getBuild tries to parse "ip"
>>>>>>> as
>>>>>>> a
>>>>>>> number. :(
>>>>>>>
>>>>>>> I tried to get past this problem by changing the required jtreg
>>>>>>> version
>>>>>>> to
>>>>>>> 4.1 b01. That gets the tests running, but a third of them fail with a
>>>>>>> class
>>>>>>> loading problem: A ClassFormatError is thrown with "Truncated class
>>>>>>> file".
>>>>>>> This seems to be due to a missing
>>>>>>> java/lang/reflect/JTRegModuleHelper.class.
>>>>>>> I suspect that this requirement was introduced with the module system
>>>>>>> that
>>>>>>> was integrated a few weeks ago.
>>>>>>>
>>>>>>> So, how do I get a version of jtreg that works with the latest JDK9?
>>>>>>>
>>>>>>> BTW. It looks like the jtreg build
>>>>>>> (https://adopt-openjdk.ci.cloudbees.com/job/jtreg/) is failing because
>>>>>>> of a
>>>>>>> missing dependency on testng.
>>>>>>>
>>>>>>> Help much appreaciated,
>>>>>>> Carsten
>>>>>>
>>>>>> The version of jtreg available on cloudbees.com has the following entry
>>>>>> in
>>>>>> its MANIFEST.MF,
>>>>>>
>>>>>>       jtreg-Build: tip
>>>>>>
>>>>>> and jtreg is naively assuming it to be of the form
>>>>>>       jtreg-Build: b<integer>
>>>>>>
>>>>>> I can make jtreg be more tolerant, but I also also note that the binary
>>>>>> is
>>>>>> missing lib/asmtools.jar, which is required by some tests.  The
>>>>>> contents
>>>>>> of
>>>>>> the tar bundle are all dated 25 January 2016, 10:47 which is somewhat
>>>>>> suspicious.
>>>>>>
>>>>>> -- Jon
>>>>


From david.holmes at oracle.com  Thu Jun  9 00:43:18 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 9 Jun 2016 10:43:18 +1000
Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32
In-Reply-To: <57569540.9010106@oracle.com>
References: <5746FDF3.3030102@oracle.com>
	<a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
	<57569540.9010106@oracle.com>
Message-ID: <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com>

Hi Leonid,

Sorry for the delay.

On 7/06/2016 7:34 PM, Leonid Mesnik wrote:
> Hi
>
> Added jtreg-use at openjdk.java.net
>
> I think that you are right. Here is the documentation:
> http://openjdk.java.net/jtreg/tag-spec.html
>
>
> "@requires <expression>
>
>     Express a dependence on characteristics of the system being tested.
>     Some harnesses allow tests to be selected according to the
>     characteristics of the system being tested. The expression may be
>     composed of the following elements:"
>
> "os.arch The operating system architecture, as given by the
> corresponding system property."
>
> So user could expect to have "os.arch" of tested VM.
>
> If filed jtreg issues for this:
>
>  1. CODETOOLS-7901695
>     <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
>     value 'os.arch' property of JDK which executed JDK and not of tested JDK
>
>
> Following fix could be used as a temporary workaround while jtreg fix is
> not ready.  Does it make a sense? I this case it is needed to change
> linux-arm64 back to linux-aarch64 to minimize changes.

I still think we have a fundamental problem concerning what os.arch 
means. This workaround seems to work but I find it all very confusing. 
We really need a vm.arch property, distinct from os.arch.

David
-----



> Leonid
>
> On 31.05.2016 04:26, David Holmes wrote:
>> Hi Leonid,
>>
>> This really strikes me as as a jtreg problem that should be fixed in
>> jtreg. When writing an @requires clause in a test the test writer
>> should not have to be thinking "oh wait! Is this going to query the VM
>> running jtreg or the VM running the test?". It should obviously be the
>> VM running the test.
>>
>> That said we also seem to have a problem with the definition of os.arch:
>>
>> os.arch     Operating system architecture
>>
>> if it is returning the build architecture of the VM and not the OS it
>> is running on. That in itself argues for two distinct properties.
>>
>> David
>>
>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>>> Hi
>>>
>>> Could you please review following fix:
>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>>> for bug
>>> https://bugs.openjdk.java.net/browse/JDK-8157831
>>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>>
>>> The property "os.name" which was used to filter tests depends on the
>>> arch of jdk which is used to run jtreg. It might differ from arch of
>>> tested jdk.
>>> This fix introduce new property "vm.arch" which depends on the arch of
>>> tested jdk and could be used to filter tests with @requires.
>>>
>>> I verified that tests are filtered where it is expected.
>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot
>>> testing.
>>>
>>> Leonid
>>>
>

From jonathan.gibbons at oracle.com  Fri Jun 10 23:09:30 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Fri, 10 Jun 2016 16:09:30 -0700
Subject: Status of jtreg build
In-Reply-To: <CA+kOe09xmZtSvAPka6ioSpTVcajQXsTc7rNJd9YnAU+CtHF3Sg@mail.gmail.com>
References: <CAP_pwnXOc0vfk6bMEoAu9X9D_Bcd-vg+T_TYyocKeCE1s3NFww@mail.gmail.com>	<570D648A.5020301@oracle.com>	<CA+kOe08Df0Dctxz9uWxoNpz2prqqyqmapuZOUG0ekDeWeXg_UQ@mail.gmail.com>	<CA+3eh11DB7ppJbtet5EooqA8XvGKtkT7-JOSZPp1GpGEaHeqzg@mail.gmail.com>
	<CA+kOe09xmZtSvAPka6ioSpTVcajQXsTc7rNJd9YnAU+CtHF3Sg@mail.gmail.com>
Message-ID: <575B48AA.3050907@oracle.com>

Martin, Volker, jtreg builders,

I've updated jtreg so that it can take testng-*.jar and jcommander-*.jar 
as found
on Maven.

Updated instructions are in
* make/Defs.gmk (if you use make)
* make/build.properties (if you use Ant)

https://bugs.openjdk.java.net/browse/CODETOOLS-7901669

-- Jon


On 04/13/2016 08:26 AM, Martin Buchholz wrote:
> Maven likes to have as many jar files as possible, so jcommander and
> testng are separated.
> But jtreg thinks testng.jar should contain jcommander, so I ended up
> having to build testng-jar-all
>
> (jtreg should probably switch to maven's view of the world and take
> jcommander as another dependency)
>
> Hacky build script snippet:
>
> # --- testng ---
> # Build "fat" testng.jar (incorporating jcommander) from source.
> # No one seems to distribute such fat testng jars anymore.
> rm -rf testng testng-*
> wget -qOtestng.zip https://github.com/cbeust/testng/archive/testng-6.8.5.zip
> unzip -q testng.zip
> rm testng.zip
> mv testng-* testng
> (
>    export JAVA_HOME="$HOME/jdk/jdk6"
>    export PATH=$JAVA_HOME/bin:$PATH
>    cd testng &&
>    mkdir -p ~/.ant/lib &&
>    cp ivy-2.1.0.jar ~/.ant/lib/. &&
>    ant clean compile copy-resources testng-jar-all &&
>    rm ~/.ant/lib/ivy-2.1.0.jar
> )
> TESTNG_HOME="$ROOT/testng"
> TESTNG_JAR=$(find "$ROOT/testng/target/" -name "testng*jar")
>
> On Tue, Apr 12, 2016 at 11:53 PM, Volker Simonis
> <volker.simonis at gmail.com> wrote:
>>
>> On Tue, Apr 12, 2016 at 11:28 PM, Martin Buchholz <martinrb at google.com>
>> wrote:
>>> jtreg build on
>>> https://adopt-openjdk.ci.cloudbees.com/
>>> is broken, as is its dependency asmtools
>>> The jtreg-4.2 build they advertise was created before there was any 4.2
>>> tag.
>>> They seem to be missing testng as a dependency.
>>> The project does keep trying (and failing) to build, however.
>>>
>>> I tried and failed to find on the Net the "full" testng-6.8.zip that
>>> used to be distributed on testng.org.
>>>
>> That seems true, but I think all you needed from the "full" testng-6.8.zip
>> was the LICENSE file. See jtreg/make/jtreg.gmk
>>
>> $(JTREG_IMAGEDIR)/legal/testng/LICENSE.txt: $(call
>> PosixPath,$(TESTNG_HOME)/LICENSE.txt)
>>          $(MKDIR) -p $(@D)
>>          $(CAT) $(TESTNG_HOME)/LICENSE.txt >> $@
>>
>> The testng jar file is specified by TESTNG_JAR anyway. So I think you can
>> download the jar from
>>
>> http://mvnrepository.com/artifact/org.testng/testng/6.8 or
>> http://mvnrepository.com/artifact/org.testng/testng/6.8.5
>>
>> because http://openjdk.java.net/jtreg/build.html now recommends 6.8.5 and
>> get the license file from:
>>
>> https://github.com/cbeust/testng
>>
>>> On Tue, Apr 12, 2016 at 2:11 PM, Jonathan Gibbons
>>> <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>> On 04/11/2016 11:06 AM, Carsten Varming wrote:
>>>>> Dear jtreg devs,
>>>>>
>>>>> I wanted to download jtreg to run JDK9 hotspot regression tests, but I
>>>>> have been unsuccessful so far. Perhaps you know what I need to do to
>>>>> get
>>>>> going.
>>>>>
>>>>> The hotspot regression tests need at least jtreg 4.2 b01. When I
>>>>> downloaded the latest build published at
>>>>> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/ (4.2.0-tip, from
>>>>> build
>>>>> 496) and tried the hotspot regression tests I got:
>>>>>
>>>>> Error: Unexpected exception occurred! java.lang.NumberFormatException:
>>>>> For
>>>>> input string: "ip"
>>>>> java.lang.NumberFormatException: For input string: "ip"
>>>>>          at
>>>>>
>>>>> java.lang.NumberFormatException.forInputString(java.base at 9-internal/NumberFormatException.java:65)
>>>>>          at
>>>>> java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:695)
>>>>>          at
>>>>> java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:813)
>>>>>          at com.sun.javatest.regtest.Version.getBuild(Version.java:186)
>>>>>          at com.sun.javatest.regtest.Version.compareTo(Version.java:168)
>>>>>          at com.sun.javatest.regtest.Main.run(Main.java:1091)
>>>>>          at com.sun.javatest.regtest.Main.run(Main.java:1037)
>>>>>          at com.sun.javatest.regtest.Main.main(Main.java:951)
>>>>>
>>>>> I suspect the check against "requiredVersion=4.2 b01" from TEST.ROOT
>>>>>
>>>>> (http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/1c08ca66db33/test/TEST.ROOT)
>>>>> went wrong. I suspect "build = manifest.getProperty("jtreg-Build");" in
>>>>>
>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/6bfef17a03d5/src/share/classes/com/sun/javatest/regtest/Version.java
>>>>> sets Version.build to "tip" and Version.getBuild tries to parse "ip" as
>>>>> a
>>>>> number. :(
>>>>>
>>>>> I tried to get past this problem by changing the required jtreg version
>>>>> to
>>>>> 4.1 b01. That gets the tests running, but a third of them fail with a
>>>>> class
>>>>> loading problem: A ClassFormatError is thrown with "Truncated class
>>>>> file".
>>>>> This seems to be due to a missing
>>>>> java/lang/reflect/JTRegModuleHelper.class.
>>>>> I suspect that this requirement was introduced with the module system
>>>>> that
>>>>> was integrated a few weeks ago.
>>>>>
>>>>> So, how do I get a version of jtreg that works with the latest JDK9?
>>>>>
>>>>> BTW. It looks like the jtreg build
>>>>> (https://adopt-openjdk.ci.cloudbees.com/job/jtreg/) is failing because
>>>>> of a
>>>>> missing dependency on testng.
>>>>>
>>>>> Help much appreaciated,
>>>>> Carsten
>>>>
>>>> The version of jtreg available on cloudbees.com has the following entry
>>>> in
>>>> its MANIFEST.MF,
>>>>
>>>>      jtreg-Build: tip
>>>>
>>>> and jtreg is naively assuming it to be of the form
>>>>      jtreg-Build: b<integer>
>>>>
>>>> I can make jtreg be more tolerant, but I also also note that the binary
>>>> is
>>>> missing lib/asmtools.jar, which is required by some tests.  The contents
>>>> of
>>>> the tar bundle are all dated 25 January 2016, 10:47 which is somewhat
>>>> suspicious.
>>>>
>>>> -- Jon
>>


From martinrb at google.com  Sat Jun 11 16:33:46 2016
From: martinrb at google.com (Martin Buchholz)
Date: Sat, 11 Jun 2016 09:33:46 -0700
Subject: Status of jtreg build
In-Reply-To: <575B48AA.3050907@oracle.com>
References: <CAP_pwnXOc0vfk6bMEoAu9X9D_Bcd-vg+T_TYyocKeCE1s3NFww@mail.gmail.com>
	<570D648A.5020301@oracle.com>
	<CA+kOe08Df0Dctxz9uWxoNpz2prqqyqmapuZOUG0ekDeWeXg_UQ@mail.gmail.com>
	<CA+3eh11DB7ppJbtet5EooqA8XvGKtkT7-JOSZPp1GpGEaHeqzg@mail.gmail.com>
	<CA+kOe09xmZtSvAPka6ioSpTVcajQXsTc7rNJd9YnAU+CtHF3Sg@mail.gmail.com>
	<575B48AA.3050907@oracle.com>
Message-ID: <CA+kOe0-39gG4U8y4zPYMUt_J-+U5piCXpO1A+UWsfXPJ+uBpgg@mail.gmail.com>

Thanks, Jonathan,

testng.org no longer tries to be a direct source of binary artifacts.
You might point them at
http://mvnrepository.com/artifact/com.beust/jcommander
http://mvnrepository.com/artifact/org.testng/testng

Looking at the Usages column at
http://mvnrepository.com/artifact/org.testng/testng, I would guess 6.9.6
was a bug fix release for 6.9.5.


On Fri, Jun 10, 2016 at 4:09 PM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> Martin, Volker, jtreg builders,
>
> I've updated jtreg so that it can take testng-*.jar and jcommander-*.jar
> as found
> on Maven.
>
> Updated instructions are in
> * make/Defs.gmk (if you use make)
> * make/build.properties (if you use Ant)
>
> https://bugs.openjdk.java.net/browse/CODETOOLS-7901669
>
> -- Jon
>
>
> On 04/13/2016 08:26 AM, Martin Buchholz wrote:
>
>> Maven likes to have as many jar files as possible, so jcommander and
>> testng are separated.
>> But jtreg thinks testng.jar should contain jcommander, so I ended up
>> having to build testng-jar-all
>>
>> (jtreg should probably switch to maven's view of the world and take
>> jcommander as another dependency)
>>
>> Hacky build script snippet:
>>
>> # --- testng ---
>> # Build "fat" testng.jar (incorporating jcommander) from source.
>> # No one seems to distribute such fat testng jars anymore.
>> rm -rf testng testng-*
>> wget -qOtestng.zip
>> https://github.com/cbeust/testng/archive/testng-6.8.5.zip
>> unzip -q testng.zip
>> rm testng.zip
>> mv testng-* testng
>> (
>>    export JAVA_HOME="$HOME/jdk/jdk6"
>>    export PATH=$JAVA_HOME/bin:$PATH
>>    cd testng &&
>>    mkdir -p ~/.ant/lib &&
>>    cp ivy-2.1.0.jar ~/.ant/lib/. &&
>>    ant clean compile copy-resources testng-jar-all &&
>>    rm ~/.ant/lib/ivy-2.1.0.jar
>> )
>> TESTNG_HOME="$ROOT/testng"
>> TESTNG_JAR=$(find "$ROOT/testng/target/" -name "testng*jar")
>>
>> On Tue, Apr 12, 2016 at 11:53 PM, Volker Simonis
>> <volker.simonis at gmail.com> wrote:
>>
>>>
>>> On Tue, Apr 12, 2016 at 11:28 PM, Martin Buchholz <martinrb at google.com>
>>> wrote:
>>>
>>>> jtreg build on
>>>> https://adopt-openjdk.ci.cloudbees.com/
>>>> is broken, as is its dependency asmtools
>>>> The jtreg-4.2 build they advertise was created before there was any 4.2
>>>> tag.
>>>> They seem to be missing testng as a dependency.
>>>> The project does keep trying (and failing) to build, however.
>>>>
>>>> I tried and failed to find on the Net the "full" testng-6.8.zip that
>>>> used to be distributed on testng.org.
>>>>
>>>> That seems true, but I think all you needed from the "full"
>>> testng-6.8.zip
>>> was the LICENSE file. See jtreg/make/jtreg.gmk
>>>
>>> $(JTREG_IMAGEDIR)/legal/testng/LICENSE.txt: $(call
>>> PosixPath,$(TESTNG_HOME)/LICENSE.txt)
>>>          $(MKDIR) -p $(@D)
>>>          $(CAT) $(TESTNG_HOME)/LICENSE.txt >> $@
>>>
>>> The testng jar file is specified by TESTNG_JAR anyway. So I think you can
>>> download the jar from
>>>
>>> http://mvnrepository.com/artifact/org.testng/testng/6.8 or
>>> http://mvnrepository.com/artifact/org.testng/testng/6.8.5
>>>
>>> because http://openjdk.java.net/jtreg/build.html now recommends 6.8.5
>>> and
>>> get the license file from:
>>>
>>> https://github.com/cbeust/testng
>>>
>>> On Tue, Apr 12, 2016 at 2:11 PM, Jonathan Gibbons
>>>> <jonathan.gibbons at oracle.com> wrote:
>>>>
>>>>>
>>>>> On 04/11/2016 11:06 AM, Carsten Varming wrote:
>>>>>
>>>>>> Dear jtreg devs,
>>>>>>
>>>>>> I wanted to download jtreg to run JDK9 hotspot regression tests, but I
>>>>>> have been unsuccessful so far. Perhaps you know what I need to do to
>>>>>> get
>>>>>> going.
>>>>>>
>>>>>> The hotspot regression tests need at least jtreg 4.2 b01. When I
>>>>>> downloaded the latest build published at
>>>>>> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/ (4.2.0-tip, from
>>>>>> build
>>>>>> 496) and tried the hotspot regression tests I got:
>>>>>>
>>>>>> Error: Unexpected exception occurred! java.lang.NumberFormatException:
>>>>>> For
>>>>>> input string: "ip"
>>>>>> java.lang.NumberFormatException: For input string: "ip"
>>>>>>          at
>>>>>>
>>>>>> java.lang.NumberFormatException.forInputString(java.base at 9-internal
>>>>>> /NumberFormatException.java:65)
>>>>>>          at
>>>>>> java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:695)
>>>>>>          at
>>>>>> java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:813)
>>>>>>          at
>>>>>> com.sun.javatest.regtest.Version.getBuild(Version.java:186)
>>>>>>          at
>>>>>> com.sun.javatest.regtest.Version.compareTo(Version.java:168)
>>>>>>          at com.sun.javatest.regtest.Main.run(Main.java:1091)
>>>>>>          at com.sun.javatest.regtest.Main.run(Main.java:1037)
>>>>>>          at com.sun.javatest.regtest.Main.main(Main.java:951)
>>>>>>
>>>>>> I suspect the check against "requiredVersion=4.2 b01" from TEST.ROOT
>>>>>>
>>>>>> (
>>>>>> http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/1c08ca66db33/test/TEST.ROOT
>>>>>> )
>>>>>> went wrong. I suspect "build = manifest.getProperty("jtreg-Build");"
>>>>>> in
>>>>>>
>>>>>>
>>>>>> http://hg.openjdk.java.net/code-tools/jtreg/file/6bfef17a03d5/src/share/classes/com/sun/javatest/regtest/Version.java
>>>>>> sets Version.build to "tip" and Version.getBuild tries to parse "ip"
>>>>>> as
>>>>>> a
>>>>>> number. :(
>>>>>>
>>>>>> I tried to get past this problem by changing the required jtreg
>>>>>> version
>>>>>> to
>>>>>> 4.1 b01. That gets the tests running, but a third of them fail with a
>>>>>> class
>>>>>> loading problem: A ClassFormatError is thrown with "Truncated class
>>>>>> file".
>>>>>> This seems to be due to a missing
>>>>>> java/lang/reflect/JTRegModuleHelper.class.
>>>>>> I suspect that this requirement was introduced with the module system
>>>>>> that
>>>>>> was integrated a few weeks ago.
>>>>>>
>>>>>> So, how do I get a version of jtreg that works with the latest JDK9?
>>>>>>
>>>>>> BTW. It looks like the jtreg build
>>>>>> (https://adopt-openjdk.ci.cloudbees.com/job/jtreg/) is failing
>>>>>> because
>>>>>> of a
>>>>>> missing dependency on testng.
>>>>>>
>>>>>> Help much appreaciated,
>>>>>> Carsten
>>>>>>
>>>>>
>>>>> The version of jtreg available on cloudbees.com has the following
>>>>> entry
>>>>> in
>>>>> its MANIFEST.MF,
>>>>>
>>>>>      jtreg-Build: tip
>>>>>
>>>>> and jtreg is naively assuming it to be of the form
>>>>>      jtreg-Build: b<integer>
>>>>>
>>>>> I can make jtreg be more tolerant, but I also also note that the binary
>>>>> is
>>>>> missing lib/asmtools.jar, which is required by some tests.  The
>>>>> contents
>>>>> of
>>>>> the tar bundle are all dated 25 January 2016, 10:47 which is somewhat
>>>>> suspicious.
>>>>>
>>>>> -- Jon
>>>>>
>>>>
>>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20160611/a9eef81d/attachment.html>

From jonathan.gibbons at oracle.com  Tue Jun 14 15:53:41 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Tue, 14 Jun 2016 08:53:41 -0700
Subject: Status of jtreg build
In-Reply-To: <CA+kOe0-39gG4U8y4zPYMUt_J-+U5piCXpO1A+UWsfXPJ+uBpgg@mail.gmail.com>
References: <CAP_pwnXOc0vfk6bMEoAu9X9D_Bcd-vg+T_TYyocKeCE1s3NFww@mail.gmail.com>
	<570D648A.5020301@oracle.com>
	<CA+kOe08Df0Dctxz9uWxoNpz2prqqyqmapuZOUG0ekDeWeXg_UQ@mail.gmail.com>
	<CA+3eh11DB7ppJbtet5EooqA8XvGKtkT7-JOSZPp1GpGEaHeqzg@mail.gmail.com>
	<CA+kOe09xmZtSvAPka6ioSpTVcajQXsTc7rNJd9YnAU+CtHF3Sg@mail.gmail.com>
	<575B48AA.3050907@oracle.com>
	<CA+kOe0-39gG4U8y4zPYMUt_J-+U5piCXpO1A+UWsfXPJ+uBpgg@mail.gmail.com>
Message-ID: <57602885.3030802@oracle.com>

I'll add some explanatory text re: location of binaries.

I'll add more text about versions.  It takes "process" to 
use/test/support newer versions, so my intent is to document the version 
being used in Oracle JDK org; others are free to use/try newer versions, 
and to report any issues they may encounter when using other versions.

-- Jon

On 06/11/2016 09:33 AM, Martin Buchholz wrote:
> Thanks, Jonathan,
>
> testng.org <http://testng.org> no longer tries to be a direct source 
> of binary artifacts.
> You might point them at
> http://mvnrepository.com/artifact/com.beust/jcommander
> http://mvnrepository.com/artifact/org.testng/testng
>
> Looking at the Usages column at 
> http://mvnrepository.com/artifact/org.testng/testng, I would guess 
> 6.9.6 was a bug fix release for 6.9.5.
>
>
> On Fri, Jun 10, 2016 at 4:09 PM, Jonathan Gibbons 
> <jonathan.gibbons at oracle.com <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>     Martin, Volker, jtreg builders,
>
>     I've updated jtreg so that it can take testng-*.jar and
>     jcommander-*.jar as found
>     on Maven.
>
>     Updated instructions are in
>     * make/Defs.gmk (if you use make)
>     * make/build.properties (if you use Ant)
>
>     https://bugs.openjdk.java.net/browse/CODETOOLS-7901669
>
>     -- Jon
>
>
>     On 04/13/2016 08:26 AM, Martin Buchholz wrote:
>
>         Maven likes to have as many jar files as possible, so
>         jcommander and
>         testng are separated.
>         But jtreg thinks testng.jar should contain jcommander, so I
>         ended up
>         having to build testng-jar-all
>
>         (jtreg should probably switch to maven's view of the world and
>         take
>         jcommander as another dependency)
>
>         Hacky build script snippet:
>
>         # --- testng ---
>         # Build "fat" testng.jar (incorporating jcommander) from source.
>         # No one seems to distribute such fat testng jars anymore.
>         rm -rf testng testng-*
>         wget -qOtestng.zip
>         https://github.com/cbeust/testng/archive/testng-6.8.5.zip
>         unzip -q testng.zip
>         rm testng.zip
>         mv testng-* testng
>         (
>            export JAVA_HOME="$HOME/jdk/jdk6"
>            export PATH=$JAVA_HOME/bin:$PATH
>            cd testng &&
>            mkdir -p ~/.ant/lib &&
>            cp ivy-2.1.0.jar ~/.ant/lib/. &&
>            ant clean compile copy-resources testng-jar-all &&
>            rm ~/.ant/lib/ivy-2.1.0.jar
>         )
>         TESTNG_HOME="$ROOT/testng"
>         TESTNG_JAR=$(find "$ROOT/testng/target/" -name "testng*jar")
>
>         On Tue, Apr 12, 2016 at 11:53 PM, Volker Simonis
>         <volker.simonis at gmail.com <mailto:volker.simonis at gmail.com>>
>         wrote:
>
>
>             On Tue, Apr 12, 2016 at 11:28 PM, Martin Buchholz
>             <martinrb at google.com <mailto:martinrb at google.com>>
>             wrote:
>
>                 jtreg build on
>                 https://adopt-openjdk.ci.cloudbees.com/
>                 is broken, as is its dependency asmtools
>                 The jtreg-4.2 build they advertise was created before
>                 there was any 4.2
>                 tag.
>                 They seem to be missing testng as a dependency.
>                 The project does keep trying (and failing) to build,
>                 however.
>
>                 I tried and failed to find on the Net the "full"
>                 testng-6.8.zip that
>                 used to be distributed on testng.org <http://testng.org>.
>
>             That seems true, but I think all you needed from the
>             "full" testng-6.8.zip
>             was the LICENSE file. See jtreg/make/jtreg.gmk
>
>             $(JTREG_IMAGEDIR)/legal/testng/LICENSE.txt: $(call
>             PosixPath,$(TESTNG_HOME)/LICENSE.txt)
>                      $(MKDIR) -p $(@D)
>                      $(CAT) $(TESTNG_HOME)/LICENSE.txt >> $@
>
>             The testng jar file is specified by TESTNG_JAR anyway. So
>             I think you can
>             download the jar from
>
>             http://mvnrepository.com/artifact/org.testng/testng/6.8 or
>             http://mvnrepository.com/artifact/org.testng/testng/6.8.5
>
>             because http://openjdk.java.net/jtreg/build.html now
>             recommends 6.8.5 and
>             get the license file from:
>
>             https://github.com/cbeust/testng
>
>                 On Tue, Apr 12, 2016 at 2:11 PM, Jonathan Gibbons
>                 <jonathan.gibbons at oracle.com
>                 <mailto:jonathan.gibbons at oracle.com>> wrote:
>
>
>                     On 04/11/2016 11:06 AM, Carsten Varming wrote:
>
>                         Dear jtreg devs,
>
>                         I wanted to download jtreg to run JDK9 hotspot
>                         regression tests, but I
>                         have been unsuccessful so far. Perhaps you
>                         know what I need to do to
>                         get
>                         going.
>
>                         The hotspot regression tests need at least
>                         jtreg 4.2 b01. When I
>                         downloaded the latest build published at
>                         https://adopt-openjdk.ci.cloudbees.com/job/jtreg/
>                         (4.2.0-tip, from
>                         build
>                         496) and tried the hotspot regression tests I got:
>
>                         Error: Unexpected exception occurred!
>                         java.lang.NumberFormatException:
>                         For
>                         input string: "ip"
>                         java.lang.NumberFormatException: For input
>                         string: "ip"
>                                  at
>
>                         java.lang.NumberFormatException.forInputString(java.base at 9-internal/NumberFormatException.java:65)
>                                  at
>                         java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:695)
>                                  at
>                         java.lang.Integer.parseInt(java.base at 9-internal/Integer.java:813)
>                                  at
>                         com.sun.javatest.regtest.Version.getBuild(Version.java:186)
>                                  at
>                         com.sun.javatest.regtest.Version.compareTo(Version.java:168)
>                                  at
>                         com.sun.javatest.regtest.Main.run(Main.java:1091)
>                                  at
>                         com.sun.javatest.regtest.Main.run(Main.java:1037)
>                                  at
>                         com.sun.javatest.regtest.Main.main(Main.java:951)
>
>                         I suspect the check against
>                         "requiredVersion=4.2 b01" from TEST.ROOT
>
>                         (http://hg.openjdk.java.net/jdk9/hs-rt/hotspot/file/1c08ca66db33/test/TEST.ROOT)
>                         went wrong. I suspect "build =
>                         manifest.getProperty("jtreg-Build");" in
>
>                         http://hg.openjdk.java.net/code-tools/jtreg/file/6bfef17a03d5/src/share/classes/com/sun/javatest/regtest/Version.java
>                         sets Version.build to "tip" and
>                         Version.getBuild tries to parse "ip" as
>                         a
>                         number. :(
>
>                         I tried to get past this problem by changing
>                         the required jtreg version
>                         to
>                         4.1 b01. That gets the tests running, but a
>                         third of them fail with a
>                         class
>                         loading problem: A ClassFormatError is thrown
>                         with "Truncated class
>                         file".
>                         This seems to be due to a missing
>                         java/lang/reflect/JTRegModuleHelper.class.
>                         I suspect that this requirement was introduced
>                         with the module system
>                         that
>                         was integrated a few weeks ago.
>
>                         So, how do I get a version of jtreg that works
>                         with the latest JDK9?
>
>                         BTW. It looks like the jtreg build
>                         (https://adopt-openjdk.ci.cloudbees.com/job/jtreg/)
>                         is failing because
>                         of a
>                         missing dependency on testng.
>
>                         Help much appreaciated,
>                         Carsten
>
>
>                     The version of jtreg available on cloudbees.com
>                     <http://cloudbees.com> has the following entry
>                     in
>                     its MANIFEST.MF,
>
>                          jtreg-Build: tip
>
>                     and jtreg is naively assuming it to be of the form
>                          jtreg-Build: b<integer>
>
>                     I can make jtreg be more tolerant, but I also also
>                     note that the binary
>                     is
>                     missing lib/asmtools.jar, which is required by
>                     some tests.  The contents
>                     of
>                     the tar bundle are all dated 25 January 2016,
>                     10:47 which is somewhat
>                     suspicious.
>
>                     -- Jon
>
>
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20160614/63be0139/attachment-0001.html>

From martinrb at google.com  Tue Jun 14 22:16:19 2016
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 14 Jun 2016 15:16:19 -0700
Subject: Status of jtreg build
In-Reply-To: <57602885.3030802@oracle.com>
References: <CAP_pwnXOc0vfk6bMEoAu9X9D_Bcd-vg+T_TYyocKeCE1s3NFww@mail.gmail.com>
	<570D648A.5020301@oracle.com>
	<CA+kOe08Df0Dctxz9uWxoNpz2prqqyqmapuZOUG0ekDeWeXg_UQ@mail.gmail.com>
	<CA+3eh11DB7ppJbtet5EooqA8XvGKtkT7-JOSZPp1GpGEaHeqzg@mail.gmail.com>
	<CA+kOe09xmZtSvAPka6ioSpTVcajQXsTc7rNJd9YnAU+CtHF3Sg@mail.gmail.com>
	<575B48AA.3050907@oracle.com>
	<CA+kOe0-39gG4U8y4zPYMUt_J-+U5piCXpO1A+UWsfXPJ+uBpgg@mail.gmail.com>
	<57602885.3030802@oracle.com>
Message-ID: <CA+kOe09neGXUwG3mnYjBQdtVwv=a+tcDYjxJTjLqU3UcTq1Rtg@mail.gmail.com>

On Tue, Jun 14, 2016 at 8:53 AM, Jonathan Gibbons <
jonathan.gibbons at oracle.com> wrote:

> I'll add some explanatory text re: location of binaries.
>
> I'll add more text about versions.  It takes "process" to use/test/support
> newer versions, so my intent is to document the version being used in
> Oracle JDK org; others are free to use/try newer versions, and to report
> any issues they may encounter when using other versions.
>

Thanks.  Yes, cross-version compatibility testing requires real effort, and
that effort would be more justified if jtreg was a library rather than a
binary.  As it is, updating to the latest upstream releases of dependencies
once every few years is reasonable.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20160614/01c7b9ab/attachment.html>

From leonid.mesnik at oracle.com  Thu Jun 16 10:47:32 2016
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Thu, 16 Jun 2016 13:47:32 +0300
Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32
In-Reply-To: <84a86cbe-8624-dea6-2127-8c704901b004@oracle.com>
References: <5746FDF3.3030102@oracle.com>
	<a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
	<57569540.9010106@oracle.com>
	<84a86cbe-8624-dea6-2127-8c704901b004@oracle.com>
Message-ID: <576283C4.4050008@oracle.com>

Hi

On 09.06.2016 03:43, David Holmes wrote:
> Hi Leonid,
>
> Sorry for the delay.
>
> On 7/06/2016 7:34 PM, Leonid Mesnik wrote:
>> Hi
>>
>> Added jtreg-use at openjdk.java.net
>>
>> I think that you are right. Here is the documentation:
>> http://openjdk.java.net/jtreg/tag-spec.html
>>
>>
>> "@requires <expression>
>>
>>     Express a dependence on characteristics of the system being tested.
>>     Some harnesses allow tests to be selected according to the
>>     characteristics of the system being tested. The expression may be
>>     composed of the following elements:"
>>
>> "os.arch The operating system architecture, as given by the
>> corresponding system property."
>>
>> So user could expect to have "os.arch" of tested VM.
>>
>> If filed jtreg issues for this:
>>
>>  1. CODETOOLS-7901695
>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
>>     value 'os.arch' property of JDK which executed JDK and not of 
>> tested JDK
>>
>>
>> Following fix could be used as a temporary workaround while jtreg fix is
>> not ready.  Does it make a sense? I this case it is needed to change
>> linux-arm64 back to linux-aarch64 to minimize changes.
>
> I still think we have a fundamental problem concerning what os.arch 
> means. This workaround seems to work but I find it all very confusing. 
> We really need a vm.arch property, distinct from os.arch.
I see that CODETOOLS-7901695 is going to be fixed. After it is 
implemented the 'os.arch' property will point to 'os.arch' of tested JDK 
as it described in jtreg documentation.
However there are 64 failures in nightly are caused by failures of JVMCI 
tests. Does it make a sense to implement this fix as a workaround to 
remove noise until jtreg is fixed?

Leonid
>
> David
> -----
>
>
>
>> Leonid
>>
>> On 31.05.2016 04:26, David Holmes wrote:
>>> Hi Leonid,
>>>
>>> This really strikes me as as a jtreg problem that should be fixed in
>>> jtreg. When writing an @requires clause in a test the test writer
>>> should not have to be thinking "oh wait! Is this going to query the VM
>>> running jtreg or the VM running the test?". It should obviously be the
>>> VM running the test.
>>>
>>> That said we also seem to have a problem with the definition of 
>>> os.arch:
>>>
>>> os.arch     Operating system architecture
>>>
>>> if it is returning the build architecture of the VM and not the OS it
>>> is running on. That in itself argues for two distinct properties.
>>>
>>> David
>>>
>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>>>> Hi
>>>>
>>>> Could you please review following fix:
>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>>>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>>>> for bug
>>>> https://bugs.openjdk.java.net/browse/JDK-8157831
>>>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>>>
>>>> The property "os.name" which was used to filter tests depends on the
>>>> arch of jdk which is used to run jtreg. It might differ from arch of
>>>> tested jdk.
>>>> This fix introduce new property "vm.arch" which depends on the arch of
>>>> tested jdk and could be used to filter tests with @requires.
>>>>
>>>> I verified that tests are filtered where it is expected.
>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot
>>>> testing.
>>>>
>>>> Leonid
>>>>
>>


From david.holmes at oracle.com  Thu Jun 16 10:55:30 2016
From: david.holmes at oracle.com (David Holmes)
Date: Thu, 16 Jun 2016 20:55:30 +1000
Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32
In-Reply-To: <576283C4.4050008@oracle.com>
References: <5746FDF3.3030102@oracle.com>
	<a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
	<57569540.9010106@oracle.com>
	<84a86cbe-8624-dea6-2127-8c704901b004@oracle.com>
	<576283C4.4050008@oracle.com>
Message-ID: <aa768e63-b7ec-18b5-3ee7-30dda3038dd7@oracle.com>

On 16/06/2016 8:47 PM, Leonid Mesnik wrote:
> Hi
>
> On 09.06.2016 03:43, David Holmes wrote:
>> Hi Leonid,
>>
>> Sorry for the delay.
>>
>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote:
>>> Hi
>>>
>>> Added jtreg-use at openjdk.java.net
>>>
>>> I think that you are right. Here is the documentation:
>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>
>>>
>>> "@requires <expression>
>>>
>>>     Express a dependence on characteristics of the system being tested.
>>>     Some harnesses allow tests to be selected according to the
>>>     characteristics of the system being tested. The expression may be
>>>     composed of the following elements:"
>>>
>>> "os.arch The operating system architecture, as given by the
>>> corresponding system property."
>>>
>>> So user could expect to have "os.arch" of tested VM.
>>>
>>> If filed jtreg issues for this:
>>>
>>>  1. CODETOOLS-7901695
>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
>>>     value 'os.arch' property of JDK which executed JDK and not of
>>> tested JDK
>>>
>>>
>>> Following fix could be used as a temporary workaround while jtreg fix is
>>> not ready.  Does it make a sense? I this case it is needed to change
>>> linux-arm64 back to linux-aarch64 to minimize changes.
>>
>> I still think we have a fundamental problem concerning what os.arch
>> means. This workaround seems to work but I find it all very confusing.
>> We really need a vm.arch property, distinct from os.arch.
> I see that CODETOOLS-7901695 is going to be fixed. After it is
> implemented the 'os.arch' property will point to 'os.arch' of tested JDK
> as it described in jtreg documentation.
> However there are 64 failures in nightly are caused by failures of JVMCI
> tests. Does it make a sense to implement this fix as a workaround to
> remove noise until jtreg is fixed?

There may be some delay between jtreg being fixed and the updated 
version being put in to use.

Implementing the workaround seems reasonable.

Thanks,
David

> Leonid
>>
>> David
>> -----
>>
>>
>>
>>> Leonid
>>>
>>> On 31.05.2016 04:26, David Holmes wrote:
>>>> Hi Leonid,
>>>>
>>>> This really strikes me as as a jtreg problem that should be fixed in
>>>> jtreg. When writing an @requires clause in a test the test writer
>>>> should not have to be thinking "oh wait! Is this going to query the VM
>>>> running jtreg or the VM running the test?". It should obviously be the
>>>> VM running the test.
>>>>
>>>> That said we also seem to have a problem with the definition of
>>>> os.arch:
>>>>
>>>> os.arch     Operating system architecture
>>>>
>>>> if it is returning the build architecture of the VM and not the OS it
>>>> is running on. That in itself argues for two distinct properties.
>>>>
>>>> David
>>>>
>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>>>>> Hi
>>>>>
>>>>> Could you please review following fix:
>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>>>>> hotspot http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>>>>> for bug
>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831
>>>>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>>>>
>>>>> The property "os.name" which was used to filter tests depends on the
>>>>> arch of jdk which is used to run jtreg. It might differ from arch of
>>>>> tested jdk.
>>>>> This fix introduce new property "vm.arch" which depends on the arch of
>>>>> tested jdk and could be used to filter tests with @requires.
>>>>>
>>>>> I verified that tests are filtered where it is expected.
>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot
>>>>> testing.
>>>>>
>>>>> Leonid
>>>>>
>>>
>

From leonid.mesnik at oracle.com  Thu Jun 16 12:34:33 2016
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Thu, 16 Jun 2016 15:34:33 +0300
Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32
In-Reply-To: <aa768e63-b7ec-18b5-3ee7-30dda3038dd7@oracle.com>
References: <5746FDF3.3030102@oracle.com>
	<a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
	<57569540.9010106@oracle.com>
	<84a86cbe-8624-dea6-2127-8c704901b004@oracle.com>
	<576283C4.4050008@oracle.com>
	<aa768e63-b7ec-18b5-3ee7-30dda3038dd7@oracle.com>
Message-ID: <57629CD9.40609@oracle.com>

Hi

I've updated fix

The vm.simpleArch variable has been added which corresponds to 
os.simpleArch of tested platform. All hotspot tests have been updated to 
use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to read 
'os.arch' from tested JDK then it would be possible just revert this fix 
and preserver same behavior (See CODETOOLS-7901695 
<https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>) .

Updated webrev:
http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/ 
<http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.01/root/>
http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/ 
<http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.01/hotspot/>

Testing is still in progress.

Leonid

On 16.06.2016 13:55, David Holmes wrote:
> On 16/06/2016 8:47 PM, Leonid Mesnik wrote:
>> Hi
>>
>> On 09.06.2016 03:43, David Holmes wrote:
>>> Hi Leonid,
>>>
>>> Sorry for the delay.
>>>
>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote:
>>>> Hi
>>>>
>>>> Added jtreg-use at openjdk.java.net
>>>>
>>>> I think that you are right. Here is the documentation:
>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>
>>>>
>>>> "@requires <expression>
>>>>
>>>>     Express a dependence on characteristics of the system being 
>>>> tested.
>>>>     Some harnesses allow tests to be selected according to the
>>>>     characteristics of the system being tested. The expression may be
>>>>     composed of the following elements:"
>>>>
>>>> "os.arch The operating system architecture, as given by the
>>>> corresponding system property."
>>>>
>>>> So user could expect to have "os.arch" of tested VM.
>>>>
>>>> If filed jtreg issues for this:
>>>>
>>>>  1. CODETOOLS-7901695
>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
>>>>     value 'os.arch' property of JDK which executed JDK and not of
>>>> tested JDK
>>>>
>>>>
>>>> Following fix could be used as a temporary workaround while jtreg 
>>>> fix is
>>>> not ready.  Does it make a sense? I this case it is needed to change
>>>> linux-arm64 back to linux-aarch64 to minimize changes.
>>>
>>> I still think we have a fundamental problem concerning what os.arch
>>> means. This workaround seems to work but I find it all very confusing.
>>> We really need a vm.arch property, distinct from os.arch.
>> I see that CODETOOLS-7901695 is going to be fixed. After it is
>> implemented the 'os.arch' property will point to 'os.arch' of tested JDK
>> as it described in jtreg documentation.
>> However there are 64 failures in nightly are caused by failures of JVMCI
>> tests. Does it make a sense to implement this fix as a workaround to
>> remove noise until jtreg is fixed?
>
> There may be some delay between jtreg being fixed and the updated 
> version being put in to use.
>
> Implementing the workaround seems reasonable.
>
> Thanks,
> David
>
>> Leonid
>>>
>>> David
>>> -----
>>>
>>>
>>>
>>>> Leonid
>>>>
>>>> On 31.05.2016 04:26, David Holmes wrote:
>>>>> Hi Leonid,
>>>>>
>>>>> This really strikes me as as a jtreg problem that should be fixed in
>>>>> jtreg. When writing an @requires clause in a test the test writer
>>>>> should not have to be thinking "oh wait! Is this going to query 
>>>>> the VM
>>>>> running jtreg or the VM running the test?". It should obviously be 
>>>>> the
>>>>> VM running the test.
>>>>>
>>>>> That said we also seem to have a problem with the definition of
>>>>> os.arch:
>>>>>
>>>>> os.arch     Operating system architecture
>>>>>
>>>>> if it is returning the build architecture of the VM and not the OS it
>>>>> is running on. That in itself argues for two distinct properties.
>>>>>
>>>>> David
>>>>>
>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>>>>>> Hi
>>>>>>
>>>>>> Could you please review following fix:
>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>>>>>> hotspot 
>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>>>>>> for bug
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831
>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>>>>>
>>>>>> The property "os.name" which was used to filter tests depends on the
>>>>>> arch of jdk which is used to run jtreg. It might differ from arch of
>>>>>> tested jdk.
>>>>>> This fix introduce new property "vm.arch" which depends on the 
>>>>>> arch of
>>>>>> tested jdk and could be used to filter tests with @requires.
>>>>>>
>>>>>> I verified that tests are filtered where it is expected.
>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot
>>>>>> testing.
>>>>>>
>>>>>> Leonid
>>>>>>
>>>>
>>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20160616/c4f86b79/attachment-0001.html>

From leonid.mesnik at oracle.com  Thu Jun 16 15:09:36 2016
From: leonid.mesnik at oracle.com (Leonid Mesnik)
Date: Thu, 16 Jun 2016 18:09:36 +0300
Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32
In-Reply-To: <5762AD73.9030506@oracle.com>
References: <5746FDF3.3030102@oracle.com>
	<a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
	<57569540.9010106@oracle.com>
	<84a86cbe-8624-dea6-2127-8c704901b004@oracle.com>
	<576283C4.4050008@oracle.com>
	<aa768e63-b7ec-18b5-3ee7-30dda3038dd7@oracle.com>
	<57629CD9.40609@oracle.com> <5762AD73.9030506@oracle.com>
Message-ID: <5762C130.5030607@oracle.com>

Thanks for reviewing.
The testing finished successfully. Still waiting for more reviews.

Leonid

On 16.06.2016 16:45, Dmitrij Pochepko wrote:
> Leonid,
>
> thank you for taking care of this issue.
> Looks good to me(not a reviewer).
>
> Thanks,
> Dmitrij
>> Hi
>>
>> I've updated fix
>>
>> The vm.simpleArch variable has been added which corresponds to 
>> os.simpleArch of tested platform. All hotspot tests have been updated 
>> to use vm.simpleArch instead of os.simpleArch. Once jtreg  is fixed 
>> to read 'os.arch' from tested JDK then it would be possible just 
>> revert this fix and preserver same behavior (See CODETOOLS-7901695 
>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>) .
>>
>> Updated webrev:
>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/
>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/
>>
>> Testing is still in progress.
>>
>> Leonid
>>
>> On 16.06.2016 13:55, David Holmes wrote:
>>> On 16/06/2016 8:47 PM, Leonid Mesnik wrote:
>>>> Hi
>>>>
>>>> On 09.06.2016 03:43, David Holmes wrote:
>>>>> Hi Leonid,
>>>>>
>>>>> Sorry for the delay.
>>>>>
>>>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote:
>>>>>> Hi
>>>>>>
>>>>>> Added jtreg-use at openjdk.java.net
>>>>>>
>>>>>> I think that you are right. Here is the documentation:
>>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>>
>>>>>>
>>>>>> "@requires <expression>
>>>>>>
>>>>>>     Express a dependence on characteristics of the system being 
>>>>>> tested.
>>>>>>     Some harnesses allow tests to be selected according to the
>>>>>>     characteristics of the system being tested. The expression 
>>>>>> may be
>>>>>>     composed of the following elements:"
>>>>>>
>>>>>> "os.arch The operating system architecture, as given by the
>>>>>> corresponding system property."
>>>>>>
>>>>>> So user could expect to have "os.arch" of tested VM.
>>>>>>
>>>>>> If filed jtreg issues for this:
>>>>>>
>>>>>>  1. CODETOOLS-7901695
>>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
>>>>>>     value 'os.arch' property of JDK which executed JDK and not of
>>>>>> tested JDK
>>>>>>
>>>>>>
>>>>>> Following fix could be used as a temporary workaround while jtreg 
>>>>>> fix is
>>>>>> not ready.  Does it make a sense? I this case it is needed to change
>>>>>> linux-arm64 back to linux-aarch64 to minimize changes.
>>>>>
>>>>> I still think we have a fundamental problem concerning what os.arch
>>>>> means. This workaround seems to work but I find it all very 
>>>>> confusing.
>>>>> We really need a vm.arch property, distinct from os.arch.
>>>> I see that CODETOOLS-7901695 is going to be fixed. After it is
>>>> implemented the 'os.arch' property will point to 'os.arch' of 
>>>> tested JDK
>>>> as it described in jtreg documentation.
>>>> However there are 64 failures in nightly are caused by failures of 
>>>> JVMCI
>>>> tests. Does it make a sense to implement this fix as a workaround to
>>>> remove noise until jtreg is fixed?
>>>
>>> There may be some delay between jtreg being fixed and the updated 
>>> version being put in to use.
>>>
>>> Implementing the workaround seems reasonable.
>>>
>>> Thanks,
>>> David
>>>
>>>> Leonid
>>>>>
>>>>> David
>>>>> -----
>>>>>
>>>>>
>>>>>
>>>>>> Leonid
>>>>>>
>>>>>> On 31.05.2016 04:26, David Holmes wrote:
>>>>>>> Hi Leonid,
>>>>>>>
>>>>>>> This really strikes me as as a jtreg problem that should be 
>>>>>>> fixed in
>>>>>>> jtreg. When writing an @requires clause in a test the test writer
>>>>>>> should not have to be thinking "oh wait! Is this going to query 
>>>>>>> the VM
>>>>>>> running jtreg or the VM running the test?". It should obviously 
>>>>>>> be the
>>>>>>> VM running the test.
>>>>>>>
>>>>>>> That said we also seem to have a problem with the definition of
>>>>>>> os.arch:
>>>>>>>
>>>>>>> os.arch     Operating system architecture
>>>>>>>
>>>>>>> if it is returning the build architecture of the VM and not the 
>>>>>>> OS it
>>>>>>> is running on. That in itself argues for two distinct properties.
>>>>>>>
>>>>>>> David
>>>>>>>
>>>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>>>>>>>> Hi
>>>>>>>>
>>>>>>>> Could you please review following fix:
>>>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>>>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>>>>>>>> hotspot 
>>>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>>>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>>>>>>>> for bug
>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831
>>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>>>>>>>
>>>>>>>> The property "os.name" which was used to filter tests depends 
>>>>>>>> on the
>>>>>>>> arch of jdk which is used to run jtreg. It might differ from 
>>>>>>>> arch of
>>>>>>>> tested jdk.
>>>>>>>> This fix introduce new property "vm.arch" which depends on the 
>>>>>>>> arch of
>>>>>>>> tested jdk and could be used to filter tests with @requires.
>>>>>>>>
>>>>>>>> I verified that tests are filtered where it is expected.
>>>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular 
>>>>>>>> hotspot
>>>>>>>> testing.
>>>>>>>>
>>>>>>>> Leonid
>>>>>>>>
>>>>>>
>>>>
>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20160616/f93e0fb2/attachment.html>

From david.holmes at oracle.com  Thu Jun 16 21:07:41 2016
From: david.holmes at oracle.com (David Holmes)
Date: Fri, 17 Jun 2016 07:07:41 +1000
Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32
In-Reply-To: <57629CD9.40609@oracle.com>
References: <5746FDF3.3030102@oracle.com>
	<a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
	<57569540.9010106@oracle.com>
	<84a86cbe-8624-dea6-2127-8c704901b004@oracle.com>
	<576283C4.4050008@oracle.com>
	<aa768e63-b7ec-18b5-3ee7-30dda3038dd7@oracle.com>
	<57629CD9.40609@oracle.com>
Message-ID: <58938c44-3915-9288-d329-481da167b0da@oracle.com>

Looks good!

Thanks,
David

On 16/06/2016 10:34 PM, Leonid Mesnik wrote:
> Hi
>
> I've updated fix
>
> The vm.simpleArch variable has been added which corresponds to
> os.simpleArch of tested platform. All hotspot tests have been updated to
> use vm.simpleArch instead of os.simpleArch. Once jtreg  is fixed to read
> 'os.arch' from tested JDK then it would be possible just revert this fix
> and preserver same behavior (See CODETOOLS-7901695
> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>) .
>
> Updated webrev:
> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.01/root/>http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/
> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.01/hotspot/>http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/
>
> Testing is still in progress.
>
> Leonid
>
> On 16.06.2016 13:55, David Holmes wrote:
>> On 16/06/2016 8:47 PM, Leonid Mesnik wrote:
>>> Hi
>>>
>>> On 09.06.2016 03:43, David Holmes wrote:
>>>> Hi Leonid,
>>>>
>>>> Sorry for the delay.
>>>>
>>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote:
>>>>> Hi
>>>>>
>>>>> Added jtreg-use at openjdk.java.net
>>>>>
>>>>> I think that you are right. Here is the documentation:
>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>
>>>>>
>>>>> "@requires <expression>
>>>>>
>>>>>     Express a dependence on characteristics of the system being
>>>>> tested.
>>>>>     Some harnesses allow tests to be selected according to the
>>>>>     characteristics of the system being tested. The expression may be
>>>>>     composed of the following elements:"
>>>>>
>>>>> "os.arch The operating system architecture, as given by the
>>>>> corresponding system property."
>>>>>
>>>>> So user could expect to have "os.arch" of tested VM.
>>>>>
>>>>> If filed jtreg issues for this:
>>>>>
>>>>>  1. CODETOOLS-7901695
>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
>>>>>     value 'os.arch' property of JDK which executed JDK and not of
>>>>> tested JDK
>>>>>
>>>>>
>>>>> Following fix could be used as a temporary workaround while jtreg
>>>>> fix is
>>>>> not ready.  Does it make a sense? I this case it is needed to change
>>>>> linux-arm64 back to linux-aarch64 to minimize changes.
>>>>
>>>> I still think we have a fundamental problem concerning what os.arch
>>>> means. This workaround seems to work but I find it all very confusing.
>>>> We really need a vm.arch property, distinct from os.arch.
>>> I see that CODETOOLS-7901695 is going to be fixed. After it is
>>> implemented the 'os.arch' property will point to 'os.arch' of tested JDK
>>> as it described in jtreg documentation.
>>> However there are 64 failures in nightly are caused by failures of JVMCI
>>> tests. Does it make a sense to implement this fix as a workaround to
>>> remove noise until jtreg is fixed?
>>
>> There may be some delay between jtreg being fixed and the updated
>> version being put in to use.
>>
>> Implementing the workaround seems reasonable.
>>
>> Thanks,
>> David
>>
>>> Leonid
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>
>>>>> Leonid
>>>>>
>>>>> On 31.05.2016 04:26, David Holmes wrote:
>>>>>> Hi Leonid,
>>>>>>
>>>>>> This really strikes me as as a jtreg problem that should be fixed in
>>>>>> jtreg. When writing an @requires clause in a test the test writer
>>>>>> should not have to be thinking "oh wait! Is this going to query
>>>>>> the VM
>>>>>> running jtreg or the VM running the test?". It should obviously be
>>>>>> the
>>>>>> VM running the test.
>>>>>>
>>>>>> That said we also seem to have a problem with the definition of
>>>>>> os.arch:
>>>>>>
>>>>>> os.arch     Operating system architecture
>>>>>>
>>>>>> if it is returning the build architecture of the VM and not the OS it
>>>>>> is running on. That in itself argues for two distinct properties.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Could you please review following fix:
>>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>>>>>>> hotspot
>>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>>>>>>> for bug
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>>>>>>
>>>>>>> The property "os.name" which was used to filter tests depends on the
>>>>>>> arch of jdk which is used to run jtreg. It might differ from arch of
>>>>>>> tested jdk.
>>>>>>> This fix introduce new property "vm.arch" which depends on the
>>>>>>> arch of
>>>>>>> tested jdk and could be used to filter tests with @requires.
>>>>>>>
>>>>>>> I verified that tests are filtered where it is expected.
>>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot
>>>>>>> testing.
>>>>>>>
>>>>>>> Leonid
>>>>>>>
>>>>>
>>>
>

From dmitrij.pochepko at oracle.com  Thu Jun 16 13:45:23 2016
From: dmitrij.pochepko at oracle.com (Dmitrij Pochepko)
Date: Thu, 16 Jun 2016 16:45:23 +0300
Subject: RFR: 8157831: JVMCI tests should not be executed on linux-arm32
In-Reply-To: <57629CD9.40609@oracle.com>
References: <5746FDF3.3030102@oracle.com>
	<a346027c-5f9b-4b82-b6f3-9b8657902759@oracle.com>
	<57569540.9010106@oracle.com>
	<84a86cbe-8624-dea6-2127-8c704901b004@oracle.com>
	<576283C4.4050008@oracle.com>
	<aa768e63-b7ec-18b5-3ee7-30dda3038dd7@oracle.com>
	<57629CD9.40609@oracle.com>
Message-ID: <5762AD73.9030506@oracle.com>

Leonid,

thank you for taking care of this issue.
Looks good to me(not a reviewer).

Thanks,
Dmitrij
> Hi
>
> I've updated fix
>
> The vm.simpleArch variable has been added which corresponds to 
> os.simpleArch of tested platform. All hotspot tests have been updated 
> to use vm.simpleArch instead of os.simpleArch. Once jtreg is fixed to 
> read 'os.arch' from tested JDK then it would be possible just revert 
> this fix and preserver same behavior (See CODETOOLS-7901695 
> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>) .
>
> Updated webrev:
> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/root/
> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.01/hotspot/
>
> Testing is still in progress.
>
> Leonid
>
> On 16.06.2016 13:55, David Holmes wrote:
>> On 16/06/2016 8:47 PM, Leonid Mesnik wrote:
>>> Hi
>>>
>>> On 09.06.2016 03:43, David Holmes wrote:
>>>> Hi Leonid,
>>>>
>>>> Sorry for the delay.
>>>>
>>>> On 7/06/2016 7:34 PM, Leonid Mesnik wrote:
>>>>> Hi
>>>>>
>>>>> Added jtreg-use at openjdk.java.net
>>>>>
>>>>> I think that you are right. Here is the documentation:
>>>>> http://openjdk.java.net/jtreg/tag-spec.html
>>>>>
>>>>>
>>>>> "@requires <expression>
>>>>>
>>>>>     Express a dependence on characteristics of the system being 
>>>>> tested.
>>>>>     Some harnesses allow tests to be selected according to the
>>>>>     characteristics of the system being tested. The expression may be
>>>>>     composed of the following elements:"
>>>>>
>>>>> "os.arch The operating system architecture, as given by the
>>>>> corresponding system property."
>>>>>
>>>>> So user could expect to have "os.arch" of tested VM.
>>>>>
>>>>> If filed jtreg issues for this:
>>>>>
>>>>>  1. CODETOOLS-7901695
>>>>> <https://bugs.openjdk.java.net/browse/CODETOOLS-7901695>jtreg uses
>>>>>     value 'os.arch' property of JDK which executed JDK and not of
>>>>> tested JDK
>>>>>
>>>>>
>>>>> Following fix could be used as a temporary workaround while jtreg 
>>>>> fix is
>>>>> not ready.  Does it make a sense? I this case it is needed to change
>>>>> linux-arm64 back to linux-aarch64 to minimize changes.
>>>>
>>>> I still think we have a fundamental problem concerning what os.arch
>>>> means. This workaround seems to work but I find it all very confusing.
>>>> We really need a vm.arch property, distinct from os.arch.
>>> I see that CODETOOLS-7901695 is going to be fixed. After it is
>>> implemented the 'os.arch' property will point to 'os.arch' of tested 
>>> JDK
>>> as it described in jtreg documentation.
>>> However there are 64 failures in nightly are caused by failures of 
>>> JVMCI
>>> tests. Does it make a sense to implement this fix as a workaround to
>>> remove noise until jtreg is fixed?
>>
>> There may be some delay between jtreg being fixed and the updated 
>> version being put in to use.
>>
>> Implementing the workaround seems reasonable.
>>
>> Thanks,
>> David
>>
>>> Leonid
>>>>
>>>> David
>>>> -----
>>>>
>>>>
>>>>
>>>>> Leonid
>>>>>
>>>>> On 31.05.2016 04:26, David Holmes wrote:
>>>>>> Hi Leonid,
>>>>>>
>>>>>> This really strikes me as as a jtreg problem that should be fixed in
>>>>>> jtreg. When writing an @requires clause in a test the test writer
>>>>>> should not have to be thinking "oh wait! Is this going to query 
>>>>>> the VM
>>>>>> running jtreg or the VM running the test?". It should obviously 
>>>>>> be the
>>>>>> VM running the test.
>>>>>>
>>>>>> That said we also seem to have a problem with the definition of
>>>>>> os.arch:
>>>>>>
>>>>>> os.arch     Operating system architecture
>>>>>>
>>>>>> if it is returning the build architecture of the VM and not the 
>>>>>> OS it
>>>>>> is running on. That in itself argues for two distinct properties.
>>>>>>
>>>>>> David
>>>>>>
>>>>>> On 26/05/2016 11:45 PM, Leonid Mesnik wrote:
>>>>>>> Hi
>>>>>>>
>>>>>>> Could you please review following fix:
>>>>>>> root http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/root/
>>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/root/>
>>>>>>> hotspot 
>>>>>>> http://cr.openjdk.java.net/~lmesnik/8157831/webrev.00/hotspot/
>>>>>>> <http://cr.openjdk.java.net/%7Elmesnik/8157831/webrev.00/hotspot/>
>>>>>>> for bug
>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8157831
>>>>>>> <https://bugs.openjdk.java.net/browse/JDK-8157831>
>>>>>>>
>>>>>>> The property "os.name" which was used to filter tests depends on 
>>>>>>> the
>>>>>>> arch of jdk which is used to run jtreg. It might differ from 
>>>>>>> arch of
>>>>>>> tested jdk.
>>>>>>> This fix introduce new property "vm.arch" which depends on the 
>>>>>>> arch of
>>>>>>> tested jdk and could be used to filter tests with @requires.
>>>>>>>
>>>>>>> I verified that tests are filtered where it is expected.
>>>>>>> Note: I am going to push this fix in jdk9/hs to fix regular hotspot
>>>>>>> testing.
>>>>>>>
>>>>>>> Leonid
>>>>>>>
>>>>>
>>>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/jtreg-use/attachments/20160616/a1b2240b/attachment-0001.html>

From david.dehaven at oracle.com  Mon Jun 27 21:10:47 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 27 Jun 2016 14:10:47 -0700
Subject: TestNG with test libraries
Message-ID: <DCFD28DA-198E-463E-ABB7-CAD8C18FFBF8@oracle.com>


We have a directory marked as TestNG tests but some helper classes outside that directory that we would like to use. Since TestNG tests don't use the @test (or can they?) is there a way to tell jtreg/testng to add the library to the classpath when building/running?

-DrD-


From jonathan.gibbons at oracle.com  Mon Jun 27 21:19:54 2016
From: jonathan.gibbons at oracle.com (Jonathan Gibbons)
Date: Mon, 27 Jun 2016 14:19:54 -0700
Subject: TestNG with test libraries
In-Reply-To: <DCFD28DA-198E-463E-ABB7-CAD8C18FFBF8@oracle.com>
References: <DCFD28DA-198E-463E-ABB7-CAD8C18FFBF8@oracle.com>
Message-ID: <5771987A.2000600@oracle.com>



On 06/27/2016 02:10 PM, David DeHaven wrote:
> We have a directory marked as TestNG tests but some helper classes outside that directory that we would like to use. Since TestNG tests don't use the @test (or can they?) is there a way to tell jtreg/testng to add the library to the classpath when building/running?
>
> -DrD-
>

Are you using the TEST.properties mechanism to declare a directory full 
of just TestNG tests?

Assuming you are following the convention to put a TEST.proiperties file 
in the root dir of your TestNG hierarchy, with an entry like
     TestNG.dirs = .

add another property
     lib.dirs = <path>

where <path> is what you might otherwise put in a @library tag, i.e.  a 
path that does not begin with '/', which with be evaluated relative to 
the immediately enclosing directory, or a path that does begin with '/', 
which will be evaluated relative to the root directory of the test suite 
(i.e. the directory containing the TEST.ROOT file).


TestNG tests can actually contain @test directives, but only for 
documentary info, like @bug, @synopsis, etc.

-- Jon

From david.dehaven at oracle.com  Mon Jun 27 21:54:21 2016
From: david.dehaven at oracle.com (David DeHaven)
Date: Mon, 27 Jun 2016 14:54:21 -0700
Subject: TestNG with test libraries
In-Reply-To: <5771987A.2000600@oracle.com>
References: <DCFD28DA-198E-463E-ABB7-CAD8C18FFBF8@oracle.com>
	<5771987A.2000600@oracle.com>
Message-ID: <0F0FDD9A-6413-4A47-884E-A59A4C2ADAAF@oracle.com>


>> We have a directory marked as TestNG tests but some helper classes outside that directory that we would like to use. Since TestNG tests don't use the @test (or can they?) is there a way to tell jtreg/testng to add the library to the classpath when building/running?
>> 
>> -DrD-
>> 
> 
> Are you using the TEST.properties mechanism to declare a directory full of just TestNG tests?
> 
> Assuming you are following the convention to put a TEST.proiperties file in the root dir of your TestNG hierarchy, with an entry like
>    TestNG.dirs = .
> 
> add another property
>    lib.dirs = <path>
> 
> where <path> is what you might otherwise put in a @library tag, i.e.  a path that does not begin with '/', which with be evaluated relative to the immediately enclosing directory, or a path that does begin with '/', which will be evaluated relative to the root directory of the test suite (i.e. the directory containing the TEST.ROOT file).

Oh, right, I didn't think of that. We're using TEST.properties to set up the addReads arguments...

-DrD-