From aleksey.shipilev at oracle.com Wed Dec 4 08:54:49 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Wed, 04 Dec 2013 20:54:49 +0400 Subject: Proposal: Java Object Layout (jol) Message-ID: <529F5E59.1080601@oracle.com> Hi, I would like to propose another tool for inclusion into Code Tools project. Please find the proposal below: ----8<------------------------------------------------------------------- Tool Name: Java Object Layout (jol) Tool Purpose: Java Object Layout (jol) is the minimalistic set of tools for analyzing the object layout schemes in JVM. Proposed By: Aleksey Shipilev, Oracle, Java SE Performance team Rationale: Java Object Layout is the VM/GC introspection tool which helps to debug and analyze the object/heap memory footprint, GC object layout, and other intricate memory layout problems. There were a lot of cases where major motivation for a code change was to affect the field layout (e.g. @Contended, and generally concurrency), or fix a particular nastiness in object layout (e.g. GC layout peculiarities). In many cases, people needed a similar tool to explain the performance effect and motivation for the JDK/VM change. jol will help Contributors to do the due diligence prior the change, without digging into the source code, or winding up with their own, possibly broken, throw-away tools. jol is bundled with runnable samples which explain quite a few things about the layout schemes in current VMs. This frees low level JDK/VM developers from having to memorize layout intricacies. ----8<------------------------------------------------------------------- Thanks, -Aleksey. From magnus.ihse.bursie at oracle.com Thu Dec 5 04:56:12 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Thu, 05 Dec 2013 13:56:12 +0100 Subject: CodeTool proposal: Webrev In-Reply-To: <5283DD48.3060402@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> Message-ID: <52A077EC.7040001@oracle.com> On 2013-11-13 21:12, Jonathan Gibbons wrote: > > In the absence of any reasons to the contrary, I suggest we move > forward on hosting webrev within the code-tools project. So, now that we have a webrev repo and mailing list; how do we continue? I sent a post to the webrev-dev list with a suggestion on how to populate the new repo, but it it seem to have fallen on deaf ears. (It turned out I was the only subscriber to the list... :)) Someone with committer rights in code-tools need to do the commit. /Magnus From dalibor.topic at oracle.com Fri Dec 6 06:10:19 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 06 Dec 2013 15:10:19 +0100 Subject: CodeTool proposal: Webrev In-Reply-To: <52A077EC.7040001@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> Message-ID: <52A1DACB.9080606@oracle.com> On 12/5/13 1:56 PM, Magnus Ihse Bursie wrote: > So, now that we have a webrev repo and mailing list; how do we continue? It should be added to the code tools web page at http://openjdk.java.net/projects/code-tools/ (and maybe have a small page of its own, as well ;) > (It turned out I was the only subscriber to the list... :)) Heh ;) See above ;) > Someone with committer rights in code-tools need to do the commit. You can also ask ops at openjdk for assistance in populating the repository, if all else fails. cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From Roger.Riggs at Oracle.com Fri Dec 6 06:27:35 2013 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 06 Dec 2013 09:27:35 -0500 Subject: CodeTool proposal: Webrev In-Reply-To: <52A077EC.7040001@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> Message-ID: <52A1DED7.80705@Oracle.com> Hi Magnus, Why does it need a separate alias (btw, I didn't see any notice of one being created). Roger On 12/05/2013 07:56 AM, Magnus Ihse Bursie wrote: > On 2013-11-13 21:12, Jonathan Gibbons wrote: >> >> In the absence of any reasons to the contrary, I suggest we move >> forward on hosting webrev within the code-tools project. > > So, now that we have a webrev repo and mailing list; how do we continue? > > I sent a post to the webrev-dev list with a suggestion on how to > populate the new repo, but it it seem to have fallen on deaf ears. (It > turned out I was the only subscriber to the list... :)) > > Someone with committer rights in code-tools need to do the commit. > > /Magnus From jonathan.gibbons at oracle.com Fri Dec 6 08:07:36 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 06 Dec 2013 08:07:36 -0800 Subject: CodeTool proposal: Webrev In-Reply-To: <52A1DACB.9080606@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> <52A1DACB.9080606@oracle.com> Message-ID: <52A1F648.60709@oracle.com> Dalibor, ops at openjdk have done their magic, so there is no need to trouble them further at this point. I will be updating the code-tools pages for webrev, and will push changes for Magnus until he has committer rights. -- Jon On 12/06/2013 06:10 AM, Dalibor Topic wrote: > On 12/5/13 1:56 PM, Magnus Ihse Bursie wrote: >> So, now that we have a webrev repo and mailing list; how do we continue? > It should be added to the code tools web page at http://openjdk.java.net/projects/code-tools/ (and maybe have a small page of its own, as well ;) > >> (It turned out I was the only subscriber to the list... :)) > Heh ;) See above ;) > >> Someone with committer rights in code-tools need to do the commit. > You can also ask ops at openjdk for assistance in populating the repository, if all else fails. > > cheers, > dalibor topic From jonathan.gibbons at oracle.com Fri Dec 6 08:09:08 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 06 Dec 2013 08:09:08 -0800 Subject: CodeTool proposal: Webrev In-Reply-To: <52A1DED7.80705@Oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> <52A1DED7.80705@Oracle.com> Message-ID: <52A1F6A4.2090501@oracle.com> Roger, We're still in the process of making it happen. As for why a separate alias, we've just followed the practice for existing subprojects within the CodeTools project. -- Jon On 12/06/2013 06:27 AM, Roger Riggs wrote: > Hi Magnus, > > Why does it need a separate alias (btw, I didn't see any notice of one > being created). > > Roger > > > On 12/05/2013 07:56 AM, Magnus Ihse Bursie wrote: >> On 2013-11-13 21:12, Jonathan Gibbons wrote: >>> >>> In the absence of any reasons to the contrary, I suggest we move >>> forward on hosting webrev within the code-tools project. >> >> So, now that we have a webrev repo and mailing list; how do we continue? >> >> I sent a post to the webrev-dev list with a suggestion on how to >> populate the new repo, but it it seem to have fallen on deaf ears. >> (It turned out I was the only subscriber to the list... :)) >> >> Someone with committer rights in code-tools need to do the commit. >> >> /Magnus > From dalibor.topic at oracle.com Fri Dec 6 08:09:52 2013 From: dalibor.topic at oracle.com (Dalibor Topic) Date: Fri, 06 Dec 2013 17:09:52 +0100 Subject: CodeTool proposal: Webrev In-Reply-To: <52A1F648.60709@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> <52A1DACB.9080606@oracle.com> <52A1F648.60709@oracle.com> Message-ID: <52A1F6D0.8070603@oracle.com> On 12/6/13 5:07 PM, Jonathan Gibbons wrote: > Dalibor, > > ops at openjdk have done their magic, so there is no need to trouble them further at this point. I will be updating the code-tools pages for webrev, and will push changes for Magnus until he has committer rights. > Awesome, thanks - sorry for the noise then ;) cheers, dalibor topic -- Oracle Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 Oracle Java Platform Group ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Gesch?ftsf?hrer: J?rgen Kunz Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Astrid Kepper, Val Maher Green Oracle Oracle is committed to developing practices and products that help protect the environment From jonathan.gibbons at oracle.com Sun Dec 8 17:27:43 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Sun, 08 Dec 2013 17:27:43 -0800 Subject: Welcome to webrev Message-ID: <52A51C8F.7000303@oracle.com> Code-tools folk, webrev is now being hosted by the code-tools project, under the lead of Magnus Ihse Bursie of the build group. I will leave it to him to make a more complete and wider announcement. Thanks to the folk behind the scenes who helped make this happen. -- Jon From magnus.ihse.bursie at oracle.com Mon Dec 9 00:39:44 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 09 Dec 2013 09:39:44 +0100 Subject: CodeTool proposal: Webrev In-Reply-To: <52A1F6A4.2090501@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> <52A1DED7.80705@Oracle.com> <52A1F6A4.2090501@oracle.com> Message-ID: <52A581D0.7070203@oracle.com> On 2013-12-06 17:09, Jonathan Gibbons wrote: > Roger, > > We're still in the process of making it happen. As for why a separate > alias, we've just followed the practice for existing subprojects > within the CodeTools project. Actually, I was thinking that this might be overkill. Seeing that code-tools-dev is not exactly drowned in mails, I wonder if it would perhaps be better to have webrev development use this list instead? I'm mostly worried that forcing people to subscribe to yet another mailing list will diminish the number of people that will see changes and volunteer for code review, for instance. /Magnus From aleksey.shipilev at oracle.com Mon Dec 9 01:02:43 2013 From: aleksey.shipilev at oracle.com (Aleksey Shipilev) Date: Mon, 9 Dec 2013 13:02:43 +0400 Subject: CodeTool proposal: Webrev In-Reply-To: <52A581D0.7070203@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> <52A1DED7.80705@Oracle.com> <52A1F6A4.2090501@oracle.com> <52A581D0.7070203@oracle.com> Message-ID: <40A3274B-112B-496B-82B9-211D383205EC@oracle.com> On 09.12.2013, at 12:39, Magnus Ihse Bursie wrote: > On 2013-12-06 17:09, Jonathan Gibbons wrote: >> Roger, >> >> We're still in the process of making it happen. As for why a separate alias, we've just followed the practice for existing subprojects within the CodeTools project. > > Actually, I was thinking that this might be overkill. Seeing that code-tools-dev is not exactly drowned in mails, I wonder if it would perhaps be better to have webrev development use this list instead? I'm mostly worried that forcing people to subscribe to yet another mailing list will diminish the number of people that will see changes and volunteer for code review, for instance. I shared this sentiment for both jmh, jcstress, and the upcoming jol. The practice, however, seems to indicate people are subscribing to low-traffic per-subproject lists without much prejudice, and the reviews are still happening within the focused group of people that care enough, as indicated by taking steps to subscribe. -Aleksey. From magnus.ihse.bursie at oracle.com Mon Dec 9 01:59:36 2013 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Mon, 09 Dec 2013 10:59:36 +0100 Subject: CodeTool proposal: Webrev In-Reply-To: <40A3274B-112B-496B-82B9-211D383205EC@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> <52A1DED7.80705@Oracle.com> <52A1F6A4.2090501@oracle.com> <52A581D0.7070203@oracle.com> <40A3274B-112B-496B-82B9-211D383205EC@oracle.com> Message-ID: <52A59488.8010704@oracle.com> On 2013-12-09 10:02, Aleksey Shipilev wrote: > > I shared this sentiment for both jmh, jcstress, and the upcoming jol. The practice, however, seems to indicate people are subscribing to low-traffic per-subproject lists without much prejudice, and the reviews are still happening within the focused group of people that care enough, as indicated by taking steps to subscribe. > Okay then. :) /Magnus From roger.riggs at oracle.com Mon Dec 9 06:18:22 2013 From: roger.riggs at oracle.com (roger riggs) Date: Mon, 09 Dec 2013 09:18:22 -0500 Subject: CodeTool proposal: Webrev In-Reply-To: <52A59488.8010704@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> <52A1DED7.80705@Oracle.com> <52A1F6A4.2090501@oracle.com> <52A581D0.7070203@oracle.com> <40A3274B-112B-496B-82B9-211D383205EC@oracle.com> <52A59488.8010704@oracle.com> Message-ID: <52A5D12E.4030707@oracle.com> Point taken about the reviews. But the changes affect a great many people and there needs to be a consistent wide distribution of the changes. It comes for free if a broader distribution for all changes and discussion. Roger On 12/9/2013 4:59 AM, Magnus Ihse Bursie wrote: > On 2013-12-09 10:02, Aleksey Shipilev wrote: >> >> I shared this sentiment for both jmh, jcstress, and the upcoming jol. >> The practice, however, seems to indicate people are subscribing to >> low-traffic per-subproject lists without much prejudice, and the >> reviews are still happening within the focused group of people that >> care enough, as indicated by taking steps to subscribe. >> > > Okay then. :) > > /Magnus From jonathan.gibbons at oracle.com Mon Dec 9 07:54:16 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Mon, 09 Dec 2013 07:54:16 -0800 Subject: CodeTool proposal: Webrev In-Reply-To: <52A5D12E.4030707@oracle.com> References: <52813D5F.5070408@oracle.com> <5283DD48.3060402@oracle.com> <52A077EC.7040001@oracle.com> <52A1DED7.80705@Oracle.com> <52A1F6A4.2090501@oracle.com> <52A581D0.7070203@oracle.com> <40A3274B-112B-496B-82B9-211D383205EC@oracle.com> <52A59488.8010704@oracle.com> <52A5D12E.4030707@oracle.com> Message-ID: <52A5E7A8.8050409@oracle.com> I think announcements about significant new versions should be on either discuss at ojn or announce at ojn. -- Jon On 12/09/2013 06:18 AM, roger riggs wrote: > Point taken about the reviews. > > But the changes affect a great many people and there needs to be a > consistent > wide distribution of the changes. It comes for free if a broader > distribution for all > changes and discussion. > > Roger > > > On 12/9/2013 4:59 AM, Magnus Ihse Bursie wrote: >> On 2013-12-09 10:02, Aleksey Shipilev wrote: >>> >>> I shared this sentiment for both jmh, jcstress, and the upcoming >>> jol. The practice, however, seems to indicate people are subscribing >>> to low-traffic per-subproject lists without much prejudice, and the >>> reviews are still happening within the focused group of people that >>> care enough, as indicated by taking steps to subscribe. >>> >> >> Okay then. :) >> >> /Magnus > From volker.simonis at gmail.com Tue Dec 10 02:12:43 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 10 Dec 2013 11:12:43 +0100 Subject: Please update http://openjdk.java.net/jtreg/build.html Message-ID: Hi, yesterday I've build jtreg from source as described at: http://openjdk.java.net/jtreg/build.html While I succeed in the end, I found that some of the information on that page could be improved to make the build process easier. Following my proposals for updating the instructions: JavaHelp - add the follwing: "Unzip the javahelp zip file (e.g. javahelp2_0_05.zip) and set JAVAHELP_HOME to point to the resulting jh2.0/javahelp directory." JT Harness - add the following: "Notice that unpacking the jtharness harness will not implicitly create a directory. It is advised to first explicitly create a jtharness directory and unzip the jtharness archive therein. JTHARNESS_HOME should point to that directory." Xalan - add the following after the link to Xalan: "Go to the "Download/Build" section and follow the "xalan-j distribution directory" link. From there choose "Xalan java download area" and download "xalan-j_2_7_1-bin.zip" from the "binaries/" direcotry. Set XALANHOME to the directory which will be created when you unzip the xalan zip archive." JUnit - add the following: "Notice that only version smaller than 4.11 are supported. JUnit 4.11 and above do not contain the required org.hamcrest any more (they are now contained in their own jar file hamcrest-core.jar but jtreg/jtharness isn?t currently prepared to handle this). Set JUNIT_JAR to the junit jar file." TestNG - add the follwing: "For TestNG it is not enough to just download the testng jar file. Instead you have to download the complete testng archive from the link for ANT users in the download section. Unzip the archive and set TESTNG_HOME to point to the created directory and TESTNG_JAR to point to the testng jar file in that directory." - Because JUnit and TestNG are required for running the jdk regression test I'd suggest to move the JUnit and TestNG sections from the optional to the required dependencies. Ant - I also found that I did need to have ANTHOME defined. Otherwise I got build errors like: ../src/share/classes/com/sun/javatest/regtest/Main.java:61: package org.apache.tools.ant does not exist import org.apache.tools.ant.BuildException; - so please move the "Ant" section from optional to the required section and remove the sentence "It need not be set if you are just building jtreg." I havn't installed and used HTMLCheck/LinkLint but without these two, a complete build command line may look as follows: JDK15HOME=/share/software/Java/jdk1.6.0_26 JAVAHELP_HOME=/share/software/Java/JTREG_from_source/deps/jh2.0/javahelp JTHARNESS_HOME=/share/software/Java/JTREG_from_source/deps/jtharness-4_4_1-MR1-bin-b13-20_dec_2011 XALANHOME=/share/software/Java/JTREG_from_source/deps/xalan-j_2_7_1 TESTNG_HOME=/share/software/Java/JTREG_from_source/deps/testng-6.8 JUNIT_JAR=/share/software/Java/JTREG_from_source/deps/junit-4.10.jar TESTNG_JAR=/share/software/Java/JTREG_from_source/deps/testng-6.8/testng-6.8.jar ANTHOME=/share/software/Java/JTREG_from_source/deps/apache-ant-1.9.2 make -C make The resulting jtreg image can be found under build/images. It may be good to add such a line as example on how to build JTreg. Please feel free to correct and improve my proposal. Regards, Volker From volker.simonis at gmail.com Tue Dec 10 07:37:12 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 10 Dec 2013 16:37:12 +0100 Subject: System.exit() forbidden by JT Harness in agentvm mode Message-ID: Hi, when running the com/sun/java/swing/plaf/windows/8016551/bug8016551.java regression test with the newest version of jtreg (build from source) in agentvm mode I get the following error: ----------System.err:(33/2049)---------- java.lang.reflect.InvocationTargetException at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300) at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275) at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350) at bug8016551.main(bug8016551.java:46) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:483) at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) at java.lang.Thread.run(Thread.java:744) Caused by: java.lang.SecurityException: System.exit() forbidden by JT Harness at com.sun.javatest.JavaTestSecurityManager.checkExit(JavaTestSecurityManager.java:117) at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:395) at bug8016551$1.run(bug8016551.java:57) at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301) at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) at java.awt.EventQueue.access$400(EventQueue.java:97) at java.awt.EventQueue$3.run(EventQueue.java:697) at java.awt.EventQueue$3.run(EventQueue.java:691) at java.security.AccessController.doPrivileged(Native Method) at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) If the test is run in othervm mode it succeeds. I looked at this problem a litter loser and found out the following: - there are 99 test which use JFrame.setDefaultCloseOperation(EXIT_ON_CLOSE) - they are in java/awt (15), javax/swing (79), sun/java2d (3), javax/imageio/plugins/gif/GifTransparencyTest.java (setDefaultCloseOperation present but never called) and com/sun/java/swing/plaf/windows/8016551/bug8016551.java - all test in java/awt and sun/java2d are always executed in othervm mode anyway (because of 'othervm.dirs=java/awt ..' in TEST.ROOT) Now I'm not sure if this security-exception is right at this place - i.e. if jtreg/jtharness work as expected here. If yes and if there's no option/workaround to switch this behaviour off, we should either add 'javax/swing' as well to the 'othervm.dirs' list in TEST.ROOT and explicitly flag the remain test to require othervm mode by adding the corresponding '@run main/othervm' tag to the java source file. If adding 'javax/swing' to 'othervm.dirs' is considered to general, we would have to explicitly flag each single test with '@run main/othervm'. What do you think? Volker PS: there are 208 test which call System.exit() directly. I haven't analysed them until now, but the same reasoning applies for them as well. From jonathan.gibbons at oracle.com Tue Dec 10 08:22:08 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Dec 2013 08:22:08 -0800 Subject: Please update http://openjdk.java.net/jtreg/build.html In-Reply-To: References: Message-ID: <52A73FB0.8090501@oracle.com> Volker, Thank you for your suggestions. I will work on incorporating them into the main build.html file. -- Jon On 12/10/2013 02:12 AM, Volker Simonis wrote: > Hi, > > yesterday I've build jtreg from source as described at: > http://openjdk.java.net/jtreg/build.html > > While I succeed in the end, I found that some of the information on > that page could be improved to make the build process easier. > Following my proposals for updating the instructions: > > JavaHelp > > - add the follwing: "Unzip the javahelp zip file (e.g. > javahelp2_0_05.zip) and set JAVAHELP_HOME to point to the resulting > jh2.0/javahelp directory." > > JT Harness > > - add the following: "Notice that unpacking the jtharness harness will > not implicitly create a directory. It is advised to first explicitly > create a jtharness directory and unzip the jtharness archive therein. > JTHARNESS_HOME should point to that directory." > > Xalan > > - add the following after the link to Xalan: "Go to the > "Download/Build" section and follow the "xalan-j distribution > directory" link. From there choose "Xalan java download area" and > download "xalan-j_2_7_1-bin.zip" from the "binaries/" direcotry. Set > XALANHOME to the directory which will be created when you unzip the > xalan zip archive." > > JUnit > > - add the following: "Notice that only version smaller than 4.11 are > supported. JUnit 4.11 and above do not contain the required > org.hamcrest any more (they are now contained in their own jar file > hamcrest-core.jar but jtreg/jtharness isn?t currently prepared to > handle this). Set JUNIT_JAR to the junit jar file." > > TestNG > > - add the follwing: "For TestNG it is not enough to just download the > testng jar file. Instead you have to download the complete testng > archive from the link for ANT users in the download section. Unzip the > archive and set TESTNG_HOME to point to the created directory and > TESTNG_JAR to point to the testng jar file in that directory." > > - Because JUnit and TestNG are required for running the jdk regression > test I'd suggest to move the JUnit and TestNG sections from the > optional to the required dependencies. > > Ant > > - I also found that I did need to have ANTHOME defined. Otherwise I > got build errors like: > > ../src/share/classes/com/sun/javatest/regtest/Main.java:61: package > org.apache.tools.ant does not exist > import org.apache.tools.ant.BuildException; > > - so please move the "Ant" section from optional to the required > section and remove the sentence "It need not be set if you are just > building jtreg." > > I havn't installed and used HTMLCheck/LinkLint but without these two, > a complete build command line may look as follows: > > JDK15HOME=/share/software/Java/jdk1.6.0_26 > JAVAHELP_HOME=/share/software/Java/JTREG_from_source/deps/jh2.0/javahelp > JTHARNESS_HOME=/share/software/Java/JTREG_from_source/deps/jtharness-4_4_1-MR1-bin-b13-20_dec_2011 > XALANHOME=/share/software/Java/JTREG_from_source/deps/xalan-j_2_7_1 > TESTNG_HOME=/share/software/Java/JTREG_from_source/deps/testng-6.8 > JUNIT_JAR=/share/software/Java/JTREG_from_source/deps/junit-4.10.jar > TESTNG_JAR=/share/software/Java/JTREG_from_source/deps/testng-6.8/testng-6.8.jar > ANTHOME=/share/software/Java/JTREG_from_source/deps/apache-ant-1.9.2 > make -C make > > The resulting jtreg image can be found under build/images. > > It may be good to add such a line as example on how to build JTreg. > > Please feel free to correct and improve my proposal. > > Regards, > Volker From jonathan.gibbons at oracle.com Tue Dec 10 08:47:52 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Dec 2013 08:47:52 -0800 Subject: System.exit() forbidden by JT Harness in agentvm mode In-Reply-To: References: Message-ID: <52A745B8.1070705@oracle.com> Volker, From the history books, initially there was only "samevm" and "othervm" mode and "othervm" mode was the default. "samevm" mode was problematic in the face of bad tests (especially bad tests on Windows) and only the langtools test suite evolved to the point where we recommended the use of "samevm" mode. As a result, "agentvm" mode was added, which is like samevm, but better. It has worked well for most tests, but as you have noticed, does not work well if a test tries to exit the JVM. Those tests need some amount of TLC if they are to leverage "agentvm" mode. You can use othervm.dirs in TEST.ROOT, but that was added as a pragmatic, stop gap measure, to faciitate running most of the tests in the faster "agentvm" mode, while allowing some older parts of the test suite to continue running in the slower "othervm" world. The core-libs team have led an effort to clean up the core-libs tests and to provide the test/Makefile as a standard way of running the tests. It seems like it is time to embark on a similar effort for the client tests. -- Jon On 12/10/2013 07:37 AM, Volker Simonis wrote: > Hi, > > when running the > com/sun/java/swing/plaf/windows/8016551/bug8016551.java regression > test with the newest version of jtreg (build from source) in agentvm > mode I get the following error: > > ----------System.err:(33/2049)---------- > java.lang.reflect.InvocationTargetException > at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300) > at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275) > at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities.java:1350) > at bug8016551.main(bug8016551.java:46) > at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.lang.reflect.Method.invoke(Method.java:483) > at com.sun.javatest.regtest.MainAction$SameVMRunnable.run(MainAction.java:754) > at java.lang.Thread.run(Thread.java:744) > Caused by: java.lang.SecurityException: System.exit() forbidden by JT Harness > at com.sun.javatest.JavaTestSecurityManager.checkExit(JavaTestSecurityManager.java:117) > at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:395) > at bug8016551$1.run(bug8016551.java:57) > at java.awt.event.InvocationEvent.dispatch(InvocationEvent.java:301) > at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) > at java.awt.EventQueue.access$400(EventQueue.java:97) > at java.awt.EventQueue$3.run(EventQueue.java:697) > at java.awt.EventQueue$3.run(EventQueue.java:691) > at java.security.AccessController.doPrivileged(Native Method) > at java.security.ProtectionDomain$1.doIntersectionPrivilege(ProtectionDomain.java:75) > at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) > at java.awt.EventDispatchThread.pumpOneEventForFilters(EventDispatchThread.java:201) > at java.awt.EventDispatchThread.pumpEventsForFilter(EventDispatchThread.java:116) > at java.awt.EventDispatchThread.pumpEventsForHierarchy(EventDispatchThread.java:105) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:101) > at java.awt.EventDispatchThread.pumpEvents(EventDispatchThread.java:93) > at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) > > If the test is run in othervm mode it succeeds. > > I looked at this problem a litter loser and found out the following: > > - there are 99 test which use JFrame.setDefaultCloseOperation(EXIT_ON_CLOSE) > - they are in java/awt (15), javax/swing (79), sun/java2d (3), > javax/imageio/plugins/gif/GifTransparencyTest.java > (setDefaultCloseOperation present but never called) and > com/sun/java/swing/plaf/windows/8016551/bug8016551.java > - all test in java/awt and sun/java2d are always executed in othervm > mode anyway (because of 'othervm.dirs=java/awt ..' in TEST.ROOT) > > Now I'm not sure if this security-exception is right at this place - > i.e. if jtreg/jtharness work as expected here. > > If yes and if there's no option/workaround to switch this behaviour > off, we should either add 'javax/swing' as well to the 'othervm.dirs' > list in TEST.ROOT and explicitly flag the remain test to require > othervm mode by adding the corresponding '@run main/othervm' tag to > the java source file. > > If adding 'javax/swing' to 'othervm.dirs' is considered to general, we > would have to explicitly flag each single test with '@run > main/othervm'. > > What do you think? > > Volker > > PS: there are 208 test which call System.exit() directly. I haven't > analysed them until now, but the same reasoning applies for them as > well. From volker.simonis at gmail.com Tue Dec 10 14:02:04 2013 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 10 Dec 2013 23:02:04 +0100 Subject: System.exit() forbidden by JT Harness in agentvm mode In-Reply-To: <52A745B8.1070705@oracle.com> References: <52A745B8.1070705@oracle.com> Message-ID: Hi Jonathan, thanks for you comments. But there's still one thing I don't understand: what's the exact reason that tests in the agentvm mode are running under a special security manager while test running in othervm mode aren't restricted in this way. Is this really necessary? Regards, Volker On Tuesday, December 10, 2013, Jonathan Gibbons wrote: > Volker, > > From the history books, initially there was only "samevm" and "othervm" > mode and "othervm" mode was the default. > > "samevm" mode was problematic in the face of bad tests (especially bad > tests on Windows) and only the langtools test suite evolved to the point > where we recommended the use of "samevm" mode. > > As a result, "agentvm" mode was added, which is like > samevm, but better. It has worked well for most tests, > but as you have noticed, does not work well if a test tries to exit the > JVM. Those tests need some amount of TLC if they are to leverage "agentvm" > mode. > > You can use othervm.dirs in TEST.ROOT, but that was added as a pragmatic, > stop gap measure, to faciitate running most of the tests in the faster > "agentvm" mode, while allowing some older parts of the test suite to > continue running in the slower "othervm" world. > > The core-libs team have led an effort to clean up the core-libs tests and > to provide the test/Makefile as a standard way of running the tests. It > seems like it is time to embark on a similar effort for the client tests. > > -- Jon > > On 12/10/2013 07:37 AM, Volker Simonis wrote: > >> Hi, >> >> when running the >> com/sun/java/swing/plaf/windows/8016551/bug8016551.java regression >> test with the newest version of jtreg (build from source) in agentvm >> mode I get the following error: >> >> ----------System.err:(33/2049)---------- >> java.lang.reflect.InvocationTargetException >> at java.awt.EventQueue.invokeAndWait(EventQueue.java:1300) >> at java.awt.EventQueue.invokeAndWait(EventQueue.java:1275) >> at javax.swing.SwingUtilities.invokeAndWait(SwingUtilities. >> java:1350) >> at bug8016551.main(bug8016551.java:46) >> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >> at sun.reflect.NativeMethodAccessorImpl.invoke( >> NativeMethodAccessorImpl.java:62) >> at sun.reflect.DelegatingMethodAccessorImpl.invoke( >> DelegatingMethodAccessorImpl.java:43) >> at java.lang.reflect.Method.invoke(Method.java:483) >> at com.sun.javatest.regtest.MainAction$SameVMRunnable.run( >> MainAction.java:754) >> at java.lang.Thread.run(Thread.java:744) >> Caused by: java.lang.SecurityException: System.exit() forbidden by JT >> Harness >> at com.sun.javatest.JavaTestSecurityManager.checkExit( >> JavaTestSecurityManager.java:117) >> at javax.swing.JFrame.setDefaultCloseOperation(JFrame.java:395) >> at bug8016551$1.run(bug8016551.java:57) >> at java.awt.event.InvocationEvent.dispatch( >> InvocationEvent.java:301) >> at java.awt.EventQueue.dispatchEventImpl(EventQueue.java:744) >> at java.awt.EventQueue.access$400(EventQueue.java:97) >> at java.awt.EventQueue$3.run(EventQueue.java:697) >> at java.awt.EventQueue$3.run(EventQueue.java:691) >> at java.security.AccessController.doPrivileged(Native Method) >> at java.security.ProtectionDomain$1.doIntersectionPrivilege( >> ProtectionDomain.java:75) >> at java.awt.EventQueue.dispatchEvent(EventQueue.java:714) >> at java.awt.EventDispatchThread.pumpOneEventForFilters( >> EventDispatchThread.java:201) >> at java.awt.EventDispatchThread.pumpEventsForFilter( >> EventDispatchThread.java:116) >> at java.awt.EventDispatchThread.pumpEventsForHierarchy( >> EventDispatchThread.java:105) >> at java.awt.EventDispatchThread.pumpEvents( >> EventDispatchThread.java:101) >> at java.awt.EventDispatchThread.pumpEvents( >> EventDispatchThread.java:93) >> at java.awt.EventDispatchThread.run(EventDispatchThread.java:82) >> >> If the test is run in othervm mode it succeeds. >> >> I looked at this problem a litter loser and found out the following: >> >> - there are 99 test which use JFrame.setDefaultCloseOperation(EXIT_ >> ON_CLOSE) >> - they are in java/awt (15), javax/swing (79), sun/java2d (3), >> javax/imageio/plugins/gif/GifTransparencyTest.java >> (setDefaultCloseOperation present but never called) and >> com/sun/java/swing/plaf/windows/8016551/bug8016551.java >> - all test in java/awt and sun/java2d are always executed in othervm >> mode anyway (because of 'othervm.dirs=java/awt ..' in TEST.ROOT) >> >> Now I'm not sure if this security-exception is right at this place - >> i.e. if jtreg/jtharness work as expected here. >> >> If yes and if there's no option/workaround to switch this behaviour >> off, we should either add 'javax/swing' as well to the 'othervm.dirs' >> list in TEST.ROOT and explicitly flag the remain test to require >> othervm mode by adding the corresponding '@run main/othervm' tag to >> the java source file. >> >> If adding 'javax/swing' to 'othervm.dirs' is considered to general, we >> would have to explicitly flag each single test with '@run >> main/othervm'. >> >> What do you think? >> >> Volker >> >> PS: there are 208 test which call System.exit() directly. I haven't >> analysed them until now, but the same reasoning applies for them as >> well. >> > > From jonathan.gibbons at oracle.com Tue Dec 10 14:04:19 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 10 Dec 2013 14:04:19 -0800 Subject: System.exit() forbidden by JT Harness in agentvm mode In-Reply-To: References: <52A745B8.1070705@oracle.com> Message-ID: <52A78FE3.2000300@oracle.com> In othervm mode, no restrictions are placed on the JVM, and by default, no security manager is installed, so tests can play with all those "dangerous" calls in java.lang.System all they want. We need to be able to write tests that call System.exit or System.setProperties(new Properties()); etc By contrast, in samevm and agentvm modes, there is a presumption that a test will be reasonably well behaved, but just in case, we install a security manager to make sure. -- Jon P.S. I remember when someone wrote a test for System.setProperties that removed the definition of System.lineSeparator, causing jtreg to crash as soon as it tried to write the test results. On 12/10/2013 02:02 PM, Volker Simonis wrote: > > Hi Jonathan, > > thanks for you comments. But there's still one thing I > don't understand: what's the exact reason that tests in the agentvm > mode are running under a special security manager while test running > in othervm mode aren't restricted in this way. Is this really necessary? > > Regards, > Volker From jonathan.gibbons at oracle.com Wed Dec 11 12:12:41 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Dec 2013 12:12:41 -0800 Subject: Please update http://openjdk.java.net/jtreg/build.html In-Reply-To: References: Message-ID: <52A8C739.8050200@oracle.com> On 12/10/2013 02:12 AM, Volker Simonis wrote: > JT Harness > > - add the following: "Notice that unpacking the jtharness harness will > not implicitly create a directory. It is advised to first explicitly > create a jtharness directory and unzip the jtharness archive therein. > JTHARNESS_HOME should point to that directory." Volker, Thanks for commenting on this. Filed https://bugs.openjdk.java.net/browse/CODETOOLS-7900275 -- Jon From jonathan.gibbons at oracle.com Wed Dec 11 15:13:24 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 11 Dec 2013 15:13:24 -0800 Subject: Please update http://openjdk.java.net/jtreg/build.html In-Reply-To: <52A73FB0.8090501@oracle.com> References: <52A73FB0.8090501@oracle.com> Message-ID: <52A8F194.3080903@oracle.com> Volker, I have incorporated your suggestions into the main build.html. Thank you for taking the trouble to contribute a very specific set of suggestions and improvements. -- Jon On 12/10/2013 08:22 AM, Jonathan Gibbons wrote: > Volker, > > Thank you for your suggestions. I will work on incorporating them > into the main build.html file. > > -- Jon > > On 12/10/2013 02:12 AM, Volker Simonis wrote: >> Hi, >> >> yesterday I've build jtreg from source as described at: >> http://openjdk.java.net/jtreg/build.html >> >> While I succeed in the end, I found that some of the information on >> that page could be improved to make the build process easier. >> Following my proposals for updating the instructions: >> >> JavaHelp >> >> - add the follwing: "Unzip the javahelp zip file (e.g. >> javahelp2_0_05.zip) and set JAVAHELP_HOME to point to the resulting >> jh2.0/javahelp directory." >> >> JT Harness >> >> - add the following: "Notice that unpacking the jtharness harness will >> not implicitly create a directory. It is advised to first explicitly >> create a jtharness directory and unzip the jtharness archive therein. >> JTHARNESS_HOME should point to that directory." >> >> Xalan >> >> - add the following after the link to Xalan: "Go to the >> "Download/Build" section and follow the "xalan-j distribution >> directory" link. From there choose "Xalan java download area" and >> download "xalan-j_2_7_1-bin.zip" from the "binaries/" direcotry. Set >> XALANHOME to the directory which will be created when you unzip the >> xalan zip archive." >> >> JUnit >> >> - add the following: "Notice that only version smaller than 4.11 are >> supported. JUnit 4.11 and above do not contain the required >> org.hamcrest any more (they are now contained in their own jar file >> hamcrest-core.jar but jtreg/jtharness isn?t currently prepared to >> handle this). Set JUNIT_JAR to the junit jar file." >> >> TestNG >> >> - add the follwing: "For TestNG it is not enough to just download the >> testng jar file. Instead you have to download the complete testng >> archive from the link for ANT users in the download section. Unzip the >> archive and set TESTNG_HOME to point to the created directory and >> TESTNG_JAR to point to the testng jar file in that directory." >> >> - Because JUnit and TestNG are required for running the jdk regression >> test I'd suggest to move the JUnit and TestNG sections from the >> optional to the required dependencies. >> >> Ant >> >> - I also found that I did need to have ANTHOME defined. Otherwise I >> got build errors like: >> >> ../src/share/classes/com/sun/javatest/regtest/Main.java:61: package >> org.apache.tools.ant does not exist >> import org.apache.tools.ant.BuildException; >> >> - so please move the "Ant" section from optional to the required >> section and remove the sentence "It need not be set if you are just >> building jtreg." >> >> I havn't installed and used HTMLCheck/LinkLint but without these two, >> a complete build command line may look as follows: >> >> JDK15HOME=/share/software/Java/jdk1.6.0_26 >> JAVAHELP_HOME=/share/software/Java/JTREG_from_source/deps/jh2.0/javahelp >> JTHARNESS_HOME=/share/software/Java/JTREG_from_source/deps/jtharness-4_4_1-MR1-bin-b13-20_dec_2011 >> >> XALANHOME=/share/software/Java/JTREG_from_source/deps/xalan-j_2_7_1 >> TESTNG_HOME=/share/software/Java/JTREG_from_source/deps/testng-6.8 >> JUNIT_JAR=/share/software/Java/JTREG_from_source/deps/junit-4.10.jar >> TESTNG_JAR=/share/software/Java/JTREG_from_source/deps/testng-6.8/testng-6.8.jar >> >> ANTHOME=/share/software/Java/JTREG_from_source/deps/apache-ant-1.9.2 >> make -C make >> >> The resulting jtreg image can be found under build/images. >> >> It may be good to add such a line as example on how to build JTreg. >> >> Please feel free to correct and improve my proposal. >> >> Regards, >> Volker > From jonathan.gibbons at oracle.com Thu Dec 12 18:29:49 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Dec 2013 18:29:49 -0800 Subject: Please update http://openjdk.java.net/jtreg/build.html In-Reply-To: <52A8C739.8050200@oracle.com> References: <52A8C739.8050200@oracle.com> Message-ID: <52AA711D.4080104@oracle.com> Looks like this has just been fixed in jtharness 4.5. Woohoo! That's the good news. The bad news is that that Oracle will not piublish binaries for jtharness 4.5 or later. So I guess we'd better start checking out the build instructions for jtharness as well. -- Jon On 12/11/2013 12:12 PM, Jonathan Gibbons wrote: > > On 12/10/2013 02:12 AM, Volker Simonis wrote: >> JT Harness >> >> - add the following: "Notice that unpacking the jtharness harness will >> not implicitly create a directory. It is advised to first explicitly >> create a jtharness directory and unzip the jtharness archive therein. >> JTHARNESS_HOME should point to that directory." > > Volker, > > Thanks for commenting on this. > > Filed https://bugs.openjdk.java.net/browse/CODETOOLS-7900275 > > -- Jon From richard.warburton at gmail.com Fri Dec 13 02:28:50 2013 From: richard.warburton at gmail.com (Richard Warburton) Date: Fri, 13 Dec 2013 10:28:50 +0000 Subject: Please update http://openjdk.java.net/jtreg/build.html In-Reply-To: <52AA711D.4080104@oracle.com> References: <52A8C739.8050200@oracle.com> <52AA711D.4080104@oracle.com> Message-ID: Hi, Looks like this has just been fixed in jtharness 4.5. Woohoo! > That's the good news. The bad news is that that Oracle will > not piublish binaries for jtharness 4.5 or later. So I guess we'd > better start checking out the build instructions for jtharness > as well. > Do releases of these projects get tagged in the mercurial repo? Looking at the jtreg repo [0] I can see a series of build numbered releases and only starting at 4.1 but no history of released code. Is this due to jtreg being historically somewhere else? regards, Richard Warburton http://insightfullogic.com @RichardWarburto [0] http://hg.openjdk.java.net/code-tools/jtreg/tags From jonathan.gibbons at oracle.com Fri Dec 13 08:11:29 2013 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 13 Dec 2013 08:11:29 -0800 Subject: Please update http://openjdk.java.net/jtreg/build.html In-Reply-To: References: <52A8C739.8050200@oracle.com> <52AA711D.4080104@oracle.com> Message-ID: <52AB31B1.2000308@oracle.com> On 12/13/2013 02:28 AM, Richard Warburton wrote: > Hi, > > Looks like this has just been fixed in jtharness 4.5. Woohoo! > That's the good news. The bad news is that that Oracle will > not piublish binaries for jtharness 4.5 or later. So I guess we'd > better start checking out the build instructions for jtharness > as well. > > > Do releases of these projects get tagged in the mercurial repo? > > Looking at the jtreg repo [0] I can see a series of build numbered > releases and only starting at 4.1 but no history of released code. Is > this due to jtreg being historically somewhere else? > Hi Richard, Yes. jtreg was not Open Source before jtreg 4.1: the code for these early releases is not publicly available. The first few OS releases were via source bundles, so I initialized the Mercurial repo with the contents of these bundles. The intervening changesets in the closed version of the repos are not publicly available. Now, all dev work on jtreg uses the OpenJDK code-tools/jtreg Mercurial repo. There are occasional tags which represent occasional checkpoints. Unfortunately, we cannot publish binary builds corresponding to these versions, but they do correspond to the versions used within Oracle. Generally, internally, we use the latest tagged build (i.e. jtreg4.1-bNN) with a few brave folk being prepared to use the tip. And, FWIW, the need to stay on the 4.1 bNN numbering system has gone away so I expect that going forward, we will revert to a more conventional numbering system. I am aware that I have not written up some of the newer features (like test groups.) We are also working on a major update to the tag spec, but without some form of time dilation effect, there are not enough hours in the day for the people involved. -- Jon > regards, > > Richard Warburton > > http://insightfullogic.com > @RichardWarburto > > [0] http://hg.openjdk.java.net/code-tools/jtreg/tags From richard.warburton at gmail.com Sat Dec 14 01:40:05 2013 From: richard.warburton at gmail.com (Richard Warburton) Date: Sat, 14 Dec 2013 09:40:05 +0000 Subject: Please update http://openjdk.java.net/jtreg/build.html In-Reply-To: <52AB31B1.2000308@oracle.com> References: <52A8C739.8050200@oracle.com> <52AA711D.4080104@oracle.com> <52AB31B1.2000308@oracle.com> Message-ID: Hi, > Looks like this has just been fixed in jtharness 4.5. Woohoo! >> That's the good news. The bad news is that that Oracle will >> not piublish binaries for jtharness 4.5 or later. So I guess we'd >> better start checking out the build instructions for jtharness >> as well. >> > > Do releases of these projects get tagged in the mercurial repo? > > Looking at the jtreg repo [0] I can see a series of build numbered > releases and only starting at 4.1 but no history of released code. Is this > due to jtreg being historically somewhere else? > > > Hi Richard, > > Yes. jtreg was not Open Source before jtreg 4.1: the code for these early > releases is not publicly available. > > The first few OS releases were via source bundles, so I initialized the > Mercurial repo with the contents of these bundles. The intervening > changesets in the closed version of the repos are not publicly available. > > Now, all dev work on jtreg uses the OpenJDK code-tools/jtreg Mercurial > repo. There are occasional tags which represent occasional checkpoints. > Unfortunately, we cannot publish binary builds corresponding to these > versions, but they do correspond to the versions used within Oracle. > Generally, internally, we use the latest tagged build (i.e. jtreg4.1-bNN) > with a few brave folk being prepared to use the tip. > > And, FWIW, the need to stay on the 4.1 bNN numbering system has gone away > so I expect that going forward, we will revert to a more conventional > numbering system. > > I am aware that I have not written up some of the newer features (like > test groups.) We are also working on a major update to the tag spec, but > without some form of time dilation effect, there are not enough hours in > the day for the people involved. > Thanks for clarifying this - it all makes a lot more sense now. regards, Richard Warburton http://insightfullogic.com @RichardWarburto