From peter.brunet at oracle.com Wed Jun 3 23:27:58 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 03 Jun 2015 18:27:58 -0500 Subject: cpp files Message-ID: <556F8D7E.2020304@oracle.com> Hi, As part of my test I need to build a simple DLL and then load it from my test class. Can jtreg build the DLL or will I need to create it and include it in my test directory? -Pete From jonathan.gibbons at oracle.com Thu Jun 4 01:13:05 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 03 Jun 2015 18:13:05 -0700 Subject: cpp files In-Reply-To: <556F8D7E.2020304@oracle.com> References: <556F8D7E.2020304@oracle.com> Message-ID: <556FA621.4000108@oracle.com> On 06/03/2015 04:27 PM, Pete Brunet wrote: > Hi, As part of my test I need to build a simple DLL and then load it > from my test class. Can jtreg build the DLL or will I need to create it > and include it in my test directory? -Pete jtreg cannot directly compile native code. In theory, you could do it in a shell script, but that immediately becomes a rats nest of "which platform, and where do I find the compilers?" If you are talking about native code and tests in OpenJDK repositories, then it is not acceptable to stash binaries in OpenJDK repositories. But, there is an infrastructure in place for an OpenJDK build to build native libraries to be made available to test code. Perhaps someone else on this list can explain how that works. -- Jon From peter.brunet at oracle.com Thu Jun 4 01:43:39 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 03 Jun 2015 20:43:39 -0500 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FA621.4000108@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> Message-ID: <556FAD4B.4000700@oracle.com> Cross posting to build-dev for possible insight regarding Jon's last paragraph below. On 6/3/15 8:13 PM, Jonathan Gibbons wrote: > > On 06/03/2015 04:27 PM, Pete Brunet wrote: >> Hi, As part of my test I need to build a simple DLL and then load it >> from my test class. Can jtreg build the DLL or will I need to create it >> and include it in my test directory? -Pete > > jtreg cannot directly compile native code. In theory, you could do it > in a shell script, but that immediately becomes a rats nest of "which > platform, and where do I find the compilers?" > > If you are talking about native code and tests in OpenJDK > repositories, then it is not acceptable to stash binaries in OpenJDK > repositories. But, there is an infrastructure in place for an OpenJDK > build to build native libraries to be made available to test code. > Perhaps someone else on this list can explain how that works. > > -- Jon From peter.brunet at oracle.com Thu Jun 4 02:33:01 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Wed, 03 Jun 2015 21:33:01 -0500 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FAD4B.4000700@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> Message-ID: <556FB8DD.2030309@oracle.com> On 6/3/15 8:43 PM, Pete Brunet wrote: > Cross posting to build-dev for possible insight regarding Jon's last > paragraph below. > > On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>> Hi, As part of my test I need to build a simple DLL and then load it >>> from my test class. Can jtreg build the DLL or will I need to create it >>> and include it in my test directory? -Pete >> jtreg cannot directly compile native code. In theory, you could do it >> in a shell script, but that immediately becomes a rats nest of "which >> platform, and where do I find the compilers?" Is there a way to only run the test if running on Win? The DLL will be used as part of a test of a platform independent feature. Would only running on Win be acceptable? Is "where to I find the compilers" still an issue in a Win only case? >> >> If you are talking about native code and tests in OpenJDK >> repositories, then it is not acceptable to stash binaries in OpenJDK >> repositories. But, there is an infrastructure in place for an OpenJDK >> build to build native libraries to be made available to test code. >> Perhaps someone else on this list can explain how that works. >> >> -- Jon From david.holmes at oracle.com Thu Jun 4 05:10:06 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jun 2015 15:10:06 +1000 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FAD4B.4000700@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> Message-ID: <556FDDAE.9010309@oracle.com> Peter, On 4/06/2015 11:43 AM, Pete Brunet wrote: > Cross posting to build-dev for possible insight regarding Jon's last > paragraph below. See jdk/make/test/JtregNative.gmk and other references to test-image. David > On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >> >> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>> Hi, As part of my test I need to build a simple DLL and then load it >>> from my test class. Can jtreg build the DLL or will I need to create it >>> and include it in my test directory? -Pete >> >> jtreg cannot directly compile native code. In theory, you could do it >> in a shell script, but that immediately becomes a rats nest of "which >> platform, and where do I find the compilers?" >> >> If you are talking about native code and tests in OpenJDK >> repositories, then it is not acceptable to stash binaries in OpenJDK >> repositories. But, there is an infrastructure in place for an OpenJDK >> build to build native libraries to be made available to test code. >> Perhaps someone else on this list can explain how that works. >> >> -- Jon > From david.holmes at oracle.com Thu Jun 4 05:13:14 2015 From: david.holmes at oracle.com (David Holmes) Date: Thu, 04 Jun 2015 15:13:14 +1000 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FB8DD.2030309@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FB8DD.2030309@oracle.com> Message-ID: <556FDE6A.3050403@oracle.com> On 4/06/2015 12:33 PM, Pete Brunet wrote: > > On 6/3/15 8:43 PM, Pete Brunet wrote: >> Cross posting to build-dev for possible insight regarding Jon's last >> paragraph below. >> >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>>> Hi, As part of my test I need to build a simple DLL and then load it >>>> from my test class. Can jtreg build the DLL or will I need to create it >>>> and include it in my test directory? -Pete >>> jtreg cannot directly compile native code. In theory, you could do it >>> in a shell script, but that immediately becomes a rats nest of "which >>> platform, and where do I find the compilers?" > Is there a way to only run the test if running on Win? The DLL will be @requires os.family == windows Or something like that. David ----- > used as part of a test of a platform independent feature. Would only > running on Win be acceptable? Is "where to I find the compilers" still > an issue in a Win only case? >>> >>> If you are talking about native code and tests in OpenJDK >>> repositories, then it is not acceptable to stash binaries in OpenJDK >>> repositories. But, there is an infrastructure in place for an OpenJDK >>> build to build native libraries to be made available to test code. >>> Perhaps someone else on this list can explain how that works. >>> >>> -- Jon > From denisl at openscg.com Thu Jun 4 19:20:03 2015 From: denisl at openscg.com (Lussier, Denis) Date: Thu, 4 Jun 2015 15:20:03 -0400 Subject: need to build a DLL for an openjdk test In-Reply-To: References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FDDAE.9010309@oracle.com> Message-ID: In my personal JDK6/7 experience from a couple years back, the Windows OpenJDK build environment is an order of magnitude trickier to work thru than the Linux one. You need outdated versions of lots of tools, utilities, environments, compilers and operating systems to get it all right (a single binary that runs on old & new Windows versions with just a simple non-root install with no rebooting). In the end you get something that works darn well (although there were still rough edges in the area of Swings Fonts and Sound a couple years back). Not suer if the Oracle propietary binaries still use non GPL components in these areas on Windows. --Luss On Thu, Jun 4, 2015 at 4:18 AM, Staffan Larsen wrote: > > > On 4 jun 2015, at 07:10, David Holmes wrote: > > > > Peter, > > > > On 4/06/2015 11:43 AM, Pete Brunet wrote: > >> Cross posting to build-dev for possible insight regarding Jon's last > >> paragraph below. > > > > See jdk/make/test/JtregNative.gmk and other references to test-image. > > There are example tests in jdk/test/native_sanity - take a look at those. > > /Staffan > > > > > David > > > >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: > >>> > >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: > >>>> Hi, As part of my test I need to build a simple DLL and then load it > >>>> from my test class. Can jtreg build the DLL or will I need to create > it > >>>> and include it in my test directory? -Pete > >>> > >>> jtreg cannot directly compile native code. In theory, you could do it > >>> in a shell script, but that immediately becomes a rats nest of "which > >>> platform, and where do I find the compilers?" > >>> > >>> If you are talking about native code and tests in OpenJDK > >>> repositories, then it is not acceptable to stash binaries in OpenJDK > >>> repositories. But, there is an infrastructure in place for an OpenJDK > >>> build to build native libraries to be made available to test code. > >>> Perhaps someone else on this list can explain how that works. > >>> > >>> -- Jon > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Thu Jun 4 08:18:49 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 4 Jun 2015 10:18:49 +0200 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FDDAE.9010309@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FDDAE.9010309@oracle.com> Message-ID: > On 4 jun 2015, at 07:10, David Holmes wrote: > > Peter, > > On 4/06/2015 11:43 AM, Pete Brunet wrote: >> Cross posting to build-dev for possible insight regarding Jon's last >> paragraph below. > > See jdk/make/test/JtregNative.gmk and other references to test-image. There are example tests in jdk/test/native_sanity - take a look at those. /Staffan > > David > >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >>> >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>>> Hi, As part of my test I need to build a simple DLL and then load it >>>> from my test class. Can jtreg build the DLL or will I need to create it >>>> and include it in my test directory? -Pete >>> >>> jtreg cannot directly compile native code. In theory, you could do it >>> in a shell script, but that immediately becomes a rats nest of "which >>> platform, and where do I find the compilers?" >>> >>> If you are talking about native code and tests in OpenJDK >>> repositories, then it is not acceptable to stash binaries in OpenJDK >>> repositories. But, there is an infrastructure in place for an OpenJDK >>> build to build native libraries to be made available to test code. >>> Perhaps someone else on this list can explain how that works. >>> >>> -- Jon >> From staffan.larsen at oracle.com Thu Jun 4 08:20:17 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 4 Jun 2015 10:20:17 +0200 Subject: need to build a DLL for an openjdk test In-Reply-To: <556FB8DD.2030309@oracle.com> References: <556F8D7E.2020304@oracle.com> <556FA621.4000108@oracle.com> <556FAD4B.4000700@oracle.com> <556FB8DD.2030309@oracle.com> Message-ID: <4E6AB5A1-1167-4603-B348-BAEB6AB43E0D@oracle.com> > On 4 jun 2015, at 04:33, Pete Brunet wrote: > > > On 6/3/15 8:43 PM, Pete Brunet wrote: >> Cross posting to build-dev for possible insight regarding Jon's last >> paragraph below. >> >> On 6/3/15 8:13 PM, Jonathan Gibbons wrote: >>> On 06/03/2015 04:27 PM, Pete Brunet wrote: >>>> Hi, As part of my test I need to build a simple DLL and then load it >>>> from my test class. Can jtreg build the DLL or will I need to create it >>>> and include it in my test directory? -Pete >>> jtreg cannot directly compile native code. In theory, you could do it >>> in a shell script, but that immediately becomes a rats nest of "which >>> platform, and where do I find the compilers?" > Is there a way to only run the test if running on Win? The DLL will be > used as part of a test of a platform independent feature. Would only > running on Win be acceptable? Is "where to I find the compilers" still > an issue in a Win only case? Yes - most test machines don?t have compilers on them. All compilation has to be done as part of the build. >>> >>> If you are talking about native code and tests in OpenJDK >>> repositories, then it is not acceptable to stash binaries in OpenJDK >>> repositories. But, there is an infrastructure in place for an OpenJDK >>> build to build native libraries to be made available to test code. >>> Perhaps someone else on this list can explain how that works. >>> >>> -- Jon > From peter.brunet at oracle.com Fri Jun 5 06:01:17 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 05 Jun 2015 01:01:17 -0500 Subject: Code not being run in JTREG environment In-Reply-To: <557138A2.9070103@oracle.com> References: <5571339E.5080902@oracle.com> <557138A2.9070103@oracle.com> Message-ID: <55713B2D.9080604@oracle.com> Hi, When I run java from the command line I can tell my code in java.awt.Toolkit.getDefaultToolkit is running but when I run in a JTREG environment I don't see any indication that the code is executing. The jtr log shows that my test java is being invoked and when I use -version the right version string appears in the log. Any ideas on what I might be doing wrong? Thanks, Pete From david.holmes at oracle.com Fri Jun 5 06:06:45 2015 From: david.holmes at oracle.com (David Holmes) Date: Fri, 05 Jun 2015 16:06:45 +1000 Subject: Code not being run in JTREG environment In-Reply-To: <55713B2D.9080604@oracle.com> References: <5571339E.5080902@oracle.com> <557138A2.9070103@oracle.com> <55713B2D.9080604@oracle.com> Message-ID: <55713C75.3060306@oracle.com> Hi Peter, On 5/06/2015 4:01 PM, Pete Brunet wrote: > Hi, When I run java from the command line I can tell my code in > java.awt.Toolkit.getDefaultToolkit is running but when I run in a JTREG > environment I don't see any indication that the code is executing. The > jtr log shows that my test java is being invoked and when I use -version > the right version string appears in the log. > > Any ideas on what I might be doing wrong? Need more info. How are you running jtreg? How is your test launched ie othervm ? Is output from the test itself seen? David > Thanks, Pete > From peter.brunet at oracle.com Fri Jun 5 12:57:27 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 05 Jun 2015 07:57:27 -0500 Subject: Code not being run in JTREG environment In-Reply-To: <55713C75.3060306@oracle.com> References: <5571339E.5080902@oracle.com> <557138A2.9070103@oracle.com> <55713B2D.9080604@oracle.com> <55713C75.3060306@oracle.com> Message-ID: <55719CB7.1080601@oracle.com> On 6/5/15 1:06 AM, David Holmes wrote: > Hi Peter, > > On 5/06/2015 4:01 PM, Pete Brunet wrote: >> Hi, When I run java from the command line I can tell my code in >> java.awt.Toolkit.getDefaultToolkit is running but when I run in a JTREG >> environment I don't see any indication that the code is executing. The >> jtr log shows that my test java is being invoked and when I use -version >> the right version string appears in the log. >> >> Any ideas on what I might be doing wrong? > > Need more info. How are you running jtreg? How is your test launched > ie othervm ? Is output from the test itself seen? Hi David, This is the invocation with the prompt at the client directory of the local repo: /cygdrive/c/Users/Pete/jtreg/bin/jtreg -jdk:./build/windows-x86_64-normal-server-release/images/jdk ./jdk/test/javax/accessibility/AccessibilityProvider/ This is from the shell script: # @test # @bug 8055160 # @summary Unit test for javax.accessibility.AccessibilitySPI # # @build Load FooProvider BarProvider UnusedProvider # @run shell basic.sh # # Command-line usage: sh basic.sh /path/to/build This is from the jtr file: Working Directory: /cygdrive/c/Users/Pete/JDK9/JDK-8055160/client/JTwork/scratch + C:/Users/Pete/JDK9/JDK-8055160/client/./build/windows-x86_64-normal-server-release/images/jdk/bin/java -Djavax.accessibility.assistive_technologies=FooProvider -cp 'C:/Users/Pete/JDK9/JDK-8055160/client/JTwork/classes/javax/accessibility/AccessibilityProvider;x.test' Load pass FooProvider Working Directory: C:\\Users\\Pete\\JDK9\\JDK-8055160\\client\\JTwork\\scratch Exception in thread "main" java.lang.RuntimeException: FooProvider was not activated at Load.main(Load.java:78) I don't see any output from printlns (or existence of a debug file I create) in java.awt.Toolkit.getDefaultToolkit but I do see all output from my test. This might not be a show stopper for me. I could call java.awt.Toolkit.getDefaultToolkit from my test but I want to understand why it's called when running my java.exe from the command line but not from within jtreg. Maybe I am not using jtreg correctly. I added awt-dev list in case that group might know the answer. Later in the morning I'll put a Thread.dumpStack in getDefaultToolkit and maybe that will give me a hint as to why it is called in the non-jtreg case but not in the jtreg environment. Pete > > David > >> Thanks, Pete >> From jonathan.gibbons at oracle.com Fri Jun 5 15:14:32 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 05 Jun 2015 08:14:32 -0700 Subject: Code not being run in JTREG environment In-Reply-To: <55719CB7.1080601@oracle.com> References: <5571339E.5080902@oracle.com> <557138A2.9070103@oracle.com> <55713B2D.9080604@oracle.com> <55713C75.3060306@oracle.com> <55719CB7.1080601@oracle.com> Message-ID: <5571BCD8.3020805@oracle.com> Pete, As a matter of style, note that jtreg directives can span lines, and so # @run shell basic.sh # # Command-line usage: sh basic.sh /path/to/build is equivalent to # @run shell basic.sh Command-line usage: sh basic.sh /path/to/build because it is all in the same comment block. I'd recommend deleting the # character on the intervening line, so that it reads # @run shell basic.sh # Command-line usage: sh basic.sh /path/to/build As for why your test might behave differently in a jtreg environment, are you dependent on any environment variables? jtreg specifically runs with a limited set of env vars set. See the jtreg tag spec and/or the command line help for more details (or ask here) if you think this might be a factor. -- Jon On 06/05/2015 05:57 AM, Pete Brunet wrote: > > On 6/5/15 1:06 AM, David Holmes wrote: >> Hi Peter, >> >> On 5/06/2015 4:01 PM, Pete Brunet wrote: >>> Hi, When I run java from the command line I can tell my code in >>> java.awt.Toolkit.getDefaultToolkit is running but when I run in a JTREG >>> environment I don't see any indication that the code is executing. The >>> jtr log shows that my test java is being invoked and when I use -version >>> the right version string appears in the log. >>> >>> Any ideas on what I might be doing wrong? >> Need more info. How are you running jtreg? How is your test launched >> ie othervm ? Is output from the test itself seen? > Hi David, This is the invocation with the prompt at the client directory > of the local repo: > > /cygdrive/c/Users/Pete/jtreg/bin/jtreg > -jdk:./build/windows-x86_64-normal-server-release/images/jdk > ./jdk/test/javax/accessibility/AccessibilityProvider/ > > This is from the shell script: > > # @test > # @bug 8055160 > # @summary Unit test for javax.accessibility.AccessibilitySPI > # > # @build Load FooProvider BarProvider UnusedProvider > # @run shell basic.sh > # > # Command-line usage: sh basic.sh /path/to/build > > This is from the jtr file: > > Working Directory: > /cygdrive/c/Users/Pete/JDK9/JDK-8055160/client/JTwork/scratch > + > C:/Users/Pete/JDK9/JDK-8055160/client/./build/windows-x86_64-normal-server-release/images/jdk/bin/java > -Djavax.accessibility.assistive_technologies=FooProvider -cp > 'C:/Users/Pete/JDK9/JDK-8055160/client/JTwork/classes/javax/accessibility/AccessibilityProvider;x.test' > Load pass FooProvider > Working Directory: > C:\\Users\\Pete\\JDK9\\JDK-8055160\\client\\JTwork\\scratch > Exception in thread "main" java.lang.RuntimeException: FooProvider was > not activated > at Load.main(Load.java:78) > > I don't see any output from printlns (or existence of a debug file I > create) in java.awt.Toolkit.getDefaultToolkit but I do see all output > from my test. > > This might not be a show stopper for me. I could call > java.awt.Toolkit.getDefaultToolkit from my test but I want to understand > why it's called when running my java.exe from the command line but not > from within jtreg. Maybe I am not using jtreg correctly. > > I added awt-dev list in case that group might know the answer. > > Later in the morning I'll put a Thread.dumpStack in getDefaultToolkit > and maybe that will give me a hint as to why it is called in the > non-jtreg case but not in the jtreg environment. > > Pete >> David >> >>> Thanks, Pete >>> From peter.brunet at oracle.com Fri Jun 5 15:26:29 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 05 Jun 2015 10:26:29 -0500 Subject: Code not being run in JTREG environment In-Reply-To: <5571BCD8.3020805@oracle.com> References: <5571339E.5080902@oracle.com> <557138A2.9070103@oracle.com> <55713B2D.9080604@oracle.com> <55713C75.3060306@oracle.com> <55719CB7.1080601@oracle.com> <5571BCD8.3020805@oracle.com> Message-ID: <5571BFA5.6090009@oracle.com> On 6/5/15 10:14 AM, Jonathan Gibbons wrote: > Pete, > > As a matter of style, note that jtreg directives can span lines, and so > > # @run shell basic.sh > # > # Command-line usage: sh basic.sh /path/to/build > > is equivalent to > > # @run shell basic.sh Command-line usage: sh basic.sh /path/to/build > > because it is all in the same comment block. > > I'd recommend deleting the # character on the intervening line, so that > it reads > > # @run shell basic.sh > > # Command-line usage: sh basic.sh /path/to/build Thanks Jon, I deleted the # (and left it as a blank line). > > > As for why your test might behave differently in a jtreg environment, > are you dependent on any environment variables? jtreg specifically > runs with a limited set of env vars set. See the jtreg tag spec > and/or the command line help for more details (or ask here) if you > think this might be a factor. The test is not dependent on any environment variables. > > -- Jon > > On 06/05/2015 05:57 AM, Pete Brunet wrote: >> >> On 6/5/15 1:06 AM, David Holmes wrote: >>> Hi Peter, >>> >>> On 5/06/2015 4:01 PM, Pete Brunet wrote: >>>> Hi, When I run java from the command line I can tell my code in >>>> java.awt.Toolkit.getDefaultToolkit is running but when I run in a >>>> JTREG >>>> environment I don't see any indication that the code is executing. >>>> The >>>> jtr log shows that my test java is being invoked and when I use >>>> -version >>>> the right version string appears in the log. >>>> >>>> Any ideas on what I might be doing wrong? >>> Need more info. How are you running jtreg? How is your test launched >>> ie othervm ? Is output from the test itself seen? >> Hi David, This is the invocation with the prompt at the client directory >> of the local repo: >> >> /cygdrive/c/Users/Pete/jtreg/bin/jtreg >> -jdk:./build/windows-x86_64-normal-server-release/images/jdk >> ./jdk/test/javax/accessibility/AccessibilityProvider/ >> >> This is from the shell script: >> >> # @test >> # @bug 8055160 >> # @summary Unit test for javax.accessibility.AccessibilitySPI >> # >> # @build Load FooProvider BarProvider UnusedProvider >> # @run shell basic.sh >> # >> # Command-line usage: sh basic.sh /path/to/build >> >> This is from the jtr file: >> >> Working Directory: >> /cygdrive/c/Users/Pete/JDK9/JDK-8055160/client/JTwork/scratch >> + >> C:/Users/Pete/JDK9/JDK-8055160/client/./build/windows-x86_64-normal-server-release/images/jdk/bin/java >> >> -Djavax.accessibility.assistive_technologies=FooProvider -cp >> 'C:/Users/Pete/JDK9/JDK-8055160/client/JTwork/classes/javax/accessibility/AccessibilityProvider;x.test' >> >> Load pass FooProvider >> Working Directory: >> C:\\Users\\Pete\\JDK9\\JDK-8055160\\client\\JTwork\\scratch >> Exception in thread "main" java.lang.RuntimeException: FooProvider was >> not activated >> at Load.main(Load.java:78) >> >> I don't see any output from printlns (or existence of a debug file I >> create) in java.awt.Toolkit.getDefaultToolkit but I do see all output >> from my test. >> >> This might not be a show stopper for me. I could call >> java.awt.Toolkit.getDefaultToolkit from my test but I want to understand >> why it's called when running my java.exe from the command line but not >> from within jtreg. Maybe I am not using jtreg correctly. >> >> I added awt-dev list in case that group might know the answer. >> >> Later in the morning I'll put a Thread.dumpStack in getDefaultToolkit >> and maybe that will give me a hint as to why it is called in the >> non-jtreg case but not in the jtreg environment. >> >> Pete >>> David >>> >>>> Thanks, Pete >>>> > From jonathan.gibbons at oracle.com Fri Jun 5 15:41:08 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 05 Jun 2015 08:41:08 -0700 Subject: Code not being run in JTREG environment In-Reply-To: <5571BFA5.6090009@oracle.com> References: <5571339E.5080902@oracle.com> <557138A2.9070103@oracle.com> <55713B2D.9080604@oracle.com> <55713C75.3060306@oracle.com> <55719CB7.1080601@oracle.com> <5571BCD8.3020805@oracle.com> <5571BFA5.6090009@oracle.com> Message-ID: <5571C314.6050500@oracle.com> On 06/05/2015 08:26 AM, Pete Brunet wrote: > > On 6/5/15 10:14 AM, Jonathan Gibbons wrote: >> Pete, >> >> As a matter of style, note that jtreg directives can span lines, and so >> >> # @run shell basic.sh >> # >> # Command-line usage: sh basic.sh /path/to/build >> >> is equivalent to >> >> # @run shell basic.sh Command-line usage: sh basic.sh /path/to/build >> >> because it is all in the same comment block. >> >> I'd recommend deleting the # character on the intervening line, so that >> it reads >> >> # @run shell basic.sh >> >> # Command-line usage: sh basic.sh /path/to/build > Thanks Jon, I deleted the # (and left it as a blank line). >> >> As for why your test might behave differently in a jtreg environment, >> are you dependent on any environment variables? jtreg specifically >> runs with a limited set of env vars set. See the jtreg tag spec >> and/or the command line help for more details (or ask here) if you >> think this might be a factor. > The test is not dependent on any environment variables. If it were me, I would proceed with debug prints in your shell script (or use set -x, so that shell commands are echoed they are executed) and then have a debug print in the main program in your java class, so that you can confirm that the shell script is executing your class correctly. After that, you're down to differential debugging -- what is different between you running the class manually and jtreg running the shell script that runs the class. Primary environmental issues to investigate could be * system properties * env variables * class loader * threads and thread groups >> -- Jon >> >> On 06/05/2015 05:57 AM, Pete Brunet wrote: >>> On 6/5/15 1:06 AM, David Holmes wrote: >>>> Hi Peter, >>>> >>>> On 5/06/2015 4:01 PM, Pete Brunet wrote: >>>>> Hi, When I run java from the command line I can tell my code in >>>>> java.awt.Toolkit.getDefaultToolkit is running but when I run in a >>>>> JTREG >>>>> environment I don't see any indication that the code is executing. >>>>> The >>>>> jtr log shows that my test java is being invoked and when I use >>>>> -version >>>>> the right version string appears in the log. >>>>> >>>>> Any ideas on what I might be doing wrong? >>>> Need more info. How are you running jtreg? How is your test launched >>>> ie othervm ? Is output from the test itself seen? >>> Hi David, This is the invocation with the prompt at the client directory >>> of the local repo: >>> >>> /cygdrive/c/Users/Pete/jtreg/bin/jtreg >>> -jdk:./build/windows-x86_64-normal-server-release/images/jdk >>> ./jdk/test/javax/accessibility/AccessibilityProvider/ >>> >>> This is from the shell script: >>> >>> # @test >>> # @bug 8055160 >>> # @summary Unit test for javax.accessibility.AccessibilitySPI >>> # >>> # @build Load FooProvider BarProvider UnusedProvider >>> # @run shell basic.sh >>> # >>> # Command-line usage: sh basic.sh /path/to/build >>> >>> This is from the jtr file: >>> >>> Working Directory: >>> /cygdrive/c/Users/Pete/JDK9/JDK-8055160/client/JTwork/scratch >>> + >>> C:/Users/Pete/JDK9/JDK-8055160/client/./build/windows-x86_64-normal-server-release/images/jdk/bin/java >>> >>> -Djavax.accessibility.assistive_technologies=FooProvider -cp >>> 'C:/Users/Pete/JDK9/JDK-8055160/client/JTwork/classes/javax/accessibility/AccessibilityProvider;x.test' >>> >>> Load pass FooProvider >>> Working Directory: >>> C:\\Users\\Pete\\JDK9\\JDK-8055160\\client\\JTwork\\scratch >>> Exception in thread "main" java.lang.RuntimeException: FooProvider was >>> not activated >>> at Load.main(Load.java:78) >>> >>> I don't see any output from printlns (or existence of a debug file I >>> create) in java.awt.Toolkit.getDefaultToolkit but I do see all output >>> from my test. >>> >>> This might not be a show stopper for me. I could call >>> java.awt.Toolkit.getDefaultToolkit from my test but I want to understand >>> why it's called when running my java.exe from the command line but not >>> from within jtreg. Maybe I am not using jtreg correctly. >>> >>> I added awt-dev list in case that group might know the answer. >>> >>> Later in the morning I'll put a Thread.dumpStack in getDefaultToolkit >>> and maybe that will give me a hint as to why it is called in the >>> non-jtreg case but not in the jtreg environment. >>> >>> Pete >>>> David >>>> >>>>> Thanks, Pete >>>>> From peter.brunet at oracle.com Fri Jun 5 21:47:04 2015 From: peter.brunet at oracle.com (Pete Brunet) Date: Fri, 05 Jun 2015 16:47:04 -0500 Subject: Code not being run in JTREG environment In-Reply-To: <5571C314.6050500@oracle.com> References: <5571339E.5080902@oracle.com> <557138A2.9070103@oracle.com> <55713B2D.9080604@oracle.com> <55713C75.3060306@oracle.com> <55719CB7.1080601@oracle.com> <5571BCD8.3020805@oracle.com> <5571BFA5.6090009@oracle.com> <5571C314.6050500@oracle.com> Message-ID: <557218D8.7020700@oracle.com> Found the problem. Since my test had no GUI, Toolkit.getDefaultToolkit was not called. What I am testing is a side effect of calling getDefaultToolkit. I will add a call to getDefaultToolkit in my test. Pete On 6/5/15 10:41 AM, Jonathan Gibbons wrote: > On 06/05/2015 08:26 AM, Pete Brunet wrote: >> >> On 6/5/15 10:14 AM, Jonathan Gibbons wrote: >>> Pete, >>> >>> As a matter of style, note that jtreg directives can span lines, and so >>> >>> # @run shell basic.sh >>> # >>> # Command-line usage: sh basic.sh /path/to/build >>> >>> is equivalent to >>> >>> # @run shell basic.sh Command-line usage: sh basic.sh /path/to/build >>> >>> because it is all in the same comment block. >>> >>> I'd recommend deleting the # character on the intervening line, so that >>> it reads >>> >>> # @run shell basic.sh >>> >>> # Command-line usage: sh basic.sh /path/to/build >> Thanks Jon, I deleted the # (and left it as a blank line). >>> >>> As for why your test might behave differently in a jtreg environment, >>> are you dependent on any environment variables? jtreg specifically >>> runs with a limited set of env vars set. See the jtreg tag spec >>> and/or the command line help for more details (or ask here) if you >>> think this might be a factor. >> The test is not dependent on any environment variables. > > > If it were me, I would proceed with debug prints in your shell script > (or use set -x, so that shell commands are echoed they are executed) > and then have a debug print in the main program in your java class, so > that you can confirm that the shell script is executing your class > correctly. After that, you're down to differential debugging -- what > is different between you running the class manually and jtreg running > the shell script that runs the class. Primary environmental issues to > investigate could be > > * system properties > * env variables > * class loader > * threads and thread groups > >>> -- Jon >>> >>> On 06/05/2015 05:57 AM, Pete Brunet wrote: >>>> On 6/5/15 1:06 AM, David Holmes wrote: >>>>> Hi Peter, >>>>> >>>>> On 5/06/2015 4:01 PM, Pete Brunet wrote: >>>>>> Hi, When I run java from the command line I can tell my code in >>>>>> java.awt.Toolkit.getDefaultToolkit is running but when I run in a >>>>>> JTREG >>>>>> environment I don't see any indication that the code is executing. >>>>>> The >>>>>> jtr log shows that my test java is being invoked and when I use >>>>>> -version >>>>>> the right version string appears in the log. >>>>>> >>>>>> Any ideas on what I might be doing wrong? >>>>> Need more info. How are you running jtreg? How is your test launched >>>>> ie othervm ? Is output from the test itself seen? >>>> Hi David, This is the invocation with the prompt at the client >>>> directory >>>> of the local repo: >>>> >>>> /cygdrive/c/Users/Pete/jtreg/bin/jtreg >>>> -jdk:./build/windows-x86_64-normal-server-release/images/jdk >>>> ./jdk/test/javax/accessibility/AccessibilityProvider/ >>>> >>>> This is from the shell script: >>>> >>>> # @test >>>> # @bug 8055160 >>>> # @summary Unit test for javax.accessibility.AccessibilitySPI >>>> # >>>> # @build Load FooProvider BarProvider UnusedProvider >>>> # @run shell basic.sh >>>> # >>>> # Command-line usage: sh basic.sh /path/to/build >>>> >>>> This is from the jtr file: >>>> >>>> Working Directory: >>>> /cygdrive/c/Users/Pete/JDK9/JDK-8055160/client/JTwork/scratch >>>> + >>>> C:/Users/Pete/JDK9/JDK-8055160/client/./build/windows-x86_64-normal-server-release/images/jdk/bin/java >>>> >>>> >>>> -Djavax.accessibility.assistive_technologies=FooProvider -cp >>>> 'C:/Users/Pete/JDK9/JDK-8055160/client/JTwork/classes/javax/accessibility/AccessibilityProvider;x.test' >>>> >>>> >>>> Load pass FooProvider >>>> Working Directory: >>>> C:\\Users\\Pete\\JDK9\\JDK-8055160\\client\\JTwork\\scratch >>>> Exception in thread "main" java.lang.RuntimeException: FooProvider was >>>> not activated >>>> at Load.main(Load.java:78) >>>> >>>> I don't see any output from printlns (or existence of a debug file I >>>> create) in java.awt.Toolkit.getDefaultToolkit but I do see all output >>>> from my test. >>>> >>>> This might not be a show stopper for me. I could call >>>> java.awt.Toolkit.getDefaultToolkit from my test but I want to >>>> understand >>>> why it's called when running my java.exe from the command line but not >>>> from within jtreg. Maybe I am not using jtreg correctly. >>>> >>>> I added awt-dev list in case that group might know the answer. >>>> >>>> Later in the morning I'll put a Thread.dumpStack in getDefaultToolkit >>>> and maybe that will give me a hint as to why it is called in the >>>> non-jtreg case but not in the jtreg environment. >>>> >>>> Pete >>>>> David >>>>> >>>>>> Thanks, Pete >>>>>> > From jonathan.gibbons at oracle.com Fri Jun 5 21:49:38 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 05 Jun 2015 14:49:38 -0700 Subject: Code not being run in JTREG environment In-Reply-To: <557218D8.7020700@oracle.com> References: <5571339E.5080902@oracle.com> <557138A2.9070103@oracle.com> <55713B2D.9080604@oracle.com> <55713C75.3060306@oracle.com> <55719CB7.1080601@oracle.com> <5571BCD8.3020805@oracle.com> <5571BFA5.6090009@oracle.com> <5571C314.6050500@oracle.com> <557218D8.7020700@oracle.com> Message-ID: <55721972.5050306@oracle.com> Thanks for the update and for closing out this thread. -- Jon On 06/05/2015 02:47 PM, Pete Brunet wrote: > Found the problem. Since my test had no GUI, Toolkit.getDefaultToolkit > was not called. What I am testing is a side effect of calling > getDefaultToolkit. I will add a call to getDefaultToolkit in my test. > > Pete > > On 6/5/15 10:41 AM, Jonathan Gibbons wrote: >> On 06/05/2015 08:26 AM, Pete Brunet wrote: >>> On 6/5/15 10:14 AM, Jonathan Gibbons wrote: >>>> Pete, >>>> >>>> As a matter of style, note that jtreg directives can span lines, and so >>>> >>>> # @run shell basic.sh >>>> # >>>> # Command-line usage: sh basic.sh /path/to/build >>>> >>>> is equivalent to >>>> >>>> # @run shell basic.sh Command-line usage: sh basic.sh /path/to/build >>>> >>>> because it is all in the same comment block. >>>> >>>> I'd recommend deleting the # character on the intervening line, so that >>>> it reads >>>> >>>> # @run shell basic.sh >>>> >>>> # Command-line usage: sh basic.sh /path/to/build >>> Thanks Jon, I deleted the # (and left it as a blank line). >>>> As for why your test might behave differently in a jtreg environment, >>>> are you dependent on any environment variables? jtreg specifically >>>> runs with a limited set of env vars set. See the jtreg tag spec >>>> and/or the command line help for more details (or ask here) if you >>>> think this might be a factor. >>> The test is not dependent on any environment variables. >> >> If it were me, I would proceed with debug prints in your shell script >> (or use set -x, so that shell commands are echoed they are executed) >> and then have a debug print in the main program in your java class, so >> that you can confirm that the shell script is executing your class >> correctly. After that, you're down to differential debugging -- what >> is different between you running the class manually and jtreg running >> the shell script that runs the class. Primary environmental issues to >> investigate could be >> >> * system properties >> * env variables >> * class loader >> * threads and thread groups >> >>>> -- Jon >>>> >>>> On 06/05/2015 05:57 AM, Pete Brunet wrote: >>>>> On 6/5/15 1:06 AM, David Holmes wrote: >>>>>> Hi Peter, >>>>>> >>>>>> On 5/06/2015 4:01 PM, Pete Brunet wrote: >>>>>>> Hi, When I run java from the command line I can tell my code in >>>>>>> java.awt.Toolkit.getDefaultToolkit is running but when I run in a >>>>>>> JTREG >>>>>>> environment I don't see any indication that the code is executing. >>>>>>> The >>>>>>> jtr log shows that my test java is being invoked and when I use >>>>>>> -version >>>>>>> the right version string appears in the log. >>>>>>> >>>>>>> Any ideas on what I might be doing wrong? >>>>>> Need more info. How are you running jtreg? How is your test launched >>>>>> ie othervm ? Is output from the test itself seen? >>>>> Hi David, This is the invocation with the prompt at the client >>>>> directory >>>>> of the local repo: >>>>> >>>>> /cygdrive/c/Users/Pete/jtreg/bin/jtreg >>>>> -jdk:./build/windows-x86_64-normal-server-release/images/jdk >>>>> ./jdk/test/javax/accessibility/AccessibilityProvider/ >>>>> >>>>> This is from the shell script: >>>>> >>>>> # @test >>>>> # @bug 8055160 >>>>> # @summary Unit test for javax.accessibility.AccessibilitySPI >>>>> # >>>>> # @build Load FooProvider BarProvider UnusedProvider >>>>> # @run shell basic.sh >>>>> # >>>>> # Command-line usage: sh basic.sh /path/to/build >>>>> >>>>> This is from the jtr file: >>>>> >>>>> Working Directory: >>>>> /cygdrive/c/Users/Pete/JDK9/JDK-8055160/client/JTwork/scratch >>>>> + >>>>> C:/Users/Pete/JDK9/JDK-8055160/client/./build/windows-x86_64-normal-server-release/images/jdk/bin/java >>>>> >>>>> >>>>> -Djavax.accessibility.assistive_technologies=FooProvider -cp >>>>> 'C:/Users/Pete/JDK9/JDK-8055160/client/JTwork/classes/javax/accessibility/AccessibilityProvider;x.test' >>>>> >>>>> >>>>> Load pass FooProvider >>>>> Working Directory: >>>>> C:\\Users\\Pete\\JDK9\\JDK-8055160\\client\\JTwork\\scratch >>>>> Exception in thread "main" java.lang.RuntimeException: FooProvider was >>>>> not activated >>>>> at Load.main(Load.java:78) >>>>> >>>>> I don't see any output from printlns (or existence of a debug file I >>>>> create) in java.awt.Toolkit.getDefaultToolkit but I do see all output >>>>> from my test. >>>>> >>>>> This might not be a show stopper for me. I could call >>>>> java.awt.Toolkit.getDefaultToolkit from my test but I want to >>>>> understand >>>>> why it's called when running my java.exe from the command line but not >>>>> from within jtreg. Maybe I am not using jtreg correctly. >>>>> >>>>> I added awt-dev list in case that group might know the answer. >>>>> >>>>> Later in the morning I'll put a Thread.dumpStack in getDefaultToolkit >>>>> and maybe that will give me a hint as to why it is called in the >>>>> non-jtreg case but not in the jtreg environment. >>>>> >>>>> Pete >>>>>> David >>>>>> >>>>>>> Thanks, Pete >>>>>>> From brian.burkhalter at oracle.com Wed Jun 10 23:45:48 2015 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 10 Jun 2015 16:45:48 -0700 Subject: jtreg @requires vm.opt.name question Message-ID: <5BBC3438-A018-499F-B2D1-E63FA343DBAD@oracle.com> Is this tag @requires vm.opt.InitialHeapSize >= 512M a supported capability now? That is to say, the test would be run if and only if the heap size could be guaranteed to be at least 512 megabytes? Thanks, Brian -------------- next part -------------- An HTML attachment was scrubbed... URL: From staffan.larsen at oracle.com Fri Jun 19 20:19:19 2015 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Fri, 19 Jun 2015 22:19:19 +0200 Subject: stack strace when test timeout In-Reply-To: <52E24719.3040306@oracle.com> References: <52E24719.3040306@oracle.com> Message-ID: This is a standard feature of jtreg since a few releases back. You can even write your own ?timeout handlers? to define what should happen on a timeout. See the -timeoutHandler option as well as the TimeoutHandler class in jtreg. /Staffan > On 24 jan 2014, at 11:57, Tristan Yan wrote: > > Hi Jon > Recently I'm working on regression bugs. I found some regression bugs failed with timeout very randomly. It's very hard to reproduce the failure even we try more than thousand times retry. This make me wonder is there any way we can setup for jtreg we can get java stack strace when timeout occurs. This definitely will help to analysis the failure. Is there a config that already exists in jtreg? Can we expect it if it is not. > Thank you > Tristan -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.holmes at oracle.com Mon Jun 29 12:40:05 2015 From: david.holmes at oracle.com (David Holmes) Date: Mon, 29 Jun 2015 22:40:05 +1000 Subject: Correct "library" usage and concurrent use of scratch directory Message-ID: <55913CA5.5090305@oracle.com> Hi, We have a test that sometimes fails with a ClassNotFoundException: test.Empty. Here's the file structure: runtime/Metaspace/ classes/test/Empty.java FragmentMetaspace.java FragmentMetaspaceSimple.java And here's the test directives from the failing FragmentMetaspaceSimple.java: /** * @test * @library /runtime/testlibrary * @library classes * @build test.Empty ClassUnloadCommon * @run main/othervm/timeout=200 FragmentMetaspaceSimple */ Does this look right? I've only reproduced the failure when running both tests in the Metaspace directory. And locally when that happens TraceExceptions shows me that the Classloader can't find the JTwork/scratch/./classes directory. The other test is specified as: /** * @test * @library /runtime/testlibrary * @modules java.compiler * @build GeneratedClassLoader * @run main/othervm/timeout=200 -Xmx300m FragmentMetaspace */ will they both try to manipulate the scratch directory? Thanks, David From sadhak001 at gmail.com Tue Jun 30 22:23:53 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Tue, 30 Jun 2015 23:23:53 +0100 Subject: javahelp2_0_05.zip no longer available at http://download.java.net/javadesktop/javahelp/javahelp2_0_05.zip Message-ID: Hi all, Uptill now we were able to download javahelp2_0_05.zip from http://download.java.net/javadesktop/javahelp/javahelp2_0_05.zip, and just recently get a 404 error from the same location. I understand this binary may not be available anymore - does anyone know more about it. In the meanwhile I have been able to secure this binary needed for two of our critical build farm builds. Anu more info on this will be highly appreciated. Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* -------------- next part -------------- An HTML attachment was scrubbed... URL: From sadhak001 at gmail.com Tue Jun 30 22:32:10 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Tue, 30 Jun 2015 23:32:10 +0100 Subject: javahelp2_0_05.zip no longer available at http://download.java.net/javadesktop/javahelp/javahelp2_0_05.zip In-Reply-To: References: Message-ID: The below issue is now resolved: https://java.net/jira/browse/ADOPTOPENJDK-7 The issue was related to what happened to the missing binary in my previous email. This shouldn't happen again. Cheers, Mani On Tue, Jun 30, 2015 at 11:23 PM, Mani Sarkar wrote: > Hi all, > > Uptill now we were able to download javahelp2_0_05.zip from > http://download.java.net/javadesktop/javahelp/javahelp2_0_05.zip, and > just recently get a 404 error from the same location. > > I understand this binary may not be available anymore - does anyone know > more about it. > > In the meanwhile I have been able to secure this binary needed for two of > our critical build farm builds. > > Anu more info on this will be highly appreciated. > > Cheers, > Mani > > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ > > *Don't chase success, rather aim for "Excellence", and success will come > chasing after you!* > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2016:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* -------------- next part -------------- An HTML attachment was scrubbed... URL: