From balchandra.vaidya at oracle.com Mon Jan 5 08:22:53 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Mon, 05 Jan 2015 13:52:53 +0530 Subject: JDK 9 early access b44 test results now available Message-ID: <54AA49DD.9040507@oracle.com> JDK 9 ea b44 test results are now available at : http://www.java.net/download/openjdk/testresults/9/testresults.html The jdk test results contain 28 differences from the b43 test results. There are 4 testcase failures, those failures are under investigation. 0: /home/jtest/merge9/b43/jdk/JTwork pass: 4,915; fail: 12; not run: 1,606 1: /home/jtest/merge9/b44/jdk/JTwork pass: 4,937; fail: 16; not run: 1,710 0 1 Test --- pass com/oracle/security/ucrypto/TestAlias.java --- fail com/sun/crypto/provider/Cipher/AES/CICO.java --- pass com/sun/crypto/provider/KeyAgreement/SameDHKeyStressTest.java --- pass com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationContentTest.java --- pass com/sun/management/GarbageCollectorMXBean/GarbageCollectionNotificationTest.java --- pass java/io/InputStream/TransferTo.java --- pass java/io/ObjectInputStream/PeekInputStreamTest.java --- pass java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java pass fail java/lang/ClassLoader/EndorsedDirs.java pass fail java/lang/ClassLoader/ExtDirs.java --- pass java/nio/channels/FileChannel/GetClosedChannel.java --- fail java/security/KeyStore/ProbeKeystores.java --- pass java/util/Locale/LocaleProviders.sh --- pass java/util/PluggableLocale/BreakIteratorProviderTest.sh --- pass java/util/PluggableLocale/CalendarDataProviderTest.sh --- pass java/util/PluggableLocale/CalendarNameProviderTest.sh --- pass java/util/PluggableLocale/CollatorProviderTest.sh --- pass java/util/PluggableLocale/CurrencyNameProviderTest.sh --- pass java/util/PluggableLocale/DateFormatProviderTest.sh --- pass java/util/PluggableLocale/DateFormatSymbolsProviderTest.sh --- pass java/util/PluggableLocale/DecimalFormatSymbolsProviderTest.sh --- pass java/util/PluggableLocale/GenericTest.sh --- pass java/util/PluggableLocale/LocaleNameProviderTest.sh --- pass java/util/PluggableLocale/NumberFormatProviderTest.sh --- pass java/util/PluggableLocale/TimeZoneNameProviderTest.sh --- pass java/util/ResourceBundle/Bug6299235Test.sh --- pass sun/util/calendar/zi/TestZoneInfo310.java --- pass tools/launcher/TooSmallStackSize.java 28 differences The hotspot test results contain 13 differences from the b43 test results. There is 1 testcase failure, this failure is under investigation. 0: /home/jtest/merge9/b43/hotspot/JTwork pass: 659; fail: 37; error: 1; not run: 31 1: /home/jtest/merge9/b44/hotspot/JTwork pass: 670; fail: 37; error: 1; not run: 31 0 1 Test fail pass compiler/dependencies/MonomorphicObjectCall/TestMonomorphicObjectCall.java --- pass compiler/exceptions/SumTest.java --- pass compiler/rangechecks/TestRangeCheckSmearing.java --- pass compiler/rangechecks/TestRangeCheckSmearingLoopOpts.java --- pass compiler/uncommontrap/TestDeoptOOM.java --- pass compiler/uncommontrap/TraceDeoptimizationNoRealloc.java --- pass gc/TestCardTablePageCommits.java pass fail runtime/CommandLine/TraceExceptionsTest.java --- pass runtime/Safepoint/AssertSafepointCheckConsistency1.java --- pass runtime/Safepoint/AssertSafepointCheckConsistency2.java --- pass runtime/Safepoint/AssertSafepointCheckConsistency3.java --- pass runtime/Safepoint/AssertSafepointCheckConsistency4.java --- pass runtime/SharedArchiveFile/PrintSharedArchiveAndExit.java 13 differences The langtools test results contain 17 differences from the b43 test results. No new testcase failures found. 0: /home/jtest/merge9/b43/langtools/JTwork pass: 3,163; not run: 14 1: /home/jtest/merge9/b44/langtools/JTwork pass: 3,178; not run: 14 0 1 Test --- pass tools/javac/lambda/8066974/T8066974.java --- pass tools/javac/lambda/8067792/T8067792.java --- pass tools/javac/lambda/lambdaNaming/TestNonSerializableLambdaNameStability.java --- pass tools/sjavac/CompileCircularSources.java --- pass tools/sjavac/CompileExcludingDependency.java --- pass tools/sjavac/CompileWithAtFile.java --- pass tools/sjavac/CompileWithInvisibleSources.java --- pass tools/sjavac/CompileWithOverrideSources.java --- pass tools/sjavac/IncCompileChangeNative.java --- pass tools/sjavac/IncCompileDropClasses.java --- pass tools/sjavac/IncCompileFullyQualifiedRef.java --- pass tools/sjavac/IncCompileNoChanges.java --- pass tools/sjavac/IncCompileUpdateNative.java --- pass tools/sjavac/IncCompileWithChanges.java --- pass tools/sjavac/PermittedArtifact.java pass --- tools/sjavac/SJavac.java --- pass tools/sjavac/StateDir.java 17 differences The nashorn test result is available at http://download.java.net/openjdk/testresults/9/archives/b44/emailable-report.html Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From adinn at redhat.com Mon Jan 5 11:43:40 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 05 Jan 2015 11:43:40 +0000 Subject: Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: <5490513A.30004@oracle.com> References: <5490282E.4070704@oracle.com> <549050F1.5060500@redhat.com> <5490513A.30004@oracle.com> Message-ID: <54AA78EC.2090702@redhat.com> Hi Rory, I am afraid I spoke too soon as far as building/running Byteman on JDK9 b42 is concerned (I made an error during testing whihc meant that I did nto test the correct version). The Byteman agent code (that's everything in in byteman-jar) appears to be working ok. However, there appears to be a problem with the BMUnit package (that's bundled in byteman-bmunit.jar) which integrates the Byteman agent into JUnit and TestNG. The problem arises because BMUnit relies on class Virtual Machine and other related classes to autoload the Byteman agent into a test JVM. The relevant behaviour is defined by the following classes com.sun.tools.attach.VirtualMachine com.sun.tools.attach.VirtualMachineDescriptor com.sun.tools.attach.AttachNotSupportedException com.sun.tools.attach.AgentLoadException com.sun.tools.attach.AgentInitializationException The code in byteman-bmunit.jar references the exception classes. There are also references to these classes in the utility jar byteman-install.jar which encapsulates the agent load routines. Both these jars build ok with JDK9 b42 -- references to the attach package are successfully resolved at compile time. However, I am getting run-time resolve failures for when the classes which reference then are loaded at runtime -- for example: ------------------------------------------------------- Running TestSuite ATest::foo() org.apache.maven.surefire.booter.SurefireExecutionException: com/sun/tools/attach/AgentInitializationException; nested exception is java.lang.NoClassDefFoundError: com/sun/tools/attach/AgentInitializationException java.lang.NoClassDefFoundError: com/sun/tools/attach/AgentInitializationException at org.jboss.byteman.contrib.bmunit.BMNGAbstractRunner.switchClass(BMNGAbstractRunner.java:231) at org.jboss.byteman.contrib.bmunit.BMNGListener.onFinish(BMNGListener.java:156) . . . Class BMNGAbstractRunner is a Byteman class which subclasses one of the classes in the TestNG test package so that it can identify Byteman annotations on test classes/methods before/after the associated tests are run. It's job is to load the Byteman agent (if it is not already present in the JVM) and then post it details of code transformations needed in order to test the application and request removal of the transforms once the test has been run. Transforms may require the agent to inject trace code, validation checks or code which creates and propagates faults into either application or runtime classes. The error above occurs when BMNGAbstractRunner invokes a method which initiates the agent load. The latter method calls Install.install() (defined in byteman-install.jar) which in turn calls VritualMachine.loadAgent(). If the agent load fails the BMUnit code tries to catch an AgentInitializationException because that indicates that the agent is already present. With JDK6/7/8 this exception class is resolved at compile time and runtime. With JDK9 the runtime resolution fails as you can see above. It is worth noting that I can bypass the above resolution problem in the BMUNit code by modifying the catch to use type Exception. However, when I do that I then find that the code in the byteman-install.jar also fails to resolve references to classes in the attach package. That in itself is not very surprising. However, what makes this interesting is that this resolution failure does not always happen. Class Install has a main method which exposes the same behaviour that BMUnit is employing allowing you to load an agent into an independently running JVM. If I invoke this main method from the java command line then references from Install (and other classes) to classes in the attach package /are/ resolved at runtime. So, when TestNG or JUnit invoke Install.install() we get runtime resolve failures but when class Install is run and invokes Install.install() the attach classes are resolved. I have not yet looked at what is going on in the JDK9 code to identify why the attach package class lookups fail under TestNG nor, indeed, why the command line invocation of class Install somehow manages to resolve those references. I will try to do so in the next few days. However, if you have any inkling as to how changes in the class lookup that might inhibit runtime (but not compile-time) resolution of references to this package I'd be very interested to hear it. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From Alan.Bateman at oracle.com Mon Jan 5 11:46:29 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 Jan 2015 11:46:29 +0000 Subject: Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: <54AA78EC.2090702@redhat.com> References: <5490282E.4070704@oracle.com> <549050F1.5060500@redhat.com> <5490513A.30004@oracle.com> <54AA78EC.2090702@redhat.com> Message-ID: <54AA7995.4080105@oracle.com> On 05/01/2015 11:43, Andrew Dinn wrote: > Hi Rory, > > I am afraid I spoke too soon as far as building/running Byteman on JDK9 > b42 is concerned (I made an error during testing whihc meant that I did > nto test the correct version). > > The Byteman agent code (that's everything in in byteman-jar) appears to > be working ok. However, there appears to be a problem with the BMUnit > package (that's bundled in byteman-bmunit.jar) which integrates the > Byteman agent into JUnit and TestNG. > > The problem arises because BMUnit relies on class Virtual Machine and > other related classes to autoload the Byteman agent into a test JVM. > The relevant behaviour is defined by the following classes > > com.sun.tools.attach.VirtualMachine > com.sun.tools.attach.VirtualMachineDescriptor > com.sun.tools.attach.AttachNotSupportedException > com.sun.tools.attach.AgentLoadException > com.sun.tools.attach.AgentInitializationException > > The code in byteman-bmunit.jar references the exception classes. There > are also references to these classes in the utility jar > byteman-install.jar which encapsulates the agent load routines. > > Both these jars build ok with JDK9 b42 -- references to the attach > package are successfully resolved at compile time. However, I am getting > run-time resolve failures for when the classes which reference then are > loaded at runtime -- for example: > > Are you running with a JRE download rather than a JDK download by any chance? The com.sun.tools.attach types should be visible when you are running with a JDK image. -Alan From adinn at redhat.com Mon Jan 5 11:58:08 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 05 Jan 2015 11:58:08 +0000 Subject: Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: <54AA7995.4080105@oracle.com> References: <5490282E.4070704@oracle.com> <549050F1.5060500@redhat.com> <5490513A.30004@oracle.com> <54AA78EC.2090702@redhat.com> <54AA7995.4080105@oracle.com> Message-ID: <54AA7C50.9000502@redhat.com> On 05/01/15 11:46, Alan Bateman wrote: >> . . . > Are you running with a JRE download rather than a JDK download by any > chance? The com.sun.tools.attach types should be visible when you are > running with a JDK image. Yes, I am running with a JDK download, specifically the Linux 64 bit b42 release that Rory mentioned when he advertised availability of that version jdk-9-ea-bin-b42-linux-x64-10_dec_2014.tar.gz regards, Andrew Dinn ----------- From Alan.Bateman at oracle.com Mon Jan 5 12:16:44 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 Jan 2015 12:16:44 +0000 Subject: Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: <54AA7C50.9000502@redhat.com> References: <5490282E.4070704@oracle.com> <549050F1.5060500@redhat.com> <5490513A.30004@oracle.com> <54AA78EC.2090702@redhat.com> <54AA7995.4080105@oracle.com> <54AA7C50.9000502@redhat.com> Message-ID: <54AA80AC.7080607@oracle.com> On 05/01/2015 11:58, Andrew Dinn wrote: > On 05/01/15 11:46, Alan Bateman wrote: >>> . . . >> Are you running with a JRE download rather than a JDK download by any >> chance? The com.sun.tools.attach types should be visible when you are >> running with a JDK image. > Yes, I am running with a JDK download, specifically the Linux 64 bit b42 > release that Rory mentioned when he advertised availability of that version > > jdk-9-ea-bin-b42-linux-x64-10_dec_2014.tar.gz > > regards, > If it's the JDK image then this should work as it's the equivalent of pre jdk9-b41 with tools.jar on the class path. So I think you will have to dig into, my only guess at this point is that TestNG is somehow delegating to the extension class loader rather than the system/application class loader. -Alan From adinn at redhat.com Mon Jan 5 16:55:42 2015 From: adinn at redhat.com (Andrew Dinn) Date: Mon, 05 Jan 2015 16:55:42 +0000 Subject: Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: <54AA80AC.7080607@oracle.com> References: <5490282E.4070704@oracle.com> <549050F1.5060500@redhat.com> <5490513A.30004@oracle.com> <54AA78EC.2090702@redhat.com> <54AA7995.4080105@oracle.com> <54AA7C50.9000502@redhat.com> <54AA80AC.7080607@oracle.com> Message-ID: <54AAC20E.3050405@redhat.com> Hi Alan/Rory, On 05/01/15 12:16, Alan Bateman wrote: >> . . . > If it's the JDK image then this should work as it's the equivalent of > pre jdk9-b41 with tools.jar on the class path. So I think you will have > to dig into, my only guess at this point is that TestNG is somehow > delegating to the extension class loader rather than the > system/application class loader. I have debugged this and the problem is indeed to do with faulty delegation - on the part of maven [naturlich :-]. Details are provided below. In summary, the problem can be fixed by configuring maven to stop dorking around with class loading. I'll be posting a new Byteman micro-release in the next week which can build and run correctly with all of JDK6/7/8/9. I'll announce details on this list when it is ready. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- The maven surefire plugin provides a boolean configuration property (childDelegation=true/false) which controls the behaviour of its loader implementation, class IsolatedClassLoader. The property configures loading to proceed either by normal parent delegation (childDelegation=true [sic]) or by means of a URL loader which first tries to use the bootstrap loader and then does a file lookup over each path element of the classpath (childDelegation=false). [Yes, I know the property name is bizarrely counter-intuitive but then this is maven %-]. Of course, being maven, it also defaults this configuration switch to false . . . which means that parent delegation as expected by the JDK9 module setup is bypassed. This rather dirty maven trick works ok for Byteman using JDK 6, 7 and 8 because with those versions the pom finagles tools.jar into the classpath as a runtime dependency. Of course, with 9 I had to disable that dependency so parent delegation is the only way to get the missing classes. If the pom configures tests to be run with childDelegation=true then things still work ok. From Alan.Bateman at oracle.com Mon Jan 5 17:09:18 2015 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 05 Jan 2015 17:09:18 +0000 Subject: Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: <54AAC20E.3050405@redhat.com> References: <5490282E.4070704@oracle.com> <549050F1.5060500@redhat.com> <5490513A.30004@oracle.com> <54AA78EC.2090702@redhat.com> <54AA7995.4080105@oracle.com> <54AA7C50.9000502@redhat.com> <54AA80AC.7080607@oracle.com> <54AAC20E.3050405@redhat.com> Message-ID: <54AAC53E.40306@oracle.com> Thanks for the update. So I'm curious how this worked previously, was this Maven plugin using its own class loader to load types from tools.jar? -Alan On 05/01/2015 16:55, Andrew Dinn wrote: > Hi Alan/Rory, > > On 05/01/15 12:16, Alan Bateman wrote: >>> . . . >> If it's the JDK image then this should work as it's the equivalent of >> pre jdk9-b41 with tools.jar on the class path. So I think you will have >> to dig into, my only guess at this point is that TestNG is somehow >> delegating to the extension class loader rather than the >> system/application class loader. > I have debugged this and the problem is indeed to do with faulty > delegation - on the part of maven [naturlich :-]. Details are provided > below. In summary, the problem can be fixed by configuring maven to stop > dorking around with class loading. I'll be posting a new Byteman > micro-release in the next week which can build and run correctly with > all of JDK6/7/8/9. I'll announce details on this list when it is ready. > > regards, > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in UK and Wales under Company Registration No. 3798903 > Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters > (USA), Michael O'Neill (Ireland) > > ----- 8< -------- 8< -------- 8< -------- 8< -------- 8< -------- 8< --- > > The maven surefire plugin provides a boolean configuration property > (childDelegation=true/false) which controls the behaviour of its loader > implementation, class IsolatedClassLoader. The property configures > loading to proceed either by normal parent delegation > (childDelegation=true [sic]) or by means of a URL loader which first > tries to use the bootstrap loader and then does a file lookup over each > path element of the classpath (childDelegation=false). > > [Yes, I know the property name is bizarrely counter-intuitive but then > this is maven %-]. > > Of course, being maven, it also defaults this configuration switch to > false . . . which means that parent delegation as expected by the JDK9 > module setup is bypassed. This rather dirty maven trick works ok for > Byteman using JDK 6, 7 and 8 because with those versions the pom > finagles tools.jar into the classpath as a runtime dependency. Of > course, with 9 I had to disable that dependency so parent delegation is > the only way to get the missing classes. If the pom configures tests to > be run with childDelegation=true then things still work ok. From adinn at redhat.com Tue Jan 6 09:44:13 2015 From: adinn at redhat.com (Andrew Dinn) Date: Tue, 06 Jan 2015 09:44:13 +0000 Subject: Early Access builds for JDK 9 b42, JDK 8 b18 & JDK 7 b03 are available on java.net In-Reply-To: <54AAC53E.40306@oracle.com> References: <5490282E.4070704@oracle.com> <549050F1.5060500@redhat.com> <5490513A.30004@oracle.com> <54AA78EC.2090702@redhat.com> <54AA7995.4080105@oracle.com> <54AA7C50.9000502@redhat.com> <54AA80AC.7080607@oracle.com> <54AAC20E.3050405@redhat.com> <54AAC53E.40306@oracle.com> Message-ID: <54ABAE6D.80102@redhat.com> On 05/01/15 17:09, Alan Bateman wrote: > > Thanks for the update. So I'm curious how this worked previously, was > this Maven plugin using its own class loader to load types from tools.jar? Well, . . . maven was using its own classloader to load types from /whatever jars/ it found in the classpath. So, to test an app with BMUnit you need to add both the byteman jars /and/ the tools jar to the classpath. e.g. from maven with Linux/Windows (but not Mac OSX) the latter requirement means you add this dependency: com.sun tools 1.6 system ${tools.jar} Of course, that fails if you are using JDK9. So, one of the changes needed to build byteman-bmunit.jar with JDK9 is to add the dependency in a profile conditional on the JDK version being in the range 1.6-1.8. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in UK and Wales under Company Registration No. 3798903 Directors: Michael Cunningham (USA), Matt Parson (USA), Charlie Peters (USA), Michael O'Neill (Ireland) From balchandra.vaidya at oracle.com Wed Jan 7 14:39:22 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Wed, 07 Jan 2015 20:09:22 +0530 Subject: JDK 8u40 ea b20 test results now available Message-ID: <54AD451A.6010505@oracle.com> JDK 8u40 ea b20 test results are now available at http://www.java.net/download/openjdk/testresults/8/testresults.html The jdk test results contain 1 difference from the b19 test results. No new testcase failures found. 0: /home/jtest/merge8/jdk8u40-b19/jdk/JTwork pass: 4,766; fail: 14; error: 1; not run: 1,004 1: /home/jtest/merge8/jdk8u40-b20/jdk/JTwork pass: 4,767; fail: 13; error: 1; not run: 1,004 0 1 Test fail pass com/sun/jndi/ldap/LdapTimeoutTest.java 1 differences The hotspot test results contain 1 difference from the b19 test results. No new testcase failures found. 0: /home/jtest/merge8/jdk8u40-b19/hotspot/JTwork pass: 614; fail: 34; error: 2; not run: 16 1: /home/jtest/merge8/jdk8u40-b20/hotspot/JTwork pass: 615; fail: 33; error: 2; not run: 16 0 1 Test fail pass gc/g1/TestShrinkAuxiliaryData25.java 1 differences The langtools test results contain 0 differences from the b19 test results. The nashorn test result is available at http://download.java.net/openjdk/testresults/8/archives8/jdk8u40-b20/emailable-report.html Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From balchandra.vaidya at oracle.com Tue Jan 13 13:55:40 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Tue, 13 Jan 2015 19:25:40 +0530 Subject: JDK 7u80 early access b04 test results now available Message-ID: <54B523DC.10506@oracle.com> JDK 7u80 ea b04 test results are now available at http://www.java.net/download/openjdk/testresults/7/testresults.html The jdk test results contain 5 differences from the b03 test results. There is one testcase failure, this failure is under investigation. 0: /home/jtest/merge7/jdk7u80-b03/jdk/JTwork pass: 3,966; fail: 13; not run: 857 1: /home/jtest/merge7/jdk7u80-b04/jdk/JTwork pass: 3,969; fail: 14; not run: 861 0 1 Test --- pass java/lang/Class/getDeclaredField/ClassDeclaredFieldsTest.java --- pass java/lang/reflect/Generics/ThreadSafety.java pass fail java/lang/reflect/Method/GenericStringTest.java --- pass javax/xml/jaxp/testng/parse/XMLEntityScannerLoad.java --- pass sun/tools/jconsole/ResourceCheckTest.sh 5 differences The hotspot test results contain 4 differences from the b03 test results. There are two testcase failures, those failures are under investigation. 0: /home/jtest/merge7/jdk7u80-b03/hotspot/JTwork pass: 285; fail: 9; not run: 4 1: /home/jtest/merge7/jdk7u80-b04/hotspot/JTwork pass: 286; fail: 10; error: 1; not run: 4 0 1 Test --- pass compiler/loopopts/TestDeadBackbranchArrayAccess.java --- pass runtime/CheckEndorsedAndExtDirs/EndorsedExtDirs.java --- fail runtime/LoadClass/LoadClassNegative.java pass error serviceability/sa/jmap-hashcode/Test8028623.java 4 differences The langtools test results contain 4 differences from the b03 test results. No new testcase failures found. 0: /home/jtest/merge7/jdk7u80-b03/langtools/JTwork pass: 1,970; not run: 4 1: /home/jtest/merge7/jdk7u80-b04/langtools/JTwork pass: 1,974; not run: 4 0 1 Test --- pass tools/javac/T6695379/AnnotationsAreNotCopiedToBridgeMethodsTest.java --- pass tools/javac/annotations/clinit/AnnoWithClinit1.java --- pass tools/javac/annotations/clinit/AnnoWithClinitFail.java --- pass tools/javac/flow/LVTHarness.java 4 differences Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From balchandra.vaidya at oracle.com Wed Jan 14 14:55:18 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Wed, 14 Jan 2015 20:25:18 +0530 Subject: JDK 9 early access b45 test results now available Message-ID: <54B68356.9060002@oracle.com> JDK 9 ea b45 test results are now available at : http://www.java.net/download/openjdk/testresults/9/testresults.html The jdk test results contain 9 differences from the b44 test results. No new testcase failures found. 0: /home/jtest/merge9/b44/jdk/JTwork pass: 4,937; fail: 16; not run: 1,710 1: /home/jtest/merge9/b45/jdk/JTwork pass: 4,944; fail: 12; not run: 1,711 0 1 Test fail pass com/sun/crypto/provider/Cipher/AES/CICO.java fail pass java/lang/ClassLoader/EndorsedDirs.java fail pass java/lang/ClassLoader/ExtDirs.java pass --- java/lang/ClassLoader/deadlock/GetResource.java fail pass java/security/KeyStore/ProbeKeystores.java --- pass javax/smartcardio/CommandAPDUTest.java --- pass javax/smartcardio/ResponseAPDUTest.java --- pass javax/smartcardio/TerminalFactorySpiTest.java --- pass sun/rmi/rmic/iiopCompilation/IIOPCompilation.java 9 differences The hotspot test results contain 5 differences from the b44 test results. No new testcase failures found. 0: /home/jtest/merge9/b44/hotspot/JTwork pass: 670; fail: 37; error: 1; not run: 31 1: /home/jtest/merge9/b45/hotspot/JTwork pass: 675; fail: 36; error: 1; not run: 31 0 1 Test --- pass compiler/tiered/ConstantGettersTransitionsTest.java --- pass compiler/tiered/LevelTransitionTest.java --- pass compiler/whitebox/DeoptimizeFramesTest.java --- pass gc/TestSmallHeap.java fail pass runtime/CommandLine/TraceExceptionsTest.java 5 differences The langtools test results contain 0 differences from the b44 test results. No new testcase failures found. The nashorn test result is available at http://download.java.net/openjdk/testresults/9/archives/b45/emailable-report.html Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnverburg at gmail.com Mon Jan 19 10:55:49 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Jan 2015 10:55:49 +0000 Subject: We have some Code Coverage results from JCov/JTreg! Message-ID: Hi all, John Oliver and Mani Sarkar spent some time on the most recent Adopt OpenJDK hackday and managed to get what looks like to be meaningful code coverage numbers for OpenJDK using the jcov/jtreg tools: Results for jdk9: http://sticky.uwcs.co.uk/jcov/ ========Code Tools Dev======== The configuration John used was as follows (is this the correct usage pattern?): Build jdk images install jtreg with the jcov export the normal vars: ``` export SOURCE_CODE=/home/joliver/workspace/jdk9/ export JTREG_INSTALL=/home/joliver/workspace/jtreg export JT_HOME=$JTREG_INSTALL export JTREG_HOME=$JTREG_INSTALL export PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk export JPRT_JTREG_HOME=${JT_HOME} export JPRT_JAVA_HOME=${PRODUCT_HOME} export JTREG_TIMEOUT_FACTOR=5 export CONCURRENCY=8 ``` cd into jdk/test edit the Makefile and add the following: ``` jdkroot=/home/joliver/workspace/jdk9/ JTREG_TEST_OPTIONS += -jcov/classes:$(jdkroot)/build/linux-x86_64-normal- server-release/jdk/modules/java.base JTREG_TEST_OPTIONS += -jcov/source:$(jdkroot)/jdk/ src/java.base/share/classes JTREG_TEST_OPTIONS += -jcov/include:* ``` just before the line: # Make sure jtreg exists then just run "make test" inside the root =======Quality Discuss======= Is this something that could be hosted by the quality group for the major OpenJDK code lines (7u, 8u and jdk9)? If not then the Adoption Group can host it on one of their external servers temporarily and we could link to that from the wiki(s)/project page(s). Cheers, Martijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rory.odonnell at oracle.com Mon Jan 19 13:53:24 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 19 Jan 2015 13:53:24 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: Message-ID: <54BD0C54.50708@oracle.com> On 19/01/2015 10:55, Martijn Verburg wrote: > Hi all, > > John Oliver and Mani Sarkar spent some time on the most recent Adopt > OpenJDK hackday and managed to get what looks like to be meaningful > code coverage numbers for OpenJDK using the jcov/jtreg tools: > > Results for jdk9: http://sticky.uwcs.co.uk/jcov/ > > ========Code Tools Dev======== > > The configuration John used was as follows (is this the correct usage > pattern?): > > Build jdk images > install jtreg with the jcov > > export the normal vars: > > ``` > export SOURCE_CODE=/home/joliver/workspace/jdk9/ > export JTREG_INSTALL=/home/joliver/workspace/jtreg > export JT_HOME=$JTREG_INSTALL > export JTREG_HOME=$JTREG_INSTALL > export > PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk > > export JPRT_JTREG_HOME=${JT_HOME} > export JPRT_JAVA_HOME=${PRODUCT_HOME} > export JTREG_TIMEOUT_FACTOR=5 > export CONCURRENCY=8 > ``` > > cd into jdk/test > > edit the Makefile and add the following: > > ``` > jdkroot=/home/joliver/workspace/jdk9/ > > JTREG_TEST_OPTIONS += > -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base > JTREG_TEST_OPTIONS += > -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes > JTREG_TEST_OPTIONS += -jcov/include:* > ``` > > just before the line: # Make sure jtreg exists > > then just run "make test" inside the root > > =======Quality Discuss======= Let me look into this Martijn, I will come back to you. Rgds,Rory > > Is this something that could be hosted by the quality group for the > major OpenJDK code lines (7u, 8u and jdk9)? > > If not then the Adoption Group can host it on one of their external > servers temporarily and we could link to that from the wiki(s)/project > page(s). > > Cheers, > Martijn -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From rory.odonnell at oracle.com Mon Jan 19 15:18:30 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 19 Jan 2015 15:18:30 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: Message-ID: <54BD2046.8020004@oracle.com> On 19/01/2015 10:55, Martijn Verburg wrote: > Hi all, > > John Oliver and Mani Sarkar spent some time on the most recent Adopt > OpenJDK hackday and managed to get what looks like to be meaningful > code coverage numbers for OpenJDK using the jcov/jtreg tools: > > Results for jdk9: http://sticky.uwcs.co.uk/jcov/ > > ========Code Tools Dev======== > > The configuration John used was as follows (is this the correct usage > pattern?): > > Build jdk images > install jtreg with the jcov > > export the normal vars: > > ``` > export SOURCE_CODE=/home/joliver/workspace/jdk9/ > export JTREG_INSTALL=/home/joliver/workspace/jtreg > export JT_HOME=$JTREG_INSTALL > export JTREG_HOME=$JTREG_INSTALL > export > PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk > > export JPRT_JTREG_HOME=${JT_HOME} > export JPRT_JAVA_HOME=${PRODUCT_HOME} > export JTREG_TIMEOUT_FACTOR=5 > export CONCURRENCY=8 > ``` > > cd into jdk/test > > edit the Makefile and add the following: > > ``` > jdkroot=/home/joliver/workspace/jdk9/ > > JTREG_TEST_OPTIONS += > -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base > JTREG_TEST_OPTIONS += > -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes > JTREG_TEST_OPTIONS += -jcov/include:* > ``` > > just before the line: # Make sure jtreg exists > > then just run "make test" inside the root > > =======Quality Discuss======= Hi Martijn, Posting the results on our wiki won't work, so I can provide a link to the results. Let me know when you have decided on the link locations. Rgds,Rory > > Is this something that could be hosted by the quality group for the > major OpenJDK code lines (7u, 8u and jdk9)? > > If not then the Adoption Group can host it on one of their external > servers temporarily and we could link to that from the wiki(s)/project > page(s). > > Cheers, > Martijn -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From martijnverburg at gmail.com Mon Jan 19 15:36:28 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Jan 2015 15:36:28 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: <54BD2046.8020004@oracle.com> References: <54BD2046.8020004@oracle.com> Message-ID: Hi Rory, Thanks - we're looking into the existing Cloudbees Jenkins instance to do this. A second question quick question - do the numbers we're publishing look right compared to your internal ones? Appreciate non OpenJDK tests run by Oracle means that they cover more. Cheers, Martijn On 19 January 2015 at 15:18, Rory O'Donnell wrote: > > On 19/01/2015 10:55, Martijn Verburg wrote: > >> Hi all, >> >> John Oliver and Mani Sarkar spent some time on the most recent Adopt >> OpenJDK hackday and managed to get what looks like to be meaningful code >> coverage numbers for OpenJDK using the jcov/jtreg tools: >> >> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >> >> ========Code Tools Dev======== >> >> The configuration John used was as follows (is this the correct usage >> pattern?): >> >> Build jdk images >> install jtreg with the jcov >> >> export the normal vars: >> >> ``` >> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >> export JTREG_INSTALL=/home/joliver/workspace/jtreg >> export JT_HOME=$JTREG_INSTALL >> export JTREG_HOME=$JTREG_INSTALL >> export PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk >> >> export JPRT_JTREG_HOME=${JT_HOME} >> export JPRT_JAVA_HOME=${PRODUCT_HOME} >> export JTREG_TIMEOUT_FACTOR=5 >> export CONCURRENCY=8 >> ``` >> >> cd into jdk/test >> >> edit the Makefile and add the following: >> >> ``` >> jdkroot=/home/joliver/workspace/jdk9/ >> >> JTREG_TEST_OPTIONS += -jcov/classes:$(jdkroot)/build/linux-x86_64-normal- >> server-release/jdk/modules/java.base >> JTREG_TEST_OPTIONS += -jcov/source:$(jdkroot)/jdk/ >> src/java.base/share/classes >> JTREG_TEST_OPTIONS += -jcov/include:* >> ``` >> >> just before the line: # Make sure jtreg exists >> >> then just run "make test" inside the root >> >> =======Quality Discuss======= >> > Hi Martijn, > > Posting the results on our wiki won't work, so I can provide a link to the > results. Let me know when you have decided on the link locations. > > Rgds,Rory > >> >> Is this something that could be hosted by the quality group for the major >> OpenJDK code lines (7u, 8u and jdk9)? >> >> If not then the Adoption Group can host it on one of their external >> servers temporarily and we could link to that from the wiki(s)/project >> page(s). >> >> Cheers, >> Martijn >> > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rory.odonnell at oracle.com Mon Jan 19 16:35:22 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 19 Jan 2015 16:35:22 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: <54BD2046.8020004@oracle.com> Message-ID: <54BD324A.8080706@oracle.com> On 19/01/2015 15:36, Martijn Verburg wrote: > Hi Rory, > > Thanks - we're looking into the existing Cloudbees Jenkins instance to > do this. ok > A second question quick question - do the numbers we're publishing > look right compared to your internal ones? > Appreciate non OpenJDK tests run by Oracle means that they cover more. > Comparing our internal numbers with yours would be like comparing apples with pears I'm afraid. Rgds,Rory > Cheers, > Martijn > > On 19 January 2015 at 15:18, Rory O'Donnell > wrote: > > > On 19/01/2015 10:55, Martijn Verburg wrote: > > Hi all, > > John Oliver and Mani Sarkar spent some time on the most recent > Adopt OpenJDK hackday and managed to get what looks like to be > meaningful code coverage numbers for OpenJDK using the > jcov/jtreg tools: > > Results for jdk9: http://sticky.uwcs.co.uk/jcov/ > > ========Code Tools Dev======== > > The configuration John used was as follows (is this the > correct usage pattern?): > > Build jdk images > install jtreg with the jcov > > export the normal vars: > > ``` > export SOURCE_CODE=/home/joliver/workspace/jdk9/ > export JTREG_INSTALL=/home/joliver/workspace/jtreg > export JT_HOME=$JTREG_INSTALL > export JTREG_HOME=$JTREG_INSTALL > export > PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk > > export JPRT_JTREG_HOME=${JT_HOME} > export JPRT_JAVA_HOME=${PRODUCT_HOME} > export JTREG_TIMEOUT_FACTOR=5 > export CONCURRENCY=8 > ``` > > cd into jdk/test > > edit the Makefile and add the following: > > ``` > jdkroot=/home/joliver/workspace/jdk9/ > > JTREG_TEST_OPTIONS += > -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base > JTREG_TEST_OPTIONS += > -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes > JTREG_TEST_OPTIONS += -jcov/include:* > ``` > > just before the line: # Make sure jtreg exists > > then just run "make test" inside the root > > =======Quality Discuss======= > > Hi Martijn, > > Posting the results on our wiki won't work, so I can provide a > link to the > results. Let me know when you have decided on the link locations. > > Rgds,Rory > > > Is this something that could be hosted by the quality group > for the major OpenJDK code lines (7u, 8u and jdk9)? > > If not then the Adoption Group can host it on one of their > external servers temporarily and we could link to that from > the wiki(s)/project page(s). > > Cheers, > Martijn > > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnverburg at gmail.com Mon Jan 19 17:28:11 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Jan 2015 17:28:11 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: <54BD324A.8080706@oracle.com> References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> Message-ID: Hi Rory, Understood - it will be good to be able to encourage various OpenJDK members to contribute / port tests into it and measure that. Small steps :-). On 19 January 2015 at 16:35, Rory O'Donnell wrote: > > On 19/01/2015 15:36, Martijn Verburg wrote: > > Hi Rory, > > Thanks - we're looking into the existing Cloudbees Jenkins instance to > do this. > > ok > > A second question quick question - do the numbers we're publishing look > right compared to your internal ones? > > Appreciate non OpenJDK tests run by Oracle means that they cover more. > > Comparing our internal numbers with yours would be like comparing apples > with pears > I'm afraid. > > Rgds,Rory > > Cheers, > Martijn > > On 19 January 2015 at 15:18, Rory O'Donnell > wrote: > >> >> On 19/01/2015 10:55, Martijn Verburg wrote: >> >>> Hi all, >>> >>> John Oliver and Mani Sarkar spent some time on the most recent Adopt >>> OpenJDK hackday and managed to get what looks like to be meaningful code >>> coverage numbers for OpenJDK using the jcov/jtreg tools: >>> >>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >>> >>> ========Code Tools Dev======== >>> >>> The configuration John used was as follows (is this the correct usage >>> pattern?): >>> >>> Build jdk images >>> install jtreg with the jcov >>> >>> export the normal vars: >>> >>> ``` >>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >>> export JTREG_INSTALL=/home/joliver/workspace/jtreg >>> export JT_HOME=$JTREG_INSTALL >>> export JTREG_HOME=$JTREG_INSTALL >>> export >>> PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk >>> >>> export JPRT_JTREG_HOME=${JT_HOME} >>> export JPRT_JAVA_HOME=${PRODUCT_HOME} >>> export JTREG_TIMEOUT_FACTOR=5 >>> export CONCURRENCY=8 >>> ``` >>> >>> cd into jdk/test >>> >>> edit the Makefile and add the following: >>> >>> ``` >>> jdkroot=/home/joliver/workspace/jdk9/ >>> >>> JTREG_TEST_OPTIONS += >>> -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base >>> JTREG_TEST_OPTIONS += >>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes >>> JTREG_TEST_OPTIONS += -jcov/include:* >>> ``` >>> >>> just before the line: # Make sure jtreg exists >>> >>> then just run "make test" inside the root >>> >>> =======Quality Discuss======= >>> >> Hi Martijn, >> >> Posting the results on our wiki won't work, so I can provide a link to the >> results. Let me know when you have decided on the link locations. >> >> Rgds,Rory >> >>> >>> Is this something that could be hosted by the quality group for the >>> major OpenJDK code lines (7u, 8u and jdk9)? >>> >>> If not then the Adoption Group can host it on one of their external >>> servers temporarily and we could link to that from the wiki(s)/project >>> page(s). >>> >>> Cheers, >>> Martijn >>> >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rory.odonnell at oracle.com Mon Jan 19 17:33:01 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 19 Jan 2015 17:33:01 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> Message-ID: <54BD3FCD.9040304@oracle.com> On 19/01/2015 17:28, Martijn Verburg wrote: > Hi Rory, > > Understood - it will be good to be able to encourage various OpenJDK > members to contribute / port tests into it and measure that. Small > steps :-). Sounds good Martijn, talk more on this at FOSDEM ? Rgds,Rory > > On 19 January 2015 at 16:35, Rory O'Donnell > wrote: > > > On 19/01/2015 15:36, Martijn Verburg wrote: >> Hi Rory, >> >> Thanks - we're looking into the existing Cloudbees Jenkins >> instance to do this. > ok >> A second question quick question - do the numbers we're >> publishing look right compared to your internal ones? >> Appreciate non OpenJDK tests run by Oracle means that they cover >> more. >> > Comparing our internal numbers with yours would be like comparing > apples with pears > I'm afraid. > > Rgds,Rory > >> Cheers, >> Martijn >> >> On 19 January 2015 at 15:18, Rory O'Donnell >> > wrote: >> >> >> On 19/01/2015 10:55, Martijn Verburg wrote: >> >> Hi all, >> >> John Oliver and Mani Sarkar spent some time on the most >> recent Adopt OpenJDK hackday and managed to get what >> looks like to be meaningful code coverage numbers for >> OpenJDK using the jcov/jtreg tools: >> >> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >> >> ========Code Tools Dev======== >> >> The configuration John used was as follows (is this the >> correct usage pattern?): >> >> Build jdk images >> install jtreg with the jcov >> >> export the normal vars: >> >> ``` >> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >> export JTREG_INSTALL=/home/joliver/workspace/jtreg >> export JT_HOME=$JTREG_INSTALL >> export JTREG_HOME=$JTREG_INSTALL >> export >> PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk >> >> export JPRT_JTREG_HOME=${JT_HOME} >> export JPRT_JAVA_HOME=${PRODUCT_HOME} >> export JTREG_TIMEOUT_FACTOR=5 >> export CONCURRENCY=8 >> ``` >> >> cd into jdk/test >> >> edit the Makefile and add the following: >> >> ``` >> jdkroot=/home/joliver/workspace/jdk9/ >> >> JTREG_TEST_OPTIONS += >> -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base >> JTREG_TEST_OPTIONS += >> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes >> JTREG_TEST_OPTIONS += -jcov/include:* >> ``` >> >> just before the line: # Make sure jtreg exists >> >> then just run "make test" inside the root >> >> =======Quality Discuss======= >> >> Hi Martijn, >> >> Posting the results on our wiki won't work, so I can provide >> a link to the >> results. Let me know when you have decided on the link >> locations. >> >> Rgds,Rory >> >> >> Is this something that could be hosted by the quality >> group for the major OpenJDK code lines (7u, 8u and jdk9)? >> >> If not then the Adoption Group can host it on one of >> their external servers temporarily and we could link to >> that from the wiki(s)/project page(s). >> >> Cheers, >> Martijn >> >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnverburg at gmail.com Mon Jan 19 17:34:17 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 19 Jan 2015 17:34:17 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: <54BD3FCD.9040304@oracle.com> References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> Message-ID: Sadly I may not be able to make FOSDEM, still trying to wrangle some clever ways to make it. Cheers, Martijn On 19 January 2015 at 17:33, Rory O'Donnell wrote: > > On 19/01/2015 17:28, Martijn Verburg wrote: > > Hi Rory, > > Understood - it will be good to be able to encourage various OpenJDK > members to contribute / port tests into it and measure that. Small steps > :-). > > Sounds good Martijn, talk more on this at FOSDEM ? > > Rgds,Rory > > > On 19 January 2015 at 16:35, Rory O'Donnell > wrote: > >> >> On 19/01/2015 15:36, Martijn Verburg wrote: >> >> Hi Rory, >> >> Thanks - we're looking into the existing Cloudbees Jenkins instance to >> do this. >> >> ok >> >> A second question quick question - do the numbers we're publishing look >> right compared to your internal ones? >> >> Appreciate non OpenJDK tests run by Oracle means that they cover more. >> >> >> Comparing our internal numbers with yours would be like comparing >> apples with pears >> I'm afraid. >> >> Rgds,Rory >> >> Cheers, >> Martijn >> >> On 19 January 2015 at 15:18, Rory O'Donnell >> wrote: >> >>> >>> On 19/01/2015 10:55, Martijn Verburg wrote: >>> >>>> Hi all, >>>> >>>> John Oliver and Mani Sarkar spent some time on the most recent Adopt >>>> OpenJDK hackday and managed to get what looks like to be meaningful code >>>> coverage numbers for OpenJDK using the jcov/jtreg tools: >>>> >>>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >>>> >>>> ========Code Tools Dev======== >>>> >>>> The configuration John used was as follows (is this the correct usage >>>> pattern?): >>>> >>>> Build jdk images >>>> install jtreg with the jcov >>>> >>>> export the normal vars: >>>> >>>> ``` >>>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >>>> export JTREG_INSTALL=/home/joliver/workspace/jtreg >>>> export JT_HOME=$JTREG_INSTALL >>>> export JTREG_HOME=$JTREG_INSTALL >>>> export >>>> PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk >>>> >>>> export JPRT_JTREG_HOME=${JT_HOME} >>>> export JPRT_JAVA_HOME=${PRODUCT_HOME} >>>> export JTREG_TIMEOUT_FACTOR=5 >>>> export CONCURRENCY=8 >>>> ``` >>>> >>>> cd into jdk/test >>>> >>>> edit the Makefile and add the following: >>>> >>>> ``` >>>> jdkroot=/home/joliver/workspace/jdk9/ >>>> >>>> JTREG_TEST_OPTIONS += >>>> -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base >>>> JTREG_TEST_OPTIONS += >>>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes >>>> JTREG_TEST_OPTIONS += -jcov/include:* >>>> ``` >>>> >>>> just before the line: # Make sure jtreg exists >>>> >>>> then just run "make test" inside the root >>>> >>>> =======Quality Discuss======= >>>> >>> Hi Martijn, >>> >>> Posting the results on our wiki won't work, so I can provide a link to >>> the >>> results. Let me know when you have decided on the link locations. >>> >>> Rgds,Rory >>> >>>> >>>> Is this something that could be hosted by the quality group for the >>>> major OpenJDK code lines (7u, 8u and jdk9)? >>>> >>>> If not then the Adoption Group can host it on one of their external >>>> servers temporarily and we could link to that from the wiki(s)/project >>>> page(s). >>>> >>>> Cheers, >>>> Martijn >>>> >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> > > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sadhak001 at gmail.com Mon Jan 19 22:56:16 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Mon, 19 Jan 2015 22:56:16 +0000 Subject: We have some Code Coverage results from JCov/JTreg! Message-ID: Hi all, On the below I was going to suggest, is it possible to have JCov metrics from other non-published tests and sources run on various environments and then combine them with the public version (from our servers). John Oliver did a patch for JaCoCO long ago, that way we can see pathways from other tests which only improve overall coverage metrics. Is there something available with the JCov tool itself ? Is this an idea that is feasible ? Cheers, Mani -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* > Message: 4 > Date: Mon, 19 Jan 2015 17:28:11 +0000 > From: Martijn Verburg > To: "Rory O'Donnell" > Cc: "quality-discuss at openjdk.java.net" > > Subject: Re: We have some Code Coverage results from JCov/JTreg! > Message-ID: > < > CAP7YuAS4RKwJFybHCi_r5q0Qr08MPr-Sz_7HNxRLN6n39cpn1Q at mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Hi Rory, > > Understood - it will be good to be able to encourage various OpenJDK > members to contribute / port tests into it and measure that. Small steps > :-). > > On 19 January 2015 at 16:35, Rory O'Donnell > wrote: > > > > > On 19/01/2015 15:36, Martijn Verburg wrote: > > > > Hi Rory, > > > > Thanks - we're looking into the existing Cloudbees Jenkins instance to > > do this. > > > > ok > > > > A second question quick question - do the numbers we're publishing look > > right compared to your internal ones? > > > > Appreciate non OpenJDK tests run by Oracle means that they cover more. > > > > Comparing our internal numbers with yours would be like comparing apples > > with pears > > I'm afraid. > > > > Rgds,Rory > > > > Cheers, > > Martijn > > > > On 19 January 2015 at 15:18, Rory O'Donnell > > wrote: > > > >> > >> On 19/01/2015 10:55, Martijn Verburg wrote: > >> > >>> Hi all, > >>> > >>> John Oliver and Mani Sarkar spent some time on the most recent Adopt > >>> OpenJDK hackday and managed to get what looks like to be meaningful > code > >>> coverage numbers for OpenJDK using the jcov/jtreg tools: > >>> > >>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ > >>> > >>> ========Code Tools Dev======== > >>> > >>> The configuration John used was as follows (is this the correct usage > >>> pattern?): > >>> > >>> Build jdk images > >>> install jtreg with the jcov > >>> > >>> export the normal vars: > >>> > >>> ``` > >>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ > >>> export JTREG_INSTALL=/home/joliver/workspace/jtreg > >>> export JT_HOME=$JTREG_INSTALL > >>> export JTREG_HOME=$JTREG_INSTALL > >>> export > >>> > PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk > >>> > >>> export JPRT_JTREG_HOME=${JT_HOME} > >>> export JPRT_JAVA_HOME=${PRODUCT_HOME} > >>> export JTREG_TIMEOUT_FACTOR=5 > >>> export CONCURRENCY=8 > >>> ``` > >>> > >>> cd into jdk/test > >>> > >>> edit the Makefile and add the following: > >>> > >>> ``` > >>> jdkroot=/home/joliver/workspace/jdk9/ > >>> > >>> JTREG_TEST_OPTIONS += > >>> > -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base > >>> JTREG_TEST_OPTIONS += > >>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes > >>> JTREG_TEST_OPTIONS += -jcov/include:* > >>> ``` > >>> > >>> just before the line: # Make sure jtreg exists > >>> > >>> then just run "make test" inside the root > >>> > >>> =======Quality Discuss======= > >>> > >> Hi Martijn, > >> > >> Posting the results on our wiki won't work, so I can provide a link to > the > >> results. Let me know when you have decided on the link locations. > >> > >> Rgds,Rory > >> > >>> > >>> Is this something that could be hosted by the quality group for the > >>> major OpenJDK code lines (7u, 8u and jdk9)? > >>> > >>> If not then the Adoption Group can host it on one of their external > >>> servers temporarily and we could link to that from the wiki(s)/project > >>> page(s). > >>> > >>> Cheers, > >>> Martijn > >>> > >> > >> -- > >> Rgds,Rory O'Donnell > >> Quality Engineering Manager > >> Oracle EMEA , Dublin, Ireland > >> > >> > > > > -- > > Rgds,Rory O'Donnell > > Quality Engineering Manager > > Oracle EMEA , Dublin, Ireland > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: < > http://mail.openjdk.java.net/pipermail/quality-discuss/attachments/20150119/2c08545b/attachment.html > > > > End of quality-discuss Digest, Vol 39, Issue 4 > ********************************************** -------------- next part -------------- An HTML attachment was scrubbed... URL: From rory.odonnell at oracle.com Tue Jan 20 08:50:04 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Tue, 20 Jan 2015 08:50:04 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: Message-ID: <54BE16BC.7060203@oracle.com> Hi Mani, I think Martijn's suggestion works better : - " it will be good to be able to encourage various OpenJDK members to contribute / port tests into it and measure that. Small steps" Rgds,Rory On 19/01/2015 22:56, Mani Sarkar wrote: > Hi all, > > On the below I was going to suggest, is it possible to have JCov > metrics from other non-published tests and sources run on various > environments and then combine them with the public version (from our > servers). > > John Oliver did a patch for JaCoCO long ago, that way we can see > pathways from other tests which only improve overall coverage metrics. > Is there something available with the JCov tool itself ? > > Is this an idea that is feasible ? > > Cheers, > Mani > > -- > @theNeomatrix369 *| **Blog > **| *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > *| **Bitbucket > * * | **Github > ** | **LinkedIn > * > *Come to Devoxx UK 2015:* http://www.devoxx.co.uk/ > > */Don't chase success, rather aim for "Excellence", and success will > come chasing after you!/* > > > Message: 4 > Date: Mon, 19 Jan 2015 17:28:11 +0000 > From: Martijn Verburg > > To: "Rory O'Donnell" > > Cc: "quality-discuss at openjdk.java.net > " > > > Subject: Re: We have some Code Coverage results from JCov/JTreg! > Message-ID: > > > > Content-Type: text/plain; charset="utf-8" > > Hi Rory, > > Understood - it will be good to be able to encourage various OpenJDK > members to contribute / port tests into it and measure that. Small > steps > :-). > > On 19 January 2015 at 16:35, Rory O'Donnell > > > wrote: > > > > > On 19/01/2015 15:36, Martijn Verburg wrote: > > > > Hi Rory, > > > > Thanks - we're looking into the existing Cloudbees Jenkins > instance to > > do this. > > > > ok > > > > A second question quick question - do the numbers we're > publishing look > > right compared to your internal ones? > > > > Appreciate non OpenJDK tests run by Oracle means that they > cover more. > > > > Comparing our internal numbers with yours would be like > comparing apples > > with pears > > I'm afraid. > > > > Rgds,Rory > > > > Cheers, > > Martijn > > > > On 19 January 2015 at 15:18, Rory O'Donnell > > > > wrote: > > > >> > >> On 19/01/2015 10:55, Martijn Verburg wrote: > >> > >>> Hi all, > >>> > >>> John Oliver and Mani Sarkar spent some time on the most recent > Adopt > >>> OpenJDK hackday and managed to get what looks like to be > meaningful code > >>> coverage numbers for OpenJDK using the jcov/jtreg tools: > >>> > >>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ > >>> > >>> ========Code Tools Dev======== > >>> > >>> The configuration John used was as follows (is this the > correct usage > >>> pattern?): > >>> > >>> Build jdk images > >>> install jtreg with the jcov > >>> > >>> export the normal vars: > >>> > >>> ``` > >>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ > >>> export JTREG_INSTALL=/home/joliver/workspace/jtreg > >>> export JT_HOME=$JTREG_INSTALL > >>> export JTREG_HOME=$JTREG_INSTALL > >>> export > >>> > PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk > >>> > >>> export JPRT_JTREG_HOME=${JT_HOME} > >>> export JPRT_JAVA_HOME=${PRODUCT_HOME} > >>> export JTREG_TIMEOUT_FACTOR=5 > >>> export CONCURRENCY=8 > >>> ``` > >>> > >>> cd into jdk/test > >>> > >>> edit the Makefile and add the following: > >>> > >>> ``` > >>> jdkroot=/home/joliver/workspace/jdk9/ > >>> > >>> JTREG_TEST_OPTIONS += > >>> > -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base > >>> JTREG_TEST_OPTIONS += > >>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes > >>> JTREG_TEST_OPTIONS += -jcov/include:* > >>> ``` > >>> > >>> just before the line: # Make sure jtreg exists > >>> > >>> then just run "make test" inside the root > >>> > >>> =======Quality Discuss======= > >>> > >> Hi Martijn, > >> > >> Posting the results on our wiki won't work, so I can provide a > link to the > >> results. Let me know when you have decided on the link locations. > >> > >> Rgds,Rory > >> > >>> > >>> Is this something that could be hosted by the quality group > for the > >>> major OpenJDK code lines (7u, 8u and jdk9)? > >>> > >>> If not then the Adoption Group can host it on one of their > external > >>> servers temporarily and we could link to that from the > wiki(s)/project > >>> page(s). > >>> > >>> Cheers, > >>> Martijn > >>> > >> > >> -- > >> Rgds,Rory O'Donnell > >> Quality Engineering Manager > >> Oracle EMEA , Dublin, Ireland > >> > >> > > > > -- > > Rgds,Rory O'Donnell > > Quality Engineering Manager > > Oracle EMEA , Dublin, Ireland > > > > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: > > > End of quality-discuss Digest, Vol 39, Issue 4 > ********************************************** > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -------------- next part -------------- An HTML attachment was scrubbed... URL: From balchandra.vaidya at oracle.com Fri Jan 23 12:12:47 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Fri, 23 Jan 2015 17:42:47 +0530 Subject: JDK 8u40 ea b21 test results now available Message-ID: <54C23ABF.4080903@oracle.com> JDK 8u40 ea b21 test results are now available at http://www.java.net/download/openjdk/testresults/8/testresults.html The jdk test results contain 4 differences from the b20 test results. There are 2 testcase failures, those failures are under investigation. 0: /home/jtest/merge8/jdk8u40-b20/jdk/JTwork pass: 4,767; fail: 13; error: 1; not run: 1,004 1: /home/jtest/merge8/jdk8u40-b21/jdk/JTwork pass: 4,768; fail: 15; not run: 1,003 0 1 Test --- pass java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java pass fail java/lang/management/MemoryMXBean/LowMemoryTest2.sh error pass sun/tools/jstatd/TestJstatdExternalRegistry.java --- fail sun/util/calendar/zi/TestZoneInfo310.java 4 differences The hotspot test results contain 1 difference from the b20 test results. There is 1 testcase failure, this failure is under investigation. 0: /home/jtest/merge8/jdk8u40-b20/hotspot/JTwork pass: 615; fail: 33; error: 2; not run: 16 1: /home/jtest/merge8/jdk8u40-b21/hotspot/JTwork pass: 615; fail: 34; error: 1; not run: 16 0 1 Test error fail serviceability/sa/jmap-hashcode/Test8028623.java 1 differences The langtools test results contain 0 differences from the b20 test results. The nashorn test result is available at http://download.java.net/openjdk/testresults/8/archives8/jdk8u40-b21/emailable-report.html Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From balchandra.vaidya at oracle.com Fri Jan 23 12:23:26 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Fri, 23 Jan 2015 17:53:26 +0530 Subject: JDK 9 early access b46 test results now available Message-ID: <54C23D3E.5030908@oracle.com> JDK 9 ea b46 test results are now available at : http://www.java.net/download/openjdk/testresults/9/testresults.html The jdk test results contain 2 differences from the b45 test results. No new testcase failures found. 0: /home/jtest/merge9/b45/jdk/JTwork pass: 4,944; fail: 12; not run: 1,711 1: /home/jtest/merge9/b46/jdk/JTwork pass: 4,944; fail: 12; not run: 1,712 0 1 Test --- pass javax/crypto/KeyGenerator/TestKGParity.java pass --- javax/management/remote/mandatory/notif/NotifReconnectDeadlockTest.java 2 differences The hotspot test results contain 1 difference from the b45 test results. No new testcase failures found. 0: /home/jtest/merge9/b45/hotspot/JTwork pass: 675; fail: 36; error: 1; not run: 31 1: /home/jtest/merge9/b46/hotspot/JTwork pass: 676; fail: 35; error: 1; not run: 31 0 1 Test fail pass gc/g1/TestShrinkAuxiliaryData25.java 1 differences The langtools test results contain 9 differences from the b45 test results. No new testcase failures found. 0: /home/jtest/merge9/b45/langtools/JTwork pass: 3,178; not run: 14 1: /home/jtest/merge9/b46/langtools/JTwork pass: 3,187; not run: 14 0 1 Test --- pass tools/javac/BranchToFewerDefines.java --- pass tools/javac/Diagnostics/compressed/8067883/T8067883.java --- pass tools/javac/api/file/SJFM_AsPath.java --- pass tools/javac/api/file/SJFM_GetFileObjects.java --- pass tools/javac/api/file/SJFM_IsSameFile.java --- pass tools/javac/api/file/SJFM_Locations.java --- pass tools/javac/conditional/ConditionalWithFinalStrings.java --- pass tools/javac/generics/MissingCast2.java --- pass tools/javac/tree/8067914/NukeExtraCast.java 9 differences The nashorn test result is available at http://download.java.net/openjdk/testresults/9/archives/b46/emailable-report.html Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnverburg at gmail.com Sun Jan 25 14:15:00 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 25 Jan 2015 14:15:00 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> Message-ID: Looks like I'm going now :-) - we can discuss further then, in the mean time Mani and I will try to get something up and running on the CloudBees CI instances. Cheers, Martijn On 19 January 2015 at 17:34, Martijn Verburg wrote: > Sadly I may not be able to make FOSDEM, still trying to wrangle some > clever ways to make it. > > Cheers, > Martijn > > On 19 January 2015 at 17:33, Rory O'Donnell > wrote: > >> >> On 19/01/2015 17:28, Martijn Verburg wrote: >> >> Hi Rory, >> >> Understood - it will be good to be able to encourage various OpenJDK >> members to contribute / port tests into it and measure that. Small steps >> :-). >> >> Sounds good Martijn, talk more on this at FOSDEM ? >> >> Rgds,Rory >> >> >> On 19 January 2015 at 16:35, Rory O'Donnell >> wrote: >> >>> >>> On 19/01/2015 15:36, Martijn Verburg wrote: >>> >>> Hi Rory, >>> >>> Thanks - we're looking into the existing Cloudbees Jenkins instance to >>> do this. >>> >>> ok >>> >>> A second question quick question - do the numbers we're publishing >>> look right compared to your internal ones? >>> >>> Appreciate non OpenJDK tests run by Oracle means that they cover >>> more. >>> >>> Comparing our internal numbers with yours would be like comparing >>> apples with pears >>> I'm afraid. >>> >>> Rgds,Rory >>> >>> Cheers, >>> Martijn >>> >>> On 19 January 2015 at 15:18, Rory O'Donnell >>> wrote: >>> >>>> >>>> On 19/01/2015 10:55, Martijn Verburg wrote: >>>> >>>>> Hi all, >>>>> >>>>> John Oliver and Mani Sarkar spent some time on the most recent Adopt >>>>> OpenJDK hackday and managed to get what looks like to be meaningful code >>>>> coverage numbers for OpenJDK using the jcov/jtreg tools: >>>>> >>>>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >>>>> >>>>> ========Code Tools Dev======== >>>>> >>>>> The configuration John used was as follows (is this the correct usage >>>>> pattern?): >>>>> >>>>> Build jdk images >>>>> install jtreg with the jcov >>>>> >>>>> export the normal vars: >>>>> >>>>> ``` >>>>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >>>>> export JTREG_INSTALL=/home/joliver/workspace/jtreg >>>>> export JT_HOME=$JTREG_INSTALL >>>>> export JTREG_HOME=$JTREG_INSTALL >>>>> export >>>>> PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk >>>>> >>>>> export JPRT_JTREG_HOME=${JT_HOME} >>>>> export JPRT_JAVA_HOME=${PRODUCT_HOME} >>>>> export JTREG_TIMEOUT_FACTOR=5 >>>>> export CONCURRENCY=8 >>>>> ``` >>>>> >>>>> cd into jdk/test >>>>> >>>>> edit the Makefile and add the following: >>>>> >>>>> ``` >>>>> jdkroot=/home/joliver/workspace/jdk9/ >>>>> >>>>> JTREG_TEST_OPTIONS += >>>>> -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base >>>>> JTREG_TEST_OPTIONS += >>>>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes >>>>> JTREG_TEST_OPTIONS += -jcov/include:* >>>>> ``` >>>>> >>>>> just before the line: # Make sure jtreg exists >>>>> >>>>> then just run "make test" inside the root >>>>> >>>>> =======Quality Discuss======= >>>>> >>>> Hi Martijn, >>>> >>>> Posting the results on our wiki won't work, so I can provide a link to >>>> the >>>> results. Let me know when you have decided on the link locations. >>>> >>>> Rgds,Rory >>>> >>>>> >>>>> Is this something that could be hosted by the quality group for the >>>>> major OpenJDK code lines (7u, 8u and jdk9)? >>>>> >>>>> If not then the Adoption Group can host it on one of their external >>>>> servers temporarily and we could link to that from the wiki(s)/project >>>>> page(s). >>>>> >>>>> Cheers, >>>>> Martijn >>>>> >>>> >>>> -- >>>> Rgds,Rory O'Donnell >>>> Quality Engineering Manager >>>> Oracle EMEA , Dublin, Ireland >>>> >>>> >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> >> >> -- >> Rgds,Rory O'Donnell >> Quality Engineering Manager >> Oracle EMEA , Dublin, Ireland >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnverburg at gmail.com Sun Jan 25 14:45:10 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 25 Jan 2015 14:45:10 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> Message-ID: Right, @Mani - How's your week placed? Let's see if we can get together to make https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/openjdk-1.9-linux-x86_64/ produce some results. @Rory - I've made a few changes to the Cloudbees CI build farm, would it be possible to enhance https://wiki.openjdk.java.net/display/Adoption/Quality+Outreach page so that it has: 1.) A link to the Quality Outreach section of the build farm ( https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/) 2.) It lists OpenJDK being built nightly (listed here: https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK) 3.) Lists the OpenJDK code tools being built nightly (listed here: https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK%20code-tools/) Also, I'm not sure if we should reach out to code-tools, jdk9-dev and jdk8u-dev and ask them to have links to the CI farm as well? I think it would be a good idea to highlight this though. Cheers, Martijn On 25 January 2015 at 14:15, Martijn Verburg wrote: > Looks like I'm going now :-) - we can discuss further then, in the mean > time Mani and I will try to get something up and running on the CloudBees > CI instances. > > Cheers, > Martijn > > On 19 January 2015 at 17:34, Martijn Verburg > wrote: > >> Sadly I may not be able to make FOSDEM, still trying to wrangle some >> clever ways to make it. >> >> Cheers, >> Martijn >> >> On 19 January 2015 at 17:33, Rory O'Donnell >> wrote: >> >>> >>> On 19/01/2015 17:28, Martijn Verburg wrote: >>> >>> Hi Rory, >>> >>> Understood - it will be good to be able to encourage various OpenJDK >>> members to contribute / port tests into it and measure that. Small steps >>> :-). >>> >>> Sounds good Martijn, talk more on this at FOSDEM ? >>> >>> Rgds,Rory >>> >>> >>> On 19 January 2015 at 16:35, Rory O'Donnell >>> wrote: >>> >>>> >>>> On 19/01/2015 15:36, Martijn Verburg wrote: >>>> >>>> Hi Rory, >>>> >>>> Thanks - we're looking into the existing Cloudbees Jenkins instance >>>> to do this. >>>> >>>> ok >>>> >>>> A second question quick question - do the numbers we're publishing >>>> look right compared to your internal ones? >>>> >>>> Appreciate non OpenJDK tests run by Oracle means that they cover >>>> more. >>>> >>>> Comparing our internal numbers with yours would be like comparing >>>> apples with pears >>>> I'm afraid. >>>> >>>> Rgds,Rory >>>> >>>> Cheers, >>>> Martijn >>>> >>>> On 19 January 2015 at 15:18, Rory O'Donnell >>>> wrote: >>>> >>>>> >>>>> On 19/01/2015 10:55, Martijn Verburg wrote: >>>>> >>>>>> Hi all, >>>>>> >>>>>> John Oliver and Mani Sarkar spent some time on the most recent Adopt >>>>>> OpenJDK hackday and managed to get what looks like to be meaningful code >>>>>> coverage numbers for OpenJDK using the jcov/jtreg tools: >>>>>> >>>>>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >>>>>> >>>>>> ========Code Tools Dev======== >>>>>> >>>>>> The configuration John used was as follows (is this the correct usage >>>>>> pattern?): >>>>>> >>>>>> Build jdk images >>>>>> install jtreg with the jcov >>>>>> >>>>>> export the normal vars: >>>>>> >>>>>> ``` >>>>>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >>>>>> export JTREG_INSTALL=/home/joliver/workspace/jtreg >>>>>> export JT_HOME=$JTREG_INSTALL >>>>>> export JTREG_HOME=$JTREG_INSTALL >>>>>> export >>>>>> PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk >>>>>> >>>>>> export JPRT_JTREG_HOME=${JT_HOME} >>>>>> export JPRT_JAVA_HOME=${PRODUCT_HOME} >>>>>> export JTREG_TIMEOUT_FACTOR=5 >>>>>> export CONCURRENCY=8 >>>>>> ``` >>>>>> >>>>>> cd into jdk/test >>>>>> >>>>>> edit the Makefile and add the following: >>>>>> >>>>>> ``` >>>>>> jdkroot=/home/joliver/workspace/jdk9/ >>>>>> >>>>>> JTREG_TEST_OPTIONS += >>>>>> -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base >>>>>> JTREG_TEST_OPTIONS += >>>>>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes >>>>>> JTREG_TEST_OPTIONS += -jcov/include:* >>>>>> ``` >>>>>> >>>>>> just before the line: # Make sure jtreg exists >>>>>> >>>>>> then just run "make test" inside the root >>>>>> >>>>>> =======Quality Discuss======= >>>>>> >>>>> Hi Martijn, >>>>> >>>>> Posting the results on our wiki won't work, so I can provide a link to >>>>> the >>>>> results. Let me know when you have decided on the link locations. >>>>> >>>>> Rgds,Rory >>>>> >>>>>> >>>>>> Is this something that could be hosted by the quality group for the >>>>>> major OpenJDK code lines (7u, 8u and jdk9)? >>>>>> >>>>>> If not then the Adoption Group can host it on one of their external >>>>>> servers temporarily and we could link to that from the wiki(s)/project >>>>>> page(s). >>>>>> >>>>>> Cheers, >>>>>> Martijn >>>>>> >>>>> >>>>> -- >>>>> Rgds,Rory O'Donnell >>>>> Quality Engineering Manager >>>>> Oracle EMEA , Dublin, Ireland >>>>> >>>>> >>>> >>>> -- >>>> Rgds,Rory O'Donnell >>>> Quality Engineering Manager >>>> Oracle EMEA , Dublin, Ireland >>>> >>>> >>> >>> -- >>> Rgds,Rory O'Donnell >>> Quality Engineering Manager >>> Oracle EMEA , Dublin, Ireland >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From martijnverburg at gmail.com Sun Jan 25 17:49:40 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Sun, 25 Jan 2015 17:49:40 +0000 Subject: FOSS projects tested on Java 7u, 8u and 9dev - some detective skills required! Message-ID: Hi all, Quick update and a request for help! 1.) We're co-ordinating efforts here: https://wiki.openjdk. java.net/display/Adoption/Quality+Outreach One of the issues is that we don't have links to the CI server involved in the builds in many cases. ACTION: We'd like some help in tracking down where the public CI servers are! 2.) I've gone through and performed a triage today but there are still a large number of projects on https://java.net/projects/adoptopenjdk/pages/TestingJava8 which have not been migrated across. One of the issues is that we don't have links to the CI server involved in the builds in many cases. ACTION: We'd like some help in tracking down where the public CI servers are! As and when people find them, please fire the links back to quality-discuss (for projects on https://wiki.openjdk. java.net/display/Adoption/Quality+Outreach) and adoption-discuss (for projects on https://java.net/projects/adoptopenjdk/pages/TestingJava8) and Rory and I will update accordingly. Cheers, Martijn -------------- next part -------------- An HTML attachment was scrubbed... URL: From rory.odonnell at oracle.com Mon Jan 26 10:32:57 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 26 Jan 2015 10:32:57 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> Message-ID: <54C617D9.2020605@oracle.com> On 25/01/2015 14:45, Martijn Verburg wrote: > Right, > > @Mani - How's your week placed? Let's see if we can get together to make > https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/openjdk-1.9-linux-x86_64/ > produce some results. > > @Rory - I've made a few changes to the Cloudbees CI build farm, would it be > possible to enhance > https://wiki.openjdk.java.net/display/Adoption/Quality+Outreach page so > that it has: > > 1.) A link to the Quality Outreach section of the build farm ( > https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/) > > 2.) It lists OpenJDK being built nightly (listed here: > https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK) > > 3.) Lists the OpenJDK code tools being built nightly (listed here: > https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK%20code-tools/) Done - listed you as maintainer, should I have said London JUGs ? Rgds,Rory > > Also, I'm not sure if we should reach out to code-tools, jdk9-dev and > jdk8u-dev and ask them to have links to the CI farm as well? I think it > would be a good idea to highlight this though. > > Cheers, > Martijn > > On 25 January 2015 at 14:15, Martijn Verburg > wrote: > >> Looks like I'm going now :-) - we can discuss further then, in the mean >> time Mani and I will try to get something up and running on the CloudBees >> CI instances. >> >> Cheers, >> Martijn >> >> On 19 January 2015 at 17:34, Martijn Verburg >> wrote: >> >>> Sadly I may not be able to make FOSDEM, still trying to wrangle some >>> clever ways to make it. >>> >>> Cheers, >>> Martijn >>> >>> On 19 January 2015 at 17:33, Rory O'Donnell >>> wrote: >>> >>>> On 19/01/2015 17:28, Martijn Verburg wrote: >>>> >>>> Hi Rory, >>>> >>>> Understood - it will be good to be able to encourage various OpenJDK >>>> members to contribute / port tests into it and measure that. Small steps >>>> :-). >>>> >>>> Sounds good Martijn, talk more on this at FOSDEM ? >>>> >>>> Rgds,Rory >>>> >>>> >>>> On 19 January 2015 at 16:35, Rory O'Donnell >>>> wrote: >>>> >>>>> On 19/01/2015 15:36, Martijn Verburg wrote: >>>>> >>>>> Hi Rory, >>>>> >>>>> Thanks - we're looking into the existing Cloudbees Jenkins instance >>>>> to do this. >>>>> >>>>> ok >>>>> >>>>> A second question quick question - do the numbers we're publishing >>>>> look right compared to your internal ones? >>>>> >>>>> Appreciate non OpenJDK tests run by Oracle means that they cover >>>>> more. >>>>> >>>>> Comparing our internal numbers with yours would be like comparing >>>>> apples with pears >>>>> I'm afraid. >>>>> >>>>> Rgds,Rory >>>>> >>>>> Cheers, >>>>> Martijn >>>>> >>>>> On 19 January 2015 at 15:18, Rory O'Donnell >>>>> wrote: >>>>> >>>>>> On 19/01/2015 10:55, Martijn Verburg wrote: >>>>>> >>>>>>> Hi all, >>>>>>> >>>>>>> John Oliver and Mani Sarkar spent some time on the most recent Adopt >>>>>>> OpenJDK hackday and managed to get what looks like to be meaningful code >>>>>>> coverage numbers for OpenJDK using the jcov/jtreg tools: >>>>>>> >>>>>>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >>>>>>> >>>>>>> ========Code Tools Dev======== >>>>>>> >>>>>>> The configuration John used was as follows (is this the correct usage >>>>>>> pattern?): >>>>>>> >>>>>>> Build jdk images >>>>>>> install jtreg with the jcov >>>>>>> >>>>>>> export the normal vars: >>>>>>> >>>>>>> ``` >>>>>>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >>>>>>> export JTREG_INSTALL=/home/joliver/workspace/jtreg >>>>>>> export JT_HOME=$JTREG_INSTALL >>>>>>> export JTREG_HOME=$JTREG_INSTALL >>>>>>> export >>>>>>> PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk >>>>>>> >>>>>>> export JPRT_JTREG_HOME=${JT_HOME} >>>>>>> export JPRT_JAVA_HOME=${PRODUCT_HOME} >>>>>>> export JTREG_TIMEOUT_FACTOR=5 >>>>>>> export CONCURRENCY=8 >>>>>>> ``` >>>>>>> >>>>>>> cd into jdk/test >>>>>>> >>>>>>> edit the Makefile and add the following: >>>>>>> >>>>>>> ``` >>>>>>> jdkroot=/home/joliver/workspace/jdk9/ >>>>>>> >>>>>>> JTREG_TEST_OPTIONS += >>>>>>> -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base >>>>>>> JTREG_TEST_OPTIONS += >>>>>>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes >>>>>>> JTREG_TEST_OPTIONS += -jcov/include:* >>>>>>> ``` >>>>>>> >>>>>>> just before the line: # Make sure jtreg exists >>>>>>> >>>>>>> then just run "make test" inside the root >>>>>>> >>>>>>> =======Quality Discuss======= >>>>>>> >>>>>> Hi Martijn, >>>>>> >>>>>> Posting the results on our wiki won't work, so I can provide a link to >>>>>> the >>>>>> results. Let me know when you have decided on the link locations. >>>>>> >>>>>> Rgds,Rory >>>>>> >>>>>>> Is this something that could be hosted by the quality group for the >>>>>>> major OpenJDK code lines (7u, 8u and jdk9)? >>>>>>> >>>>>>> If not then the Adoption Group can host it on one of their external >>>>>>> servers temporarily and we could link to that from the wiki(s)/project >>>>>>> page(s). >>>>>>> >>>>>>> Cheers, >>>>>>> Martijn >>>>>>> >>>>>> -- >>>>>> Rgds,Rory O'Donnell >>>>>> Quality Engineering Manager >>>>>> Oracle EMEA , Dublin, Ireland >>>>>> >>>>>> >>>>> -- >>>>> Rgds,Rory O'Donnell >>>>> Quality Engineering Manager >>>>> Oracle EMEA , Dublin, Ireland >>>>> >>>>> >>>> -- >>>> Rgds,Rory O'Donnell >>>> Quality Engineering Manager >>>> Oracle EMEA , Dublin, Ireland >>>> >>>> -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From martijnverburg at gmail.com Mon Jan 26 10:35:25 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 26 Jan 2015 10:35:25 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: <54C617D9.2020605@oracle.com> References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> <54C617D9.2020605@oracle.com> Message-ID: Hi Rory, I think Adoption Group would be best, thanks! Cheers, Martijn On 26 January 2015 at 10:32, Rory O'Donnell wrote: > > On 25/01/2015 14:45, Martijn Verburg wrote: > >> Right, >> >> @Mani - How's your week placed? Let's see if we can get together to make >> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/ >> job/openjdk-1.9-linux-x86_64/ >> produce some results. >> >> @Rory - I've made a few changes to the Cloudbees CI build farm, would it >> be >> possible to enhance >> https://wiki.openjdk.java.net/display/Adoption/Quality+Outreach page so >> that it has: >> >> 1.) A link to the Quality Outreach section of the build farm ( >> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/) >> >> 2.) It lists OpenJDK being built nightly (listed here: >> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK) >> >> 3.) Lists the OpenJDK code tools being built nightly (listed here: >> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK%20code-tools/) >> > Done - listed you as maintainer, should I have said London JUGs ? > > Rgds,Rory > > >> Also, I'm not sure if we should reach out to code-tools, jdk9-dev and >> jdk8u-dev and ask them to have links to the CI farm as well? I think it >> would be a good idea to highlight this though. >> >> Cheers, >> Martijn >> >> On 25 January 2015 at 14:15, Martijn Verburg >> wrote: >> >> Looks like I'm going now :-) - we can discuss further then, in the mean >>> time Mani and I will try to get something up and running on the CloudBees >>> CI instances. >>> >>> Cheers, >>> Martijn >>> >>> On 19 January 2015 at 17:34, Martijn Verburg >>> wrote: >>> >>> Sadly I may not be able to make FOSDEM, still trying to wrangle some >>>> clever ways to make it. >>>> >>>> Cheers, >>>> Martijn >>>> >>>> On 19 January 2015 at 17:33, Rory O'Donnell >>>> wrote: >>>> >>>> On 19/01/2015 17:28, Martijn Verburg wrote: >>>>> >>>>> Hi Rory, >>>>> >>>>> Understood - it will be good to be able to encourage various OpenJDK >>>>> members to contribute / port tests into it and measure that. Small >>>>> steps >>>>> :-). >>>>> >>>>> Sounds good Martijn, talk more on this at FOSDEM ? >>>>> >>>>> Rgds,Rory >>>>> >>>>> >>>>> On 19 January 2015 at 16:35, Rory O'Donnell < >>>>> rory.odonnell at oracle.com> >>>>> wrote: >>>>> >>>>> On 19/01/2015 15:36, Martijn Verburg wrote: >>>>>> >>>>>> Hi Rory, >>>>>> >>>>>> Thanks - we're looking into the existing Cloudbees Jenkins instance >>>>>> to do this. >>>>>> >>>>>> ok >>>>>> >>>>>> A second question quick question - do the numbers we're publishing >>>>>> look right compared to your internal ones? >>>>>> >>>>>> Appreciate non OpenJDK tests run by Oracle means that they cover >>>>>> more. >>>>>> >>>>>> Comparing our internal numbers with yours would be like comparing >>>>>> apples with pears >>>>>> I'm afraid. >>>>>> >>>>>> Rgds,Rory >>>>>> >>>>>> Cheers, >>>>>> Martijn >>>>>> >>>>>> On 19 January 2015 at 15:18, Rory O'Donnell >>>>> > >>>>>> wrote: >>>>>> >>>>>> On 19/01/2015 10:55, Martijn Verburg wrote: >>>>>>> >>>>>>> Hi all, >>>>>>>> >>>>>>>> John Oliver and Mani Sarkar spent some time on the most recent Adopt >>>>>>>> OpenJDK hackday and managed to get what looks like to be meaningful >>>>>>>> code >>>>>>>> coverage numbers for OpenJDK using the jcov/jtreg tools: >>>>>>>> >>>>>>>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >>>>>>>> >>>>>>>> ========Code Tools Dev======== >>>>>>>> >>>>>>>> The configuration John used was as follows (is this the correct >>>>>>>> usage >>>>>>>> pattern?): >>>>>>>> >>>>>>>> Build jdk images >>>>>>>> install jtreg with the jcov >>>>>>>> >>>>>>>> export the normal vars: >>>>>>>> >>>>>>>> ``` >>>>>>>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >>>>>>>> export JTREG_INSTALL=/home/joliver/workspace/jtreg >>>>>>>> export JT_HOME=$JTREG_INSTALL >>>>>>>> export JTREG_HOME=$JTREG_INSTALL >>>>>>>> export >>>>>>>> PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal- >>>>>>>> server-release/images/jdk >>>>>>>> >>>>>>>> export JPRT_JTREG_HOME=${JT_HOME} >>>>>>>> export JPRT_JAVA_HOME=${PRODUCT_HOME} >>>>>>>> export JTREG_TIMEOUT_FACTOR=5 >>>>>>>> export CONCURRENCY=8 >>>>>>>> ``` >>>>>>>> >>>>>>>> cd into jdk/test >>>>>>>> >>>>>>>> edit the Makefile and add the following: >>>>>>>> >>>>>>>> ``` >>>>>>>> jdkroot=/home/joliver/workspace/jdk9/ >>>>>>>> >>>>>>>> JTREG_TEST_OPTIONS += >>>>>>>> -jcov/classes:$(jdkroot)/build/linux-x86_64-normal- >>>>>>>> server-release/jdk/modules/java.base >>>>>>>> JTREG_TEST_OPTIONS += >>>>>>>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes >>>>>>>> JTREG_TEST_OPTIONS += -jcov/include:* >>>>>>>> ``` >>>>>>>> >>>>>>>> just before the line: # Make sure jtreg exists >>>>>>>> >>>>>>>> then just run "make test" inside the root >>>>>>>> >>>>>>>> =======Quality Discuss======= >>>>>>>> >>>>>>>> Hi Martijn, >>>>>>> >>>>>>> Posting the results on our wiki won't work, so I can provide a link >>>>>>> to >>>>>>> the >>>>>>> results. Let me know when you have decided on the link locations. >>>>>>> >>>>>>> Rgds,Rory >>>>>>> >>>>>>> Is this something that could be hosted by the quality group for the >>>>>>>> major OpenJDK code lines (7u, 8u and jdk9)? >>>>>>>> >>>>>>>> If not then the Adoption Group can host it on one of their external >>>>>>>> servers temporarily and we could link to that from the >>>>>>>> wiki(s)/project >>>>>>>> page(s). >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Martijn >>>>>>>> >>>>>>>> -- >>>>>>> Rgds,Rory O'Donnell >>>>>>> Quality Engineering Manager >>>>>>> Oracle EMEA , Dublin, Ireland >>>>>>> >>>>>>> >>>>>>> -- >>>>>> Rgds,Rory O'Donnell >>>>>> Quality Engineering Manager >>>>>> Oracle EMEA , Dublin, Ireland >>>>>> >>>>>> >>>>>> -- >>>>> Rgds,Rory O'Donnell >>>>> Quality Engineering Manager >>>>> Oracle EMEA , Dublin, Ireland >>>>> >>>>> >>>>> > -- > Rgds,Rory O'Donnell > Quality Engineering Manager > Oracle EMEA , Dublin, Ireland > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rory.odonnell at oracle.com Mon Jan 26 11:10:36 2015 From: rory.odonnell at oracle.com (Rory O'Donnell) Date: Mon, 26 Jan 2015 11:10:36 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: <54C617D9.2020605@oracle.com> References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> <54C617D9.2020605@oracle.com> Message-ID: <54C620AC.4040701@oracle.com> On 26/01/2015 10:32, Rory O'Donnell wrote: > > On 25/01/2015 14:45, Martijn Verburg wrote: >> Right, >> >> @Mani - How's your week placed? Let's see if we can get together to >> make >> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/openjdk-1.9-linux-x86_64/ >> >> produce some results. >> >> @Rory - I've made a few changes to the Cloudbees CI build farm, would >> it be >> possible to enhance >> https://wiki.openjdk.java.net/display/Adoption/Quality+Outreach page so >> that it has: >> >> 1.) A link to the Quality Outreach section of the build farm ( >> https://adopt-openjdk.ci.cloudbees.com/view/Quality%20Outreach/) >> >> 2.) It lists OpenJDK being built nightly (listed here: >> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK) >> >> 3.) Lists the OpenJDK code tools being built nightly (listed here: >> https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK%20code-tools/) > Done - listed you as maintainer, should I have said London JUGs ? > > Rgds,Rory Martijn - it appears I over stepped the mark. The OpenJDK Bylaws are very clear [4] on what an OpenJDK Group can and can not do: "Groups may have web content and one or more mailing lists. Groups do not have code repositories of their own" so accordingly Groups' don't have build farms, etc. [4] http://openjdk.java.net/bylaws#_4 I have removed the links, let's discuss other options at FOSDEM . Rgds,Rory >> >> Also, I'm not sure if we should reach out to code-tools, jdk9-dev and >> jdk8u-dev and ask them to have links to the CI farm as well? I think it >> would be a good idea to highlight this though. >> >> Cheers, >> Martijn >> >> On 25 January 2015 at 14:15, Martijn Verburg >> wrote: >> >>> Looks like I'm going now :-) - we can discuss further then, in the mean >>> time Mani and I will try to get something up and running on the >>> CloudBees >>> CI instances. >>> >>> Cheers, >>> Martijn >>> >>> On 19 January 2015 at 17:34, Martijn Verburg >>> wrote: >>> >>>> Sadly I may not be able to make FOSDEM, still trying to wrangle some >>>> clever ways to make it. >>>> >>>> Cheers, >>>> Martijn >>>> >>>> On 19 January 2015 at 17:33, Rory O'Donnell >>>> wrote: >>>> >>>>> On 19/01/2015 17:28, Martijn Verburg wrote: >>>>> >>>>> Hi Rory, >>>>> >>>>> Understood - it will be good to be able to encourage various >>>>> OpenJDK >>>>> members to contribute / port tests into it and measure that. Small >>>>> steps >>>>> :-). >>>>> >>>>> Sounds good Martijn, talk more on this at FOSDEM ? >>>>> >>>>> Rgds,Rory >>>>> >>>>> >>>>> On 19 January 2015 at 16:35, Rory O'Donnell >>>>> >>>>> wrote: >>>>> >>>>>> On 19/01/2015 15:36, Martijn Verburg wrote: >>>>>> >>>>>> Hi Rory, >>>>>> >>>>>> Thanks - we're looking into the existing Cloudbees Jenkins >>>>>> instance >>>>>> to do this. >>>>>> >>>>>> ok >>>>>> >>>>>> A second question quick question - do the numbers we're publishing >>>>>> look right compared to your internal ones? >>>>>> >>>>>> Appreciate non OpenJDK tests run by Oracle means that they cover >>>>>> more. >>>>>> >>>>>> Comparing our internal numbers with yours would be like comparing >>>>>> apples with pears >>>>>> I'm afraid. >>>>>> >>>>>> Rgds,Rory >>>>>> >>>>>> Cheers, >>>>>> Martijn >>>>>> >>>>>> On 19 January 2015 at 15:18, Rory O'Donnell >>>>>> >>>>>> wrote: >>>>>> >>>>>>> On 19/01/2015 10:55, Martijn Verburg wrote: >>>>>>> >>>>>>>> Hi all, >>>>>>>> >>>>>>>> John Oliver and Mani Sarkar spent some time on the most recent >>>>>>>> Adopt >>>>>>>> OpenJDK hackday and managed to get what looks like to be >>>>>>>> meaningful code >>>>>>>> coverage numbers for OpenJDK using the jcov/jtreg tools: >>>>>>>> >>>>>>>> Results for jdk9: http://sticky.uwcs.co.uk/jcov/ >>>>>>>> >>>>>>>> ========Code Tools Dev======== >>>>>>>> >>>>>>>> The configuration John used was as follows (is this the correct >>>>>>>> usage >>>>>>>> pattern?): >>>>>>>> >>>>>>>> Build jdk images >>>>>>>> install jtreg with the jcov >>>>>>>> >>>>>>>> export the normal vars: >>>>>>>> >>>>>>>> ``` >>>>>>>> export SOURCE_CODE=/home/joliver/workspace/jdk9/ >>>>>>>> export JTREG_INSTALL=/home/joliver/workspace/jtreg >>>>>>>> export JT_HOME=$JTREG_INSTALL >>>>>>>> export JTREG_HOME=$JTREG_INSTALL >>>>>>>> export >>>>>>>> PRODUCT_HOME=$SOURCE_CODE/build/linux-x86_64-normal-server-release/images/jdk >>>>>>>> >>>>>>>> >>>>>>>> export JPRT_JTREG_HOME=${JT_HOME} >>>>>>>> export JPRT_JAVA_HOME=${PRODUCT_HOME} >>>>>>>> export JTREG_TIMEOUT_FACTOR=5 >>>>>>>> export CONCURRENCY=8 >>>>>>>> ``` >>>>>>>> >>>>>>>> cd into jdk/test >>>>>>>> >>>>>>>> edit the Makefile and add the following: >>>>>>>> >>>>>>>> ``` >>>>>>>> jdkroot=/home/joliver/workspace/jdk9/ >>>>>>>> >>>>>>>> JTREG_TEST_OPTIONS += >>>>>>>> -jcov/classes:$(jdkroot)/build/linux-x86_64-normal-server-release/jdk/modules/java.base >>>>>>>> >>>>>>>> JTREG_TEST_OPTIONS += >>>>>>>> -jcov/source:$(jdkroot)/jdk/src/java.base/share/classes >>>>>>>> JTREG_TEST_OPTIONS += -jcov/include:* >>>>>>>> ``` >>>>>>>> >>>>>>>> just before the line: # Make sure jtreg exists >>>>>>>> >>>>>>>> then just run "make test" inside the root >>>>>>>> >>>>>>>> =======Quality Discuss======= >>>>>>>> >>>>>>> Hi Martijn, >>>>>>> >>>>>>> Posting the results on our wiki won't work, so I can provide a >>>>>>> link to >>>>>>> the >>>>>>> results. Let me know when you have decided on the link locations. >>>>>>> >>>>>>> Rgds,Rory >>>>>>> >>>>>>>> Is this something that could be hosted by the quality group for >>>>>>>> the >>>>>>>> major OpenJDK code lines (7u, 8u and jdk9)? >>>>>>>> >>>>>>>> If not then the Adoption Group can host it on one of their >>>>>>>> external >>>>>>>> servers temporarily and we could link to that from the >>>>>>>> wiki(s)/project >>>>>>>> page(s). >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Martijn >>>>>>>> >>>>>>> -- >>>>>>> Rgds,Rory O'Donnell >>>>>>> Quality Engineering Manager >>>>>>> Oracle EMEA , Dublin, Ireland >>>>>>> >>>>>>> >>>>>> -- >>>>>> Rgds,Rory O'Donnell >>>>>> Quality Engineering Manager >>>>>> Oracle EMEA , Dublin, Ireland >>>>>> >>>>>> >>>>> -- >>>>> Rgds,Rory O'Donnell >>>>> Quality Engineering Manager >>>>> Oracle EMEA , Dublin, Ireland >>>>> >>>>> > -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland From jonathan.gibbons at oracle.com Thu Jan 29 02:51:19 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 28 Jan 2015 18:51:19 -0800 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> Message-ID: <54C9A027.50008@oracle.com> On 01/25/2015 06:45 AM, Martijn Verburg wrote: > Also, I'm not sure if we should reach out to code-tools, jdk9-dev and > jdk8u-dev and ask them to have links to the CI farm as well? I think > it would be a good idea to highlight this though. > > Cheers, > Martijn Consider the code-tools group reached. The jtreg page has had a link for a while, but I'll make a more general link on the Code Tools page as well. -- Jon From jonathan.gibbons at oracle.com Thu Jan 29 03:20:45 2015 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Wed, 28 Jan 2015 19:20:45 -0800 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: <54C9A027.50008@oracle.com> References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> <54C9A027.50008@oracle.com> Message-ID: <54C9A70D.4070106@oracle.com> On 01/28/2015 06:51 PM, Jonathan Gibbons wrote: > > On 01/25/2015 06:45 AM, Martijn Verburg wrote: >> Also, I'm not sure if we should reach out to code-tools, jdk9-dev and >> jdk8u-dev and ask them to have links to the CI farm as well? I think >> it would be a good idea to highlight this though. >> >> Cheers, >> Martijn > > Consider the code-tools group reached. The jtreg page has had a link > for a while, but I'll make a more general link on the Code Tools page > as well. > > -- Jon > Done. http://openjdk.java.net/projects/code-tools/ See "Other Resources". (It may take a few minutes to show up.) -- Jon From martijnverburg at gmail.com Thu Jan 29 15:39:39 2015 From: martijnverburg at gmail.com (Martijn Verburg) Date: Thu, 29 Jan 2015 15:39:39 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: <54C9A70D.4070106@oracle.com> References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> <54C9A027.50008@oracle.com> <54C9A70D.4070106@oracle.com> Message-ID: Thanks Jonathan, For everyone else, we have our first published results for jdk9 which will be built nightly! See the following link as an example: https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ws/build/linux-x86_64-normal-server-release/testoutput/jdk_core/JTreport/jcov/index.html The numbers for JDK Core are better than expected (around 70%) Kudos to John Oliver and Mani Sarkar for getting the Cloudbees Jenkins build into place. We can discuss what this all means and what could be hosted / linked to from where, but it's a good start! Cheers, Martijn On 29 January 2015 at 03:20, Jonathan Gibbons wrote: > > On 01/28/2015 06:51 PM, Jonathan Gibbons wrote: > >> >> On 01/25/2015 06:45 AM, Martijn Verburg wrote: >> >>> Also, I'm not sure if we should reach out to code-tools, jdk9-dev and >>> jdk8u-dev and ask them to have links to the CI farm as well? I think it >>> would be a good idea to highlight this though. >>> >>> Cheers, >>> Martijn >>> >> >> Consider the code-tools group reached. The jtreg page has had a link for >> a while, but I'll make a more general link on the Code Tools page as well. >> >> -- Jon >> >> > Done. > > http://openjdk.java.net/projects/code-tools/ > See "Other Resources". (It may take a few minutes to show up.) > > -- Jon > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sadhak001 at gmail.com Thu Jan 29 21:46:18 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Thu, 29 Jan 2015 21:46:18 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> <54C9A027.50008@oracle.com> <54C9A70D.4070106@oracle.com> Message-ID: Great to have these coverage metrics after a long time - thanks to John Oliver for the team work we did to get this off the ground, mostly it was his expertise to do the necessary tweaks. Please save this link as it will automatically be updated with regular commits made into the jdk9/dev repo. Any feedback or queries, feel free to get back to us. Cheers, Mani On Thu, Jan 29, 2015 at 3:39 PM, Martijn Verburg wrote: > Thanks Jonathan, > > For everyone else, we have our first published results for jdk9 which will > be built nightly! See the following link as an example: > > > https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ws/build/linux-x86_64-normal-server-release/testoutput/jdk_core/JTreport/jcov/index.html > > The numbers for JDK Core are better than expected (around 70%) > > Kudos to John Oliver and Mani Sarkar for getting the Cloudbees Jenkins > build into place. > > We can discuss what this all means and what could be hosted / linked to > from where, but it's a good start! > > > Cheers, > Martijn > > On 29 January 2015 at 03:20, Jonathan Gibbons > > wrote: > > > > > On 01/28/2015 06:51 PM, Jonathan Gibbons wrote: > > > >> > >> On 01/25/2015 06:45 AM, Martijn Verburg wrote: > >> > >>> Also, I'm not sure if we should reach out to code-tools, jdk9-dev and > >>> jdk8u-dev and ask them to have links to the CI farm as well? I think > it > >>> would be a good idea to highlight this though. > >>> > >>> Cheers, > >>> Martijn > >>> > >> > >> Consider the code-tools group reached. The jtreg page has had a link for > >> a while, but I'll make a more general link on the Code Tools page as > well. > >> > >> -- Jon > >> > >> > > Done. > > > > http://openjdk.java.net/projects/code-tools/ > > See "Other Resources". (It may take a few minutes to show up.) > > > > -- Jon > > > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2015:* 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 Fri Jan 30 00:05:34 2015 From: sadhak001 at gmail.com (Mani Sarkar) Date: Fri, 30 Jan 2015 00:05:34 +0000 Subject: We have some Code Coverage results from JCov/JTreg! In-Reply-To: References: <54BD2046.8020004@oracle.com> <54BD324A.8080706@oracle.com> <54BD3FCD.9040304@oracle.com> <54C9A027.50008@oracle.com> <54C9A70D.4070106@oracle.com> Message-ID: On advice from our lead devops, we have decided to move the whole testoutput folder to another location so during builds the reports from previous builds are still available, the link to the new location to the jcov reports is: https://adopt-openjdk.ci.cloudbees.com/view/OpenJDK/job/openjdk-1.9-linux-x86_64/ws/testoutput/jdk_core/JTreport/jcov/index.html The reports are archived and available for every build as tar.gz files. I also have a separate archive for just jcov created along with the two available archives under latest builds. Cheers, Mani On Thu, Jan 29, 2015 at 9:46 PM, Mani Sarkar wrote: > Great to have these coverage metrics after a long time - thanks to John > Oliver for the team work we did to get this off the ground, mostly it was > his expertise to do the necessary tweaks. > > Please save this link as it will automatically be updated with regular > commits made into the jdk9/dev repo. > > Any feedback or queries, feel free to get back to us. > > Cheers, > Mani > > On Thu, Jan 29, 2015 at 3:39 PM, Martijn Verburg > wrote: > >> Thanks Jonathan, >> >> For everyone else, we have our first published results for jdk9 which will >> be built nightly! See the following link as an example: >> >> >> https://adopt-openjdk.ci.cloudbees.com/job/openjdk-1.9-linux-x86_64/ws/build/linux-x86_64-normal-server-release/testoutput/jdk_core/JTreport/jcov/index.html >> >> The numbers for JDK Core are better than expected (around 70%) >> >> Kudos to John Oliver and Mani Sarkar for getting the Cloudbees Jenkins >> build into place. >> >> We can discuss what this all means and what could be hosted / linked to >> from where, but it's a good start! >> >> >> Cheers, >> Martijn >> >> On 29 January 2015 at 03:20, Jonathan Gibbons < >> jonathan.gibbons at oracle.com> >> wrote: >> >> > >> > On 01/28/2015 06:51 PM, Jonathan Gibbons wrote: >> > >> >> >> >> On 01/25/2015 06:45 AM, Martijn Verburg wrote: >> >> >> >>> Also, I'm not sure if we should reach out to code-tools, jdk9-dev and >> >>> jdk8u-dev and ask them to have links to the CI farm as well? I think >> it >> >>> would be a good idea to highlight this though. >> >>> >> >>> Cheers, >> >>> Martijn >> >>> >> >> >> >> Consider the code-tools group reached. The jtreg page has had a link >> for >> >> a while, but I'll make a more general link on the Code Tools page as >> well. >> >> >> >> -- Jon >> >> >> >> >> > Done. >> > >> > http://openjdk.java.net/projects/code-tools/ >> > See "Other Resources". (It may take a few minutes to show up.) >> > >> > -- Jon >> > >> > > > > -- > @theNeomatrix369 * | **Blog > ** | *LJC Associate & LJC Advocate > (@adoptopenjdk & @adoptajsr programs) > *Meet-a-Project - *MutabilityDetector > * | **Bitbucket > * * | **Github > * * | **LinkedIn > * > *Come to Devoxx UK 2015:* 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 2015:* 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 balchandra.vaidya at oracle.com Fri Jan 30 07:28:16 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Fri, 30 Jan 2015 12:58:16 +0530 Subject: JDK 9 early access b47 test results now available Message-ID: <54CB3290.7040104@oracle.com> JDK 9 ea b47 test results are now available at : http://www.java.net/download/openjdk/testresults/9/testresults.html The jdk test results contain 16 differences from the b46 test results. No new testcase failures found. 0: /home/jtest/merge9/b46/jdk/JTwork pass: 4,944; fail: 12; not run: 1,712 1: /home/jtest/merge9/b47/jdk/JTwork pass: 4,952; fail: 10; not run: 1,712 0 1 Test --- pass com/sun/crypto/provider/Mac/EmptyByteBufferTest.java --- pass com/sun/crypto/provider/Mac/LargeByteBufferTest.java --- pass com/sun/crypto/provider/Mac/MacSameTest.java --- pass com/sun/crypto/provider/Mac/NullByteBufferTest.java fail pass java/beans/XMLEncoder/java_awt_GridBagLayout.java pass --- java/lang/instrument/IsModifiableClassAgent.java fail pass java/lang/invoke/LFCaching/LFGarbageCollectedTest.java --- pass java/lang/management/ThreadMXBean/ThreadMXBeanStateTest.java pass --- java/util/logging/AnonLoggerWeakRefLeak.sh pass --- java/util/logging/LoggerWeakRefLeak.sh --- pass java/util/logging/TestLoggerWeakRefLeak.java --- pass sun/security/pkcs11/Mac/MacKAT.java --- pass sun/security/pkcs11/Mac/MacSameTest.java --- pass sun/security/x509/Extensions/DefaultCriticality.java pass --- sun/tools/common/CommonTests.sh --- pass tools/launcher/MultipleJRERemoved.java 16 differences The hotspot test results contain 29 differences from the b46 test results. There are 3 testcase failures, those failures are under investigation. 0: /home/jtest/merge9/b46/hotspot/JTwork pass: 676; fail: 35; error: 1; not run: 31 1: /home/jtest/merge9/b47/hotspot/JTwork pass: 698; fail: 36; error: 1; not run: 30 0 1 Test --- pass compiler/arraycopy/TestArrayCopyMacro.java pass --- compiler/arraycopy/TestArrayOfNoTypeCheck.java --- pass compiler/arraycopy/TestArraysCopyOfNoTypeCheck.java --- pass compiler/arraycopy/TestInstanceCloneAsLoadsStores.java --- pass compiler/codecache/cli/TestSegmentedCodeCacheOption.java --- pass compiler/codecache/cli/codeheapsize/TestCodeHeapSizeOptions.java --- pass compiler/codecache/cli/printcodecache/TestPrintCodeCacheOption.java --- pass compiler/codecache/jmx/BeanTypeTest.java --- pass compiler/codecache/jmx/CodeHeapBeanPresenceTest.java --- pass compiler/codecache/jmx/GetUsageTest.java --- pass compiler/codecache/jmx/InitialAndMaxUsageTest.java --- pass compiler/codecache/jmx/ManagerNamesTest.java --- pass compiler/codecache/jmx/MemoryPoolsPresenceTest.java --- pass compiler/codecache/jmx/PeakUsageTest.java --- pass compiler/codecache/jmx/PoolsIndependenceTest.java --- pass compiler/codecache/jmx/ThresholdNotificationsTest.java --- pass compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java --- pass compiler/codecache/jmx/UsageThresholdExceededTest.java --- pass compiler/codecache/jmx/UsageThresholdIncreasedTest.java --- pass compiler/codecache/jmx/UsageThresholdNotExceededTest.java fail --- gc/g1/TestEagerReclaimHumongousRegions2.java --- fail gc/g1/TestEagerReclaimHumongousRegionsClearMarkBits.java --- fail gc/g1/TestEagerReclaimHumongousRegionsWithRefs.java --- fail gc/g1/TestG1TraceEagerReclaimHumongousObjects.java fail --- gc/g1/TestG1TraceReclaimDeadHumongousObjectsAtYoungGC.java --- pass runtime/BadObjectClass/BootstrapRedefine.java --- pass runtime/CommandLine/TestNullTerminatedFlags.java --- pass runtime/SharedArchiveFile/DumpSymbolAndStringTable.java --- pass runtime/SharedArchiveFile/SharedSymbolTableBucketSize.java 29 differences The langtools test results contain 4 differences from the b46 test results. No new testcase failures found. 0: /home/jtest/merge9/b46/langtools/JTwork pass: 3,187; not run: 14 1: /home/jtest/merge9/b47/langtools/JTwork pass: 3,191; not run: 14 0 1 Test --- pass tools/javac/classfiles/InnerClasses/T8068517.java --- pass tools/javac/generics/LowerBoundBottomTypeTest.java --- pass tools/javac/lambda/methodReferenceExecution/MethodReferencePackagePrivateQualifier.java --- pass tools/javac/processing/TestMultipleErrors.java 4 differences The nashorn test result is available at http://download.java.net/openjdk/testresults/9/archives/b47/emailable-report.html Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From balchandra.vaidya at oracle.com Fri Jan 30 07:34:53 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Fri, 30 Jan 2015 13:04:53 +0530 Subject: JDK 8u40 ea b22 test results now available Message-ID: <54CB341D.5050105@oracle.com> JDK 8u40 ea b22 test results are now available at http://www.java.net/download/openjdk/testresults/8/testresults.html The jdk test results contain 11 differences from the b21 test results. There are 11 testcase failures, those failures are under investigation. 0: /home/jtest/merge8/jdk8u40-b21/jdk/JTwork pass: 4,768; fail: 15; not run: 1,003 1: /home/jtest/merge8/jdk8u40-b22/jdk/JTwork pass: 4,757; fail: 26; not run: 1,003 0 1 Test pass fail java/rmi/activation/ActivationSystem/activeGroup/IdempotentActiveGroup.java pass fail sun/security/ec/TestEC.java pass fail sun/security/ssl/com/sun/net/ssl/internal/ssl/ProtocolVersion/HttpsProtocols.java pass fail sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/CustomizedDefaultProtocols.java pass fail sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/DefaultEnabledProtocols.java pass fail sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLContextImpl/NoOldVersionContext.java pass fail sun/security/ssl/com/sun/net/ssl/internal/ssl/SSLEngineImpl/DelegatedTaskWrongException.java pass fail sun/security/ssl/javax/net/ssl/NewAPIs/testEnabledProtocols.java pass fail sun/security/ssl/javax/net/ssl/ServerName/SSLEngineExplorer.java pass fail sun/security/ssl/javax/net/ssl/ServerName/SSLSocketExplorer.java pass fail sun/security/ssl/sanity/interop/ClientJSSEServerJSSE.java 11 differences The hotspot test results contain 6 differences from the b21 test results. No new testcase failures found. 0: /home/jtest/merge8/jdk8u40-b21/hotspot/JTwork pass: 615; fail: 34; error: 1; not run: 16 1: /home/jtest/merge8/jdk8u40-b22/hotspot/JTwork pass: 621; fail: 34; error: 1; not run: 16 0 1 Test --- pass gc/arguments/TestSurvivorAlignmentInBytesOption.java --- pass gc/survivorAlignment/TestAllocationInEden.java --- pass gc/survivorAlignment/TestPromotionFromEdenToTenured.java --- pass gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterFullGC.java --- pass gc/survivorAlignment/TestPromotionFromSurvivorToTenuredAfterMinorGC.java --- pass gc/survivorAlignment/TestPromotionToSurvivor.java 6 differences The langtools test results contain 0 differences from the b21 test results. The nashorn test result is available at http://download.java.net/openjdk/testresults/8/archives8/jdk8u40-b22/emailable-report.html Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: From balchandra.vaidya at oracle.com Fri Jan 30 07:46:22 2015 From: balchandra.vaidya at oracle.com (Balchandra Vaidya) Date: Fri, 30 Jan 2015 13:16:22 +0530 Subject: JDK 7u80 early access b05 test results now available Message-ID: <54CB36CE.8060608@oracle.com> JDK 7u80 ea b05 test results are now available at http://www.java.net/download/openjdk/testresults/7/testresults.html The jdk test results contain 2 differences from the b04 test results. No new testcase failures found. 0: /home/jtest/merge7/jdk7u80-b04/jdk/JTwork pass: 3,968; fail: 14; error: 1; not run: 861 1: /home/jtest/merge7/jdk7u80-b05/jdk/JTwork pass: 3,970; fail: 13; error: 1; not run: 862 0 1 Test --- pass java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fail pass java/lang/reflect/Method/GenericStringTest.java 2 differences The hotspot test results contain 4 differences from the b04 test results. No new testcase failures found. 0: /home/jtest/merge7/jdk7u80-b04/hotspot/JTwork pass: 285; fail: 11; error: 1; not run: 4 1: /home/jtest/merge7/jdk7u80-b05/hotspot/JTwork pass: 289; fail: 11; not run: 4 0 1 Test --- pass compiler/jsr292/RedefineMethodUsedByMultipleMethodHandlesNoASM.java --- pass compiler/rangechecks/TestRangeCheckSmearing.java --- pass compiler/rangechecks/TestRangeCheckSmearingLoopOpts.java error pass serviceability/sa/jmap-hashcode/Test8028623.java 4 differences The langtools test results contain 0 differences from the b04 test results. Thanks Balchandra -------------- next part -------------- An HTML attachment was scrubbed... URL: