From Roger.Riggs at Oracle.com Mon Aug 1 15:37:06 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 1 Aug 2016 11:37:06 -0400 Subject: CFV: New JDK 9 Committer: Ajit Ghaisas In-Reply-To: References: Message-ID: Vote: Yes On 7/28/2016 4:43 AM, Sergey Bylokhov wrote: > I hereby nominate Ajit Ghaisas to JDK 9 Committer. > From ambarish.rapte at oracle.com Mon Aug 1 16:25:03 2016 From: ambarish.rapte at oracle.com (Ambarish Rapte) Date: Mon, 1 Aug 2016 09:25:03 -0700 (PDT) Subject: CFV: New JDK 9 Committer: Ajit Ghaisas In-Reply-To: References: Message-ID: <755f934b-ec44-4b2c-92df-5c7d1af2a354@default> Vote: YES -----Original Message----- From: Sergey Bylokhov Sent: Thursday, July 28, 2016 2:14 PM To: jdk9-dev at openjdk.java.net Subject: CFV: New JDK 9 Committer: Ajit Ghaisas I hereby nominate Ajit Ghaisas to JDK 9 Committer. Ajit is currently a JDK 9 Author and a member of the client team at Oracle. He has made 16 contributions to the JDK 9: http://hg.openjdk.java.net/jdk9/client/jdk/log?revcount=40&rev=Ghaisas Votes are due by August 11, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. Sergey Bylokhov [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote -- Best regards, Sergey. From li.jiang at oracle.com Tue Aug 2 05:53:06 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 2 Aug 2016 13:53:06 +0800 Subject: RFR 8158486 : remove the wptg id line from jaxp resource file in JDK9 Message-ID: <72c9d1af-4031-b775-2cbf-5fc04e6a95ff@oracle.com> Hi Joe, Would you help to review this change? This is the JDK 9 release version of change about removal of wptg id line for jaxp resource files. http://cr.openjdk.java.net/~fyuan/leo/8158486/webrev.00/ This line would impact the L10n resource update process. By removing this obsolete line, we can avoid to review these files which actually haven't change. Thanks, Leo From li.jiang at oracle.com Tue Aug 2 06:16:34 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 2 Aug 2016 14:16:34 +0800 Subject: RFR 8158486 : remove the wptg id line from jaxp resource file in JDK9 In-Reply-To: <72c9d1af-4031-b775-2cbf-5fc04e6a95ff@oracle.com> References: <72c9d1af-4031-b775-2cbf-5fc04e6a95ff@oracle.com> Message-ID: <75873e4b-43dd-7b48-3f5d-590ae93c508f@oracle.com> bug: https://bugs.openjdk.java.net/browse/JDK-8158486 -Leo On 08/02/2016 01:53 PM, Leo Jiang wrote: > Hi Joe, > > Would you help to review this change? > > This is the JDK 9 release version of change about removal of wptg id line for jaxp resource files. > > http://cr.openjdk.java.net/~fyuan/leo/8158486/webrev.00/ > > This line would impact the L10n resource update process. By removing this obsolete line, we can avoid to review these > files which actually haven't change. > > > Thanks, > Leo From christoph.langer at sap.com Tue Aug 2 07:08:25 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Aug 2016 07:08:25 +0000 Subject: RFR 8158486 : remove the wptg id line from jaxp resource file in JDK9 In-Reply-To: <75873e4b-43dd-7b48-3f5d-590ae93c508f@oracle.com> References: <72c9d1af-4031-b775-2cbf-5fc04e6a95ff@oracle.com> <75873e4b-43dd-7b48-3f5d-590ae93c508f@oracle.com> Message-ID: Hi Leo, Joe, I think you should also take the chance to check/update all headers (that is, in the .java files) Best regards Christoph > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of Leo > Jiang > Sent: Dienstag, 2. August 2016 08:17 > To: jdk9-dev at openjdk.java.net > Subject: Re: RFR 8158486 : remove the wptg id line from jaxp resource file in > JDK9 > > bug: https://bugs.openjdk.java.net/browse/JDK-8158486 > > -Leo > > On 08/02/2016 01:53 PM, Leo Jiang wrote: > > Hi Joe, > > > > Would you help to review this change? > > > > This is the JDK 9 release version of change about removal of wptg id line for > jaxp resource files. > > > > http://cr.openjdk.java.net/~fyuan/leo/8158486/webrev.00/ > > > > This line would impact the L10n resource update process. By removing this > obsolete line, we can avoid to review these > > files which actually haven't change. > > > > > > Thanks, > > Leo From li.jiang at oracle.com Tue Aug 2 07:17:53 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 2 Aug 2016 15:17:53 +0800 Subject: RFR 8158486 : remove the wptg id line from jaxp resource file in JDK9 In-Reply-To: References: <72c9d1af-4031-b775-2cbf-5fc04e6a95ff@oracle.com> <75873e4b-43dd-7b48-3f5d-590ae93c508f@oracle.com> Message-ID: <52dca2f4-4896-dde5-b7b0-79420fd69fd1@oracle.com> Some java resource files had been included in this change. I'm not sure if other files have same issue. The impact to l10n process is that even no real change but translation tool would still update the svn line automatically. I'm not sure if has same case for other files. Thanks, Leo On 08/02/2016 03:08 PM, Langer, Christoph wrote: > Hi Leo, Joe, > > I think you should also take the chance to check/update all headers (that is, in the .java files) > > Best regards > Christoph > >> -----Original Message----- >> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of Leo >> Jiang >> Sent: Dienstag, 2. August 2016 08:17 >> To: jdk9-dev at openjdk.java.net >> Subject: Re: RFR 8158486 : remove the wptg id line from jaxp resource file in >> JDK9 >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8158486 >> >> -Leo >> >> On 08/02/2016 01:53 PM, Leo Jiang wrote: >>> Hi Joe, >>> >>> Would you help to review this change? >>> >>> This is the JDK 9 release version of change about removal of wptg id line for >> jaxp resource files. >>> >>> http://cr.openjdk.java.net/~fyuan/leo/8158486/webrev.00/ >>> >>> This line would impact the L10n resource update process. By removing this >> obsolete line, we can avoid to review these >>> files which actually haven't change. >>> >>> >>> Thanks, >>> Leo From christoph.langer at sap.com Tue Aug 2 07:27:15 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 2 Aug 2016 07:27:15 +0000 Subject: RFR 8158486 : remove the wptg id line from jaxp resource file in JDK9 In-Reply-To: <52dca2f4-4896-dde5-b7b0-79420fd69fd1@oracle.com> References: <72c9d1af-4031-b775-2cbf-5fc04e6a95ff@oracle.com> <75873e4b-43dd-7b48-3f5d-590ae93c508f@oracle.com> <52dca2f4-4896-dde5-b7b0-79420fd69fd1@oracle.com> Message-ID: <15606432e6fa4d99badeae8c19ceec6d@DEWDFE13DE11.global.corp.sap> Sure, it's a good idea to do this change. Joe should probably guide you through updating the headers. Best Christoph > -----Original Message----- > From: Leo Jiang [mailto:li.jiang at oracle.com] > Sent: Dienstag, 2. August 2016 09:18 > To: Langer, Christoph ; Joe Wang > > Cc: jdk9-dev at openjdk.java.net > Subject: Re: RFR 8158486 : remove the wptg id line from jaxp resource file in > JDK9 > > Some java resource files had been included in this change. I'm not sure if other > files have same issue. > > The impact to l10n process is that even no real change but translation tool > would still update the svn line > automatically. I'm not sure if has same case for other files. > > Thanks, > Leo > > On 08/02/2016 03:08 PM, Langer, Christoph wrote: > > Hi Leo, Joe, > > > > I think you should also take the chance to check/update all headers (that is, in > the .java files) > > > > Best regards > > Christoph > > > >> -----Original Message----- > >> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Leo > >> Jiang > >> Sent: Dienstag, 2. August 2016 08:17 > >> To: jdk9-dev at openjdk.java.net > >> Subject: Re: RFR 8158486 : remove the wptg id line from jaxp resource file > in > >> JDK9 > >> > >> bug: https://bugs.openjdk.java.net/browse/JDK-8158486 > >> > >> -Leo > >> > >> On 08/02/2016 01:53 PM, Leo Jiang wrote: > >>> Hi Joe, > >>> > >>> Would you help to review this change? > >>> > >>> This is the JDK 9 release version of change about removal of wptg id line > for > >> jaxp resource files. > >>> > >>> http://cr.openjdk.java.net/~fyuan/leo/8158486/webrev.00/ > >>> > >>> This line would impact the L10n resource update process. By removing this > >> obsolete line, we can avoid to review these > >>> files which actually haven't change. > >>> > >>> > >>> Thanks, > >>> Leo From li.jiang at oracle.com Tue Aug 2 08:33:51 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 2 Aug 2016 16:33:51 +0800 Subject: RFR 8159713 and 8161183 : minor fixes for jar.properties Message-ID: <668bc8d2-3580-9b92-a757-53243021e6f7@oracle.com> Please review the minor changes in jar.properties file for L10n issue. CR: http://cr.openjdk.java.net/~fyuan/leo/8159713-8161183/webrev.00/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties.udiff.html We have two issues related to l10n in this properties file. ===== bug https://bugs.openjdk.java.net/browse/JDK-8159713 Make the non-translated keywords clear to translator in jar.properties Translator would translate the keywords if we don't tell the translation team. As Alan suggested, enclosing the keywords with quote would help translation team understand the words shouldn't be translated. ===== bug https://bugs.openjdk.java.net/browse/JDK-8161183 the char sequence '\n\' is necessary for correct line break. Thanks, Leo From naoto.sato at oracle.com Tue Aug 2 18:09:29 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 2 Aug 2016 11:09:29 -0700 Subject: RFR 8159713 and 8161183 : minor fixes for jar.properties In-Reply-To: <668bc8d2-3580-9b92-a757-53243021e6f7@oracle.com> References: <668bc8d2-3580-9b92-a757-53243021e6f7@oracle.com> Message-ID: +1 Naoto On 8/2/16 1:33 AM, Leo Jiang wrote: > Please review the minor changes in jar.properties file for L10n issue. > > CR: > http://cr.openjdk.java.net/~fyuan/leo/8159713-8161183/webrev.00/src/jdk.jartool/share/classes/sun/tools/jar/resources/jar.properties.udiff.html > > > We have two issues related to l10n in this properties file. > > ===== > bug https://bugs.openjdk.java.net/browse/JDK-8159713 > Make the non-translated keywords clear to translator in jar.properties > > Translator would translate the keywords if we don't tell the translation > team. As Alan suggested, enclosing the keywords with quote would help > translation team understand the words shouldn't be translated. > > ===== > bug https://bugs.openjdk.java.net/browse/JDK-8161183 > > the char sequence '\n\' is necessary for correct line break. > > Thanks, > Leo From martijnverburg at gmail.com Tue Aug 2 20:44:00 2016 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 2 Aug 2016 21:44:00 +0100 Subject: updates to JEP 277 - Enhanced Deprecation In-Reply-To: <467ed11b-8d02-416d-20eb-ea5d747a5430@oracle.com> References: <467ed11b-8d02-416d-20eb-ea5d747a5430@oracle.com> Message-ID: Hi Stuart, Looks good although the whimsical part of me will miss 'condemned' somewhat! Very, very happy to see @Deprecation already being applied to some unsafe internal APIs, with tooling support I think we can all look forward to educating developers that having things like Thread.stop removed forever, is a very good thing (tm). If the dynamic deprecation feature arrives in a Java 1.9.x update I think that will be a nice bonus, but static code analysis will go a long way nonetheless. Cheers, Martijn On 27 July 2016 at 06:59, Stuart Marks wrote: > Hi all, > > I've done a major update to the text of JEP 277.[1] Most of this is to > reflect the reality of what's happening in JDK 9, and some of it is tying > off of loose ends. > > The most significant change is around the treatment of warning messages > mandated by the JLS (9.6.4.6). Currently, deprecation warnings can be > suppressed with @SuppressWarnings("deprecation"). Currently, this > suppresses warnings even if the API is deprecated with forRemoval=true. > This is a problem, since the removal warning might be missed, leading to > unexpected compile-time or run-time errors when the API is actually removed. > > The proposal is to have uses of APIs deprecated for removal generate > warnings anyway, even within code that as @SuppressWarnings("deprecation"). > > These new "deprecation for removal" warnings can in turn be suppressed > using a different warnings suppression string, > > @SuppressWarnings("dep-removal") > > The idea is that you get a warning for use of a for-removal deprecated > API, even if you've previously suppressed the warning. Essentially you have > to suppress it again if you want to continue using the API warning-free. > This is somewhat intrusive, but I think it's warranted, given the gravity > of the for-removal deprecation. > > Highlights of other changes to the JEP include: > > * update terminology from "condemned" to "forRemoval" > > * new material on policy for usage of @Deprecated in Java SE, particularly > with regarding to forRemoval=true > > * updated list of deprecation candidates, with specific references to APIs > being deprecated in Java SE 9 > > * removal of dynamic deprecation detection usage tool from JDK 9, for lack > of time :-( > > * new material describing issues with warning messages > > s'marks > > > [1] https://bugs.openjdk.java.net/browse/JDK-8065614 > From alejandro.murillo at oracle.com Wed Aug 3 16:32:03 2016 From: alejandro.murillo at oracle.com (alejandro.murillo at oracle.com) Date: Wed, 3 Aug 2016 16:32:03 GMT Subject: jdk9-b130: dev Message-ID: <201608031632.u73GW3eG023278@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/d94d54a3192f http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/0de67a63e2c7 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/3665ebc22a42 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/6c827500e345 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/39c6293131d9 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/e66cdc2de6b0 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/7d54c7056328 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/77f9692d5976 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-5049012 client-libs PrintToFile option is not disabled for flavors that do not support des JDK-5080830 client-libs SheetCollate is not handled properly by the cross platform print dlg JDK-6567433 client-libs JComponent.updateUI() may create StackOverflowError JDK-7059970 client-libs Test case: javax/imageio/plugins/png/ITXtTest.java is not closing a fi JDK-7156316 client-libs [macosx] Ctrl+Space does generate Unknown keychar JDK-8036915 client-libs setLocationRelativeTo stopped working in Ubuntu 13.10 (Unity) JDK-8054991 client-libs sun.font.GlyphList uses broken double-checked locking JDK-8143064 client-libs Icons are not properly rendered with Windows L&F on HiDPI display JDK-8145207 client-libs [macosx] JList, VO can't access non-visible list items JDK-8149115 client-libs [hidpi] Linux: display-wise scaling factor should probably be taken in JDK-8150954 client-libs Taking screenshots on x11 composite desktop produce wrong result JDK-8152968 client-libs JTree Collapse Buttons Clipped Off Under GTK JDK-8153512 client-libs Taskbar support reported for Xfce4. JDK-8155515 client-libs Desktop.moveToTrash() javadoc issue JDK-8156212 client-libs Typo in javadoc of java.awt.Taskbar, setIconBadge spec JDK-8156460 client-libs [macosx] Test case javax/swing/JPopupMenu/6827786/bug6827786.java fail JDK-8157137 client-libs [PIT] [TEST_BUG] compilation failed for some tests from jdk/test/java/ JDK-8158205 client-libs HiDPI hand cursor broken on Windows JDK-8158362 client-libs [macosx] Regression: at least java/awt/event/KeyEvent/AltCharAccelerat JDK-8158377 client-libs [macosx] Regression: java/awt/KeyboardFocusmanager/ConsumeNextMnemonic JDK-8158389 client-libs [macosx] Regression: javax/swing/JMenu/4213634/bug4213634.java JDK-8158485 client-libs The "File" menu's menuitems can not bring up information window or mod JDK-8158496 client-libs [macosx] Swing mnemonics broken on Mac JDK-8158501 client-libs [macosx] The checkbox can't be checked via an event generate on the me JDK-8158512 client-libs [Regression] Test java/awt/Mouse/MouseModifiersUnitTest/MouseModifiers JDK-8158526 client-libs [macosx] java/awt/event/MouseEvent/MouseButtonsAndKeyMasksTest/MouseBu JDK-8158621 client-libs The ALT key can not work with any key JDK-8159168 client-libs [hidpi] Window.setShape() works incorrectly on HiDPI JDK-8159374 client-libs Taskbar.setIconBadge() spec omits mention of exception for ICON_BADGE_ JDK-8159460 client-libs On Ubuntu Unity, problem with java/awt/Window/FindOwner/FindOwnerTest JDK-8159587 client-libs IOOBE in javax/swing/JFileChooser/7199708/bug7199708.java JDK-8159956 client-libs EXCEPTION_ACCESS_VIOLATION in sun.awt.windows.ThemeReader.getThemeMarg JDK-8160145 client-libs [macosx] Keep pressed the Alt, Shift & Ctrl Keys,and then Click 'Click JDK-8160266 client-libs [macosx] NestedModalDialogTest.java and NestedModelessDialogTest.java JDK-8160421 client-libs Regression: JDK-8139192 causes NPE in java.awt.Toolkit.createCustomCur JDK-8160721 client-libs Avoid deoptimizations in Font.equals. JDK-8160764 client-libs [TEST_BUG] java/awt/TextArea/TextAreaScrolling/TextAreaScrolling.java JDK-8160879 client-libs [PIT] CloseOnMouseClickPropertyTest fails with AA hint:Nonantialiased JDK-8160882 client-libs [PIT][TEST_BUG] a trap of java/awt/print/PrinterJob/PrintTestLexmarkIQ JDK-8161407 client-libs Provide a javadoc description for the java.desktop module JDK-8161531 client-libs Provide a javadoc description for the java.datatransfer module JDK-8066652 core-libs Default TimeZone is GMT not local if user.timezone is invalid on Mac O JDK-8066806 core-libs java.time.format.DateTimeFormatter cannot parse an offset with single JDK-8156824 core-libs com.sun.jndi.ldap.pool.PoolCleaner should clear its context class load JDK-8157135 core-libs Fix module dependencies javax/* EE tests JDK-8157570 core-libs sun.rmi.transport.GC retains a strong reference to the context class l JDK-8159684 core-libs (tz) Support tzdata2016f JDK-8160034 core-libs The `this` value in the `with` is broken by the repetition of a functi JDK-8160605 core-libs java/util/SplittableRandom/SplittableRandomTest.java failed with timeo JDK-8160681 core-libs LocalDate.ofEpochDay input validation JDK-8160801 core-libs add documentation for NativeString JDK-8162439 core-libs Runtime.Version.parse needs fast-path for major versions JDK-8162539 core-libs Test fails because it expects a blank between method signature and thr JDK-8162563 core-libs Fix double checked locking in System.console() JDK-8162624 core-libs (fs) Remove FileTypeDetectors based on libgio and libmagic JDK-8157720 deploy Create functional tests to cover JDK-8157337 JDK-8159541 deploy [test] At step6: There is a blocked dialog shown up after clicking "Co JDK-8159571 deploy The application will be blocked by Java security once the app is launc JDK-8159702 deploy Security Exception(Sealing Violation) in package com.sun.java.swing JDK-8160526 deploy [test] At step3,the applet can not be launched fine JDK-8160799 deploy [test] "Run" instead of "Install" button should show for extensions of JDK-8160802 deploy [test]MD5 is a disabled algorithm when signing jar since jdk9-b02 JDK-8160878 deploy Update CLSIDScenarios/TestAppletLaunchUsingOlderCLSID.html with cleare JDK-8160918 deploy Resurrect several regression tests from com.sun.javaws JDK-8161191 deploy [test] Build error in javaws due to missing files in changeset 4654 JDK-8161244 deploy [test]Two cases in vmargsTest need to be updated due to that some secu JDK-8161380 deploy [test] One case in EmbededCertificateTest failed due to missing a jar JDK-8161464 deploy [test]Some cases in DepreationTest should use handleJavaPopUpSettingsF JDK-8161659 deploy [test] Add more tests to System level Java cache viewer in fx jcp. JDK-8161544 globalization JDK 9 msg drop 20 resource update - openjdk JDK-8162746 install VersionCheck.java failure after change for JDK-8160921 JDK-8149519 other-libs Set java.specification.version to the MAJOR java version JDK-8159488 security-libs Deprivilege java.xml.crypto JDK-8159528 security-libs Deprivilege java.security.jgss, jdk.security.jgss and jdk.security.aut JDK-8159752 security-libs Grant de-privileged module permissions by default with java.security.p JDK-8161303 security-libs Sample NIO Server README needs updating. JDK-8161506 security-libs Deprecate pre-1.2 SecurityManager methods and fields with forRemoval=t JDK-8161898 security-libs Deprecate methods that reference javax.security.cert APIs with forRemo JDK-8162752 security-libs keytool -importkeystore should probe srcstoretype if not specified JDK-8162882 security-libs Permission merge issue in jdk.crypto.ucrypto module JDK-8134779 tools jmod: ZipException is thrown if there are duplicate resources JDK-8134847 tools jmod: module-info encountered in the cmds, libs or config is not added JDK-8143366 tools Control characters in constant pool strings are not escaped properly JDK-8154705 tools invalid use of ALL-MODULE-PATH causes crash JDK-8158224 tools NullPointerException in com.sun.tools.javac.comp.Modules.checkCyclicDe JDK-8161277 tools javax.lang.model.util.Types.isSameType(...) returns true on wildcards JDK-8161708 tools javac, consider a different way to handle access code for operators JDK-8162343 tools non-ASCII characters in source code comments (.hpp) JDK-8162538 tools plugin API should avoid read only pool, have module view separated fro JDK-8162782 tools jlink ResourcePool.releaseProperties should be removed JDK-8021787 xml javax.xml.datatype.XMLGregorianCalendar.getMonth() return is documente JDK-8158084 xml Catalog API: JAXP XML Processor Support JDK-8162598 xml XSLTC transformer swallows empty namespace declaration which is needed JDK-8162666 xml Mark ValidationWarningsTest.java as intermittently failing From weijun.wang at oracle.com Thu Aug 4 01:11:39 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 4 Aug 2016 09:11:39 +0800 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo Message-ID: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. Votes are due by 21:00 UTC, August 17, 2016. Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [2]. --Wang Weijun [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote --- 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations 2) JDK-8078813: Test JAAS with modules 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. 7) JDK-8075301: Tests for sun.security.krb5.principal system property 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout From xuelei.fan at oracle.com Thu Aug 4 06:02:40 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Thu, 4 Aug 2016 14:02:40 +0800 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <28ed3412-5da0-e872-399e-5aeeb6c39cf2@oracle.com> Vote: Yes. Xuelei On 8/4/2016 9:11 AM, Wang Weijun wrote: > I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. > > Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. > > Votes are due by 21:00 UTC, August 17, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > --Wang Weijun > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > --- > > 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > 2) JDK-8078813: Test JAAS with modules > 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs > 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. > 7) JDK-8075301: Tests for sun.security.krb5.principal system property > 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. > 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout > 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java > 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 > 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout > 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout > 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout > From bradford.wetmore at oracle.com Thu Aug 4 06:11:55 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Wed, 3 Aug 2016 23:11:55 -0700 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <5ff2b092-5edd-634e-7daa-7b0cfa13c553@oracle.com> Yes. Brad On 8/3/2016 6:11 PM, Wang Weijun wrote: > I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. > > Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. > > Votes are due by 21:00 UTC, August 17, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > --Wang Weijun > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > --- > > 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > 2) JDK-8078813: Test JAAS with modules > 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs > 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. > 7) JDK-8075301: Tests for sun.security.krb5.principal system property > 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. > 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout > 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java > 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 > 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout > 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout > 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout > From li.jiang at oracle.com Thu Aug 4 07:26:54 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Thu, 4 Aug 2016 15:26:54 +0800 Subject: RFR JDK-8163145: remove two null lines in the end of message.properties Message-ID: Hi all, Please help to review the change for this minor bug. Two lines with text 'null' is in the end of message.properties, which are non-functional. webrev: http://cr.openjdk.java.net/~fyuan/leo/8163145/ bug: https://bugs.openjdk.java.net/browse/JDK-8163145 Thanks, Leo From nadeesh.tv at oracle.com Thu Aug 4 07:28:20 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Thu, 04 Aug 2016 12:58:20 +0530 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <57A2EE94.4050207@oracle.com> Vote:Yes On 8/4/2016 6:41 AM, Wang Weijun wrote: > I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. > > Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. > > Votes are due by 21:00 UTC, August 17, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > --Wang Weijun > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > --- > > 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > 2) JDK-8078813: Test JAAS with modules > 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs > 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. > 7) JDK-8075301: Tests for sun.security.krb5.principal system property > 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. > 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout > 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java > 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 > 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout > 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout > 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout > -- Thanks and Regards, Nadeesh TV From Roger.Riggs at Oracle.com Thu Aug 4 13:18:47 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 4 Aug 2016 09:18:47 -0400 Subject: RFR JDK-8163145: remove two null lines in the end of message.properties In-Reply-To: References: Message-ID: Looks fine, Roger On 8/4/2016 3:26 AM, Leo Jiang wrote: > Hi all, > > Please help to review the change for this minor bug. Two lines with > text 'null' is in the end of message.properties, which are > non-functional. > > webrev: > http://cr.openjdk.java.net/~fyuan/leo/8163145/ > > bug: > https://bugs.openjdk.java.net/browse/JDK-8163145 > > Thanks, > Leo From huizhe.wang at oracle.com Thu Aug 4 15:50:54 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 04 Aug 2016 08:50:54 -0700 Subject: RFR JDK-8163145: remove two null lines in the end of message.properties In-Reply-To: References: Message-ID: <57A3645E.1060804@oracle.com> +1 Joe On 8/4/16, 6:18 AM, Roger Riggs wrote: > Looks fine, > > Roger > > On 8/4/2016 3:26 AM, Leo Jiang wrote: >> Hi all, >> >> Please help to review the change for this minor bug. Two lines with >> text 'null' is in the end of message.properties, which are >> non-functional. >> >> webrev: >> http://cr.openjdk.java.net/~fyuan/leo/8163145/ >> >> bug: >> https://bugs.openjdk.java.net/browse/JDK-8163145 >> >> Thanks, >> Leo > From huizhe.wang at oracle.com Thu Aug 4 16:36:55 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 04 Aug 2016 09:36:55 -0700 Subject: RFR 8158486 : remove the wptg id line from jaxp resource file in JDK9 In-Reply-To: <15606432e6fa4d99badeae8c19ceec6d@DEWDFE13DE11.global.corp.sap> References: <72c9d1af-4031-b775-2cbf-5fc04e6a95ff@oracle.com> <75873e4b-43dd-7b48-3f5d-590ae93c508f@oracle.com> <52dca2f4-4896-dde5-b7b0-79420fd69fd1@oracle.com> <15606432e6fa4d99badeae8c19ceec6d@DEWDFE13DE11.global.corp.sap> Message-ID: <57A36F27.5040307@oracle.com> Thanks Christoph, and sorry Leo the late response. For XSLTErrorResources.java, the header/copy can be replaced with the following. Please note the empty line before "package" is required. /* * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.sun.org.apache.xalan.internal.res; For src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java: /* * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.sun.org.apache.xalan.internal.xsltc.compiler.util; For src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java: /* * reserved comment block * DO NOT REMOVE OR ALTER! */ /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.sun.org.apache.xalan.internal.xsltc.runtime; Thanks, Joe On 8/2/16, 12:27 AM, Langer, Christoph wrote: > Sure, it's a good idea to do this change. Joe should probably guide you through updating the headers. > > Best > Christoph > >> -----Original Message----- >> From: Leo Jiang [mailto:li.jiang at oracle.com] >> Sent: Dienstag, 2. August 2016 09:18 >> To: Langer, Christoph; Joe Wang >> >> Cc: jdk9-dev at openjdk.java.net >> Subject: Re: RFR 8158486 : remove the wptg id line from jaxp resource file in >> JDK9 >> >> Some java resource files had been included in this change. I'm not sure if other >> files have same issue. >> >> The impact to l10n process is that even no real change but translation tool >> would still update the svn line >> automatically. I'm not sure if has same case for other files. >> >> Thanks, >> Leo >> >> On 08/02/2016 03:08 PM, Langer, Christoph wrote: >>> Hi Leo, Joe, >>> >>> I think you should also take the chance to check/update all headers (that is, in >> the .java files) >>> Best regards >>> Christoph >>> >>>> -----Original Message----- >>>> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of >> Leo >>>> Jiang >>>> Sent: Dienstag, 2. August 2016 08:17 >>>> To: jdk9-dev at openjdk.java.net >>>> Subject: Re: RFR 8158486 : remove the wptg id line from jaxp resource file >> in >>>> JDK9 >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8158486 >>>> >>>> -Leo >>>> >>>> On 08/02/2016 01:53 PM, Leo Jiang wrote: >>>>> Hi Joe, >>>>> >>>>> Would you help to review this change? >>>>> >>>>> This is the JDK 9 release version of change about removal of wptg id line >> for >>>> jaxp resource files. >>>>> http://cr.openjdk.java.net/~fyuan/leo/8158486/webrev.00/ >>>>> >>>>> This line would impact the L10n resource update process. By removing this >>>> obsolete line, we can avoid to review these >>>>> files which actually haven't change. >>>>> >>>>> >>>>> Thanks, >>>>> Leo From huizhe.wang at oracle.com Thu Aug 4 16:43:03 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 04 Aug 2016 09:43:03 -0700 Subject: RFR 8158486 : remove the wptg id line from jaxp resource file in JDK9 In-Reply-To: <57A36F27.5040307@oracle.com> References: <72c9d1af-4031-b775-2cbf-5fc04e6a95ff@oracle.com> <75873e4b-43dd-7b48-3f5d-590ae93c508f@oracle.com> <52dca2f4-4896-dde5-b7b0-79420fd69fd1@oracle.com> <15606432e6fa4d99badeae8c19ceec6d@DEWDFE13DE11.global.corp.sap> <57A36F27.5040307@oracle.com> Message-ID: <57A37097.6070708@oracle.com> For src/java.xml/share/classes/com/sun/org/apache/xml/internal/res/XMLErrorResources.java: /* * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.sun.org.apache.xml.internal.res; For src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/utils/SerializerMessages.java: /* * reserved comment block * DO NOT REMOVE OR ALTER! */ /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.sun.org.apache.xml.internal.serializer.utils; For src/java.xml/share/classes/com/sun/org/apache/xpath/internal/res/XPATHErrorResources.java: /* * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights reserved. */ /* * Licensed to the Apache Software Foundation (ASF) under one or more * contributor license agreements. See the NOTICE file distributed with * this work for additional information regarding copyright ownership. * The ASF licenses this file to You under the Apache License, Version 2.0 * (the "License"); you may not use this file except in compliance with * the License. You may obtain a copy of the License at * * http://www.apache.org/licenses/LICENSE-2.0 * * Unless required by applicable law or agreed to in writing, software * distributed under the License is distributed on an "AS IS" BASIS, * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. * See the License for the specific language governing permissions and * limitations under the License. */ package com.sun.org.apache.xpath.internal.res; Thanks, Joe On 8/4/16, 9:36 AM, Joe Wang wrote: > Thanks Christoph, and sorry Leo the late response. > > For XSLTErrorResources.java, the header/copy can be replaced with the > following. Please note the empty line before "package" is required. > > /* > * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights > reserved. > */ > /* > * Licensed to the Apache Software Foundation (ASF) under one or more > * contributor license agreements. See the NOTICE file distributed with > * this work for additional information regarding copyright ownership. > * The ASF licenses this file to You under the Apache License, Version > 2.0 > * (the "License"); you may not use this file except in compliance with > * the License. You may obtain a copy of the License at > * > * http://www.apache.org/licenses/LICENSE-2.0 > * > * Unless required by applicable law or agreed to in writing, software > * distributed under the License is distributed on an "AS IS" BASIS, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied. > * See the License for the specific language governing permissions and > * limitations under the License. > */ > > package com.sun.org.apache.xalan.internal.res; > > > For > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/compiler/util/ErrorMessages.java: > /* > * Copyright (c) 2013, 2016, Oracle and/or its affiliates. All rights > reserved. > */ > /* > * Licensed to the Apache Software Foundation (ASF) under one or more > * contributor license agreements. See the NOTICE file distributed with > * this work for additional information regarding copyright ownership. > * The ASF licenses this file to You under the Apache License, Version > 2.0 > * (the "License"); you may not use this file except in compliance with > * the License. You may obtain a copy of the License at > * > * http://www.apache.org/licenses/LICENSE-2.0 > * > * Unless required by applicable law or agreed to in writing, software > * distributed under the License is distributed on an "AS IS" BASIS, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied. > * See the License for the specific language governing permissions and > * limitations under the License. > */ > > package com.sun.org.apache.xalan.internal.xsltc.compiler.util; > > For > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ErrorMessages.java: > /* > * reserved comment block > * DO NOT REMOVE OR ALTER! > */ > /* > * Licensed to the Apache Software Foundation (ASF) under one or more > * contributor license agreements. See the NOTICE file distributed with > * this work for additional information regarding copyright ownership. > * The ASF licenses this file to You under the Apache License, Version > 2.0 > * (the "License"); you may not use this file except in compliance with > * the License. You may obtain a copy of the License at > * > * http://www.apache.org/licenses/LICENSE-2.0 > * > * Unless required by applicable law or agreed to in writing, software > * distributed under the License is distributed on an "AS IS" BASIS, > * WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or > implied. > * See the License for the specific language governing permissions and > * limitations under the License. > */ > > package com.sun.org.apache.xalan.internal.xsltc.runtime; > > > Thanks, > Joe > > On 8/2/16, 12:27 AM, Langer, Christoph wrote: >> Sure, it's a good idea to do this change. Joe should probably guide >> you through updating the headers. >> >> Best >> Christoph >> >>> -----Original Message----- >>> From: Leo Jiang [mailto:li.jiang at oracle.com] >>> Sent: Dienstag, 2. August 2016 09:18 >>> To: Langer, Christoph; Joe Wang >>> >>> Cc: jdk9-dev at openjdk.java.net >>> Subject: Re: RFR 8158486 : remove the wptg id line from jaxp >>> resource file in >>> JDK9 >>> >>> Some java resource files had been included in this change. I'm not >>> sure if other >>> files have same issue. >>> >>> The impact to l10n process is that even no real change but >>> translation tool >>> would still update the svn line >>> automatically. I'm not sure if has same case for other files. >>> >>> Thanks, >>> Leo >>> >>> On 08/02/2016 03:08 PM, Langer, Christoph wrote: >>>> Hi Leo, Joe, >>>> >>>> I think you should also take the chance to check/update all headers >>>> (that is, in >>> the .java files) >>>> Best regards >>>> Christoph >>>> >>>>> -----Original Message----- >>>>> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On >>>>> Behalf Of >>> Leo >>>>> Jiang >>>>> Sent: Dienstag, 2. August 2016 08:17 >>>>> To: jdk9-dev at openjdk.java.net >>>>> Subject: Re: RFR 8158486 : remove the wptg id line from jaxp >>>>> resource file >>> in >>>>> JDK9 >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8158486 >>>>> >>>>> -Leo >>>>> >>>>> On 08/02/2016 01:53 PM, Leo Jiang wrote: >>>>>> Hi Joe, >>>>>> >>>>>> Would you help to review this change? >>>>>> >>>>>> This is the JDK 9 release version of change about removal of wptg >>>>>> id line >>> for >>>>> jaxp resource files. >>>>>> http://cr.openjdk.java.net/~fyuan/leo/8158486/webrev.00/ >>>>>> >>>>>> This line would impact the L10n resource update process. By >>>>>> removing this >>>>> obsolete line, we can avoid to review these >>>>>> files which actually haven't change. >>>>>> >>>>>> >>>>>> Thanks, >>>>>> Leo From mark.reinhold at oracle.com Thu Aug 4 19:49:32 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 04 Aug 2016 12:49:32 -0700 Subject: JEP proposed to target JDK 9 (2016/7/22) In-Reply-To: <20160722170133.D547F1FE8D0@ribbit.us.oracle.com> References: <20160722170133.D547F1FE8D0@ribbit.us.oracle.com> Message-ID: <20160804124932.62649621eggemoggin.niobe.net> 2016/7/22 10:01:33 -0700, mark.reinhold at oracle.com: > The following JEP has been placed into the "Proposed to Target" > state by its owner after discussion and review: > > 290: Filter Incoming Serialization Data > http://openjdk.java.net/jeps/290 > > Feedback on this proposal is more than welcome, as are reasoned > objections. If no such objections are raised by 23:00 UTC on > Monday, 1 August, or if they're raised and then satisfactorily > answered, then per the JEP 2.0 process proposal [1] I'll target > this JEP to JDK 9. Hearing no objections, I've targeted this JEP to JDK 9. - Mark From artem.smotrakov at oracle.com Thu Aug 4 19:55:32 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Thu, 4 Aug 2016 12:55:32 -0700 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <7183205d-612a-a2b1-a204-d10c98fb4090@oracle.com> Vote: Yes Artem On 08/03/2016 06:11 PM, Wang Weijun wrote: > I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. > > Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. > > Votes are due by 21:00 UTC, August 17, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > --Wang Weijun > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > --- > > 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > 2) JDK-8078813: Test JAAS with modules > 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs > 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. > 7) JDK-8075301: Tests for sun.security.krb5.principal system property > 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. > 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout > 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java > 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 > 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout > 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout > 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout > From huaming.li at oracle.com Fri Aug 5 01:40:38 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 5 Aug 2016 09:40:38 +0800 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <619f60f8-75d2-a987-1b6b-16a5154d2352@oracle.com> Vote: Yes. Thank you -Hamlin On 2016/8/4 9:11, Wang Weijun wrote: > I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. > > Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. > > Votes are due by 21:00 UTC, August 17, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > --Wang Weijun > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > --- > > 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > 2) JDK-8078813: Test JAAS with modules > 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs > 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. > 7) JDK-8075301: Tests for sun.security.krb5.principal system property > 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. > 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout > 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java > 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 > 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout > 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout > 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout > From amy.lu at oracle.com Fri Aug 5 10:04:30 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 5 Aug 2016 18:04:30 +0800 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <57A464AE.4040006@oracle.com> Vote: Yes /Amy On 8/4/16 9:11 AM, Wang Weijun wrote: > I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. > > Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. > > Votes are due by 21:00 UTC, August 17, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > --Wang Weijun > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > --- > > 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > 2) JDK-8078813: Test JAAS with modules > 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs > 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. > 7) JDK-8075301: Tests for sun.security.krb5.principal system property > 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. > 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout > 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java > 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 > 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout > 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout > 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout > From vyom.tewari at oracle.com Fri Aug 5 11:12:36 2016 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Fri, 5 Aug 2016 16:42:36 +0530 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <57A474A4.4060709@oracle.com> Vote: Yes On 8/4/2016 6:41 AM, Wang Weijun wrote: > I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. > > Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. > > Votes are due by 21:00 UTC, August 17, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > --Wang Weijun > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > --- > > 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > 2) JDK-8078813: Test JAAS with modules > 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs > 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. > 7) JDK-8075301: Tests for sun.security.krb5.principal system property > 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. > 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout > 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java > 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 > 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout > 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout > 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout > From prasanta.sadhukhan at oracle.com Fri Aug 5 12:30:02 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Fri, 5 Aug 2016 18:00:02 +0530 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <28ed3412-5da0-e872-399e-5aeeb6c39cf2@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> <28ed3412-5da0-e872-399e-5aeeb6c39cf2@oracle.com> Message-ID: <57A486CA.4000802@oracle.com> Vote: yes On 8/4/2016 9:11 AM, Wang Weijun wrote: >> I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. >> >> Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. >> >> Votes are due by 21:00 UTC, August 17, 2016. >> >> Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. >> >> For Lazy Consensus voting instructions, see [2]. >> >> --Wang Weijun >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> >> --- >> >> 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations >> 2) JDK-8078813: Test JAAS with modules >> 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property >> 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" >> 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs >> 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. >> 7) JDK-8075301: Tests for sun.security.krb5.principal system property >> 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. >> 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout >> 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java >> 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 >> 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout >> 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout >> 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout >> From anthony.scarpino at oracle.com Sat Aug 6 05:33:00 2016 From: anthony.scarpino at oracle.com (Anthony Scarpino) Date: Fri, 5 Aug 2016 22:33:00 -0700 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <57A5768C.80002@oracle.com> Vote: Yes Tony On 08/03/2016 06:11 PM, Wang Weijun wrote: > I hereby nominate Sibabrata Sahoo (ssahoo) to JDK 9 Committer. > > Siba is a member of the Java SE Security Libraries SQE Team. Siba has contributed 14 changesets (listed below) to JDK 9 in the security libraries testing areas. > > Votes are due by 21:00 UTC, August 17, 2016. > > Only current JDK 9 Committers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [2]. > > --Wang Weijun > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > > --- > > 1) JDK-8141039: Test Task: Develop new tests for JEP 273: DRBG-Based SecureRandom Implementations > 2) JDK-8078813: Test JAAS with modules > 3) JDK-8151654: Additional modular test for "auth.login.defaultCallbackHandler" property > 4) JDK-8160624: sun/security/tools/keytool/printssl.sh failed with "Socket closed" > 5) JDK-8130360: Add tests to verify 3rd party security providers if they are in modular JARs > 6) JDK-8150512: Update test for jdk.security.provider.preferred security property. > 7) JDK-8075301: Tests for sun.security.krb5.principal system property > 8) JDK-8157417: Some of SecureRandom test might get timed out in linux. > 9) JDK-8159861: sun/security/tools/keytool/DefaultSignatureAlgorithm.java timeout > 10) JDK-8160341: Remove intermittent key from TestDSAGenParameterSpec.java > 11) JDK-8160940: Enable debug log in javax/net/ssl/HttpsURLConnection/Equals.java to track JDK-8160210 > 12) JDK-8158116: com/sun/crypto/provider/KeyAgreement/SupportedDHParamGens.java failed with timeout > 13) JDK-8157896: TestDSAGenParameterSpec.java test fails with timeout > 14) JDK-8157898: SupportedDSAParamGen.java failed with timeout > From alejandro.murillo at oracle.com Mon Aug 8 18:32:38 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Mon, 8 Aug 2016 12:32:38 -0600 Subject: jdk9-dev: HotSpot Message-ID: <95d1e4d2-dc8a-8afc-a7a4-6c24aad49b88@oracle.com> jdk9-hs-2016-08-04 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/8728756c2f70 http://hg.openjdk.java.net/jdk9/dev/corba/rev/f7e1d5337c2e http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/943bf73b49c3 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/874082a9b565 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/783e7e2c587f http://hg.openjdk.java.net/jdk9/dev/jdk/rev/67e8b431911d http://hg.openjdk.java.net/jdk9/dev/langtools/rev/45241cff9d3a http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/ee77c6b3713a Component : VM Status : Go for integration Date : 08/08/2016 at 13:00 MSK Tested By : VM SQE &leonid.mesnik at oracle.com Bundles : 2016-08-05-165108.amurillo.jdk9-hs-2016-08-04-snapshot) Testing: 34 new failures, 188 known failures, 469792 passed. Issues and Notes: Analysis is still in progress. No stoppers have been detected so far. Go for integration CRs for testing: 7008747: Header files with conditional behaviour can not be precompiled 8024137: Flags should be set using the proper macro 8034842: Parallelize the Free CSet phase in G1 8038332: The trace event vm/class/load is not always being sent 8048093: Explicitly setting := vs = in the -XX:+PrintFlagsFinal output 8056950: Compiled code (64-bit) on SPARC should sign extend INT parameters passed on registers to runtime or native methods. 8071652: -XX:CompileOnly does not behave as documented 8081770: [TESTBUG] regression Test7107135 needs to remove dependence on locally installed gcc 8098573: Compiler accesses to shared archive fail if archive is remapped 8132318: -XX:TraceJumps is broken on Sparc 8132919: Put compiler tests in packages 8134434: JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _exception_caught is out of phase 8138760: [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=21831450 lookup_length=1275207287 average=58.411479 load=5.572844 8140723: Remove source code conditionalized on JAVASE_EMBEDDED 8141341: CDS should be disabled if JvmtiExport::should_post_class_file_load_hook() is true. 8141633: Implement VarHandles/Unsafe intrinsics on AArch64 8143081: [ctw] Test CompileTheWorld.java needs to be updated for Jigsaw 8144278: [TESTBUG] hotspot/runtime/StackGuardPages/testme.sh should use native library build support 8144279: [TESTBUG] hotspot/runtime/jsig/Test8017498.sh should use native library build support 8145627: sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect size and has no test 8147910: Cache initial active_processor_count 8151163: All Buffer implementations should leverage Unsafe unaligned accessors 8151280: update hotspot tests to use vm.compMode instead of their own logic 8153194: PreserveFPRegistersTest.java runs out of memory in the nightlies. 8153515: [ctw] CompileTheWorld testlibrary should trigger compilation of and 8153978: New test to verify the modules info as returned by the JVMTI 8154239: -Xbootclasspath/a breaks exploded build 8155263: DisableStartThread should not be applied to GC worker threads 8156943: aarch64: string compare does not support CompactStrings 8156959: compiler/codecache/jmx/UsageThresholdExceededSeveralTimesTest.java fails with exit 134. 8156980: Hotspot build doesn't have -std=gnu++98 gcc option 8157249: [JVMCI] remove ConstantReflectionProvider.isEmbeddable method 8157306: Random infrequent null pointer exceptions in javac 8157358: Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION 8157459: G1 IHOP JFR event attribute with incorrect content type 8157861: [TESTBUG] compiler/jvmci/compilerToVM/ReprofileTest.java failed with RuntimeException 8157984: [TESTBUG] Several compiler tests fails when are executed with -XX:TieredStopAtLevel=1 8158050: Remove SA-JDI 8158350: Table in ThreadInfo.from(CompositeData) may need updates for new stack trace attributes 8158508: gc/logging/TestUnifiedLoggingSwitchStress.java timeout 8158756: [Testbug] serviceability/dcmd/compiler/CompilerQueueTest.java fails with TieredStopAtLevel=1 8159016: Over-unrolled loop is partially removed 8159063: aarch64: optimise unaligned array copy long 8159073: : Error handling incomplete when creating GC threads lazily 8159129: TestStringIntrinsicRangeChecks fails w/ No exception thrown for compressByte/inflateByte 8159368: [JVMCI] SPARCHotSpotRegisterConfig.callingConvention gives incorrect calling convention for native calls containing fp args 8159464: DumpHeap.java hits assert in G1 code 8159467: AArch64: Enable compact strings 8159606: gc/g1/TestShrinkAuxiliaryData* tests fail because GC triggered before VM initialization completed 8159620: -XX:-UseOnStackReplacement does not work together with -XX:+TieredCompilation on ppc64 and sparc 8159888: [JVMCI] the client VM build is broken when INCLUDE_JVMCI is defined 8159901: missing newline char in the exception messages in diagnosticArgument.cpp 8160085: @library' must appear before first `@run' 8160119: Utils.tryFindJvmPid sometimes find incorrect pid 8160121: [JVMCI] JvmciNotifyBootstrapFinishedEventTest.java failed NoClassDefFoundError: jdk/vm/ci/runtime/JVMCI 8160177: [JVMCI] race condition in HotSpotMemoryAccessProviderImpl.verifyReadRawObject 8160245: C1: Clean up platform #defines in c1_LIR.hpp. 8160276: Jittester: bytecode tests generation hangs in ClassWriter infinite loop 8160360: Mismatched field loads are folded in LoadNode::Value 8160425: Vectorization with signalling NaN returns wrong result 8160471: compiler/rangechecks/TestRangeCheckEliminationDisabled.java fails after JDK-8150900 8160487: JVM should validate a module by checking for an instance of java.lang.reflect.Module 8160534: aarch64: fails to build after 8157834 8160647: [JVMCI] need to be able to copy internal arrays from LocalVariableTable and LineNumberTable 8160651: StubRoutines::_dtan does not restore callee save register rbx 8160657: Compiler HotSpot tests should use the "run driver" directive where applicable 8160730: [JVMCI] compiler selection should work without -Djvmci.Compiler 8160742: Node::operator new invokes undefined behavior 8160761: [TESTBUG] Several compiler tests fail with product bits 8160773: error: package jdk.internal.jimage does not exist 8160817: Add jsadebugd functionality to jhsdb 8160825: Update minimum Solaris Studio compiler version to 5.13 8160827: gc/stress/TestStressG1Humongous.java fails with OOME 8160892: Race at the VM exit causes "WaitForMultipleObjects timed out" 8160897: Concurrent mark mark stack memory allocation leaks memory 8160898: assert while replaying ciReplay file created using TieredStopAtLevel=1 8160969: aarch64: CDS is broken after 8079507 8160997: Solaris: deprecated and interfaces should be replaced 8161027: GPL header missing comma after year 8161028: GPL header missing comma after year 8161034: GPL header missing comma after year 8161057: Solaris: deprecated/obsolete compiler flags should be removed 8161068: jdk.vm.ci.hotspot.test.MethodHandleAccessProviderTest fails 8161072: AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure 8161138: testlibrary_tests/ctw/* failed with "Failed. Unexpected exit from test [exit code: 0]" 8161147: jvm crashes when -XX:+UseCountedLoopSafepoints is enabled 8161164: quarantine more tests that can't attach symbolicator to the process on MacOS X 8161173: quarantine compiler/arraycopy/TestEliminatedArrayCopyDeopt.java 8161174: quarantine gc/stress/TestStressG1Humongous.java on 32-bit 8161175: quarantine serviceability/dcmd/compiler/CompilerQueueTest.java on 32-bit 8161177: quarantine com/sun/jdi/sde/SourceDebugExtensionTest.java on Win* 8161190: AArch64: Fix overflow in immediate cmp instruction 8161208: Unable to run jtreg tests with MinimalVM 8161258: Simplify including platform files. 8161265: [JVMCI] EnableJVMCI should only be required when its not implied by other flags 8161274: [JVMCI] compiler/jvmci/events/JvmciNotifyInstallEventTest.java fails with NoClassDefFound 8161292: [JVMCI] missing test files from 8159368 8161445: [BACKOUT] MemberNameTable doesn't purge stale entries 8161508: JVMCI: MaterializeVirtualObjectTest fails w/ "CASE: invalidate=true: has no virtual object before materialization 8161539: 8159666 breaks minimal VM 8161552: Test issue: VM init failed: GC triggered before VM initialization completed. Try increasing NewSize, current value 768K. 8161601: Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed 8161603: [JVMCI] HotSpotVMConfig.baseVtableLength is incorrectly computed 8161604: TestNewSizeFlags fails with RuntimeException: max new size != MaxNewSize value 8161651: Logic in ConnectionGraph::split_unique_types() wrongly assumes node always have memory input 8161695: compiler/jsr292/MHInlineTest.java can't be run on client-only platforms 8161907: adlc: Fix crash in cisc_spill_match if _rChild == NULL 8161915: Linking gtestLauncher may end up linking with non-gtest libjvm 8161947: runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev 8161990: Un-quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java. 8161993: G1 crashes if active_processor_count changes during startup 8162340: Better class stream parsing 8162376: TestSHA512Intrinsics.java failed with Unexpected count of intrinsic _sha5_implCompress is expected 8162384: Performance regression: bimorphic inlining may be bypassed by type speculation 8162427: fix indent in CompileTask::print_tty 8162458: Buffer view implementations use incorrect offset for Unsafe access 8162524: src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handle JNI exceptions 8162540: Crash in C2 escape analysis with assert: "node should be registered" 8162603: Unrecognized VM option 'UseCountedLoopSafepoints' 8162702: com.sun.management.internal.GcInfoBuilder.getPoolNames should not return reference of it's private member 8162869: Small fixes for AIX perf memory and attach listener 8162945: HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory -- Alejandro From mandy.chung at oracle.com Mon Aug 8 22:46:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 8 Aug 2016 15:46:09 -0700 Subject: RFR 8161544 JDK 9 msg drop 20 resource update - openjdk In-Reply-To: <578C964E.2040602@oracle.com> References: <578C964E.2040602@oracle.com> Message-ID: I skimmed on the change which looks okay. FYI. The resource files for several tool?s resource files are updated in an upcoming patch for JDK-8136930 that is currently being reviewed [1]. This will give you an idea of what is coming that will impact the localized resource files. Mandy [1] http://mail.openjdk.java.net/pipermail/jigsaw-dev/2016-August/009025.html > On Jul 18, 2016, at 1:41 AM, Leo Jiang wrote: > > Hi all, > > Please help to review these changes for localized resource files. > > http://cr.openjdk.java.net/~fyuan/leo/jdk9msgdrop20/ > You can find the folder 'read' for human reading webrev, and if any concern raise you can refer the 'raw' folder. > > In messaged drop 20 cycle, the English resource files for tools as below were updated. Please help to review the format and syntax of its localized counterpart still good. > > - pack200/unpack200 > - java > - jarsigner > - jar > - jmod > - jlink > - javac > - javadoc > > Thanks, > Leo From zoltan.majo at oracle.com Wed Aug 10 13:45:10 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 10 Aug 2016 15:45:10 +0200 Subject: CFV: New JDK 9 Committer: Doug Simon Message-ID: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 Committer. Doug is a member of Oracle Labs and has been working on Java-related technologies for the past 15+ years. He is an Author in the JDK 9 Project and has contributed more than 35 changesets to JDK 9 (most of them related to JVMCI) [1]. Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Zoltan [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 [2] http://openjdk.java.net/census#jdk9 [3] |http://openjdk.java.net/projects/#committer-vote | From zoltan.majo at oracle.com Wed Aug 10 13:46:23 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Wed, 10 Aug 2016 15:46:23 +0200 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <24852c17-d068-59ad-4049-f18ff27f917d@oracle.com> Vote: yes. Best regards, Zoltan On 08/10/2016 03:45 PM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From eric.caspole at oracle.com Wed Aug 10 14:09:19 2016 From: eric.caspole at oracle.com (Eric Caspole) Date: Wed, 10 Aug 2016 10:09:19 -0400 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <1aaf813f-37c8-e8e9-394d-05a8932557cc@oracle.com> Vote: yes Eric On 8/10/2016 9:45 AM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From volker.simonis at gmail.com Wed Aug 10 14:28:26 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 10 Aug 2016 16:28:26 +0200 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: Vote: yes Regards, Volker On Wed, Aug 10, 2016 at 3:45 PM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 Project > and has contributed more than 35 changesets to JDK 9 (most of them related > to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From frederic.parain at oracle.com Wed Aug 10 14:35:13 2016 From: frederic.parain at oracle.com (frederic parain) Date: Wed, 10 Aug 2016 10:35:13 -0400 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <693d6933-5519-0dcb-8d92-ff36384915d7@oracle.com> Vote: yes Fred On 10/08/2016 09:45, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From jon.masamitsu at oracle.com Wed Aug 10 15:16:36 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Wed, 10 Aug 2016 08:16:36 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <57AB4554.8090200@oracle.com> Vote: yes On 08/10/2016 06:45 AM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From paul.sandoz at oracle.com Wed Aug 10 16:09:09 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Aug 2016 09:09:09 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: Vote: yes Paul. From mandy.chung at oracle.com Wed Aug 10 16:13:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 10 Aug 2016 09:13:22 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <7F9F3AD9-0657-43C5-B2F4-C4E37D43736F@oracle.com> Vote: yes Mandy From vladimir.kozlov at oracle.com Wed Aug 10 16:41:35 2016 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 10 Aug 2016 09:41:35 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <4cac2cb8-0fc3-8d53-1c72-57507734ded8@oracle.com> Vote: yes On 8/10/16 6:45 AM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From vladimir.x.ivanov at oracle.com Wed Aug 10 17:04:37 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Wed, 10 Aug 2016 10:04:37 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <4172a35d-f76a-a2ce-7882-57148fb4ffac@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 8/10/16 6:45 AM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. From aleksey.shipilev at gmail.com Wed Aug 10 17:05:16 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Wed, 10 Aug 2016 20:05:16 +0300 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <7a66f487-5f5e-f5db-c7db-1ca982af7561@gmail.com> Vote: yes. -Aleksey On 08/10/2016 04:45 PM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From Roger.Riggs at Oracle.com Wed Aug 10 17:11:41 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 10 Aug 2016 13:11:41 -0400 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: Vote: Yes On 8/10/2016 9:45 AM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. From jan.lahoda at oracle.com Wed Aug 10 17:15:58 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 10 Aug 2016 19:15:58 +0200 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <57AB614E.2020801@oracle.com> Vote: yes On 10.8.2016 15:45, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From Peter.B.Kessler at Oracle.COM Wed Aug 10 17:16:00 2016 From: Peter.B.Kessler at Oracle.COM (Peter B. Kessler) Date: Wed, 10 Aug 2016 10:16:00 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: On 08/10/16 06:45 AM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 Committer. Vote: Yes ... peter From vicente.romero at oracle.com Wed Aug 10 17:27:53 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Wed, 10 Aug 2016 13:27:53 -0400 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <9599b776-ccb9-d559-fbbb-924b6c88c753@oracle.com> vote: yes Vicente On 08/10/2016 09:45 AM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From dean.long at oracle.com Wed Aug 10 18:59:09 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 10 Aug 2016 11:59:09 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <17997ef2-05b6-d590-c88b-ddd2608fe430@oracle.com> |Vote: yes dl | On 8/10/16 6:45 AM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From paul.sandoz at oracle.com Wed Aug 10 20:52:31 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Aug 2016 13:52:31 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach Message-ID: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. Votes are due by Wednesday, Aug 24, 2016. Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Paul. [1] http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) [2] http://openjdk.java.net/census#jdk9 [3] |http://openjdk.java.net/projects/#committer-vote From michael.haupt at oracle.com Wed Aug 10 21:21:03 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 10 Aug 2016 14:21:03 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <8753127A-C7E1-4F68-80F4-A16683B37536@oracle.com> Vote: yes. Best, Michael > Am 10.08.2016 um 06:45 schrieb Zolt?n Maj? : > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 Committer. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From michael.haupt at oracle.com Wed Aug 10 21:21:54 2016 From: michael.haupt at oracle.com (Michael Haupt) Date: Wed, 10 Aug 2016 14:21:54 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <515EF5B2-502B-403C-9184-F1F9F0E222E5@oracle.com> Vote: yes. Best, Michael > Am 10.08.2016 um 13:52 schrieb Paul Sandoz : > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. -- Dr. Michael Haupt | Principal Member of Technical Staff Phone: +49 331 200 7277 | Fax: +49 331 200 7561 Oracle Java Platform Group | LangTools Team | Nashorn Oracle Deutschland B.V. & Co. KG | Schiffbauergasse 14 | 14467 Potsdam, Germany ORACLE Deutschland B.V. & Co. KG | Hauptverwaltung: Riesstra?e 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. | Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Nederland, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From joe.darcy at oracle.com Wed Aug 10 21:51:23 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 10 Aug 2016 14:51:23 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <57ABA1DB.1000700@oracle.com> Vote: yes -Joe On 8/10/2016 1:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From dean.long at oracle.com Wed Aug 10 21:51:46 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 10 Aug 2016 14:51:46 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: Vote: yes dl On 8/10/16 1:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From jan.lahoda at oracle.com Wed Aug 10 21:53:36 2016 From: jan.lahoda at oracle.com (Jan Lahoda) Date: Wed, 10 Aug 2016 23:53:36 +0200 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <57ABA260.1060007@oracle.com> Vote: yes On 10.8.2016 22:52, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From brent.christian at oracle.com Wed Aug 10 22:11:07 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 10 Aug 2016 15:11:07 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <57ABA67B.5030703@oracle.com> Vote: Yes On 08/10/2016 01:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From james.laskey at oracle.com Wed Aug 10 22:15:03 2016 From: james.laskey at oracle.com (James Laskey) Date: Wed, 10 Aug 2016 19:15:03 -0300 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <93B476A1-08E3-491D-AA14-A3D9BBF6642B@oracle.com> Vote: yes Sent from my iPhone > On Aug 10, 2016, at 5:52 PM, Paul Sandoz wrote: > > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From lana.steuck at oracle.com Wed Aug 10 22:36:23 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 10 Aug 2016 22:36:23 GMT Subject: jdk9-b131: dev Message-ID: <201608102236.u7AMaNbo010814@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/8728756c2f70 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/ee77c6b3713a http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/aebfafc43714 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/8c57f4c293bb http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/783e7e2c587f http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/874082a9b565 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/943bf73b49c3 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/f7e1d5337c2e --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-4882305 client-libs StreamPrintServ.getSupportedAttributeValues returns null for Orientati JDK-4908075 client-libs Press shift and another key using robot does not trigger events proper JDK-6427331 client-libs NullPointerException in LookupOp.filter(Raster, WritableRaster) JDK-6575247 client-libs Banner checkbox in PrinterJob print dialog doesn't work JDK-6591280 client-libs getting IPP connection causes disabling jar caches JDK-7096375 client-libs Swing ignores first click after decreasing system's time JDK-7175487 client-libs Cannot customize font configuration on Linux JDK-8016313 client-libs java.awt.Headless exception has no spec since its creation JDK-8056210 client-libs Move libawt file to windows directory JDK-8074827 client-libs Resolve disabled warnings for libjavajpeg JDK-8074843 client-libs Resolve disabled warnings for libmlib_image and libmlib_image_v JDK-8117886 client-libs There is no tooltip while moving the mouse on the tray icon. JDK-8140314 client-libs Verify IIOMetadataFormat class on loading. JDK-8144594 client-libs HiDPI: awt.Choice looks improperly (Win 8) JDK-8144709 client-libs [hidpi] [TestBug] java/awt/GridLayout/ChangeGridSize/ChangeGridSize.ja JDK-8147542 client-libs Linux: ClassCastException when repainting after display resolution cha JDK-8147648 client-libs [hidpi] multiresolution image: wrong resolution variant is used as ico JDK-8148454 client-libs [PIT] Failure of ReplaceMetadataTest on TIFF with IllegalStateExceptio JDK-8157827 client-libs AWT_Desktop/Automated/Exceptions/BasicTest loads incorrect GTK version JDK-8158918 client-libs setExtendedState(1) for maximized Frame results in state==7 JDK-8160246 client-libs Regression: 4410243 reproducible with GTK LaF JDK-8160438 client-libs [PIT][macosx] [TEST_BUG] javax/swing/plaf/nimbus/8057791/bug8057791.ja JDK-8160448 client-libs Make GTK3 menus appearence similar to native. JDK-8160664 client-libs JVM crashed with font manager on Solaris 12 JDK-8160943 client-libs skipImage() in JPEGImageReader class throws IIOException if we have ga JDK-8160974 client-libs [TESTBUG] Mark more headful tests with @key headful. JDK-8161273 client-libs [hidpi] The frame insets size is wrong on Linux HiDPI because it is no JDK-8161470 client-libs [TEST_BUG] Failure javax/swing/JRadioButton/FocusTraversal/FocusTraver JDK-8161902 client-libs [PIT][TEST_BUG]sun/awt/image/OffScreenImageSource/ImageConsumerUnregis JDK-8162429 client-libs Clean up obsolete font preferences for JDS. JDK-8162432 client-libs Clean up references in font code to old Solaris releases. JDK-8162433 client-libs Remove fontconfig.properties files for older Linuxes JDK-8162488 client-libs JDK should be updated to use LittleCMS 2.8 JDK-8162545 client-libs Mac build failure JDK-8035133 core-libs Locale matching: Weight q=0 isn't handled correctly. JDK-8146215 core-libs (fs) java/nio/file/Files/probeContentType/Basic.java failed frequently JDK-8151163 core-libs All Buffer implementations should leverage Unsafe unaligned accessors JDK-8160151 core-libs java/lang/ProcessBuilder/Zombies.java failed with error "1 zombies!" JDK-8161024 core-libs Remove intermittent key from java/lang/Runtime/exec/LotsOfOutput.java JDK-8161068 core-libs jdk.vm.ci.hotspot.test.MethodHandleAccessProviderTest fails JDK-8161379 core-libs Force inline methods calling Reflection.getCallerClass JDK-8162458 core-libs Buffer view implementations use incorrect offset for Unsafe access JDK-8162745 core-libs content-types.properties files are missing some modern types JDK-8162771 core-libs Strict equality operators should not be optimistic JDK-8162815 core-libs unnecessary object creation in reflection JDK-8162817 core-libs Annotation toString output not reusable for source input JDK-8162819 core-libs fix minor Javadoc issues and remove warnings in java.net.Socket JDK-8162876 core-libs [TEST_BUG] sun/net/www/protocol/http/HttpInputStream.java fails interm JDK-8162902 core-libs Add some debugging output to test/java/nio/file/WatchService/DeleteInt JDK-8162955 core-libs Activate anonymous class loading for small sources JDK-8163149 core-libs Typo in java.net.http.AuthenticationFilter JDK-8163369 core-libs Enable generating DMH classes at link time JDK-8163476 core-libs java/lang/StackWalker/VerifyStackTrace.java fails after JDK-8163369 JDK-8157664 core-svc Remove JInfoSanityTest.java JInfoRunningProcessFlagTest.java and JMapH JDK-8158350 core-svc Table in ThreadInfo.from(CompositeData) may need updates for new stack JDK-8161177 core-svc quarantine com/sun/jdi/sde/SourceDebugExtensionTest.java on Win* JDK-8162524 core-svc src/jdk.management/share/native/libmanagement_ext/Flag.c doesn't handl JDK-8162702 core-svc com.sun.management.internal.GcInfoBuilder.getPoolNames should not retu JDK-8162945 core-svc HotspotDiagnosticMXBean getFlags erroneously reports OutOfMemory JDK-8141689 deploy [test] The "plugin2 denied" will not be sent till after the blocked di JDK-8156960 deploy Deprecate JSObject.getWindow(Applet) method JDK-8157695 deploy NEED_TEST JDK-8047110 JDK-8157696 deploy Need Test:JDK-8064606 JDK-8158562 deploy Digest Auth is not working with JDK9 JDK-8160550 deploy [linux] Increase the size of top buttons for FX JCP JDK-8161240 deploy [test] Some cases need to be updated due to new FX JCP changes JDK-8161343 deploy [test] Some cases in BlacklistTest failed due to IllegalAccessError in JDK-8161381 deploy [test] one case in JavawsRegressionTest failed due to module jdk.javaw JDK-8161384 deploy [test] One case in JawsESLCertCheckTest failed due to the cert used to JDK-8161446 deploy [test] Some cases in PolicyFileValidationTest failed due to the locati JDK-8161899 deploy [test] testSSLCertBadChainJNLP failed due to the version of tcnative-1 JDK-8162525 deploy [test] The last cmd must be wait when result is sent by app. JDK-8162526 deploy [test] Due to fix of 8161468, update tests in javaws https suite JDK-7008747 hotspot Header files with conditional behaviour can not be precompiled JDK-8024137 hotspot Flags should be set using the proper macro JDK-8034842 hotspot Parallelize the Free CSet phase in G1 JDK-8038332 hotspot The trace event vm/class/load is not always being sent JDK-8048093 hotspot Explicitly setting := vs = in the -XX:+PrintFlagsFinal output JDK-8056950 hotspot Compiled code (64-bit) on SPARC should sign extend INT parameters pass JDK-8071652 hotspot -XX:CompileOnly does not behave as documented JDK-8081770 hotspot [TESTBUG] regression Test7107135 needs to remove dependence on locally JDK-8098573 hotspot Compiler accesses to shared archive fail if archive is remapped JDK-8132318 hotspot -XX:TraceJumps is broken on Sparc JDK-8132919 hotspot Put compiler tests in packages JDK-8134434 hotspot JVM_DoPrivileged() fires assert(_exception_caught == false) failed: _e JDK-8138760 hotspot [JVMCI] VM warning: Performance bug: SystemDictionary lookup_count=218 JDK-8141341 hotspot CDS should be disabled if JvmtiExport::should_post_class_file_load_hoo JDK-8141633 hotspot Implement VarHandles/Unsafe intrinsics on AArch64 JDK-8143081 hotspot [ctw] Test CompileTheWorld.java needs to be updated for Jigsaw JDK-8144278 hotspot [TESTBUG] hotspot/runtime/StackGuardPages/testme.sh should use native JDK-8144279 hotspot [TESTBUG] hotspot/runtime/jsig/Test8017498.sh should use native librar JDK-8145627 hotspot sun.jvm.hotspot.oops.InstanceKlass::getSize() returns the incorrect si JDK-8147910 hotspot Cache initial active_processor_count JDK-8151280 hotspot Update HotSpot tests to use vm.compMode instead of their own logic JDK-8153194 hotspot PreserveFPRegistersTest.java runs out of memory in the nightlies JDK-8153515 hotspot [ctw] CompileTheWorld testlibrary should trigger compilation of and interfaces should be replaced JDK-8161072 hotspot AArch64: jtreg compiler/uncommontrap/TestDeoptOOM failure JDK-8161138 hotspot testlibrary_tests/ctw/* failed with "Failed. Unexpected exit from test JDK-8161147 hotspot jvm crashes when -XX:+UseCountedLoopSafepoints is enabled JDK-8161164 hotspot quarantine more tests that can't attach symbolicator to the process on JDK-8161172 hotspot quarantine closed/compiler/compilercontrol/RandomValidCommandsTest.jav JDK-8161174 hotspot quarantine gc/stress/TestStressG1Humongous.java on 32-bit JDK-8161175 hotspot quarantine serviceability/dcmd/compiler/CompilerQueueTest.java on 32-b JDK-8161190 hotspot AArch64: Fix overflow in immediate cmp instruction JDK-8161208 hotspot Unable to run jtreg tests with MinimalVM JDK-8161265 hotspot [JVMCI] EnableJVMCI should only be required when its not implied by ot JDK-8161274 hotspot [JVMCI] compiler/jvmci/events/JvmciNotifyInstallEventTest.java fails w JDK-8161292 hotspot [JVMCI] missing test files from 8159368 JDK-8161508 hotspot JVMCI: MaterializeVirtualObjectTest fails w/ "CASE: invalidate=true: h JDK-8161539 hotspot 8159666 breaks minimal VM JDK-8161552 hotspot Test issue: VM init failed: GC triggered before VM initialization comp JDK-8161601 hotspot Solaris: __USE_LEGACY_PROTOTYPES__ is redundant and should be removed JDK-8161603 hotspot [JVMCI] HotSpotVMConfig.baseVtableLength is incorrectly computed JDK-8161604 hotspot TestNewSizeFlags fails with RuntimeException: max new size != MaxNewSi JDK-8161651 hotspot Logic in ConnectionGraph::split_unique_types() wrongly assumes node al JDK-8161695 hotspot compiler/jsr292/MHInlineTest.java can't be run on client-only platform JDK-8161907 hotspot adlc: Fix crash in cisc_spill_match if _rChild == NULL JDK-8161947 hotspot runtime/Unsafe/GetUnsafe.java is failing on jdk9/dev JDK-8161990 hotspot Un-quarantine TestParallelHeapSizeFlags.java and TestSmallHeap.java. JDK-8161993 hotspot G1 crashes if active_processor_count changes during startup JDK-8162340 hotspot Better class stream parsing JDK-8162348 hotspot nsk/jvmti/ tests fail with "Could not find agent library ... on the li JDK-8162376 hotspot TestSHA512Intrinsics.java failed with Unexpected count of intrinsic _s JDK-8162384 hotspot Performance regression: bimorphic inlining may be bypassed by type spe JDK-8162427 hotspot fix indent in CompileTask::print_tty JDK-8162540 hotspot Crash in C2 escape analysis with assert: "node should be registered" JDK-8162603 hotspot Unrecognized VM option 'UseCountedLoopSafepoints' JDK-8162869 hotspot Small fixes for AIX perf memory and attach listener JDK-8163231 hotspot A couple of runtime tests failing for the -testset hotspot snapshot jo JDK-8056269 infrastructure get_source.sh does not copy the closed repos when cloning local filesy JDK-8079788 infrastructure Fix broken CL version detection in configure for some Visual Studio co JDK-8156980 infrastructure Hotspot build doesn't have -std=gnu++98 gcc option JDK-8157100 infrastructure missing dependency in build system JDK-8157358 infrastructure Syntax error in TOOLCHAIN_CHECK_COMPILER_VERSION JDK-8160825 infrastructure Update minimum Solaris Studio compiler version to 5.13 JDK-8161057 infrastructure Solaris: deprecated/obsolete compiler flags should be removed JDK-8161915 infrastructure Linking gtestLauncher may end up linking with non-gtest libjvm JDK-8149518 install Installer hangs during the JDK 8u74 installation process. JDK-8161945 install REGRESSION: 8u91 update of 32 bit JRE removes preferences of the 64 bi JDK-8161258 javafx [Win] Timer functionality is broken after JDK-8089563 JDK-8163180 other-libs Typos around @code javadoc tag usage JDK-8160337 security-libs Remove intermittent key from sun/security/pkcs11/rsa/TestKeyPairGenera JDK-8163303 security-libs Remove identity scope information from jarsigner -verbose output JDK-8144733 tools Iterating over elements of a Scope can return spurious inner class ele JDK-8146721 tools FileCopierPlugin should not create fake module JDK-8154817 tools Fix the click-through navigation for modules JDK-8159487 tools Add JAVA_VERSION, OS_NAME, OS_ARCH properties in release file JDK-8161970 tools Remove tools/jlink/JLinkOptimTest.java from ProblemList.txt JDK-8162359 tools javac should use stdout for --help and --version JDK-8162797 tools Code clean-up in IncludeLocalesPlugin JDK-8162874 tools AST nodes representing operators should have a common superclass JDK-8163113 tools langtools repeating annotations tests depend rely on annotations toStr JDK-8163115 tools Temporarily problem list javac repeating annotations tests JDK-8163116 tools jlink exclude VM plugin does not fully support cross platform image cr JDK-8163256 tools jlink/plugins/ExcludeVMPluginTest.java failed with Selected VM server JDK-8163382 tools ResourcePoolManager.findEntry has a bug in startsWith call JDK-8067170 xml Enable security manager on JAXP unit tests JDK-8130494 xml [TESTBUG] 2 jaxp test cases are failing JDK-8160069 xml RuntimeException thrown by XPathFactory::newInstance missing the cause JDK-8160216 xml jaxp/test/javax/xml/jaxp/unittest/validation/Bug6457662.java should cl JDK-8163266 xml Doc for ValidationEvent#getSeverity() should say it returns a constant From paul.sandoz at oracle.com Wed Aug 10 22:48:24 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 10 Aug 2016 15:48:24 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <5C3DDB40-168C-4117-9897-E61A20D2B146@oracle.com> Vote: yes Paul. From john.r.rose at oracle.com Wed Aug 10 23:09:04 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 10 Aug 2016 16:09:04 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <628EEFBA-2714-4045-8AD7-3A3C0C26F125@oracle.com> Vote: yes > On Aug 10, 2016, at 6:45 AM, Zolt?n Maj? wrote: > > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 Committer. From david.holmes at oracle.com Thu Aug 11 00:10:27 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 11 Aug 2016 10:10:27 +1000 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <016859cd-ed83-69f6-af92-b82b3e0a2936@oracle.com> Vote: yes David On 10/08/2016 11:45 PM, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 > Committer. > > Doug is a member of Oracle Labs and has been working on Java-related > technologies for the past 15+ years. He is an Author in the JDK 9 > Project and has contributed more than 35 changesets to JDK 9 (most of > them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] > http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From zoltan.majo at oracle.com Thu Aug 11 07:37:25 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Thu, 11 Aug 2016 09:37:25 +0200 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <04febc23-5a16-a8c6-5f59-6309b6efc636@oracle.com> Vote: yes. Best regards, Zoltan On 08/10/2016 10:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From daniel.fuchs at oracle.com Thu Aug 11 09:07:00 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 11 Aug 2016 10:07:00 +0100 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <9a0b50eb-c6a3-54f2-6ef3-00729f3a9531@oracle.com> Vote: yes -- daniel On 10/08/16 21:52, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. From claes.redestad at oracle.com Thu Aug 11 09:12:11 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 11 Aug 2016 11:12:11 +0200 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <57AC416B.8060209@oracle.com> Vote: yes /Claes On 2016-08-10 22:52, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From chris.hegarty at oracle.com Thu Aug 11 09:24:25 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 11 Aug 2016 10:24:25 +0100 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: Vote: YES. -Chris. From dalibor.topic at oracle.com Thu Aug 11 11:16:31 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 11 Aug 2016 13:16:31 +0200 Subject: CFV: New JDK 9 Committer: Ajit Ghaisas In-Reply-To: References: Message-ID: <80e1d960-c8f2-025f-c01f-01a516985247@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Aug 11 11:19:43 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 11 Aug 2016 13:19:43 +0200 Subject: CFV: New JDK 9 Committer: Sibabrata Sahoo In-Reply-To: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> References: <52EFA01E-2BAC-4C11-81C1-471F1154A6F5@oracle.com> Message-ID: <23fd5939-3081-0edf-bc9d-0199ac9982ff@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Aug 11 11:20:26 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 11 Aug 2016 13:20:26 +0200 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <13daaf01-49fb-27ef-6387-5a04ba58fb2e@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From dalibor.topic at oracle.com Thu Aug 11 11:20:57 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Thu, 11 Aug 2016 13:20:57 +0200 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <56d5dc1f-0ba9-df68-64cd-8d3ab8fd5c5b@oracle.com> Vote: Yes. -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Roger.Riggs at Oracle.com Thu Aug 11 14:40:05 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 11 Aug 2016 10:40:05 -0400 Subject: CFV: New JDK 9 Committer: Ajit Ghaisas In-Reply-To: References: Message-ID: <08ea9c82-a2dc-207f-029c-1b071a3ec1eb@Oracle.com> Vote: Yes On 7/28/2016 4:43 AM, Sergey Bylokhov wrote: > I hereby nominate Ajit Ghaisas to JDK 9 Committer. From Roger.Riggs at Oracle.com Thu Aug 11 14:40:46 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 11 Aug 2016 10:40:46 -0400 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <39122c20-d65a-a8a5-9bff-39d770b5dc5b@Oracle.com> Vote: Yes On 8/10/2016 4:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. From henry.jen at oracle.com Thu Aug 11 14:51:03 2016 From: henry.jen at oracle.com (Henry Jen) Date: Thu, 11 Aug 2016 07:51:03 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <39122c20-d65a-a8a5-9bff-39d770b5dc5b@Oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> <39122c20-d65a-a8a5-9bff-39d770b5dc5b@Oracle.com> Message-ID: Vote: Yes Cheers, Henry On 8/10/2016 4:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. From xueming.shen at oracle.com Thu Aug 11 15:25:16 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 11 Aug 2016 08:25:16 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <878f552a-7687-7063-6937-71109ba22a7d@oracle.com> Vote: Yes On 8/10/16 1:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From aleksey.shipilev at gmail.com Thu Aug 11 15:45:25 2016 From: aleksey.shipilev at gmail.com (Aleksey Shipilev) Date: Thu, 11 Aug 2016 18:45:25 +0300 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: Vote: yes. -Aleksey On 08/10/2016 11:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. From Sergey.Bylokhov at oracle.com Fri Aug 12 12:29:13 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Fri, 12 Aug 2016 15:29:13 +0300 Subject: Result: New JDK 9 Committer: Ajit Ghaisas Message-ID: <47e65062-ca41-9c37-5bfd-7324c68569af@oracle.com> Voting for Ajit Ghaisas [1] is now closed. Yes: 15 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Sergey Bylokhov [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-July/004554.html -- Best regards, Sergey. From mandy.chung at oracle.com Fri Aug 12 15:35:35 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 12 Aug 2016 08:35:35 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: Vote: yes Mandy From k.s.shefov at gmail.com Fri Aug 12 15:42:31 2016 From: k.s.shefov at gmail.com (Konstantin Shefov) Date: Fri, 12 Aug 2016 18:42:31 +0300 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: Vote: yes 2016-08-10 23:52 GMT+03:00 Paul Sandoz : > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation > and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this mailing > list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount= > 2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com% > 22)%20or%20user(%22sdrach%22) jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed- > by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22)> > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(% > 22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) < > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(% > 22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22)> > > [2] http://openjdk.java.net/census#jdk9 census#jdk9> > [3] |http://openjdk.java.net/projects/#committer-vote < > http://openjdk.java.net/projects/#committer-vote> > > -- Yours sincerely, Konstantin Shefov From tobias.hartmann at oracle.com Mon Aug 15 05:06:02 2016 From: tobias.hartmann at oracle.com (Tobias Hartmann) Date: Mon, 15 Aug 2016 07:06:02 +0200 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <57B14DBA.9010503@oracle.com> Vote: yes Best regards, Tobias On 10.08.2016 15:45, Zolt?n Maj? wrote: > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 Committer. > > Doug is a member of Oracle Labs and has been working on Java-related technologies for the past 15+ years. He is an Author in the JDK 9 Project and has contributed more than 35 changesets to JDK 9 (most of them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From christian.tornqvist at oracle.com Mon Aug 15 15:42:02 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Mon, 15 Aug 2016 11:42:02 -0400 Subject: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder In-Reply-To: <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> References: <227601d1f4ae$c6b3bd10$541b3730$@oracle.com> <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> Message-ID: <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> Hi David, >Do the jtreg authors agree with that rule? I'm happy to have such a simple rule as long as it is agreed upon by all. We've had some discussions about this, Jonathan says that explicit @build is needed to support running with cached classes in jtwork and modifying the classes in the @library path. This isn't something that is a very common case in Hotspot and is avoidable by using a clean jtwork dir when modifying these shared classes. Think of it this way, when you run javac on your program Main.java that use the class A, you don't have to explicitly run javac on A.java first, this is the way the javac works and there's nothing different with jtreg here. >Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >They seem general-purpose to me even if mosts tests don't need to care. >So they seem suitable inclusions into the Platform class to me. No, I was mostly talking about: test/testlibrary/jdk/test/lib/dtrace/* test/testlibrary/jdk/test/lib/AllocationHelper.java test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java test/testlibrary/jdk/test/lib/InputArguments.java I can put back the jdkLibPath and sharedObjectName code if we believe that this is something than more than one test will need. I think we should be careful about putting unnecessary code in the shared classes. >why is / listed as a library ?? This is the compiler team's decision to use package name in their tests and use / as the @library path, can't say I agree with it. >Just to be crystal clear, did you also run all the @ignore'd tests? No, that was on my list of things to do, which I forgot. Just ran it and found issues with 2 of them that I corrected: * Missing imports of Platform and JDKToolFinder in runtime/NMT/MallocStressTest.java * Extra "}" in serviceability/dcmd/jvmti/LoadAgentDcmdTest.java Thanks, Christian -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Monday, August 15, 2016 12:58 AM To: Christian Tornqvist ; hotspot-dev at openjdk.java.net Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder Hi Christian, First, thanks for attempting this, it is a huge effort! Second, as this is changing the /test/lib files then it needs to be reviewed by more than just the hotspot group. I won't claim to have examined every file in detail - there is a lot that has to be taken on face-value here. I have skimmed the webrevs and patch files. A few comments in-lined below ... On 13/08/2016 1:32 AM, Christian Tornqvist wrote: > Hi everyone, > > Please review this fix for the CNFE issue we've had in the Hotspot > jtreg tests. The two big culprits for the intermittent CNFE are: > Duplicate classes on classpath with different content and @build tags > causing class files to be written in bad places. > > There has been a lot of confusion around when there's a need to add > @build to a test. In general it turns out it has been overused, which > can lead to side effects. Here's an easy rule: > > If you run only that test in a clean jtwork folder and it passes, then > there's no need for @build. Do the jtreg authors agree with that rule? I'm happy to have such a simple rule as long as it is agreed upon by all. > If it doesn't pass, then it might need an explicit @build, here are > some examples when it might be needed: > > * If the class is used by ClassFileInstaller and this is invoked by > @run main ClassFileInstaller (sun.hotspot.Whitebox is an example of > this) > > * If it's a class that that doesn't have reference from the Test > itself (if "javac Test" wouldn't compile it, you might need to > explicitly @build it) > > The change includes: > > * Removing all unnecessary @build tags, some of the CNFE was due to > use of it to compile classes in /test/lib or /testlibrary when having > different classpath (@library) set. > > * Changed @build to @build sun.hotspot.Whitebox > > * Moved /test/lib/share/classes/jdk/test/lib to /test/lib/jdk/test/lib > > * Some of the classes in /hotspot/test/testlibrary was only used by > one or two tests, these classes shouldn't be part of the shared > testlibrary code and they were moved to the location of the test Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? They seem general-purpose to me even if mosts tests don't need to care. So they seem suitable inclusions into the Platform class to me. > > * Merged/moved the classes in /hotspot/test/testlibrary to /test/lib > > * Moved some of the /test/lib classes into packages > > * Changed @library /testlibrary to @library /test/lib Related to that I see a number of entries like: - * @library /testlibrary /test/lib / + * @library /test/lib / this is not part of your change by why is / listed as a library ?? > * Changed imports from jdk.test.lib.* to explicit imports to help in > future refactoring > > Almost all of the changes in here are in the jtreg @build and @library > tags, very little code has been touched. Copyright headers will be > updated before push. > > Testing done: Ran the entire hotspot/test/ folder multiple times > locally and in RBT Just to be crystal clear, did you also run all the @ignore'd tests? > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8157957/webrev.00/ The jdk/test/* changes only seem to be for the @library changes in the path, I don't see any changes to @build tags. Is that because all the @builds are necessary or are you simply not taking on the task of also updating the jdk tests? > A recently added test required me to fix that as well, generating and > uploading a new webrev of the Hotspot repo changes takes about 3h > though, so here's the diff for that file: > > diff -r f37577c20a6b test/serviceability/sa/sadebugd/SADebugDTest.java > > --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Wed Aug 10 > 21:02:14 > 2016 -0400 > > +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Fri Aug 12 > +++ 11:25:54 > 2016 -0400 > > @@ -26,7 +26,7 @@ > > * @summary Checks that the jshdb debugd utility sucessfully starts > * and tries to attach to a running process > * @modules java.base/jdk.internal.misc > > - * @library /test/lib/share/classes > + * @library /test/lib > * > * @run main/othervm SADebugDTest > */ Looks fine. Thanks, David ----- > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8157957 > > Thanks, > > Christian > > > > > From igor.veresov at oracle.com Mon Aug 15 22:49:42 2016 From: igor.veresov at oracle.com (Igor Veresov) Date: Mon, 15 Aug 2016 15:49:42 -0700 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <846F3A7F-3916-4966-AE10-D291B3157FDF@oracle.com> Vote: yes igor > On Aug 10, 2016, at 6:45 AM, Zolt?n Maj? wrote: > > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 Committer. > > Doug is a member of Oracle Labs and has been working on Java-related technologies for the past 15+ years. He is an Author in the JDK 9 Project and has contributed more than 35 changesets to JDK 9 (most of them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From david.holmes at oracle.com Mon Aug 15 23:11:03 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 16 Aug 2016 09:11:03 +1000 Subject: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder In-Reply-To: <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> References: <227601d1f4ae$c6b3bd10$541b3730$@oracle.com> <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> Message-ID: <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> Hi Christian, Thanks for bring a broader audience into this. For reference to others the thread started with: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198.html On 16/08/2016 1:42 AM, Christian Tornqvist wrote: > Hi David, > >> Do the jtreg authors agree with that rule? I'm happy to have such a simple > rule as long as it is agreed upon by all. > We've had some discussions about this, Jonathan says that explicit @build is > needed to support running with cached classes in jtwork and modifying the > classes in the @library path. This isn't something that is a very common > case in Hotspot and is avoidable by using a clean jtwork dir when modifying > these shared classes. > > Think of it this way, when you run javac on your program Main.java that use > the class A, you don't have to explicitly run javac on A.java first, this is > the way the javac works and there's nothing different with jtreg here. It is a bit more complicated than that with libraries on different sourcepaths, but I don't know the intricacies of javac's implicit compilation checks. There are some obvious cases where reflection means there is no compile-time dependency between classes, but I don't know if we utilize anything of that nature in the test library (arguably we should in places to ensure the library can function on compact profiles and with the minimal VM - but that is a different problem). I remain very wary of this approach because I know we had to add @build to fix some missing library class problems. >> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >> They seem general-purpose to me even if mosts tests don't need to care. >> So they seem suitable inclusions into the Platform class to me. > > No, I was mostly talking about: Ah! I missed the significance of the renames ... > test/testlibrary/jdk/test/lib/dtrace/* Could be generally useful if all our dtrace tests were located together, but as they are not ... > test/testlibrary/jdk/test/lib/AllocationHelper.java Potentially useful. We have a lot of tests that try to consume/exhaust memory, but whether they are amenable to conversion to use this utility is another matter. > test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java Potentially useful. > test/testlibrary/jdk/test/lib/InputArguments.java This seems particularly useful, but also seems to have some overlap with existing argument processing code. > I can put back the jdkLibPath and sharedObjectName code if we believe that > this is something than more than one test will need. I think we should be > careful about putting unnecessary code in the shared classes. I don't have an issue with putting any kind of utility code (like the above examples) into the shared test library if there is potential for sharing. While retrofitting existing tests to use these things and remove duplication would be a lot of effort, at least if they exist in the library someone writing new tests and browsing the library won't be tempted to re-invent the wheel. So I'd vote for not changing these. >> why is / listed as a library ?? > > This is the compiler team's decision to use package name in their tests and > use / as the @library path, can't say I agree with it. Not sure I even understand what it means! >> Just to be crystal clear, did you also run all the @ignore'd tests? > > No, that was on my list of things to do, which I forgot. Just ran it and > found issues with 2 of them that I corrected: > > * Missing imports of Platform and JDKToolFinder in > runtime/NMT/MallocStressTest.java > * Extra "}" in serviceability/dcmd/jvmti/LoadAgentDcmdTest.java Ok. You overlooked answering my query about the JDK test changes. Thanks, David > Thanks, > Christian > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Monday, August 15, 2016 12:58 AM > To: Christian Tornqvist ; > hotspot-dev at openjdk.java.net > Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: > jdk.test.lib.JDKToolFinder > > Hi Christian, > > First, thanks for attempting this, it is a huge effort! > > Second, as this is changing the /test/lib files then it needs to be > reviewed by more than just the hotspot group. > > I won't claim to have examined every file in detail - there is a lot that > has to be taken on face-value here. I have skimmed the webrevs and patch > files. > > A few comments in-lined below ... > > On 13/08/2016 1:32 AM, Christian Tornqvist wrote: >> Hi everyone, >> >> Please review this fix for the CNFE issue we've had in the Hotspot >> jtreg tests. The two big culprits for the intermittent CNFE are: >> Duplicate classes on classpath with different content and @build tags >> causing class files to be written in bad places. >> >> There has been a lot of confusion around when there's a need to add >> @build to a test. In general it turns out it has been overused, which >> can lead to side effects. Here's an easy rule: >> >> If you run only that test in a clean jtwork folder and it passes, then >> there's no need for @build. > > Do the jtreg authors agree with that rule? I'm happy to have such a simple > rule as long as it is agreed upon by all. > >> If it doesn't pass, then it might need an explicit @build, here are >> some examples when it might be needed: >> >> * If the class is used by ClassFileInstaller and this is invoked by >> @run main ClassFileInstaller (sun.hotspot.Whitebox is an example of >> this) >> >> * If it's a class that that doesn't have reference from the Test >> itself (if "javac Test" wouldn't compile it, you might need to >> explicitly @build it) >> >> The change includes: >> >> * Removing all unnecessary @build tags, some of the CNFE was due to >> use of it to compile classes in /test/lib or /testlibrary when having >> different classpath (@library) set. >> >> * Changed @build to @build sun.hotspot.Whitebox >> >> * Moved /test/lib/share/classes/jdk/test/lib to /test/lib/jdk/test/lib >> >> * Some of the classes in /hotspot/test/testlibrary was only used by >> one or two tests, these classes shouldn't be part of the shared >> testlibrary code and they were moved to the location of the test > > Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? > > They seem general-purpose to me even if mosts tests don't need to care. > So they seem suitable inclusions into the Platform class to me. > >> >> * Merged/moved the classes in /hotspot/test/testlibrary to /test/lib >> >> * Moved some of the /test/lib classes into packages >> >> * Changed @library /testlibrary to @library /test/lib > > Related to that I see a number of entries like: > > - * @library /testlibrary /test/lib / > + * @library /test/lib / > > this is not part of your change by why is / listed as a library ?? > >> * Changed imports from jdk.test.lib.* to explicit imports to help in >> future refactoring >> >> Almost all of the changes in here are in the jtreg @build and @library >> tags, very little code has been touched. Copyright headers will be >> updated before push. >> >> Testing done: Ran the entire hotspot/test/ folder multiple times >> locally and in RBT > > Just to be crystal clear, did you also run all the @ignore'd tests? > >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8157957/webrev.00/ > > The jdk/test/* changes only seem to be for the @library changes in the path, > I don't see any changes to @build tags. Is that because all the @builds are > necessary or are you simply not taking on the task of also updating the jdk > tests? > >> A recently added test required me to fix that as well, generating and >> uploading a new webrev of the Hotspot repo changes takes about 3h >> though, so here's the diff for that file: >> >> diff -r f37577c20a6b test/serviceability/sa/sadebugd/SADebugDTest.java >> >> --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Wed Aug 10 >> 21:02:14 >> 2016 -0400 >> >> +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Fri Aug 12 >> +++ 11:25:54 >> 2016 -0400 >> >> @@ -26,7 +26,7 @@ >> >> * @summary Checks that the jshdb debugd utility sucessfully starts >> * and tries to attach to a running process >> * @modules java.base/jdk.internal.misc >> >> - * @library /test/lib/share/classes >> + * @library /test/lib >> * >> * @run main/othervm SADebugDTest >> */ > > Looks fine. > > Thanks, > David > ----- > >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8157957 >> >> Thanks, >> >> Christian >> >> >> >> >> > From alexandre.iline at oracle.com Mon Aug 15 18:39:42 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Mon, 15 Aug 2016 11:39:42 -0700 Subject: RFR: 8164052 Fix legal notices in JDK tests Message-ID: Hi, Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. Shura From xuelei.fan at oracle.com Mon Aug 15 23:57:26 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 16 Aug 2016 07:57:26 +0800 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: References: Message-ID: <75b34d1c-de47-e43c-47e3-f80258e268e0@oracle.com> CC security-dev. The security part looks fine to me. Thanks, Xuelei On 8/16/2016 2:39 AM, Alexandre (Shura) Iline wrote: > Hi, > > Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. > > http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > > I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. > > Shura > From joe.darcy at oracle.com Tue Aug 16 00:14:11 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 15 Aug 2016 17:14:11 -0700 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: References: Message-ID: <57B25AD3.9000104@oracle.com> The lang, net, and util changes looks fine; cheers, -Joe On 8/15/2016 11:39 AM, Alexandre (Shura) Iline wrote: > Hi, > > Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. > > http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > > I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. > > Shura > From igor.ignatyev at oracle.com Tue Aug 16 11:04:32 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Tue, 16 Aug 2016 14:04:32 +0300 Subject: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder In-Reply-To: <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> References: <227601d1f4ae$c6b3bd10$541b3730$@oracle.com> <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> Message-ID: <73BBDB9A-83C8-4826-AA65-16F375593D00@oracle.com> Christian/David, > Ah! I missed the significance of the renames ... > >> test/testlibrary/jdk/test/lib/dtrace/* > > Could be generally useful if all our dtrace tests were located together, but as they are not ? dtrace testlibrary was created and put in common testlibrary directory exactly in order to help porting our existing dtrace tests, having it ?hidden" in hotspot/test/compiler/codecache/dtrace can lead us to reimplementing the same functionality. that is to say I think we should have it in root/testlibrary. Thanks, ? Igor > On Aug 16, 2016, at 2:11 AM, David Holmes wrote: > > Hi Christian, > > Thanks for bring a broader audience into this. For reference to others the thread started with: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198.html > > On 16/08/2016 1:42 AM, Christian Tornqvist wrote: >> Hi David, >> >>> Do the jtreg authors agree with that rule? I'm happy to have such a simple >> rule as long as it is agreed upon by all. >> We've had some discussions about this, Jonathan says that explicit @build is >> needed to support running with cached classes in jtwork and modifying the >> classes in the @library path. This isn't something that is a very common >> case in Hotspot and is avoidable by using a clean jtwork dir when modifying >> these shared classes. >> >> Think of it this way, when you run javac on your program Main.java that use >> the class A, you don't have to explicitly run javac on A.java first, this is >> the way the javac works and there's nothing different with jtreg here. > > It is a bit more complicated than that with libraries on different sourcepaths, but I don't know the intricacies of javac's implicit compilation checks. There are some obvious cases where reflection means there is no compile-time dependency between classes, but I don't know if we utilize anything of that nature in the test library (arguably we should in places to ensure the library can function on compact profiles and with the minimal VM - but that is a different problem). > > I remain very wary of this approach because I know we had to add @build to fix some missing library class problems. > >>> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >>> They seem general-purpose to me even if mosts tests don't need to care. >>> So they seem suitable inclusions into the Platform class to me. >> >> No, I was mostly talking about: > > Ah! I missed the significance of the renames ... > >> test/testlibrary/jdk/test/lib/dtrace/* > > Could be generally useful if all our dtrace tests were located together, but as they are not ... > >> test/testlibrary/jdk/test/lib/AllocationHelper.java > > Potentially useful. We have a lot of tests that try to consume/exhaust memory, but whether they are amenable to conversion to use this utility is another matter. > >> test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java > > Potentially useful. > >> test/testlibrary/jdk/test/lib/InputArguments.java > > This seems particularly useful, but also seems to have some overlap with existing argument processing code. > >> I can put back the jdkLibPath and sharedObjectName code if we believe that >> this is something than more than one test will need. I think we should be >> careful about putting unnecessary code in the shared classes. > > I don't have an issue with putting any kind of utility code (like the above examples) into the shared test library if there is potential for sharing. While retrofitting existing tests to use these things and remove duplication would be a lot of effort, at least if they exist in the library someone writing new tests and browsing the library won't be tempted to re-invent the wheel. > > So I'd vote for not changing these. > >>> why is / listed as a library ?? >> >> This is the compiler team's decision to use package name in their tests and >> use / as the @library path, can't say I agree with it. > > Not sure I even understand what it means! > >>> Just to be crystal clear, did you also run all the @ignore'd tests? >> >> No, that was on my list of things to do, which I forgot. Just ran it and >> found issues with 2 of them that I corrected: >> >> * Missing imports of Platform and JDKToolFinder in >> runtime/NMT/MallocStressTest.java >> * Extra "}" in serviceability/dcmd/jvmti/LoadAgentDcmdTest.java > > Ok. > > You overlooked answering my query about the JDK test changes. > > Thanks, > David > >> Thanks, >> Christian >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Monday, August 15, 2016 12:58 AM >> To: Christian Tornqvist ; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: >> jdk.test.lib.JDKToolFinder >> >> Hi Christian, >> >> First, thanks for attempting this, it is a huge effort! >> >> Second, as this is changing the /test/lib files then it needs to be >> reviewed by more than just the hotspot group. >> >> I won't claim to have examined every file in detail - there is a lot that >> has to be taken on face-value here. I have skimmed the webrevs and patch >> files. >> >> A few comments in-lined below ... >> >> On 13/08/2016 1:32 AM, Christian Tornqvist wrote: >>> Hi everyone, >>> >>> Please review this fix for the CNFE issue we've had in the Hotspot >>> jtreg tests. The two big culprits for the intermittent CNFE are: >>> Duplicate classes on classpath with different content and @build tags >>> causing class files to be written in bad places. >>> >>> There has been a lot of confusion around when there's a need to add >>> @build to a test. In general it turns out it has been overused, which >>> can lead to side effects. Here's an easy rule: >>> >>> If you run only that test in a clean jtwork folder and it passes, then >>> there's no need for @build. >> >> Do the jtreg authors agree with that rule? I'm happy to have such a simple >> rule as long as it is agreed upon by all. >> >>> If it doesn't pass, then it might need an explicit @build, here are >>> some examples when it might be needed: >>> >>> * If the class is used by ClassFileInstaller and this is invoked by >>> @run main ClassFileInstaller (sun.hotspot.Whitebox is an example of >>> this) >>> >>> * If it's a class that that doesn't have reference from the Test >>> itself (if "javac Test" wouldn't compile it, you might need to >>> explicitly @build it) >>> >>> The change includes: >>> >>> * Removing all unnecessary @build tags, some of the CNFE was due to >>> use of it to compile classes in /test/lib or /testlibrary when having >>> different classpath (@library) set. >>> >>> * Changed @build to @build sun.hotspot.Whitebox >>> >>> * Moved /test/lib/share/classes/jdk/test/lib to /test/lib/jdk/test/lib >>> >>> * Some of the classes in /hotspot/test/testlibrary was only used by >>> one or two tests, these classes shouldn't be part of the shared >>> testlibrary code and they were moved to the location of the test >> >> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >> >> They seem general-purpose to me even if mosts tests don't need to care. >> So they seem suitable inclusions into the Platform class to me. >> >>> >>> * Merged/moved the classes in /hotspot/test/testlibrary to /test/lib >>> >>> * Moved some of the /test/lib classes into packages >>> >>> * Changed @library /testlibrary to @library /test/lib >> >> Related to that I see a number of entries like: >> >> - * @library /testlibrary /test/lib / >> + * @library /test/lib / >> >> this is not part of your change by why is / listed as a library ?? >> >>> * Changed imports from jdk.test.lib.* to explicit imports to help in >>> future refactoring >>> >>> Almost all of the changes in here are in the jtreg @build and @library >>> tags, very little code has been touched. Copyright headers will be >>> updated before push. >>> >>> Testing done: Ran the entire hotspot/test/ folder multiple times >>> locally and in RBT >> >> Just to be crystal clear, did you also run all the @ignore'd tests? >> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8157957/webrev.00/ >> >> The jdk/test/* changes only seem to be for the @library changes in the path, >> I don't see any changes to @build tags. Is that because all the @builds are >> necessary or are you simply not taking on the task of also updating the jdk >> tests? >> >>> A recently added test required me to fix that as well, generating and >>> uploading a new webrev of the Hotspot repo changes takes about 3h >>> though, so here's the diff for that file: >>> >>> diff -r f37577c20a6b test/serviceability/sa/sadebugd/SADebugDTest.java >>> >>> --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Wed Aug 10 >>> 21:02:14 >>> 2016 -0400 >>> >>> +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Fri Aug 12 >>> +++ 11:25:54 >>> 2016 -0400 >>> >>> @@ -26,7 +26,7 @@ >>> >>> * @summary Checks that the jshdb debugd utility sucessfully starts >>> * and tries to attach to a running process >>> * @modules java.base/jdk.internal.misc >>> >>> - * @library /test/lib/share/classes >>> + * @library /test/lib >>> * >>> * @run main/othervm SADebugDTest >>> */ >> >> Looks fine. >> >> Thanks, >> David >> ----- >> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157957 >>> >>> Thanks, >>> >>> Christian >>> >>> >>> >>> >>> >> From Sergey.Bylokhov at oracle.com Tue Aug 16 12:38:57 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Aug 2016 15:38:57 +0300 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: References: Message-ID: <5ce5ba22-44d7-0acb-c0d3-04ca614500ac@oracle.com> The are some issues when 2016 was replaced to "2016, 2016" for example: test/java/awt/Focus/Cause/FocusCauseTest.java On 15.08.16 21:39, Alexandre (Shura) Iline wrote: > Hi, > > Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. > > http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > > I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. > > Shura > -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Tue Aug 16 14:11:18 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Tue, 16 Aug 2016 17:11:18 +0300 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: <959D78E3-AEC2-4BF9-BA5E-A1CABB926D03@oracle.com> References: <5ce5ba22-44d7-0acb-c0d3-04ca614500ac@oracle.com> <959D78E3-AEC2-4BF9-BA5E-A1CABB926D03@oracle.com> Message-ID: <2087cfcc-f234-b426-5092-42abbe36cb48@oracle.com> On 16.08.16 17:00, Alexandre (Shura) Iline wrote: > >> On Aug 16, 2016, at 5:38 AM, Sergey Bylokhov wrote: >> >> The are some issues when 2016 was replaced to "2016, 2016" for example: >> test/java/awt/Focus/Cause/FocusCauseTest.java > > In this file, originally incorrect ?2016, 2016,? is replaced by correct ?2016,? - this is a proper fix IMO. Are you suggesting that the same year could repeat twice? If it should be the one year then looks fine. This year was changed recently from 2016->2016,2016 in JDK-8159690, it seems it was a typo. >> >> On 15.08.16 21:39, Alexandre (Shura) Iline wrote: >>> Hi, >>> >>> Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. >>> >>> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ >>> >>> I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. >>> >>> Shura >>> >> >> >> -- >> Best regards, Sergey. > -- Best regards, Sergey. From alexandre.iline at oracle.com Tue Aug 16 14:00:41 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 16 Aug 2016 07:00:41 -0700 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: <5ce5ba22-44d7-0acb-c0d3-04ca614500ac@oracle.com> References: <5ce5ba22-44d7-0acb-c0d3-04ca614500ac@oracle.com> Message-ID: <959D78E3-AEC2-4BF9-BA5E-A1CABB926D03@oracle.com> > On Aug 16, 2016, at 5:38 AM, Sergey Bylokhov wrote: > > The are some issues when 2016 was replaced to "2016, 2016" for example: > test/java/awt/Focus/Cause/FocusCauseTest.java In this file, originally incorrect ?2016, 2016,? is replaced by correct ?2016,? - this is a proper fix IMO. Are you suggesting that the same year could repeat twice? http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/test/java/awt/Focus/Cause/FocusCauseTest.java.sdiff.html What are other issues? Shura > > On 15.08.16 21:39, Alexandre (Shura) Iline wrote: >> Hi, >> >> Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. >> >> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ >> >> I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. >> >> Shura >> > > > -- > Best regards, Sergey. From alexandre.iline at oracle.com Tue Aug 16 14:13:47 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 16 Aug 2016 07:13:47 -0700 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: <2087cfcc-f234-b426-5092-42abbe36cb48@oracle.com> References: <5ce5ba22-44d7-0acb-c0d3-04ca614500ac@oracle.com> <959D78E3-AEC2-4BF9-BA5E-A1CABB926D03@oracle.com> <2087cfcc-f234-b426-5092-42abbe36cb48@oracle.com> Message-ID: <6F72C440-9F71-4B84-9600-34F7D82BA8CA@oracle.com> > On Aug 16, 2016, at 7:11 AM, Sergey Bylokhov wrote: > > On 16.08.16 17:00, Alexandre (Shura) Iline wrote: >> >>> On Aug 16, 2016, at 5:38 AM, Sergey Bylokhov wrote: >>> >>> The are some issues when 2016 was replaced to "2016, 2016" for example: >>> test/java/awt/Focus/Cause/FocusCauseTest.java >> >> In this file, originally incorrect ?2016, 2016,? is replaced by correct ?2016,? - this is a proper fix IMO. Are you suggesting that the same year could repeat twice? > > If it should be the one year then looks fine. > This year was changed recently from 2016->2016,2016 in JDK-8159690, it seems it was a typo. Just to close this, you said there are ?some? issues. Are there others besides this file which do not look right? Shura > >>> >>> On 15.08.16 21:39, Alexandre (Shura) Iline wrote: >>>> Hi, >>>> >>>> Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. >>>> >>>> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ >>>> >>>> I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. >>>> >>>> Shura >>>> >>> >>> >>> -- >>> Best regards, Sergey. >> > > > -- > Best regards, Sergey. From iris.clark at oracle.com Tue Aug 16 16:43:45 2016 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 16 Aug 2016 09:43:45 -0700 (PDT) Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: References: Message-ID: Hi, Shura. > http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ I did a quick review of the .patch file. The changes in test/java/net/httpclient/security/Driver.java and friends are interesting. I can't say that I've ever seen that particular failure, though there are many variants. test/sun/security/provider/SecureRandom/StrongSeedReader.java, line 24: This change is puzzling. If I'm understanding the spacing correctly, a space has been added at the beginning of the line throwing off the comment alignment. Everything else looks reasonable/expected. Thanks, iris -----Original Message----- From: Alexandre (Shura) Iline Sent: Monday, August 15, 2016 11:40 AM To: jdk9-dev at openjdk.java.net Subject: RFR: 8164052 Fix legal notices in JDK tests Hi, Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. Shura From alexandre.iline at oracle.com Tue Aug 16 17:08:23 2016 From: alexandre.iline at oracle.com (Alexandre (Shura) Iline) Date: Tue, 16 Aug 2016 10:08:23 -0700 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: References: Message-ID: <22032B75-98C3-4988-B945-09C4B8D8FFD3@oracle.com> > On Aug 16, 2016, at 9:43 AM, Iris Clark wrote: > > Hi, Shura. > >> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > > I did a quick review of the .patch file. > > The changes in test/java/net/httpclient/security/Driver.java and friends are > interesting. I see "or have any? changed to "or have any questions?. This is the correct fix, right? > I can't say that I've ever seen that particular failure, though > there are many variants. > > test/sun/security/provider/SecureRandom/StrongSeedReader.java, line 24: This > change is puzzling. If I'm understanding the spacing correctly, a space > has been added at the beginning of the line throwing off the comment > alignment. Yes, that is strange. Shura > > Everything else looks reasonable/expected. > > Thanks, > iris > > -----Original Message----- > From: Alexandre (Shura) Iline > Sent: Monday, August 15, 2016 11:40 AM > To: jdk9-dev at openjdk.java.net > Subject: RFR: 8164052 Fix legal notices in JDK tests > > Hi, > > Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. > > http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > > I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. > > Shura > From jonathan.gibbons at oracle.com Tue Aug 16 17:09:20 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Tue, 16 Aug 2016 10:09:20 -0700 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: References: Message-ID: <57B348C0.5040402@oracle.com> In StrongSeedReader, you don't need, and stylististically should not, use "/**" for jtreg test description comments. -- Jon On 08/16/2016 09:43 AM, Iris Clark wrote: > Hi, Shura. > >> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > I did a quick review of the .patch file. > > The changes in test/java/net/httpclient/security/Driver.java and friends are > interesting. I can't say that I've ever seen that particular failure, though > there are many variants. > > test/sun/security/provider/SecureRandom/StrongSeedReader.java, line 24: This > change is puzzling. If I'm understanding the spacing correctly, a space > has been added at the beginning of the line throwing off the comment > alignment. > > Everything else looks reasonable/expected. > > Thanks, > iris > > -----Original Message----- > From: Alexandre (Shura) Iline > Sent: Monday, August 15, 2016 11:40 AM > To: jdk9-dev at openjdk.java.net > Subject: RFR: 8164052 Fix legal notices in JDK tests > > Hi, > > Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. > > http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > > I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. > > Shura > From iris.clark at oracle.com Tue Aug 16 17:10:24 2016 From: iris.clark at oracle.com (Iris Clark) Date: Tue, 16 Aug 2016 10:10:24 -0700 (PDT) Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: <22032B75-98C3-4988-B945-09C4B8D8FFD3@oracle.com> References: <22032B75-98C3-4988-B945-09C4B8D8FFD3@oracle.com> Message-ID: >>> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ >> The changes in test/java/net/httpclient/security/Driver.java and >> friends are interesting. > > I see "or have any? changed to "or have any questions?. > > This is the correct fix, right? Yes. Thanks, Iris From vassili.igouchkine at oracle.com Tue Aug 16 17:23:07 2016 From: vassili.igouchkine at oracle.com (Vassili Igouchkine) Date: Tue, 16 Aug 2016 10:23:07 -0700 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: <5ce5ba22-44d7-0acb-c0d3-04ca614500ac@oracle.com> References: <5ce5ba22-44d7-0acb-c0d3-04ca614500ac@oracle.com> Message-ID: <57B34BFB.2040302@oracle.com> Hi Sergey, It is "2016, 2016" replaced with "2016" here - http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/test/java/awt/Focus/Cause/FocusCauseTest.java.patch What are other issues? Regards, Vassili. On 8/16/16, 5:38 AM, Sergey Bylokhov wrote: > The are some issues when 2016 was replaced to "2016, 2016" for example: > test/java/awt/Focus/Cause/FocusCauseTest.java > > On 15.08.16 21:39, Alexandre (Shura) Iline wrote: >> Hi, >> >> Please review this bulk update of JDK test sources which is fixing >> legal notices formatting and content. >> >> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ >> >> I am sending this to the jdk9-dev at openjdk.java.net hoping that would >> be enough. Otherwise I would send the request to multiple aliases >> which have tests in idk repository. >> >> Shura >> > > From vassili.igouchkine at oracle.com Tue Aug 16 18:54:46 2016 From: vassili.igouchkine at oracle.com (Vassili Igouchkine) Date: Tue, 16 Aug 2016 11:54:46 -0700 Subject: RFR: 8164052 Fix legal notices in JDK tests In-Reply-To: References: Message-ID: <57B36176.4040108@oracle.com> On 8/16/16, 9:43 AM, Iris Clark wrote: > Hi, Shura. > >> http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > I did a quick review of the .patch file. > > The changes in test/java/net/httpclient/security/Driver.java and friends are > interesting. I can't say that I've ever seen that particular failure, though > there are many variants. > > test/sun/security/provider/SecureRandom/StrongSeedReader.java, line 24: This > change is puzzling. If I'm understanding the spacing correctly, a space > has been added at the beginning of the line throwing off the comment > alignment. This space was moved from in front of legal notice comment to behind it. This is done for cases when there is "package ..." or "import ..." etc... It does not recognize that this is just a space, I am working on fix for that. Thanks for finding this! Regards, Vassili. > > Everything else looks reasonable/expected. > > Thanks, > iris > > -----Original Message----- > From: Alexandre (Shura) Iline > Sent: Monday, August 15, 2016 11:40 AM > To: jdk9-dev at openjdk.java.net > Subject: RFR: 8164052 Fix legal notices in JDK tests > > Hi, > > Please review this bulk update of JDK test sources which is fixing legal notices formatting and content. > > http://cr.openjdk.java.net/~shurailine/8164052/webrev_00/ > > I am sending this to the jdk9-dev at openjdk.java.net hoping that would be enough. Otherwise I would send the request to multiple aliases which have tests in idk repository. > > Shura > From christian.tornqvist at oracle.com Tue Aug 16 20:50:40 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 16 Aug 2016 16:50:40 -0400 Subject: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder In-Reply-To: <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> References: <227601d1f4ae$c6b3bd10$541b3730$@oracle.com> <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> Message-ID: <31c001d1f7ff$d9bdf0c0$8d39d240$@oracle.com> Hi David, > The jdk/test/* changes only seem to be for the @library changes in the > path, I don't see any changes to @build tags. Is that because all the > @builds are necessary or are you simply not taking on the task of also > updating the jdk tests? The JDK part will have to be done as a separate change, as Dmitry pointed out, there's another copy of the test library code in /jdk/test/lib/testlibrary that should be merged down to /test/lib and the @build's should be cleaned up as well. Thanks, Christian -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Monday, August 15, 2016 7:11 PM To: Christian Tornqvist ; hotspot-dev at openjdk.java.net; jdk9-dev at openjdk.java.net Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder Hi Christian, Thanks for bring a broader audience into this. For reference to others the thread started with: http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198.html On 16/08/2016 1:42 AM, Christian Tornqvist wrote: > Hi David, > >> Do the jtreg authors agree with that rule? I'm happy to have such a >> simple > rule as long as it is agreed upon by all. > We've had some discussions about this, Jonathan says that explicit > @build is needed to support running with cached classes in jtwork and > modifying the classes in the @library path. This isn't something that > is a very common case in Hotspot and is avoidable by using a clean > jtwork dir when modifying these shared classes. > > Think of it this way, when you run javac on your program Main.java > that use the class A, you don't have to explicitly run javac on A.java > first, this is the way the javac works and there's nothing different with jtreg here. It is a bit more complicated than that with libraries on different sourcepaths, but I don't know the intricacies of javac's implicit compilation checks. There are some obvious cases where reflection means there is no compile-time dependency between classes, but I don't know if we utilize anything of that nature in the test library (arguably we should in places to ensure the library can function on compact profiles and with the minimal VM - but that is a different problem). I remain very wary of this approach because I know we had to add @build to fix some missing library class problems. >> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >> They seem general-purpose to me even if mosts tests don't need to care. >> So they seem suitable inclusions into the Platform class to me. > > No, I was mostly talking about: Ah! I missed the significance of the renames ... > test/testlibrary/jdk/test/lib/dtrace/* Could be generally useful if all our dtrace tests were located together, but as they are not ... > test/testlibrary/jdk/test/lib/AllocationHelper.java Potentially useful. We have a lot of tests that try to consume/exhaust memory, but whether they are amenable to conversion to use this utility is another matter. > test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java Potentially useful. > test/testlibrary/jdk/test/lib/InputArguments.java This seems particularly useful, but also seems to have some overlap with existing argument processing code. > I can put back the jdkLibPath and sharedObjectName code if we believe > that this is something than more than one test will need. I think we > should be careful about putting unnecessary code in the shared classes. I don't have an issue with putting any kind of utility code (like the above examples) into the shared test library if there is potential for sharing. While retrofitting existing tests to use these things and remove duplication would be a lot of effort, at least if they exist in the library someone writing new tests and browsing the library won't be tempted to re-invent the wheel. So I'd vote for not changing these. >> why is / listed as a library ?? > > This is the compiler team's decision to use package name in their > tests and use / as the @library path, can't say I agree with it. Not sure I even understand what it means! >> Just to be crystal clear, did you also run all the @ignore'd tests? > > No, that was on my list of things to do, which I forgot. Just ran it > and found issues with 2 of them that I corrected: > > * Missing imports of Platform and JDKToolFinder in > runtime/NMT/MallocStressTest.java > * Extra "}" in serviceability/dcmd/jvmti/LoadAgentDcmdTest.java Ok. You overlooked answering my query about the JDK test changes. Thanks, David > Thanks, > Christian > > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Monday, August 15, 2016 12:58 AM > To: Christian Tornqvist ; > hotspot-dev at openjdk.java.net > Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: > jdk.test.lib.JDKToolFinder > > Hi Christian, > > First, thanks for attempting this, it is a huge effort! > > Second, as this is changing the /test/lib files then it needs to > be reviewed by more than just the hotspot group. > > I won't claim to have examined every file in detail - there is a lot > that has to be taken on face-value here. I have skimmed the webrevs > and patch files. > > A few comments in-lined below ... > > On 13/08/2016 1:32 AM, Christian Tornqvist wrote: >> Hi everyone, >> >> Please review this fix for the CNFE issue we've had in the Hotspot >> jtreg tests. The two big culprits for the intermittent CNFE are: >> Duplicate classes on classpath with different content and @build tags >> causing class files to be written in bad places. >> >> There has been a lot of confusion around when there's a need to add >> @build to a test. In general it turns out it has been overused, which >> can lead to side effects. Here's an easy rule: >> >> If you run only that test in a clean jtwork folder and it passes, >> then there's no need for @build. > > Do the jtreg authors agree with that rule? I'm happy to have such a > simple rule as long as it is agreed upon by all. > >> If it doesn't pass, then it might need an explicit @build, here are >> some examples when it might be needed: >> >> * If the class is used by ClassFileInstaller and this is invoked by >> @run main ClassFileInstaller (sun.hotspot.Whitebox is an example of >> this) >> >> * If it's a class that that doesn't have reference from the Test >> itself (if "javac Test" wouldn't compile it, you might need to >> explicitly @build it) >> >> The change includes: >> >> * Removing all unnecessary @build tags, some of the CNFE was due to >> use of it to compile classes in /test/lib or /testlibrary when having >> different classpath (@library) set. >> >> * Changed @build to @build sun.hotspot.Whitebox >> >> * Moved /test/lib/share/classes/jdk/test/lib to >> /test/lib/jdk/test/lib >> >> * Some of the classes in /hotspot/test/testlibrary was only used by >> one or two tests, these classes shouldn't be part of the shared >> testlibrary code and they were moved to the location of the test > > Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? > > They seem general-purpose to me even if mosts tests don't need to care. > So they seem suitable inclusions into the Platform class to me. > >> >> * Merged/moved the classes in /hotspot/test/testlibrary to /test/lib >> >> * Moved some of the /test/lib classes into packages >> >> * Changed @library /testlibrary to @library /test/lib > > Related to that I see a number of entries like: > > - * @library /testlibrary /test/lib / > + * @library /test/lib / > > this is not part of your change by why is / listed as a library ?? > >> * Changed imports from jdk.test.lib.* to explicit imports to help in >> future refactoring >> >> Almost all of the changes in here are in the jtreg @build and >> @library tags, very little code has been touched. Copyright headers >> will be updated before push. >> >> Testing done: Ran the entire hotspot/test/ folder multiple times >> locally and in RBT > > Just to be crystal clear, did you also run all the @ignore'd tests? > >> Webrev: >> >> http://cr.openjdk.java.net/~ctornqvi/webrev/8157957/webrev.00/ > > The jdk/test/* changes only seem to be for the @library changes in the > path, I don't see any changes to @build tags. Is that because all the > @builds are necessary or are you simply not taking on the task of also > updating the jdk tests? > >> A recently added test required me to fix that as well, generating and >> uploading a new webrev of the Hotspot repo changes takes about 3h >> though, so here's the diff for that file: >> >> diff -r f37577c20a6b >> test/serviceability/sa/sadebugd/SADebugDTest.java >> >> --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Wed Aug 10 >> 21:02:14 >> 2016 -0400 >> >> +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Fri Aug 12 >> +++ 11:25:54 >> 2016 -0400 >> >> @@ -26,7 +26,7 @@ >> >> * @summary Checks that the jshdb debugd utility sucessfully starts >> * and tries to attach to a running process >> * @modules java.base/jdk.internal.misc >> >> - * @library /test/lib/share/classes >> + * @library /test/lib >> * >> * @run main/othervm SADebugDTest >> */ > > Looks fine. > > Thanks, > David > ----- > >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8157957 >> >> Thanks, >> >> Christian >> >> >> >> >> > From christian.tornqvist at oracle.com Tue Aug 16 20:52:25 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Tue, 16 Aug 2016 16:52:25 -0400 Subject: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder In-Reply-To: <73BBDB9A-83C8-4826-AA65-16F375593D00@oracle.com> References: <227601d1f4ae$c6b3bd10$541b3730$@oracle.com> <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> <73BBDB9A-83C8-4826-AA65-16F375593D00@oracle.com> Message-ID: <31c201d1f800$1889d670$499d8350$@oracle.com> Hi Igor, >dtrace testlibrary was created and put in common testlibrary directory exactly in order to help porting our existing dtrace tests, having it "hidden" in hotspot/test/compiler/codecache/dtrace can lead us to reimplementing the same functionality. that is to say I think we should have it in root/testlibrary. Since the runtime group is now responsible for dtrace, we'll record the existence of this class for any future porting of the dtrace tests. Right now, this class is not used by anyone except the codecache/dtrace test and shouldn't be in the shared code. Thanks, Christian -----Original Message----- From: Igor Ignatyev [mailto:igor.ignatyev at oracle.com] Sent: Tuesday, August 16, 2016 7:05 AM To: David Holmes ; Christian Tornqvist Cc: hotspot-dev at openjdk.java.net Developers ; jdk9-dev Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder Christian/David, > Ah! I missed the significance of the renames ... > >> test/testlibrary/jdk/test/lib/dtrace/* > > Could be generally useful if all our dtrace tests were located > together, but as they are not . dtrace testlibrary was created and put in common testlibrary directory exactly in order to help porting our existing dtrace tests, having it "hidden" in hotspot/test/compiler/codecache/dtrace can lead us to reimplementing the same functionality. that is to say I think we should have it in root/testlibrary. Thanks, - Igor > On Aug 16, 2016, at 2:11 AM, David Holmes wrote: > > Hi Christian, > > Thanks for bring a broader audience into this. For reference to others the thread started with: > > http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198. > html > > On 16/08/2016 1:42 AM, Christian Tornqvist wrote: >> Hi David, >> >>> Do the jtreg authors agree with that rule? I'm happy to have such a >>> simple >> rule as long as it is agreed upon by all. >> We've had some discussions about this, Jonathan says that explicit >> @build is needed to support running with cached classes in jtwork and >> modifying the classes in the @library path. This isn't something that >> is a very common case in Hotspot and is avoidable by using a clean >> jtwork dir when modifying these shared classes. >> >> Think of it this way, when you run javac on your program Main.java >> that use the class A, you don't have to explicitly run javac on >> A.java first, this is the way the javac works and there's nothing different with jtreg here. > > It is a bit more complicated than that with libraries on different sourcepaths, but I don't know the intricacies of javac's implicit compilation checks. There are some obvious cases where reflection means there is no compile-time dependency between classes, but I don't know if we utilize anything of that nature in the test library (arguably we should in places to ensure the library can function on compact profiles and with the minimal VM - but that is a different problem). > > I remain very wary of this approach because I know we had to add @build to fix some missing library class problems. > >>> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >>> They seem general-purpose to me even if mosts tests don't need to care. >>> So they seem suitable inclusions into the Platform class to me. >> >> No, I was mostly talking about: > > Ah! I missed the significance of the renames ... > >> test/testlibrary/jdk/test/lib/dtrace/* > > Could be generally useful if all our dtrace tests were located together, but as they are not ... > >> test/testlibrary/jdk/test/lib/AllocationHelper.java > > Potentially useful. We have a lot of tests that try to consume/exhaust memory, but whether they are amenable to conversion to use this utility is another matter. > >> test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java > > Potentially useful. > >> test/testlibrary/jdk/test/lib/InputArguments.java > > This seems particularly useful, but also seems to have some overlap with existing argument processing code. > >> I can put back the jdkLibPath and sharedObjectName code if we believe >> that this is something than more than one test will need. I think we >> should be careful about putting unnecessary code in the shared classes. > > I don't have an issue with putting any kind of utility code (like the above examples) into the shared test library if there is potential for sharing. While retrofitting existing tests to use these things and remove duplication would be a lot of effort, at least if they exist in the library someone writing new tests and browsing the library won't be tempted to re-invent the wheel. > > So I'd vote for not changing these. > >>> why is / listed as a library ?? >> >> This is the compiler team's decision to use package name in their >> tests and use / as the @library path, can't say I agree with it. > > Not sure I even understand what it means! > >>> Just to be crystal clear, did you also run all the @ignore'd tests? >> >> No, that was on my list of things to do, which I forgot. Just ran it >> and found issues with 2 of them that I corrected: >> >> * Missing imports of Platform and JDKToolFinder in >> runtime/NMT/MallocStressTest.java >> * Extra "}" in serviceability/dcmd/jvmti/LoadAgentDcmdTest.java > > Ok. > > You overlooked answering my query about the JDK test changes. > > Thanks, > David > >> Thanks, >> Christian >> >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Monday, August 15, 2016 12:58 AM >> To: Christian Tornqvist ; >> hotspot-dev at openjdk.java.net >> Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: >> jdk.test.lib.JDKToolFinder >> >> Hi Christian, >> >> First, thanks for attempting this, it is a huge effort! >> >> Second, as this is changing the /test/lib files then it needs >> to be reviewed by more than just the hotspot group. >> >> I won't claim to have examined every file in detail - there is a lot >> that has to be taken on face-value here. I have skimmed the webrevs >> and patch files. >> >> A few comments in-lined below ... >> >> On 13/08/2016 1:32 AM, Christian Tornqvist wrote: >>> Hi everyone, >>> >>> Please review this fix for the CNFE issue we've had in the Hotspot >>> jtreg tests. The two big culprits for the intermittent CNFE are: >>> Duplicate classes on classpath with different content and @build >>> tags causing class files to be written in bad places. >>> >>> There has been a lot of confusion around when there's a need to add >>> @build to a test. In general it turns out it has been overused, >>> which can lead to side effects. Here's an easy rule: >>> >>> If you run only that test in a clean jtwork folder and it passes, >>> then there's no need for @build. >> >> Do the jtreg authors agree with that rule? I'm happy to have such a >> simple rule as long as it is agreed upon by all. >> >>> If it doesn't pass, then it might need an explicit @build, here are >>> some examples when it might be needed: >>> >>> * If the class is used by ClassFileInstaller and this is invoked by >>> @run main ClassFileInstaller (sun.hotspot.Whitebox is an example of >>> this) >>> >>> * If it's a class that that doesn't have reference from the Test >>> itself (if "javac Test" wouldn't compile it, you might need to >>> explicitly @build it) >>> >>> The change includes: >>> >>> * Removing all unnecessary @build tags, some of the CNFE was due to >>> use of it to compile classes in /test/lib or /testlibrary when >>> having different classpath (@library) set. >>> >>> * Changed @build to @build sun.hotspot.Whitebox >>> >>> * Moved /test/lib/share/classes/jdk/test/lib to >>> /test/lib/jdk/test/lib >>> >>> * Some of the classes in /hotspot/test/testlibrary was only used by >>> one or two tests, these classes shouldn't be part of the shared >>> testlibrary code and they were moved to the location of the test >> >> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >> >> They seem general-purpose to me even if mosts tests don't need to care. >> So they seem suitable inclusions into the Platform class to me. >> >>> >>> * Merged/moved the classes in /hotspot/test/testlibrary to /test/lib >>> >>> * Moved some of the /test/lib classes into packages >>> >>> * Changed @library /testlibrary to @library /test/lib >> >> Related to that I see a number of entries like: >> >> - * @library /testlibrary /test/lib / >> + * @library /test/lib / >> >> this is not part of your change by why is / listed as a library ?? >> >>> * Changed imports from jdk.test.lib.* to explicit imports to help in >>> future refactoring >>> >>> Almost all of the changes in here are in the jtreg @build and >>> @library tags, very little code has been touched. Copyright headers >>> will be updated before push. >>> >>> Testing done: Ran the entire hotspot/test/ folder multiple times >>> locally and in RBT >> >> Just to be crystal clear, did you also run all the @ignore'd tests? >> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~ctornqvi/webrev/8157957/webrev.00/ >> >> The jdk/test/* changes only seem to be for the @library changes in >> the path, I don't see any changes to @build tags. Is that because all >> the @builds are necessary or are you simply not taking on the task of >> also updating the jdk tests? >> >>> A recently added test required me to fix that as well, generating >>> and uploading a new webrev of the Hotspot repo changes takes about >>> 3h though, so here's the diff for that file: >>> >>> diff -r f37577c20a6b >>> test/serviceability/sa/sadebugd/SADebugDTest.java >>> >>> --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Wed Aug 10 >>> 21:02:14 >>> 2016 -0400 >>> >>> +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Fri Aug 12 >>> +++ 11:25:54 >>> 2016 -0400 >>> >>> @@ -26,7 +26,7 @@ >>> >>> * @summary Checks that the jshdb debugd utility sucessfully starts >>> * and tries to attach to a running process >>> * @modules java.base/jdk.internal.misc >>> >>> - * @library /test/lib/share/classes >>> + * @library /test/lib >>> * >>> * @run main/othervm SADebugDTest >>> */ >> >> Looks fine. >> >> Thanks, >> David >> ----- >> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8157957 >>> >>> Thanks, >>> >>> Christian >>> >>> >>> >>> >>> >> From igor.ignatyev at oracle.com Tue Aug 16 23:58:21 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Wed, 17 Aug 2016 02:58:21 +0300 Subject: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder In-Reply-To: <31c201d1f800$1889d670$499d8350$@oracle.com> References: <227601d1f4ae$c6b3bd10$541b3730$@oracle.com> <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> <73BBDB9A-83C8-4826-AA65-16F375593D00@oracle.com> <31c201d1f800$1889d670$499d8350$@oracle.com> Message-ID: Hi Christian, I?m sorry but I fail to see how absence of other users leads to ?this class ? shouldn't be in the shared code?. if we follow this logic, we will always have problems w/ having more than one user for a class and hence we won?t have any shared code. as I said dtrace testlibrary is a common testlibrary which can and should be used for other dtrace tests. so I don?t understand why you don?t want to place it in root/test. if the problem is in retesting, recreating/reuploading webrev, I?m fine w/ doing it by a separate changeset and I?d volunteer to do that. Thanks, ? Igor > On Aug 16, 2016, at 11:52 PM, Christian Tornqvist wrote: > > Hi Igor, > >> dtrace testlibrary was created and put in common testlibrary directory > exactly in order to help porting our existing dtrace tests, having it > "hidden" in hotspot/test/compiler/codecache/dtrace can lead us to > reimplementing the same functionality. that is to say I think we should have > it in root/testlibrary. > > Since the runtime group is now responsible for dtrace, we'll record the > existence of this class for any future porting of the dtrace tests. Right > now, this class is not used by anyone except the codecache/dtrace test and > shouldn't be in the shared code. > > Thanks, > Christian > > -----Original Message----- > From: Igor Ignatyev [mailto:igor.ignatyev at oracle.com] > Sent: Tuesday, August 16, 2016 7:05 AM > To: David Holmes ; Christian Tornqvist > > Cc: hotspot-dev at openjdk.java.net Developers ; > jdk9-dev > Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: > jdk.test.lib.JDKToolFinder > > Christian/David, > >> Ah! I missed the significance of the renames ... >> >>> test/testlibrary/jdk/test/lib/dtrace/* >> >> Could be generally useful if all our dtrace tests were located >> together, but as they are not . > > dtrace testlibrary was created and put in common testlibrary directory > exactly in order to help porting our existing dtrace tests, having it > "hidden" in hotspot/test/compiler/codecache/dtrace can lead us to > reimplementing the same functionality. that is to say I think we should have > it in root/testlibrary. > > Thanks, > - Igor > >> On Aug 16, 2016, at 2:11 AM, David Holmes wrote: >> >> Hi Christian, >> >> Thanks for bring a broader audience into this. For reference to others the > thread started with: >> >> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198. >> html >> >> On 16/08/2016 1:42 AM, Christian Tornqvist wrote: >>> Hi David, >>> >>>> Do the jtreg authors agree with that rule? I'm happy to have such a >>>> simple >>> rule as long as it is agreed upon by all. >>> We've had some discussions about this, Jonathan says that explicit >>> @build is needed to support running with cached classes in jtwork and >>> modifying the classes in the @library path. This isn't something that >>> is a very common case in Hotspot and is avoidable by using a clean >>> jtwork dir when modifying these shared classes. >>> >>> Think of it this way, when you run javac on your program Main.java >>> that use the class A, you don't have to explicitly run javac on >>> A.java first, this is the way the javac works and there's nothing > different with jtreg here. >> >> It is a bit more complicated than that with libraries on different > sourcepaths, but I don't know the intricacies of javac's implicit > compilation checks. There are some obvious cases where reflection means > there is no compile-time dependency between classes, but I don't know if we > utilize anything of that nature in the test library (arguably we should in > places to ensure the library can function on compact profiles and with the > minimal VM - but that is a different problem). >> >> I remain very wary of this approach because I know we had to add @build to > fix some missing library class problems. >> >>>> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >>>> They seem general-purpose to me even if mosts tests don't need to care. >>>> So they seem suitable inclusions into the Platform class to me. >>> >>> No, I was mostly talking about: >> >> Ah! I missed the significance of the renames ... >> >>> test/testlibrary/jdk/test/lib/dtrace/* >> >> Could be generally useful if all our dtrace tests were located together, > but as they are not ... >> >>> test/testlibrary/jdk/test/lib/AllocationHelper.java >> >> Potentially useful. We have a lot of tests that try to consume/exhaust > memory, but whether they are amenable to conversion to use this utility is > another matter. >> >>> test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java >> >> Potentially useful. >> >>> test/testlibrary/jdk/test/lib/InputArguments.java >> >> This seems particularly useful, but also seems to have some overlap with > existing argument processing code. >> >>> I can put back the jdkLibPath and sharedObjectName code if we believe >>> that this is something than more than one test will need. I think we >>> should be careful about putting unnecessary code in the shared classes. >> >> I don't have an issue with putting any kind of utility code (like the > above examples) into the shared test library if there is potential for > sharing. While retrofitting existing tests to use these things and remove > duplication would be a lot of effort, at least if they exist in the library > someone writing new tests and browsing the library won't be tempted to > re-invent the wheel. >> >> So I'd vote for not changing these. >> >>>> why is / listed as a library ?? >>> >>> This is the compiler team's decision to use package name in their >>> tests and use / as the @library path, can't say I agree with it. >> >> Not sure I even understand what it means! >> >>>> Just to be crystal clear, did you also run all the @ignore'd tests? >>> >>> No, that was on my list of things to do, which I forgot. Just ran it >>> and found issues with 2 of them that I corrected: >>> >>> * Missing imports of Platform and JDKToolFinder in >>> runtime/NMT/MallocStressTest.java >>> * Extra "}" in serviceability/dcmd/jvmti/LoadAgentDcmdTest.java >> >> Ok. >> >> You overlooked answering my query about the JDK test changes. >> >> Thanks, >> David >> >>> Thanks, >>> Christian >>> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Monday, August 15, 2016 12:58 AM >>> To: Christian Tornqvist ; >>> hotspot-dev at openjdk.java.net >>> Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: >>> jdk.test.lib.JDKToolFinder >>> >>> Hi Christian, >>> >>> First, thanks for attempting this, it is a huge effort! >>> >>> Second, as this is changing the /test/lib files then it needs >>> to be reviewed by more than just the hotspot group. >>> >>> I won't claim to have examined every file in detail - there is a lot >>> that has to be taken on face-value here. I have skimmed the webrevs >>> and patch files. >>> >>> A few comments in-lined below ... >>> >>> On 13/08/2016 1:32 AM, Christian Tornqvist wrote: >>>> Hi everyone, >>>> >>>> Please review this fix for the CNFE issue we've had in the Hotspot >>>> jtreg tests. The two big culprits for the intermittent CNFE are: >>>> Duplicate classes on classpath with different content and @build >>>> tags causing class files to be written in bad places. >>>> >>>> There has been a lot of confusion around when there's a need to add >>>> @build to a test. In general it turns out it has been overused, >>>> which can lead to side effects. Here's an easy rule: >>>> >>>> If you run only that test in a clean jtwork folder and it passes, >>>> then there's no need for @build. >>> >>> Do the jtreg authors agree with that rule? I'm happy to have such a >>> simple rule as long as it is agreed upon by all. >>> >>>> If it doesn't pass, then it might need an explicit @build, here are >>>> some examples when it might be needed: >>>> >>>> * If the class is used by ClassFileInstaller and this is invoked by >>>> @run main ClassFileInstaller (sun.hotspot.Whitebox is an example of >>>> this) >>>> >>>> * If it's a class that that doesn't have reference from the Test >>>> itself (if "javac Test" wouldn't compile it, you might need to >>>> explicitly @build it) >>>> >>>> The change includes: >>>> >>>> * Removing all unnecessary @build tags, some of the CNFE was due to >>>> use of it to compile classes in /test/lib or /testlibrary when >>>> having different classpath (@library) set. >>>> >>>> * Changed @build to @build sun.hotspot.Whitebox >>>> >>>> * Moved /test/lib/share/classes/jdk/test/lib to >>>> /test/lib/jdk/test/lib >>>> >>>> * Some of the classes in /hotspot/test/testlibrary was only used by >>>> one or two tests, these classes shouldn't be part of the shared >>>> testlibrary code and they were moved to the location of the test >>> >>> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >>> >>> They seem general-purpose to me even if mosts tests don't need to care. >>> So they seem suitable inclusions into the Platform class to me. >>> >>>> >>>> * Merged/moved the classes in /hotspot/test/testlibrary to /test/lib >>>> >>>> * Moved some of the /test/lib classes into packages >>>> >>>> * Changed @library /testlibrary to @library /test/lib >>> >>> Related to that I see a number of entries like: >>> >>> - * @library /testlibrary /test/lib / >>> + * @library /test/lib / >>> >>> this is not part of your change by why is / listed as a library ?? >>> >>>> * Changed imports from jdk.test.lib.* to explicit imports to help in >>>> future refactoring >>>> >>>> Almost all of the changes in here are in the jtreg @build and >>>> @library tags, very little code has been touched. Copyright headers >>>> will be updated before push. >>>> >>>> Testing done: Ran the entire hotspot/test/ folder multiple times >>>> locally and in RBT >>> >>> Just to be crystal clear, did you also run all the @ignore'd tests? >>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8157957/webrev.00/ >>> >>> The jdk/test/* changes only seem to be for the @library changes in >>> the path, I don't see any changes to @build tags. Is that because all >>> the @builds are necessary or are you simply not taking on the task of >>> also updating the jdk tests? >>> >>>> A recently added test required me to fix that as well, generating >>>> and uploading a new webrev of the Hotspot repo changes takes about >>>> 3h though, so here's the diff for that file: >>>> >>>> diff -r f37577c20a6b >>>> test/serviceability/sa/sadebugd/SADebugDTest.java >>>> >>>> --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Wed Aug 10 >>>> 21:02:14 >>>> 2016 -0400 >>>> >>>> +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Fri Aug 12 >>>> +++ 11:25:54 >>>> 2016 -0400 >>>> >>>> @@ -26,7 +26,7 @@ >>>> >>>> * @summary Checks that the jshdb debugd utility sucessfully starts >>>> * and tries to attach to a running process >>>> * @modules java.base/jdk.internal.misc >>>> >>>> - * @library /test/lib/share/classes >>>> + * @library /test/lib >>>> * >>>> * @run main/othervm SADebugDTest >>>> */ >>> >>> Looks fine. >>> >>> Thanks, >>> David >>> ----- >>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8157957 >>>> >>>> Thanks, >>>> >>>> Christian >>>> >>>> >>>> >>>> >>>> >>> > > From david.holmes at oracle.com Wed Aug 17 03:29:10 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 17 Aug 2016 13:29:10 +1000 Subject: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder In-Reply-To: References: <227601d1f4ae$c6b3bd10$541b3730$@oracle.com> <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> <73BBDB9A-83C8-4826-AA65-16F375593D00@oracle.com> <31c201d1f800$1889d670$499d8350$@oracle.com> Message-ID: <982663a5-73c4-e490-ec47-f1cb32ce0ad5@oracle.com> On 17/08/2016 9:58 AM, Igor Ignatyev wrote: > Hi Christian, > > I?m sorry but I fail to see how absence of other users leads to ?this class ? shouldn't be in the shared code?. if we follow this logic, we will always have problems w/ having more than one user for a class and hence we won?t have any shared code. as I said dtrace testlibrary is a common testlibrary which can and should be used for other dtrace tests. so I don?t understand why you don?t want to place it in root/test. I tend to agree. Utility code should be in the library to be used by future tests, with retrofitting applied to existing tests as resources permit. I see no point in actively removing anything from the shared library as part of this when the focus is on @build issues. David ----- > if the problem is in retesting, recreating/reuploading webrev, I?m fine w/ doing it by a separate changeset and I?d volunteer to do that. > > Thanks, > ? Igor >> On Aug 16, 2016, at 11:52 PM, Christian Tornqvist wrote: >> >> Hi Igor, >> >>> dtrace testlibrary was created and put in common testlibrary directory >> exactly in order to help porting our existing dtrace tests, having it >> "hidden" in hotspot/test/compiler/codecache/dtrace can lead us to >> reimplementing the same functionality. that is to say I think we should have >> it in root/testlibrary. >> >> Since the runtime group is now responsible for dtrace, we'll record the >> existence of this class for any future porting of the dtrace tests. Right >> now, this class is not used by anyone except the codecache/dtrace test and >> shouldn't be in the shared code. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Igor Ignatyev [mailto:igor.ignatyev at oracle.com] >> Sent: Tuesday, August 16, 2016 7:05 AM >> To: David Holmes ; Christian Tornqvist >> >> Cc: hotspot-dev at openjdk.java.net Developers ; >> jdk9-dev >> Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: >> jdk.test.lib.JDKToolFinder >> >> Christian/David, >> >>> Ah! I missed the significance of the renames ... >>> >>>> test/testlibrary/jdk/test/lib/dtrace/* >>> >>> Could be generally useful if all our dtrace tests were located >>> together, but as they are not . >> >> dtrace testlibrary was created and put in common testlibrary directory >> exactly in order to help porting our existing dtrace tests, having it >> "hidden" in hotspot/test/compiler/codecache/dtrace can lead us to >> reimplementing the same functionality. that is to say I think we should have >> it in root/testlibrary. >> >> Thanks, >> - Igor >> >>> On Aug 16, 2016, at 2:11 AM, David Holmes wrote: >>> >>> Hi Christian, >>> >>> Thanks for bring a broader audience into this. For reference to others the >> thread started with: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198. >>> html >>> >>> On 16/08/2016 1:42 AM, Christian Tornqvist wrote: >>>> Hi David, >>>> >>>>> Do the jtreg authors agree with that rule? I'm happy to have such a >>>>> simple >>>> rule as long as it is agreed upon by all. >>>> We've had some discussions about this, Jonathan says that explicit >>>> @build is needed to support running with cached classes in jtwork and >>>> modifying the classes in the @library path. This isn't something that >>>> is a very common case in Hotspot and is avoidable by using a clean >>>> jtwork dir when modifying these shared classes. >>>> >>>> Think of it this way, when you run javac on your program Main.java >>>> that use the class A, you don't have to explicitly run javac on >>>> A.java first, this is the way the javac works and there's nothing >> different with jtreg here. >>> >>> It is a bit more complicated than that with libraries on different >> sourcepaths, but I don't know the intricacies of javac's implicit >> compilation checks. There are some obvious cases where reflection means >> there is no compile-time dependency between classes, but I don't know if we >> utilize anything of that nature in the test library (arguably we should in >> places to ensure the library can function on compact profiles and with the >> minimal VM - but that is a different problem). >>> >>> I remain very wary of this approach because I know we had to add @build to >> fix some missing library class problems. >>> >>>>> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >>>>> They seem general-purpose to me even if mosts tests don't need to care. >>>>> So they seem suitable inclusions into the Platform class to me. >>>> >>>> No, I was mostly talking about: >>> >>> Ah! I missed the significance of the renames ... >>> >>>> test/testlibrary/jdk/test/lib/dtrace/* >>> >>> Could be generally useful if all our dtrace tests were located together, >> but as they are not ... >>> >>>> test/testlibrary/jdk/test/lib/AllocationHelper.java >>> >>> Potentially useful. We have a lot of tests that try to consume/exhaust >> memory, but whether they are amenable to conversion to use this utility is >> another matter. >>> >>>> test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java >>> >>> Potentially useful. >>> >>>> test/testlibrary/jdk/test/lib/InputArguments.java >>> >>> This seems particularly useful, but also seems to have some overlap with >> existing argument processing code. >>> >>>> I can put back the jdkLibPath and sharedObjectName code if we believe >>>> that this is something than more than one test will need. I think we >>>> should be careful about putting unnecessary code in the shared classes. >>> >>> I don't have an issue with putting any kind of utility code (like the >> above examples) into the shared test library if there is potential for >> sharing. While retrofitting existing tests to use these things and remove >> duplication would be a lot of effort, at least if they exist in the library >> someone writing new tests and browsing the library won't be tempted to >> re-invent the wheel. >>> >>> So I'd vote for not changing these. >>> >>>>> why is / listed as a library ?? >>>> >>>> This is the compiler team's decision to use package name in their >>>> tests and use / as the @library path, can't say I agree with it. >>> >>> Not sure I even understand what it means! >>> >>>>> Just to be crystal clear, did you also run all the @ignore'd tests? >>>> >>>> No, that was on my list of things to do, which I forgot. Just ran it >>>> and found issues with 2 of them that I corrected: >>>> >>>> * Missing imports of Platform and JDKToolFinder in >>>> runtime/NMT/MallocStressTest.java >>>> * Extra "}" in serviceability/dcmd/jvmti/LoadAgentDcmdTest.java >>> >>> Ok. >>> >>> You overlooked answering my query about the JDK test changes. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Monday, August 15, 2016 12:58 AM >>>> To: Christian Tornqvist ; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: >>>> jdk.test.lib.JDKToolFinder >>>> >>>> Hi Christian, >>>> >>>> First, thanks for attempting this, it is a huge effort! >>>> >>>> Second, as this is changing the /test/lib files then it needs >>>> to be reviewed by more than just the hotspot group. >>>> >>>> I won't claim to have examined every file in detail - there is a lot >>>> that has to be taken on face-value here. I have skimmed the webrevs >>>> and patch files. >>>> >>>> A few comments in-lined below ... >>>> >>>> On 13/08/2016 1:32 AM, Christian Tornqvist wrote: >>>>> Hi everyone, >>>>> >>>>> Please review this fix for the CNFE issue we've had in the Hotspot >>>>> jtreg tests. The two big culprits for the intermittent CNFE are: >>>>> Duplicate classes on classpath with different content and @build >>>>> tags causing class files to be written in bad places. >>>>> >>>>> There has been a lot of confusion around when there's a need to add >>>>> @build to a test. In general it turns out it has been overused, >>>>> which can lead to side effects. Here's an easy rule: >>>>> >>>>> If you run only that test in a clean jtwork folder and it passes, >>>>> then there's no need for @build. >>>> >>>> Do the jtreg authors agree with that rule? I'm happy to have such a >>>> simple rule as long as it is agreed upon by all. >>>> >>>>> If it doesn't pass, then it might need an explicit @build, here are >>>>> some examples when it might be needed: >>>>> >>>>> * If the class is used by ClassFileInstaller and this is invoked by >>>>> @run main ClassFileInstaller (sun.hotspot.Whitebox is an example of >>>>> this) >>>>> >>>>> * If it's a class that that doesn't have reference from the Test >>>>> itself (if "javac Test" wouldn't compile it, you might need to >>>>> explicitly @build it) >>>>> >>>>> The change includes: >>>>> >>>>> * Removing all unnecessary @build tags, some of the CNFE was due to >>>>> use of it to compile classes in /test/lib or /testlibrary when >>>>> having different classpath (@library) set. >>>>> >>>>> * Changed @build to @build sun.hotspot.Whitebox >>>>> >>>>> * Moved /test/lib/share/classes/jdk/test/lib to >>>>> /test/lib/jdk/test/lib >>>>> >>>>> * Some of the classes in /hotspot/test/testlibrary was only used by >>>>> one or two tests, these classes shouldn't be part of the shared >>>>> testlibrary code and they were moved to the location of the test >>>> >>>> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >>>> >>>> They seem general-purpose to me even if mosts tests don't need to care. >>>> So they seem suitable inclusions into the Platform class to me. >>>> >>>>> >>>>> * Merged/moved the classes in /hotspot/test/testlibrary to /test/lib >>>>> >>>>> * Moved some of the /test/lib classes into packages >>>>> >>>>> * Changed @library /testlibrary to @library /test/lib >>>> >>>> Related to that I see a number of entries like: >>>> >>>> - * @library /testlibrary /test/lib / >>>> + * @library /test/lib / >>>> >>>> this is not part of your change by why is / listed as a library ?? >>>> >>>>> * Changed imports from jdk.test.lib.* to explicit imports to help in >>>>> future refactoring >>>>> >>>>> Almost all of the changes in here are in the jtreg @build and >>>>> @library tags, very little code has been touched. Copyright headers >>>>> will be updated before push. >>>>> >>>>> Testing done: Ran the entire hotspot/test/ folder multiple times >>>>> locally and in RBT >>>> >>>> Just to be crystal clear, did you also run all the @ignore'd tests? >>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8157957/webrev.00/ >>>> >>>> The jdk/test/* changes only seem to be for the @library changes in >>>> the path, I don't see any changes to @build tags. Is that because all >>>> the @builds are necessary or are you simply not taking on the task of >>>> also updating the jdk tests? >>>> >>>>> A recently added test required me to fix that as well, generating >>>>> and uploading a new webrev of the Hotspot repo changes takes about >>>>> 3h though, so here's the diff for that file: >>>>> >>>>> diff -r f37577c20a6b >>>>> test/serviceability/sa/sadebugd/SADebugDTest.java >>>>> >>>>> --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Wed Aug 10 >>>>> 21:02:14 >>>>> 2016 -0400 >>>>> >>>>> +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Fri Aug 12 >>>>> +++ 11:25:54 >>>>> 2016 -0400 >>>>> >>>>> @@ -26,7 +26,7 @@ >>>>> >>>>> * @summary Checks that the jshdb debugd utility sucessfully starts >>>>> * and tries to attach to a running process >>>>> * @modules java.base/jdk.internal.misc >>>>> >>>>> - * @library /test/lib/share/classes >>>>> + * @library /test/lib >>>>> * >>>>> * @run main/othervm SADebugDTest >>>>> */ >>>> >>>> Looks fine. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8157957 >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >> >> > From rahman.usta.88 at gmail.com Wed Aug 17 13:12:34 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Wed, 17 Aug 2016 16:12:34 +0300 Subject: JEP 110 - Violating Naming Convention ? Message-ID: Hello; I'm trying the new HTTP/2 Client API. For example I have a sample code below; HttpResponse response = HttpRequest .create(URI.create("https://istanbul-jug.org")) .GET() .response(); System.out.println(response.body(HttpResponse.asString())); It works excepted, however I see that the method name GET is written fully uppercase. I have never seen this usage yet anywhere in Java. Is that a right usage in Java? Thanks. -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From pavel.rappo at oracle.com Wed Aug 17 13:29:30 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Wed, 17 Aug 2016 14:29:30 +0100 Subject: JEP 110 - Violating Naming Convention ? In-Reply-To: References: Message-ID: <3BD5EC59-DFDE-4C79-B604-80BA8910E23F@oracle.com> The correct mailing list for issues in java.net area would be net-dev at openjdk.java.net IMO, these conventions are just guidelines. One can override them in some circumstances where it makes a lot of sense. Yes, the barrier for violations should be high. I believe this is one of the cases. > On 17 Aug 2016, at 14:12, Rahman USTA wrote: > > Hello; > > I'm trying the new HTTP/2 Client API. For example I have a sample code > below; > > HttpResponse response = HttpRequest > .create(URI.create("https://istanbul-jug.org")) > .GET() > .response(); > > System.out.println(response.body(HttpResponse.asString())); > > It works excepted, however I see that the method name GET is written fully > uppercase. I have never seen this usage yet anywhere in Java. Is that a > right usage in Java? > > Thanks. > > -- > Rahman USTA > Istanbul JUG > https://github.com/rahmanusta From rahman.usta.88 at gmail.com Wed Aug 17 13:51:18 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Wed, 17 Aug 2016 16:51:18 +0300 Subject: JEP 110 - Violating Naming Convention ? In-Reply-To: <3BD5EC59-DFDE-4C79-B604-80BA8910E23F@oracle.com> References: <3BD5EC59-DFDE-4C79-B604-80BA8910E23F@oracle.com> Message-ID: Thank you Pavel, this uncommon usage looks to me very weird. I hope it could be re-evaluated again. Thanks 2016-08-17 16:29 GMT+03:00 Pavel Rappo : > The correct mailing list for issues in java.net area would be > net-dev at openjdk.java.net > > IMO, these conventions are just guidelines. One can override them in some > circumstances where it makes a lot of sense. Yes, the barrier for > violations > should be high. I believe this is one of the cases. > > > On 17 Aug 2016, at 14:12, Rahman USTA wrote: > > > > Hello; > > > > I'm trying the new HTTP/2 Client API. For example I have a sample code > > below; > > > > HttpResponse response = HttpRequest > > .create(URI.create("https://istanbul-jug.org")) > > .GET() > > .response(); > > > > System.out.println(response.body(HttpResponse.asString())); > > > > It works excepted, however I see that the method name GET is written > fully > > uppercase. I have never seen this usage yet anywhere in Java. Is that a > > right usage in Java? > > > > Thanks. > > > > -- > > Rahman USTA > > Istanbul JUG > > https://github.com/rahmanusta > > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From aph at redhat.com Wed Aug 17 14:50:58 2016 From: aph at redhat.com (Andrew Haley) Date: Wed, 17 Aug 2016 15:50:58 +0100 Subject: JEP 110 - Violating Naming Convention ? In-Reply-To: References: <3BD5EC59-DFDE-4C79-B604-80BA8910E23F@oracle.com> Message-ID: <57B479D2.3030001@redhat.com> On 17/08/16 14:51, Rahman USTA wrote: > Thank you Pavel, this uncommon usage looks to me very weird. > > I hope it could be re-evaluated again. I don't agree. If you look at RFC 2616 you will see that the HTTP Method is called GET. All in capitals. In all documentation it is called GET. To call it, say, "get" would be the odd thing to do. Andrew. From neugens at redhat.com Wed Aug 17 15:02:43 2016 From: neugens at redhat.com (Mario Torre) Date: Wed, 17 Aug 2016 17:02:43 +0200 Subject: JEP 110 - Violating Naming Convention ? In-Reply-To: <57B479D2.3030001@redhat.com> References: <3BD5EC59-DFDE-4C79-B604-80BA8910E23F@oracle.com> <57B479D2.3030001@redhat.com> Message-ID: On Wed, Aug 17, 2016 at 4:50 PM, Andrew Haley wrote: > On 17/08/16 14:51, Rahman USTA wrote: >> Thank you Pavel, this uncommon usage looks to me very weird. >> >> I hope it could be re-evaluated again. > > I don't agree. If you look at RFC 2616 you will see that the HTTP > Method is called GET. All in capitals. In all documentation it is > called GET. To call it, say, "get" would be the odd thing to do. > > Andrew. Indeed, it looks more clear this way. If you see POST and the likes follow the same idea. If you think about that, you don't really "get" something as in the general concept of java use of "get", what this method does is to create a GET request (or similar a POST one). In my opinion is a clever way to highlight the API is not the usual get/set styled bean. Cheers, Mario From christian.tornqvist at oracle.com Wed Aug 17 15:36:23 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Wed, 17 Aug 2016 11:36:23 -0400 Subject: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder In-Reply-To: <982663a5-73c4-e490-ec47-f1cb32ce0ad5@oracle.com> References: <227601d1f4ae$c6b3bd10$541b3730$@oracle.com> <1487e0b0-bf4f-53bf-0567-1676ad11d17a@oracle.com> <2ad301d1f70b$91cd8040$b56880c0$@oracle.com> <904b2e99-2c4a-f3e5-6dfe-18fd0cecb1e9@oracle.com> <73BBDB9A-83C8-4826-AA65-16F375593D00@oracle.com> <31c201d1f800$1889d670$499d8350$@oracle.com> <982663a5-73c4-e490-ec47-f1cb32ce0ad5@oracle.com> Message-ID: <343701d1f89d$1c9e37e0$55daa7a0$@oracle.com> I've filed https://bugs.openjdk.java.net/browse/JDK-8164223 to deal with moving the dtrace helper classes to /test/lib once we port the runtime dtrace tests to jtreg. Thanks, Christian -----Original Message----- From: David Holmes [mailto:david.holmes at oracle.com] Sent: Tuesday, August 16, 2016 11:29 PM To: Igor Ignatyev ; Christian Tornqvist Cc: hotspot-dev at openjdk.java.net; jdk9-dev Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: jdk.test.lib.JDKToolFinder On 17/08/2016 9:58 AM, Igor Ignatyev wrote: > Hi Christian, > > I?m sorry but I fail to see how absence of other users leads to ?this class ? shouldn't be in the shared code?. if we follow this logic, we will always have problems w/ having more than one user for a class and hence we won?t have any shared code. as I said dtrace testlibrary is a common testlibrary which can and should be used for other dtrace tests. so I don?t understand why you don?t want to place it in root/test. I tend to agree. Utility code should be in the library to be used by future tests, with retrofitting applied to existing tests as resources permit. I see no point in actively removing anything from the shared library as part of this when the focus is on @build issues. David ----- > if the problem is in retesting, recreating/reuploading webrev, I?m fine w/ doing it by a separate changeset and I?d volunteer to do that. > > Thanks, > ? Igor >> On Aug 16, 2016, at 11:52 PM, Christian Tornqvist wrote: >> >> Hi Igor, >> >>> dtrace testlibrary was created and put in common testlibrary >>> directory >> exactly in order to help porting our existing dtrace tests, having it >> "hidden" in hotspot/test/compiler/codecache/dtrace can lead us to >> reimplementing the same functionality. that is to say I think we >> should have it in root/testlibrary. >> >> Since the runtime group is now responsible for dtrace, we'll record >> the existence of this class for any future porting of the dtrace >> tests. Right now, this class is not used by anyone except the >> codecache/dtrace test and shouldn't be in the shared code. >> >> Thanks, >> Christian >> >> -----Original Message----- >> From: Igor Ignatyev [mailto:igor.ignatyev at oracle.com] >> Sent: Tuesday, August 16, 2016 7:05 AM >> To: David Holmes ; Christian Tornqvist >> >> Cc: hotspot-dev at openjdk.java.net Developers >> ; jdk9-dev >> Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: >> jdk.test.lib.JDKToolFinder >> >> Christian/David, >> >>> Ah! I missed the significance of the renames ... >>> >>>> test/testlibrary/jdk/test/lib/dtrace/* >>> >>> Could be generally useful if all our dtrace tests were located >>> together, but as they are not . >> >> dtrace testlibrary was created and put in common testlibrary >> directory exactly in order to help porting our existing dtrace tests, >> having it "hidden" in hotspot/test/compiler/codecache/dtrace can lead >> us to reimplementing the same functionality. that is to say I think >> we should have it in root/testlibrary. >> >> Thanks, >> - Igor >> >>> On Aug 16, 2016, at 2:11 AM, David Holmes wrote: >>> >>> Hi Christian, >>> >>> Thanks for bring a broader audience into this. For reference to >>> others the >> thread started with: >>> >>> http://mail.openjdk.java.net/pipermail/hotspot-dev/2016-August/024198. >>> html >>> >>> On 16/08/2016 1:42 AM, Christian Tornqvist wrote: >>>> Hi David, >>>> >>>>> Do the jtreg authors agree with that rule? I'm happy to have such >>>>> a simple >>>> rule as long as it is agreed upon by all. >>>> We've had some discussions about this, Jonathan says that explicit >>>> @build is needed to support running with cached classes in jtwork >>>> and modifying the classes in the @library path. This isn't >>>> something that is a very common case in Hotspot and is avoidable by >>>> using a clean jtwork dir when modifying these shared classes. >>>> >>>> Think of it this way, when you run javac on your program Main.java >>>> that use the class A, you don't have to explicitly run javac on >>>> A.java first, this is the way the javac works and there's nothing >> different with jtreg here. >>> >>> It is a bit more complicated than that with libraries on different >> sourcepaths, but I don't know the intricacies of javac's implicit >> compilation checks. There are some obvious cases where reflection >> means there is no compile-time dependency between classes, but I >> don't know if we utilize anything of that nature in the test library >> (arguably we should in places to ensure the library can function on >> compact profiles and with the minimal VM - but that is a different problem). >>> >>> I remain very wary of this approach because I know we had to add >>> @build to >> fix some missing library class problems. >>> >>>>> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >>>>> They seem general-purpose to me even if mosts tests don't need to care. >>>>> So they seem suitable inclusions into the Platform class to me. >>>> >>>> No, I was mostly talking about: >>> >>> Ah! I missed the significance of the renames ... >>> >>>> test/testlibrary/jdk/test/lib/dtrace/* >>> >>> Could be generally useful if all our dtrace tests were located >>> together, >> but as they are not ... >>> >>>> test/testlibrary/jdk/test/lib/AllocationHelper.java >>> >>> Potentially useful. We have a lot of tests that try to >>> consume/exhaust >> memory, but whether they are amenable to conversion to use this >> utility is another matter. >>> >>>> test/testlibrary/jdk/test/lib/HeapRegionUsageTool.java >>> >>> Potentially useful. >>> >>>> test/testlibrary/jdk/test/lib/InputArguments.java >>> >>> This seems particularly useful, but also seems to have some overlap >>> with >> existing argument processing code. >>> >>>> I can put back the jdkLibPath and sharedObjectName code if we >>>> believe that this is something than more than one test will need. I >>>> think we should be careful about putting unnecessary code in the shared classes. >>> >>> I don't have an issue with putting any kind of utility code (like >>> the >> above examples) into the shared test library if there is potential >> for sharing. While retrofitting existing tests to use these things >> and remove duplication would be a lot of effort, at least if they >> exist in the library someone writing new tests and browsing the >> library won't be tempted to re-invent the wheel. >>> >>> So I'd vote for not changing these. >>> >>>>> why is / listed as a library ?? >>>> >>>> This is the compiler team's decision to use package name in their >>>> tests and use / as the @library path, can't say I agree with it. >>> >>> Not sure I even understand what it means! >>> >>>>> Just to be crystal clear, did you also run all the @ignore'd tests? >>>> >>>> No, that was on my list of things to do, which I forgot. Just ran >>>> it and found issues with 2 of them that I corrected: >>>> >>>> * Missing imports of Platform and JDKToolFinder in >>>> runtime/NMT/MallocStressTest.java >>>> * Extra "}" in serviceability/dcmd/jvmti/LoadAgentDcmdTest.java >>> >>> Ok. >>> >>> You overlooked answering my query about the JDK test changes. >>> >>> Thanks, >>> David >>> >>>> Thanks, >>>> Christian >>>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Monday, August 15, 2016 12:58 AM >>>> To: Christian Tornqvist ; >>>> hotspot-dev at openjdk.java.net >>>> Subject: Re: RFR(XL): 8157957 - ClassNotFoundException: >>>> jdk.test.lib.JDKToolFinder >>>> >>>> Hi Christian, >>>> >>>> First, thanks for attempting this, it is a huge effort! >>>> >>>> Second, as this is changing the /test/lib files then it needs >>>> to be reviewed by more than just the hotspot group. >>>> >>>> I won't claim to have examined every file in detail - there is a >>>> lot that has to be taken on face-value here. I have skimmed the >>>> webrevs and patch files. >>>> >>>> A few comments in-lined below ... >>>> >>>> On 13/08/2016 1:32 AM, Christian Tornqvist wrote: >>>>> Hi everyone, >>>>> >>>>> Please review this fix for the CNFE issue we've had in the Hotspot >>>>> jtreg tests. The two big culprits for the intermittent CNFE are: >>>>> Duplicate classes on classpath with different content and @build >>>>> tags causing class files to be written in bad places. >>>>> >>>>> There has been a lot of confusion around when there's a need to >>>>> add @build to a test. In general it turns out it has been >>>>> overused, which can lead to side effects. Here's an easy rule: >>>>> >>>>> If you run only that test in a clean jtwork folder and it passes, >>>>> then there's no need for @build. >>>> >>>> Do the jtreg authors agree with that rule? I'm happy to have such a >>>> simple rule as long as it is agreed upon by all. >>>> >>>>> If it doesn't pass, then it might need an explicit @build, here >>>>> are some examples when it might be needed: >>>>> >>>>> * If the class is used by ClassFileInstaller and this is invoked >>>>> by @run main ClassFileInstaller (sun.hotspot.Whitebox is an >>>>> example of >>>>> this) >>>>> >>>>> * If it's a class that that doesn't have reference from the Test >>>>> itself (if "javac Test" wouldn't compile it, you might need to >>>>> explicitly @build it) >>>>> >>>>> The change includes: >>>>> >>>>> * Removing all unnecessary @build tags, some of the CNFE was due >>>>> to use of it to compile classes in /test/lib or /testlibrary when >>>>> having different classpath (@library) set. >>>>> >>>>> * Changed @build to @build sun.hotspot.Whitebox >>>>> >>>>> * Moved /test/lib/share/classes/jdk/test/lib to >>>>> /test/lib/jdk/test/lib >>>>> >>>>> * Some of the classes in /hotspot/test/testlibrary was only used >>>>> by one or two tests, these classes shouldn't be part of the shared >>>>> testlibrary code and they were moved to the location of the test >>>> >>>> Are these only: Platform.jdkLibPath(), Platform.sharedObjectName ? >>>> >>>> They seem general-purpose to me even if mosts tests don't need to care. >>>> So they seem suitable inclusions into the Platform class to me. >>>> >>>>> >>>>> * Merged/moved the classes in /hotspot/test/testlibrary to >>>>> /test/lib >>>>> >>>>> * Moved some of the /test/lib classes into packages >>>>> >>>>> * Changed @library /testlibrary to @library /test/lib >>>> >>>> Related to that I see a number of entries like: >>>> >>>> - * @library /testlibrary /test/lib / >>>> + * @library /test/lib / >>>> >>>> this is not part of your change by why is / listed as a library ?? >>>> >>>>> * Changed imports from jdk.test.lib.* to explicit imports to help >>>>> in future refactoring >>>>> >>>>> Almost all of the changes in here are in the jtreg @build and >>>>> @library tags, very little code has been touched. Copyright >>>>> headers will be updated before push. >>>>> >>>>> Testing done: Ran the entire hotspot/test/ folder multiple times >>>>> locally and in RBT >>>> >>>> Just to be crystal clear, did you also run all the @ignore'd tests? >>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~ctornqvi/webrev/8157957/webrev.00/ >>>> >>>> The jdk/test/* changes only seem to be for the @library changes in >>>> the path, I don't see any changes to @build tags. Is that because >>>> all the @builds are necessary or are you simply not taking on the >>>> task of also updating the jdk tests? >>>> >>>>> A recently added test required me to fix that as well, generating >>>>> and uploading a new webrev of the Hotspot repo changes takes about >>>>> 3h though, so here's the diff for that file: >>>>> >>>>> diff -r f37577c20a6b >>>>> test/serviceability/sa/sadebugd/SADebugDTest.java >>>>> >>>>> --- a/test/serviceability/sa/sadebugd/SADebugDTest.java Wed Aug 10 >>>>> 21:02:14 >>>>> 2016 -0400 >>>>> >>>>> +++ b/test/serviceability/sa/sadebugd/SADebugDTest.java Fri Aug 12 >>>>> +++ 11:25:54 >>>>> 2016 -0400 >>>>> >>>>> @@ -26,7 +26,7 @@ >>>>> >>>>> * @summary Checks that the jshdb debugd utility sucessfully starts >>>>> * and tries to attach to a running process >>>>> * @modules java.base/jdk.internal.misc >>>>> >>>>> - * @library /test/lib/share/classes >>>>> + * @library /test/lib >>>>> * >>>>> * @run main/othervm SADebugDTest >>>>> */ >>>> >>>> Looks fine. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8157957 >>>>> >>>>> Thanks, >>>>> >>>>> Christian >>>>> >>>>> >>>>> >>>>> >>>>> >>>> >> >> > From alejandro.murillo at oracle.com Wed Aug 17 16:00:40 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Wed, 17 Aug 2016 10:00:40 -0600 Subject: jdk9-dev: HotSpot Message-ID: <32a2d34f-0870-d564-46ab-fb1ff94e1cbb@oracle.com> jdk9-hs-2016-08-12 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/a24702d4d5ab http://hg.openjdk.java.net/jdk9/dev/corba/rev/1ab4b9399c4c http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/2bf98fb4ca55 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/0df1857766af http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/9fff2477a4ca http://hg.openjdk.java.net/jdk9/dev/jdk/rev/508f985a1f6c http://hg.openjdk.java.net/jdk9/dev/langtools/rev/c949657b7390 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/6607833b50b5 Component : VM Status : Go for integration Date : 08/16/2016 at 00:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-08-12-205858.amurillo.jdk9-hs-2016-08-12-snapshot Testing: 106 new failures, 4224 known failures, 1745330 passed. Issues and Notes: There are a number of new crashes, but none of them looks critical so critical to be a stopper. Go for integration CRs for testing: 8029441: assert(!((nmethod*)_cb)->is_deopt_pc(_pc)) failed: invariant broken 8071770: G1 does not implement millis_since_last_gc which is needed by RMI GC 8145543: JPRT jobs see intermittent failures in compiler/floatingpoint/ModNaN.java 8159284: bigapps/Jetty - assert(jfa->last_Java_sp() > sp()) failed with JFR in use 8159917: Space character is missing in ClassLoaderData::print_value_on 8161030: GPL header missing comma after year 8161652: Crash with assert(ft == _type) failed in PhiNode::Value() 8161696: [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss328k 8162670: make of jtreg_tests fails if no tests are run, causing jprt test runs to also fail 8162852: Mark stress compiler and gc tests with stress keyword 8162999: Build give extraneous find warnings 8163269: Testcase missed in push for JDK-8160817 8163272: jhsdb jinfo cannot show system properties -- Alejandro From talden at gmail.com Wed Aug 17 19:35:04 2016 From: talden at gmail.com (Aaron Scott-Boddendijk) Date: Thu, 18 Aug 2016 07:35:04 +1200 Subject: JEP 110 - Violating Naming Convention ? In-Reply-To: References: <3BD5EC59-DFDE-4C79-B604-80BA8910E23F@oracle.com> <57B479D2.3030001@redhat.com> Message-ID: I agree that using METHOD() is clever. However I think it hides the fact that you're building the request, not executing it. Similarly the ".response()" on HttpRequest itself suggests you're just retrieving the response but this is where the execution happens. I would prefer the methods better describe what they're doing (verbs)... HttpResponse response = HttpRequest .create(URI.create("...")) .asGET() .send(); Still breaking the naming convention to clearly express the standard recognised HTTP method names but more clearly as setting an attribute. Then indicating where we're actually sending the request (HttpResponse being the method-call result, something everyone is familiar with). Then this makes more sense... HttpRequest request = HttpRequest .create(URI.create("...")) .asGET(); -- Aaron Scott-Boddendijk On Thu, Aug 18, 2016 at 3:02 AM, Mario Torre wrote: > On Wed, Aug 17, 2016 at 4:50 PM, Andrew Haley wrote: > > On 17/08/16 14:51, Rahman USTA wrote: > >> Thank you Pavel, this uncommon usage looks to me very weird. > >> > >> I hope it could be re-evaluated again. > > > > I don't agree. If you look at RFC 2616 you will see that the HTTP > > Method is called GET. All in capitals. In all documentation it is > > called GET. To call it, say, "get" would be the odd thing to do. > > > > Andrew. > > Indeed, it looks more clear this way. If you see POST and the likes > follow the same idea. > > If you think about that, you don't really "get" something as in the > general concept of java use of "get", what this method does is to > create a GET request (or similar a POST one). > > In my opinion is a clever way to highlight the API is not the usual > get/set styled bean. > > Cheers, > Mario > From lana.steuck at oracle.com Wed Aug 17 19:56:31 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 17 Aug 2016 19:56:31 GMT Subject: jdk9-b132: dev Message-ID: <201608171956.u7HJuVDV004545@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/a24702d4d5ab http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/55a75af751df http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/2c17b65a37a8 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d5c70818cd8a http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/9fff2477a4ca http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/907445d85e68 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/713951c08aa2 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/1ab4b9399c4c --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8163408 client-libs Fix wrong prototype of getNativeScaleFactor() in systemScale.h JDK-8134304 core-libs NPE in initialization of OptimisticTypesPersistence JDK-8136930 core-libs Simplify use of module-system options by custom launchers JDK-8144836 core-libs [TESTBUG] FJExceptionTableLeak and RemoveLeak fail with -XX:+UseParall JDK-8145732 core-libs Duplicate entry in http.nonProxyHosts will ignore subsequent entries JDK-8151158 core-libs [TESTBUG] java/util/concurrent/forkjoin/FJExceptionTableLeak.java fail JDK-8160611 core-libs Clean up ProblemList.txt for closed/resolved issues JDK-8162627 core-libs Miscellaneous changes imported from jsr166 CVS 2016-08 JDK-8162805 core-libs Optimize AtomicBoolean.getAndSet JDK-8163210 core-libs java/util/concurrent/tck/JSR166TestCase.java testWriteAfterReadLock(St JDK-8163305 core-libs Add some print instrumentation to java/nio/channels/Selector/RacyDereg JDK-8163370 core-libs Reduce number of classes loaded by common usage of java.lang.invoke JDK-8163373 core-libs Rewrite GenerateJLIClassesPlugin to avoid reflective calls into java.l JDK-8163431 core-libs probeContentType/Basic.java fails after changes for JDK-8146215 JDK-8163518 core-libs Integer overflow in StringBufferInputStream.read() and CharArrayReader JDK-8163533 core-libs jdk.vm.ci.hotspot.test.MethodHandleAccessProviderTest fails on jdk9/de JDK-8163586 core-libs java.net.http.RawChannel has been made public by mistake JDK-8163814 core-libs JDK build has been failing after 8163373 JDK-8163877 core-libs Tests added in JDK-8163518 fail on some platforms JDK-8163878 core-libs Remove unnecessary bridge methods, allocations in java.lang.invoke JDK-8163946 core-libs java/lang/String/concat/WithSecurityManager.java fails after 8163878 JDK-8163145 globalization Remove two "null" lines in the end of message.properties JDK-6469513 security-libs (smartcardio) CardPermission(String termName, String actions) violates JDK-8132943 security-libs ServerHandshaker may select non-empty OCSPStatusRequest structures whe JDK-8133910 security-libs Some sun/security/tools tests failed. JDK-8161340 security-libs ProblemList.txt update for sun/security/tools/keytool/autotest.sh JDK-8162362 security-libs Introduce system property to control enabled ciphersuites JDK-8162739 security-libs Create new keytool option to access cacerts file JDK-8163104 security-libs Unexpected NPE still possible on some Kerberos ticket calls JDK-8163435 security-libs Update issue number for SupportedDHKeys.java and UnsupportedDHKeys.jav JDK-8163489 security-libs Avoid using Utils.getFreePort() in TsacertOptionTest.java test JDK-8163503 security-libs PKCS12 keystore cannot store non-X.509 certificates JDK-8052398 tools Uniqify test framework class names JDK-8068626 tools Add javac lint warning when the @Deprecated annotation is used where i JDK-8075529 tools Documentation in DocumentationTool.getTask(...) should mention about " JDK-8129421 tools JShell: unacceptable suggestions in 'extends', 'implements' in smart c JDK-8129422 tools JShell: methods and fields of uncompleted expressions should be sugges JDK-8143048 tools Re-examine dependency on property sun.boot.class.path JDK-8143964 tools JShell API: convert query responses to Stream instead of List/Collecti JDK-8152054 tools fix @ignored langtools/test/jdk/javadoc/tool/ tests JDK-8156998 tools javac should support new option -XinheritRuntimeEnvironment JDK-8158295 tools Add a multi-release jar validation mechanism to jar tool JDK-8160137 tools HTMLDoclet and AbstractDoclet should implement Doclet JDK-8160156 tools javac is generating let expressions unnecessarily JDK-8160489 tools Multiple -Xpatch lines ignored by javac JDK-8160697 tools HTMLWriter needs perf cleanup JDK-8162711 tools javax.lang.model.util.Elements.getModuleElement returns null during an JDK-8163500 tools JShell: ProblemList.txt update: 8139872 and 8080843 fixed JDK-8163524 tools doclet resources doclet.usage.NAME.name are redundant JDK-8163817 tools JShell tests: disable minor failing editor tool cases: 8161276, 816381 JDK-8163468 xml javax/xml/jaxp/unittest/validation/Bug6773084Test.java fails intermitt JDK-8163535 xml javax/xml/jaxp/unittest/catalog/CatalogSupport2.java failed due to Soc From rahman.usta.88 at gmail.com Wed Aug 17 23:26:53 2016 From: rahman.usta.88 at gmail.com (Rahman USTA) Date: Thu, 18 Aug 2016 02:26:53 +0300 Subject: JEP 110 - Violating Naming Convention ? In-Reply-To: <20160818012043.00004d70.ecki@zusammenkunft.net> References: <3BD5EC59-DFDE-4C79-B604-80BA8910E23F@oracle.com> <20160818012043.00004d70.ecki@zusammenkunft.net> Message-ID: There is a JaxRS-Client API sample here; String entity = client.target("http://example.com/rest") .register(FilterForExampleCom.class) .path("resource/helloworld") .queryParam("greeting", "Hi World!") .request(MediaType.TEXT_PLAIN_TYPE) .header("some-header", "true") .get(String.class); I have liked this API design, it follows the traditional naming convention. 2016-08-18 2:20 GMT+03:00 Bernd Eckenfels : > Hello > > I think .get() or .put() would look even strange. With all uppercase > it is rather clear its an HTTP/2 method keyword. > > Gruss > Bernd > > Am Wed, 17 Aug 2016 > 16:51:18 +0300 schrieb Rahman USTA : > > > Thank you Pavel, this uncommon usage looks to me very weird. > > > > I hope it could be re-evaluated again. > > > > Thanks > > > > 2016-08-17 16:29 GMT+03:00 Pavel Rappo : > > > > > The correct mailing list for issues in java.net area would be > > > net-dev at openjdk.java.net > > > > > > IMO, these conventions are just guidelines. One can override them > > > in some circumstances where it makes a lot of sense. Yes, the > > > barrier for violations > > > should be high. I believe this is one of the cases. > > > > > > > On 17 Aug 2016, at 14:12, Rahman USTA > > > > wrote: > > > > > > > > Hello; > > > > > > > > I'm trying the new HTTP/2 Client API. For example I have a sample > > > > code below; > > > > > > > > HttpResponse response = HttpRequest > > > > .create(URI.create("https://istanbul-jug.org")) > > > > .GET() > > > > .response(); > > > > > > > > System.out.println(response.body(HttpResponse.asString())); > > > > > > > > It works excepted, however I see that the method name GET is > > > > written > > > fully > > > > uppercase. I have never seen this usage yet anywhere in Java. Is > > > > that a right usage in Java? > > > > > > > > Thanks. > > > > > > > > -- > > > > Rahman USTA > > > > Istanbul JUG > > > > https://github.com/rahmanusta > > > > > > > > > > > > -- Rahman USTA Istanbul JUG https://github.com/rahmanusta From weijun.wang at oracle.com Thu Aug 18 03:45:14 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 18 Aug 2016 11:45:14 +0800 Subject: Result: New JDK 9 Committer: Sibabrata Sahoo Message-ID: <7F7A3914-E419-4BFD-9421-84D1CB29C53C@oracle.com> Voting for Sibabrata Sahoo [1] is now closed. Yes: 11 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Wang Weijun [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004577.html From ecki at zusammenkunft.net Wed Aug 17 23:20:43 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Thu, 18 Aug 2016 01:20:43 +0200 Subject: JEP 110 - Violating Naming Convention ? In-Reply-To: References: <3BD5EC59-DFDE-4C79-B604-80BA8910E23F@oracle.com> Message-ID: <20160818012043.00004d70.ecki@zusammenkunft.net> Hello I think .get() or .put() would look even strange. With all uppercase it is rather clear its an HTTP/2 method keyword. Gruss Bernd Am Wed, 17 Aug 2016 16:51:18 +0300 schrieb Rahman USTA : > Thank you Pavel, this uncommon usage looks to me very weird. > > I hope it could be re-evaluated again. > > Thanks > > 2016-08-17 16:29 GMT+03:00 Pavel Rappo : > > > The correct mailing list for issues in java.net area would be > > net-dev at openjdk.java.net > > > > IMO, these conventions are just guidelines. One can override them > > in some circumstances where it makes a lot of sense. Yes, the > > barrier for violations > > should be high. I believe this is one of the cases. > > > > > On 17 Aug 2016, at 14:12, Rahman USTA > > > wrote: > > > > > > Hello; > > > > > > I'm trying the new HTTP/2 Client API. For example I have a sample > > > code below; > > > > > > HttpResponse response = HttpRequest > > > .create(URI.create("https://istanbul-jug.org")) > > > .GET() > > > .response(); > > > > > > System.out.println(response.body(HttpResponse.asString())); > > > > > > It works excepted, however I see that the method name GET is > > > written > > fully > > > uppercase. I have never seen this usage yet anywhere in Java. Is > > > that a right usage in Java? > > > > > > Thanks. > > > > > > -- > > > Rahman USTA > > > Istanbul JUG > > > https://github.com/rahmanusta > > > > > > From stuart.marks at oracle.com Fri Aug 19 00:16:09 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 18 Aug 2016 17:16:09 -0700 Subject: CFV: New JDK 9 Committer: Steve Drach In-Reply-To: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> References: <02705B6E-8BB6-4BC8-A85F-F66CF92AB460@oracle.com> Message-ID: <02d3df54-59d6-1e03-f37a-84418e33fec8@oracle.com> Vote: yes On 8/10/16 1:52 PM, Paul Sandoz wrote: > I hereby nominate Steve Drach (sdrach) to JDK 9 Committer. > > Steve has been working on the multi-release jar design and implementation and has contributed 16 change sets to JDK 9. > > Votes are due by Wednesday, Aug 24, 2016. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Paul. > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > http://hg.openjdk.java.net/jdk9/dev/langtools/log?revcount=2000&rev=desc(%22Contributed-by:%20steve.drach at oracle.com%22)%20or%20user(%22sdrach%22) > > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > From paul.sandoz at oracle.com Fri Aug 19 18:15:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 19 Aug 2016 11:15:12 -0700 Subject: RFR(m): 8145464: jdeprscan - java deprecation scanner (command-line tool) In-Reply-To: <4d01228b-a439-cb5d-6a21-c62d35bf67a5@oracle.com> References: <4d01228b-a439-cb5d-6a21-c62d35bf67a5@oracle.com> Message-ID: <7D1AD81E-2458-4A9E-B510-459DA8E40EBB@oracle.com> Hi, Here is a quick review. The code in general looks well structured and documented. Paul. CSV.java ? 74 static enum State { static is redundant CSVParseException.java ? 33 final String reason; ... 37 public CSVParseException(String reason, String input, int index) { 38 super(reason); 39 this.reason = reason; ? 53 public String getMessage() { 54 return reason + " at index " + index + ": " + input; 55 } Perhaps remove the reason field and use super.getMessage() ? LoadProc.java ? 65 List deprList = new ArrayList<>(); Make final? Main.java ? 100 final Set validReleases = Set.of("6", "7", "8", "9"); 101 final Set noForRemovalReleases = Set.of("6", "7", "8?); Can we produce the sequence using upper bound that is the current runtime version. Generally it would be nice to avoid updating this and other related code on every major release, if indeed that is possible. 224 if (! Files.isDirectory(Paths.get(dirname))) { Rogue space, or is that the style you prefer? 372 .flatMap(list -> list.stream()) list::stream Pretty ? 204 static final Pattern descPat = Pattern.compile("(?.*)\\((?.*)\\)(?.*)"); DESC_PAT 275 // public static void main(String[] args) { 276 // System.out.println(depr("", false)); 277 // System.out.println(depr("9", false)); 278 // System.out.println(depr("", true)); 279 // System.out.println(depr("9", true)); 280 // 281 // int[] pos = new int[] { 0 }; 282 // String desc = "I[F[[Ljava/util/Map$Entry;Z"; 283 // String t; 284 // 285 // while ((t = desc(desc, pos)) != null) { 286 // System.out.println(t); 287 // } 288 // } Wanna keep that? TraverseProc.java ? 95 // printPublicTypes(publicTypes); Keep? CPEntries.java ? 48 List classes; 49 List fieldRefs; 50 List methodRefs; 51 List interfaceMethodRefs; final? MethodSig ? 168 // public static void main(String[] args) { 169 // System.out.println(fromDesc("([Ljava/rmi/RMISecurityManager;)Ljava/lang/Object;")); 170 // System.out.println(fromDesc("([[IZLjava/lang/String;B[J)V")); 171 // System.out.println(fromDesc("()Ljava/lang/Object;")); 172 // System.out.println(fromDesc("(ISJZ)")); 173 // } In tests? Scan.java ? 339 // if (! startClassName.equals(foundClassName)) { 340 // System.err.printf(" method ref %s:%s%s resolved to %s%n", 341 // startClassName, findName, findDesc, curClass.getName()); 342 // } Remove? 591 } catch (IOException | ConstantPoolException ex) { Sometimes you use spaces between the ?|? and other times not in other files. TestScan ? 66 public void test1() throws IOException { Better name for test? > On 21 Jul 2016, at 17:16, Stuart Marks wrote: > > Hi all, > > Please review the code for "jdeprscan", the new Java deprecation scanner command-line tool. This is part of JEP 277, Enhanced Deprecation. > > The only deprecation warnings provided up until now are those from by javac, emitted when compiling Java source code. If you don't have the source code, or if it's inconvenient to recompile, it's hard to find out what deprecated APIs a class might be using. The jdeprscan tool will scan class files for uses of APIs that are deprecated in the JDK. (A future enhancement will allow scanning for deprecated APIs from other class libraries.) > > For example, consider the following source file, which compiles without warnings on JDK 8: > > ----- > package depr.example; > > import java.math.BigDecimal; > > public class Foo { > BigDecimal x(BigDecimal num) { > Runtime.getRuntime().traceInstructions(true); > return num.divide(BigDecimal.TEN, BigDecimal.ROUND_HALF_DOWN); > } > } > ----- > > It's possible to run jdeprscan over the compiled class file in order to detect uses of APIs newly deprecated in Java 9: > > ----- > $ jdeprscan -cp build/classes depr.example.Foo > class depr/example/Foo uses method java/lang/Runtime traceInstructions (Z)V deprecated FOR REMOVAL > class depr/example/Foo uses method java/math/BigDecimal divide (Ljava/math/BigDecimal;I)Ljava/math/BigDecimal; deprecated > ----- > > The output is somewhat cryptic and could stand to be cleaned up, but the information is all there. > > Here's the webrev: > > http://cr.openjdk.java.net/~smarks/reviews/8145464/webrev.0/ > > User-level documentation is currently a markdown file in the source code: > > http://cr.openjdk.java.net/~smarks/reviews/8145464/webrev.0/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md.html > > (Eventually, of course, this will be migrated to the right location.) > > Most of the changes are in the langtools repository, shown by the webrev above. There is a small change to the jdk repository to build a launcher for jdeprscan. The patch for that is appended below. > > Thanks, > > s'marks > > > > diff -r b211a52a7439 make/launcher/Launcher-jdk.jdeps.gmk > --- a/make/launcher/Launcher-jdk.jdeps.gmk Wed Jul 20 08:32:07 2016 -0700 > +++ b/make/launcher/Launcher-jdk.jdeps.gmk Thu Jul 21 14:09:38 2016 -0700 > @@ -36,3 +36,9 @@ > CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS \ > -DNEVER_ACT_AS_SERVER_CLASS_MACHINE, \ > )) > + > +$(eval $(call SetupBuildLauncher, jdeprscan, \ > + MAIN_CLASS := com.sun.tools.jdeprscan.Main, \ > + CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS \ > + -DNEVER_ACT_AS_SERVER_CLASS_MACHINE, \ > +)) From cthalinger at twitter.com Fri Aug 19 21:55:54 2016 From: cthalinger at twitter.com (Christian Thalinger) Date: Fri, 19 Aug 2016 11:55:54 -1000 Subject: CFV: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <7B8343E0-D244-4AB7-A41C-7FEEBB9B128A@twitter.com> Vote: yes > On Aug 10, 2016, at 3:45 AM, Zolt?n Maj? wrote: > > I hereby nominate Doug Simon (OpenJDK username: dnsimon) to JDK 9 Committer. > > Doug is a member of Oracle Labs and has been working on Java-related technologies for the past 15+ years. He is an Author in the JDK 9 Project and has contributed more than 35 changesets to JDK 9 (most of them related to JVMCI) [1]. > > Votes are due by Wednesday, Aug 24, 2016 @ 18:00 CEST. > > Only current JDK 9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > > > Zoltan > > [1] http://hg.openjdk.java.net/jdk9/hs-comp/hotspot/search/?rev=(keyword(%22doug.simon at oracle.com%22)%20or%20(author(dnsimon)%20and%20not%20desc(%22Contributed-by:%22)))%20and%20not%20desc(%22Merge%22)&revcount=500 > [2] http://openjdk.java.net/census#jdk9 > [3] |http://openjdk.java.net/projects/#committer-vote > > | From christian.tornqvist at oracle.com Sat Aug 20 13:12:10 2016 From: christian.tornqvist at oracle.com (Christian Tornqvist) Date: Sat, 20 Aug 2016 09:12:10 -0400 Subject: RFR(XXS): 8164520 - java/lang/ProcessHandle/Basic.java is missing @library tag Message-ID: <094601d1fae4$76106b10$62314130$@oracle.com> Hi everyone, Please review this small change that fixes a mistake made in JDK-8157957, the @library tag was supposed to be changed to /test/lib but instead got lost somewhere on the way. Verified the change locally. Webrev: http://cr.openjdk.java.net/~ctornqvi/webrev/8164520/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8164520 Thanks, Christian From coleen.phillimore at oracle.com Sat Aug 20 13:21:44 2016 From: coleen.phillimore at oracle.com (Coleen Phillimore) Date: Sat, 20 Aug 2016 09:21:44 -0400 Subject: RFR(XXS): 8164520 - java/lang/ProcessHandle/Basic.java is missing @library tag In-Reply-To: <094601d1fae4$76106b10$62314130$@oracle.com> References: <094601d1fae4$76106b10$62314130$@oracle.com> Message-ID: <688a0ef3-2d29-d1c0-11b6-4b9f09553e26@oracle.com> This looks good. I know how this one got through JPRT, it's because the jdk tests aren't run, right? thanks, Coleen On 8/20/16 9:12 AM, Christian Tornqvist wrote: > Hi everyone, > > > > Please review this small change that fixes a mistake made in JDK-8157957, > the @library tag was supposed to be changed to /test/lib but instead got > lost somewhere on the way. > > > > Verified the change locally. > > > > Webrev: > > http://cr.openjdk.java.net/~ctornqvi/webrev/8164520/webrev.00/ > > > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8164520 > > > > Thanks, > > Christian > From alejandro.murillo at oracle.com Mon Aug 22 19:10:33 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Mon, 22 Aug 2016 13:10:33 -0600 Subject: jdk9-dev: HotSpot Message-ID: jdk9-hs-2016-08-18 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/be1218f792a4 http://hg.openjdk.java.net/jdk9/dev/corba/rev/2021bfedf1c4 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a25e0fb60332 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/9490ba2e5e41 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/05e99eefda2b http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3cdae27c90b5 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/7efa4b3477b2 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/3a924b820d02 Component : VM Status : Go for integration Date : 08/22/2016 at 19:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-08-19-185713.amurillo.jdk9-hs-2016-08-18-snapshot Testing: 55 new failures, 2278 known failures, 1551469 passed. Issues and Notes: No stoppers have been detected so far. Go for integration CRs for testing: 8030221: Checking for anonymous class should check for NULL as well as potential nesting 8069540: Remove universal binaries support from hotspot build 8129523: java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java timeout 8133740: NMT for Linux/x86/x64 and bsd/x64 slowdebug builds includes NativeCallStack::NativeCallStack() frame in backtrace 8133747: NMT includes an extra stack frame due to assumption NMT is making on tail calls being used 8133749: os::current_frame() is not returning the proper frame on ARM and solaris-x64 8136818: Test compiler/arraycopy/TestEliminatedArrayCopyDeopt.java fails with "m1 failed" 8146697: VM crashes in test Test7005594 8157498: compiler/codecache/jmx/InitialAndMaxUsageTest.java times out on 32-bit platforms 8159461: bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or JavaThread 8160083: compiler.codecache.jmx.InitialAndMaxUsageTest can not be used w/ disabled SegmentedCodeCache 8160299: Test8015436 doesn't check which method was executed 8160833: ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg tip 8161026: GPL header missing comma in year 8161279: Various JMX-tests timed out 8162369: PPC64: Wrong ucontext used after SIGTRAP while in HTM critical section 8162477: [JVMCI] assert(wf.check_method_context(ctxk, m)) failed: proper context 8162553: Crash in class unloading due to null CLD having a zero _keep_alive value 8162881: Effect of -XX:CICompilerCount depends on ordering of other flags 8163018: Slow compiler tests in JPRT 8163105: SIGSEGV: constantPoolHandle::constantPoolHandle(ConstantPool*) 8163143: illegal bci error with interpreted frames in SA due to mirror being stored in interpreted frames 8163185: jhsdb jstack cannot work with normal mode 8163243: [TESTBUG] compiler/codecache/jmx/UsageThresholdIncreasedTest.java failed with: Failed to find sun/hotspot/WhiteBox.class 8163313: assert(comp != __null) failed: compiler not available 8163366: compiler/codecache/jmx/ThresholdNotificationsTest.java doesn't set -XX:+UnlockDiagnosticVMOptions while using WB 8163580: Cannot get Monitor Cache Dump in HSDB 8164012: com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output "Exception occurred: java.lang.IllegalMonitorStateException" not found -- Alejandro From paul.sandoz at oracle.com Mon Aug 22 22:22:13 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 22 Aug 2016 15:22:13 -0700 Subject: Exceptions thrown when linking sig-poly methods and indy Message-ID: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> Hi, For methods that make an appeal to Java code such as an up call from HotSpot to Java for linking signature-polymorphic methods or linking indy call sites (invoking bootstrap methods) it?s possible that certain important exceptions get wrapped in a LinkageError or a BootstrapMethodError. Such important exceptions are ThreadDeath, StackOverflow and possibly OOME. Some j.u.concurrent classes were updated to use VarHandles and this now very occasionally results in a test failure where ThreadDeath is wrapped in LinkageError and thus thread-based JDK code reacts differently. See https://bugs.openjdk.java.net/browse/JDK-8163553. It?s easier to reproduce by updating the failing test with an indy [1], which fails with various errors such as: Exception in thread "Thread-0" java.lang.BootstrapMethodError: call site initialization exception at java.lang.invoke.CallSite.makeSite(java.base/CallSite.java:347) at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(java.base/MethodHandleNatives.java:250) at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240) at Stop.lambda$test$1(Stop.java:15) at java.lang.Thread.run(java.base/Thread.java:843) Caused by: java.lang.ThreadDeath at java.lang.Thread.stop(java.base/Thread.java:948) at java.lang.ThreadGroup.stopOrSuspend(java.base/ThreadGroup.java:698) at java.lang.ThreadGroup.stop(java.base/ThreadGroup.java:610) at Stop.lambda$test$2(Stop.java:32) ... 1 more or more obscurely (and erroneously): Exception in thread "Thread-0" java.lang.InternalError: DMH.invokeStatic__V=Lambda(a0:L)=>{ t1:L=DirectMethodHandle.internalMemberName(a0:L); t2:V=MethodHandle.linkToStatic(t1:L);void} at java.lang.invoke.MethodHandleStatics.newInternalError(java.base/MethodHandleStatics.java:108) at java.lang.invoke.LambdaForm.compileToBytecode(java.base/LambdaForm.java:816) at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(java.base/DirectMethodHandle.java:249) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base/DirectMethodHandle.java:186) at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base/DirectMethodHandle.java:175) at java.lang.invoke.DirectMethodHandle.make(java.base/DirectMethodHandle.java:88) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.base/MethodHandles.java:2035) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(java.base/MethodHandles.java:1992) at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(java.base/MethodHandles.java:2223) at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(java.base/MethodHandles.java:2172) at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(java.base/MethodHandleNatives.java:499) at Stop.lambda$test$1(Stop.java:15) at java.lang.Thread.run(java.base/Thread.java:843) Caused by: java.lang.ThreadDeath at java.lang.Thread.stop(java.base/Thread.java:948) at java.lang.ThreadGroup.stopOrSuspend(java.base/ThreadGroup.java:698) at java.lang.ThreadGroup.stop(java.base/ThreadGroup.java:610) at Stop.lambda$test$2(Stop.java:32) ... 1 more The invokedynamic specification states that a linking exception be wrapped in BootstrapMethodError (a subtype of LinkageError): https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokedynamic I think we need to review how we manage certain special Error types thrown from linking, be the thrown directly or extracted from a known wrapping exception and re-thrown. Certainly there are cases when linking an indy call set where BootstrapMethodError should be thrown but is not (see above), but in general how should we treat the occurrence of a ThreadDeath, StackOverflow or OOME (or VirtualMachineError)? Should such exceptions be wrapped or thrown directly? if the latter that would require a specification update for invokedynamic. If they are wrapped should the VM check the cause, unwrap for special cases, and rethrow the cause? Paul. [1] import java.util.concurrent.CountDownLatch; public class Stop { public static void main(String[] args) throws Exception { test(); } public static void test() throws Exception { final CountDownLatch ready = new CountDownLatch(1); final ThreadGroup group = new ThreadGroup(""); final Thread second = new Thread(group, () -> { ready.countDown(); final Runnable r = () -> { System.out.println("RUN"); }; r.run(); while (true) { try { Thread.sleep(60000); } catch (InterruptedException shouldNotHappen) { } } }); final Thread first = new Thread(group, () -> { // Wait until "second" is started try { ready.await(); } catch (InterruptedException shouldNotHappen) { } // Now stop the group group.stop(); }); // Launch two threads as part of the same thread group first.start(); second.start(); // Check that the second thread is terminated when the // first thread terminates the thread group. second.join(); // Test passed - if never get here the test times out and fails. } } From david.holmes at oracle.com Mon Aug 22 22:58:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Aug 2016 08:58:50 +1000 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> Message-ID: <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> Hi Paul, As per my comments in the bug report I think the specification parts that state to wrap all "exceptions" are too strict (for want of a better word). One view is that they should only consider synchronous exceptions directly triggered by a problem with resolution. Another possibility is that "exception" was not intended to mean "any exception instance being a subclass of Throwable", but rather was intended to be Exception - and hence all subclasses of Error would be excluded. Or the spec is mostly right and (other than truly async exceptions like ThreadDeath) any exception encountered due to the linking should be wrapped. There are other places in the VM and libraries where exception wrapping occurs but I'm not sure if we have special handling for specific kinds of exceptions (Exceptions thrown during static initialization; Exceptions thrown during class loading/linking/resolution; exceptions thrown when a task is submitted to an Executor; etc). Cheers, David On 23/08/2016 8:22 AM, Paul Sandoz wrote: > Hi, > > For methods that make an appeal to Java code such as an up call from HotSpot to Java for linking signature-polymorphic methods or linking indy call sites (invoking bootstrap methods) it?s possible that certain important exceptions get wrapped in a LinkageError or a BootstrapMethodError. Such important exceptions are ThreadDeath, StackOverflow and possibly OOME. > > Some j.u.concurrent classes were updated to use VarHandles and this now very occasionally results in a test failure where ThreadDeath is wrapped in LinkageError and thus thread-based JDK code reacts differently. > > See https://bugs.openjdk.java.net/browse/JDK-8163553. > > It?s easier to reproduce by updating the failing test with an indy [1], which fails with various errors such as: > > Exception in thread "Thread-0" java.lang.BootstrapMethodError: call site initialization exception > at java.lang.invoke.CallSite.makeSite(java.base/CallSite.java:347) > at java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(java.base/MethodHandleNatives.java:250) > at java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandleNatives.java:240) > at Stop.lambda$test$1(Stop.java:15) > at java.lang.Thread.run(java.base/Thread.java:843) > Caused by: java.lang.ThreadDeath > at java.lang.Thread.stop(java.base/Thread.java:948) > at java.lang.ThreadGroup.stopOrSuspend(java.base/ThreadGroup.java:698) > at java.lang.ThreadGroup.stop(java.base/ThreadGroup.java:610) > at Stop.lambda$test$2(Stop.java:32) > ... 1 more > > or more obscurely (and erroneously): > > Exception in thread "Thread-0" java.lang.InternalError: DMH.invokeStatic__V=Lambda(a0:L)=>{ > t1:L=DirectMethodHandle.internalMemberName(a0:L); > t2:V=MethodHandle.linkToStatic(t1:L);void} > at java.lang.invoke.MethodHandleStatics.newInternalError(java.base/MethodHandleStatics.java:108) > at java.lang.invoke.LambdaForm.compileToBytecode(java.base/LambdaForm.java:816) > at java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(java.base/DirectMethodHandle.java:249) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base/DirectMethodHandle.java:186) > at java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base/DirectMethodHandle.java:175) > at java.lang.invoke.DirectMethodHandle.make(java.base/DirectMethodHandle.java:88) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.base/MethodHandles.java:2035) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManager(java.base/MethodHandles.java:1992) > at java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(java.base/MethodHandles.java:2223) > at java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(java.base/MethodHandles.java:2172) > at java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(java.base/MethodHandleNatives.java:499) > at Stop.lambda$test$1(Stop.java:15) > at java.lang.Thread.run(java.base/Thread.java:843) > Caused by: java.lang.ThreadDeath > at java.lang.Thread.stop(java.base/Thread.java:948) > at java.lang.ThreadGroup.stopOrSuspend(java.base/ThreadGroup.java:698) > at java.lang.ThreadGroup.stop(java.base/ThreadGroup.java:610) > at Stop.lambda$test$2(Stop.java:32) > ... 1 more > > > The invokedynamic specification states that a linking exception be wrapped in BootstrapMethodError (a subtype of LinkageError): > > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokedynamic > > > I think we need to review how we manage certain special Error types thrown from linking, be the thrown directly or extracted from a known wrapping exception and re-thrown. > > Certainly there are cases when linking an indy call set where BootstrapMethodError should be thrown but is not (see above), but in general how should we treat the occurrence of a ThreadDeath, StackOverflow or OOME (or VirtualMachineError)? > > Should such exceptions be wrapped or thrown directly? if the latter that would require a specification update for invokedynamic. > > If they are wrapped should the VM check the cause, unwrap for special cases, and rethrow the cause? > > Paul. > > [1] > import java.util.concurrent.CountDownLatch; > > public class Stop { > > public static void main(String[] args) throws Exception { > test(); > } > > public static void test() throws Exception { > final CountDownLatch ready = new CountDownLatch(1); > final ThreadGroup group = new ThreadGroup(""); > > final Thread second = new Thread(group, () -> { > ready.countDown(); > final Runnable r = () -> { System.out.println("RUN"); }; > r.run(); > while (true) { > try { > Thread.sleep(60000); > } catch (InterruptedException shouldNotHappen) { > } > } > }); > > final Thread first = new Thread(group, () -> { > // Wait until "second" is started > try { > ready.await(); > } catch (InterruptedException shouldNotHappen) { > } > // Now stop the group > group.stop(); > }); > > // Launch two threads as part of the same thread group > first.start(); > second.start(); > > // Check that the second thread is terminated when the > // first thread terminates the thread group. > second.join(); > // Test passed - if never get here the test times out and fails. > } > } > From john.r.rose at oracle.com Mon Aug 22 23:19:11 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 22 Aug 2016 16:19:11 -0700 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> Message-ID: <06987795-7DEC-42F5-B320-597FEDC14AE6@oracle.com> On Aug 22, 2016, at 3:22 PM, Paul Sandoz wrote: > The invokedynamic specification states that a linking exception be wrapped in BootstrapMethodError (a subtype of LinkageError): > > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms-6.5.invokedynamic Thanks for bringing this up. It is a known weak spot in JSR 292. If the resolution of a CP constant being fed into a BSM causes a linkage error (LE) there is no compelling reason to re-wrap it in a BSM, other than the over-simplified language of the spec. IIRC this language messes up exception structure from JDK 8 lambda capture, since that uses indy. > I think we need to review how we manage certain special Error types thrown from linking, be the thrown directly or extracted from a known wrapping exception and re-thrown. I would support wrapping fewer low-level conditions in BSME, especially those "around" and not "inside" the actual BSM call. (Where the BSM itself can help define what "around" means, as part of argument validation.) Especially LE's. Also Errors like TD/SOE/OOME/IE/VME that are logically "out of band" relative to the execution of the current bytecode. In retrospect, it would have been better to specify that any java.lang.Error arising from the linkage (including bootstrap) of an indy is just passed up directly through the bytecode that is suffering the linkage failure. Let the BSM itself catch and BSME-wrap such things, if it is important not to let them escape unwrapped. The main reason for BSME is to convert java.lang.Exceptions (even RTE's) to LinkageErrors, since BSM execution *is* linkage, and normal Exceptions cannot be allowed to leak. An older analogous case is core reflection, which throws InvocationTargetException to avoid allowing normal Exceptions to leak. Unlike BSME it is a checked exception, but otherwise similar questions arise about wrapping vs. passing. > Certainly there are cases when linking an indy call set where BootstrapMethodError should be thrown but is not (see above), but in general how should we treat the occurrence of a ThreadDeath, StackOverflow or OOME (or VirtualMachineError)? InternalError is one of those evil conditions that can occur out of band, and doesn't get wrapped. In the case you cite, the JSR 292 linkage logic is choking on a another such evil condition (TD) and throw up an IE. Throwing the right evil error is a QOI issue, rather than a spec. conformance issue. Any InternalError is a mark of bad QOI, rather than some correctly implemented spec. > Should such exceptions be wrapped or thrown directly? if the latter that would require a specification update for invokedynamic. We need a specification update. > If they are wrapped should the VM check the cause, unwrap for special cases, and rethrow the cause? We do too much of that already. Stuff like this: if (ex instanceof LinkageError) throw (LinkageError) ex; else throw new LinkageError(ex.getMessage(), ex); if (ex instanceof BootstrapMethodError) bex = (BootstrapMethodError) ex; else bex = new BootstrapMethodError("call site initialization exception", ex); The instanceof checks should be simply java.lang.Error, I think. That's the best classification we have, and it's not worth making a list of out-of-band Errors and in-band Errors. If you look at the set of subtypes you'll see many strange things (AWTError anyone?), but in the end all of them, being unchecked, are effectively throwable from anywhere. And like I said, more careful filtering can be done by the BSM itself. As a special note, if a BSM throws a *checked* exception, it will *always* be wrapped in a BSME. This is why (IIUC) the LambdaConversionException is checked: It is a specially distinguished internal error inside the lambda capture runtime, which will usually be found wrapped in a BSME. ? John From john.r.rose at oracle.com Mon Aug 22 23:24:38 2016 From: john.r.rose at oracle.com (John Rose) Date: Mon, 22 Aug 2016 16:24:38 -0700 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> Message-ID: <73396C3F-B1E5-48CE-B995-8DD0D6FE670A@oracle.com> On Aug 22, 2016, at 3:58 PM, David Holmes wrote: > > Another possibility is that "exception" was not intended to mean "any exception instance being a subclass of Throwable", but rather was intended to be Exception - and hence all subclasses of Error would be excluded. Actually, that's better than what I just posted in reply. The logic for wrapping should be more like: ? catch (Exception ex) { throw new BootstrapMethodError("call site initialization exception", ex); } else { // throw any LE, BSME, SOE, OOME, TheadDeath, etc., etc. throw ex; } Throwable has two subtypes: Exception and Error. There have occasional credible proposals to add a third subtype (e.g., to manage coroutine or closure exits), and saying "Exceptions are wrapped" is probably better than saying "non-Errors are wrapped", because it is more specific with respect to any eventual additions. ? John From david.holmes at oracle.com Tue Aug 23 00:19:23 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 23 Aug 2016 10:19:23 +1000 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <002401d1fcca$b8bc8150$2a3583f0$@apache.org> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> Message-ID: <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> On 23/08/2016 9:12 AM, Uwe Schindler wrote: > Hi, > > from my understanding of the spec: > >> As per my comments in the bug report I think the specification parts >> that state to wrap all "exceptions" are too strict (for want of a better >> word). One view is that they should only consider synchronous exceptions >> directly triggered by a problem with resolution. Another possibility is >> that "exception" was not intended to mean "any exception instance being >> a subclass of Throwable", but rather was intended to be Exception - and >> hence all subclasses of Error would be excluded. > > I think the spec says "exception" not "throwable", so only "Exception" subclasses should be wrapped. Errors should just be rethrown or not catched at all. "exception" (lower-case 'e') is a general term, all of the objects that can be caught in a catch block are exceptions. If you want to refer to specific types of exceptions then it needs to be clear e.g. Throwable, Exception, Error, etc - actual type names with capitals. >> Or the spec is mostly right and (other than truly async exceptions like >> ThreadDeath) any exception encountered due to the linking should be >> wrapped. > > Why only have special cases for such types? To me "Error" in general should never-ever be wrapped! Async exceptions can be considered special cases as they are not caused by the code being executed. Cheers, David > Uwe > >> There are other places in the VM and libraries where exception wrapping >> occurs but I'm not sure if we have special handling for specific kinds >> of exceptions (Exceptions thrown during static initialization; >> Exceptions thrown during class loading/linking/resolution; exceptions >> thrown when a task is submitted to an Executor; etc). >> >> Cheers, >> David >> >> On 23/08/2016 8:22 AM, Paul Sandoz wrote: >>> Hi, >>> >>> For methods that make an appeal to Java code such as an up call from >> HotSpot to Java for linking signature-polymorphic methods or linking indy call >> sites (invoking bootstrap methods) it?s possible that certain important >> exceptions get wrapped in a LinkageError or a BootstrapMethodError. Such >> important exceptions are ThreadDeath, StackOverflow and possibly OOME. >>> >>> Some j.u.concurrent classes were updated to use VarHandles and this now >> very occasionally results in a test failure where ThreadDeath is wrapped in >> LinkageError and thus thread-based JDK code reacts differently. >>> >>> See https://bugs.openjdk.java.net/browse/JDK-8163553. >>> >>> It?s easier to reproduce by updating the failing test with an indy [1], which >> fails with various errors such as: >>> >>> Exception in thread "Thread-0" java.lang.BootstrapMethodError: call site >> initialization exception >>> at java.lang.invoke.CallSite.makeSite(java.base/CallSite.java:347) >>> at >> java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(java.base/MethodHa >> ndleNatives.java:250) >>> at >> java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandle >> Natives.java:240) >>> at Stop.lambda$test$1(Stop.java:15) >>> at java.lang.Thread.run(java.base/Thread.java:843) >>> Caused by: java.lang.ThreadDeath >>> at java.lang.Thread.stop(java.base/Thread.java:948) >>> at >> java.lang.ThreadGroup.stopOrSuspend(java.base/ThreadGroup.java:698) >>> at java.lang.ThreadGroup.stop(java.base/ThreadGroup.java:610) >>> at Stop.lambda$test$2(Stop.java:32) >>> ... 1 more >>> >>> or more obscurely (and erroneously): >>> >>> Exception in thread "Thread-0" java.lang.InternalError: >> DMH.invokeStatic__V=Lambda(a0:L)=>{ >>> t1:L=DirectMethodHandle.internalMemberName(a0:L); >>> t2:V=MethodHandle.linkToStatic(t1:L);void} >>> at >> java.lang.invoke.MethodHandleStatics.newInternalError(java.base/MethodH >> andleStatics.java:108) >>> at >> java.lang.invoke.LambdaForm.compileToBytecode(java.base/LambdaForm.ja >> va:816) >>> at >> java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(java.base >> /DirectMethodHandle.java:249) >>> at >> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base/Dire >> ctMethodHandle.java:186) >>> at >> java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base/Dire >> ctMethodHandle.java:175) >>> at >> java.lang.invoke.DirectMethodHandle.make(java.base/DirectMethodHandle. >> java:88) >>> at >> java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.bas >> e/MethodHandles.java:2035) >>> at >> java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManag >> er(java.base/MethodHandles.java:1992) >>> at >> java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(java. >> base/MethodHandles.java:2223) >>> at >> java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(java.b >> ase/MethodHandles.java:2172) >>> at >> java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(java.bas >> e/MethodHandleNatives.java:499) >>> at Stop.lambda$test$1(Stop.java:15) >>> at java.lang.Thread.run(java.base/Thread.java:843) >>> Caused by: java.lang.ThreadDeath >>> at java.lang.Thread.stop(java.base/Thread.java:948) >>> at >> java.lang.ThreadGroup.stopOrSuspend(java.base/ThreadGroup.java:698) >>> at java.lang.ThreadGroup.stop(java.base/ThreadGroup.java:610) >>> at Stop.lambda$test$2(Stop.java:32) >>> ... 1 more >>> >>> >>> The invokedynamic specification states that a linking exception be wrapped >> in BootstrapMethodError (a subtype of LinkageError): >>> >>> https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms- >> 6.5.invokedynamic >>> >>> >>> I think we need to review how we manage certain special Error types >> thrown from linking, be the thrown directly or extracted from a known >> wrapping exception and re-thrown. >>> >>> Certainly there are cases when linking an indy call set where >> BootstrapMethodError should be thrown but is not (see above), but in >> general how should we treat the occurrence of a ThreadDeath, >> StackOverflow or OOME (or VirtualMachineError)? >>> >>> Should such exceptions be wrapped or thrown directly? if the latter that >> would require a specification update for invokedynamic. >>> >>> If they are wrapped should the VM check the cause, unwrap for special >> cases, and rethrow the cause? >>> >>> Paul. >>> >>> [1] >>> import java.util.concurrent.CountDownLatch; >>> >>> public class Stop { >>> >>> public static void main(String[] args) throws Exception { >>> test(); >>> } >>> >>> public static void test() throws Exception { >>> final CountDownLatch ready = new CountDownLatch(1); >>> final ThreadGroup group = new ThreadGroup(""); >>> >>> final Thread second = new Thread(group, () -> { >>> ready.countDown(); >>> final Runnable r = () -> { System.out.println("RUN"); }; >>> r.run(); >>> while (true) { >>> try { >>> Thread.sleep(60000); >>> } catch (InterruptedException shouldNotHappen) { >>> } >>> } >>> }); >>> >>> final Thread first = new Thread(group, () -> { >>> // Wait until "second" is started >>> try { >>> ready.await(); >>> } catch (InterruptedException shouldNotHappen) { >>> } >>> // Now stop the group >>> group.stop(); >>> }); >>> >>> // Launch two threads as part of the same thread group >>> first.start(); >>> second.start(); >>> >>> // Check that the second thread is terminated when the >>> // first thread terminates the thread group. >>> second.join(); >>> // Test passed - if never get here the test times out and fails. >>> } >>> } >>> > From uschindler at apache.org Mon Aug 22 23:12:54 2016 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 23 Aug 2016 01:12:54 +0200 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> Message-ID: <002401d1fcca$b8bc8150$2a3583f0$@apache.org> Hi, from my understanding of the spec: > As per my comments in the bug report I think the specification parts > that state to wrap all "exceptions" are too strict (for want of a better > word). One view is that they should only consider synchronous exceptions > directly triggered by a problem with resolution. Another possibility is > that "exception" was not intended to mean "any exception instance being > a subclass of Throwable", but rather was intended to be Exception - and > hence all subclasses of Error would be excluded. I think the spec says "exception" not "throwable", so only "Exception" subclasses should be wrapped. Errors should just be rethrown or not catched at all. > Or the spec is mostly right and (other than truly async exceptions like > ThreadDeath) any exception encountered due to the linking should be > wrapped. Why only have special cases for such types? To me "Error" in general should never-ever be wrapped! Uwe > There are other places in the VM and libraries where exception wrapping > occurs but I'm not sure if we have special handling for specific kinds > of exceptions (Exceptions thrown during static initialization; > Exceptions thrown during class loading/linking/resolution; exceptions > thrown when a task is submitted to an Executor; etc). > > Cheers, > David > > On 23/08/2016 8:22 AM, Paul Sandoz wrote: > > Hi, > > > > For methods that make an appeal to Java code such as an up call from > HotSpot to Java for linking signature-polymorphic methods or linking indy call > sites (invoking bootstrap methods) it?s possible that certain important > exceptions get wrapped in a LinkageError or a BootstrapMethodError. Such > important exceptions are ThreadDeath, StackOverflow and possibly OOME. > > > > Some j.u.concurrent classes were updated to use VarHandles and this now > very occasionally results in a test failure where ThreadDeath is wrapped in > LinkageError and thus thread-based JDK code reacts differently. > > > > See https://bugs.openjdk.java.net/browse/JDK-8163553. > > > > It?s easier to reproduce by updating the failing test with an indy [1], which > fails with various errors such as: > > > > Exception in thread "Thread-0" java.lang.BootstrapMethodError: call site > initialization exception > > at java.lang.invoke.CallSite.makeSite(java.base/CallSite.java:347) > > at > java.lang.invoke.MethodHandleNatives.linkCallSiteImpl(java.base/MethodHa > ndleNatives.java:250) > > at > java.lang.invoke.MethodHandleNatives.linkCallSite(java.base/MethodHandle > Natives.java:240) > > at Stop.lambda$test$1(Stop.java:15) > > at java.lang.Thread.run(java.base/Thread.java:843) > > Caused by: java.lang.ThreadDeath > > at java.lang.Thread.stop(java.base/Thread.java:948) > > at > java.lang.ThreadGroup.stopOrSuspend(java.base/ThreadGroup.java:698) > > at java.lang.ThreadGroup.stop(java.base/ThreadGroup.java:610) > > at Stop.lambda$test$2(Stop.java:32) > > ... 1 more > > > > or more obscurely (and erroneously): > > > > Exception in thread "Thread-0" java.lang.InternalError: > DMH.invokeStatic__V=Lambda(a0:L)=>{ > > t1:L=DirectMethodHandle.internalMemberName(a0:L); > > t2:V=MethodHandle.linkToStatic(t1:L);void} > > at > java.lang.invoke.MethodHandleStatics.newInternalError(java.base/MethodH > andleStatics.java:108) > > at > java.lang.invoke.LambdaForm.compileToBytecode(java.base/LambdaForm.ja > va:816) > > at > java.lang.invoke.DirectMethodHandle.makePreparedLambdaForm(java.base > /DirectMethodHandle.java:249) > > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base/Dire > ctMethodHandle.java:186) > > at > java.lang.invoke.DirectMethodHandle.preparedLambdaForm(java.base/Dire > ctMethodHandle.java:175) > > at > java.lang.invoke.DirectMethodHandle.make(java.base/DirectMethodHandle. > java:88) > > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodCommon(java.bas > e/MethodHandles.java:2035) > > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodNoSecurityManag > er(java.base/MethodHandles.java:1992) > > at > java.lang.invoke.MethodHandles$Lookup.getDirectMethodForConstant(java. > base/MethodHandles.java:2223) > > at > java.lang.invoke.MethodHandles$Lookup.linkMethodHandleConstant(java.b > ase/MethodHandles.java:2172) > > at > java.lang.invoke.MethodHandleNatives.linkMethodHandleConstant(java.bas > e/MethodHandleNatives.java:499) > > at Stop.lambda$test$1(Stop.java:15) > > at java.lang.Thread.run(java.base/Thread.java:843) > > Caused by: java.lang.ThreadDeath > > at java.lang.Thread.stop(java.base/Thread.java:948) > > at > java.lang.ThreadGroup.stopOrSuspend(java.base/ThreadGroup.java:698) > > at java.lang.ThreadGroup.stop(java.base/ThreadGroup.java:610) > > at Stop.lambda$test$2(Stop.java:32) > > ... 1 more > > > > > > The invokedynamic specification states that a linking exception be wrapped > in BootstrapMethodError (a subtype of LinkageError): > > > > https://docs.oracle.com/javase/specs/jvms/se8/html/jvms-6.html#jvms- > 6.5.invokedynamic > > > > > > I think we need to review how we manage certain special Error types > thrown from linking, be the thrown directly or extracted from a known > wrapping exception and re-thrown. > > > > Certainly there are cases when linking an indy call set where > BootstrapMethodError should be thrown but is not (see above), but in > general how should we treat the occurrence of a ThreadDeath, > StackOverflow or OOME (or VirtualMachineError)? > > > > Should such exceptions be wrapped or thrown directly? if the latter that > would require a specification update for invokedynamic. > > > > If they are wrapped should the VM check the cause, unwrap for special > cases, and rethrow the cause? > > > > Paul. > > > > [1] > > import java.util.concurrent.CountDownLatch; > > > > public class Stop { > > > > public static void main(String[] args) throws Exception { > > test(); > > } > > > > public static void test() throws Exception { > > final CountDownLatch ready = new CountDownLatch(1); > > final ThreadGroup group = new ThreadGroup(""); > > > > final Thread second = new Thread(group, () -> { > > ready.countDown(); > > final Runnable r = () -> { System.out.println("RUN"); }; > > r.run(); > > while (true) { > > try { > > Thread.sleep(60000); > > } catch (InterruptedException shouldNotHappen) { > > } > > } > > }); > > > > final Thread first = new Thread(group, () -> { > > // Wait until "second" is started > > try { > > ready.await(); > > } catch (InterruptedException shouldNotHappen) { > > } > > // Now stop the group > > group.stop(); > > }); > > > > // Launch two threads as part of the same thread group > > first.start(); > > second.start(); > > > > // Check that the second thread is terminated when the > > // first thread terminates the thread group. > > second.join(); > > // Test passed - if never get here the test times out and fails. > > } > > } > > From stuart.marks at oracle.com Tue Aug 23 02:29:18 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Mon, 22 Aug 2016 19:29:18 -0700 Subject: Moar updates to JEP 277 - Enhanced Deprecation - warnings policy Message-ID: <08ca2d08-3167-cc28-39a2-47da9ec60537@oracle.com> Hi all, I've updated the JEP 277 text once again, this time focused on the policy for issuing deprecation warnings. See the revised JEP text in the bug report: https://bugs.openjdk.java.net/browse/JDK-8065614 Specifically the following sections have been rewritten: - Deprecation vs. Introduction of Warning Messages - Impact of forRemoval on Warning Messages Policy - Suppression of Deprecation Warnings The material in these sections is not actually new; the previous version talked about these issues, but it was so terse as to be unintelligible. TL;DR: If code uses an API deprecated with forRemoval=true, the resulting warnings are not suppressed with the currently defined @SuppressWarnings("deprecation") annotation. Instead, these warnings can be suppressed with a different annotation, @SuppressWarnings("removal") The reason is that, if a deprecation warning is already suppressed with @SW("deprecation"), and the API is then "upgraded" to have forRemoval=true, this change will go unnoticed at use sites. This could lead to errors. See the JEP text for further details. s'marks From chris at hazelcast.com Tue Aug 23 04:57:43 2016 From: chris at hazelcast.com (Christoph Engelbert) Date: Tue, 23 Aug 2016 06:57:43 +0200 Subject: Moar updates to JEP 277 - Enhanced Deprecation - warnings policy In-Reply-To: <08ca2d08-3167-cc28-39a2-47da9ec60537@oracle.com> References: <08ca2d08-3167-cc28-39a2-47da9ec60537@oracle.com> Message-ID: Hey Stuart, Nice work, anyhow I wonder if there?s any idea how to deal with @SuppressWarnings(?all?) even though I hope people are not really using it. Is it handled like ?shoot yourself in the foot?? :-) Chris > On 23 Aug 2016, at 04:29, Stuart Marks wrote: > > Hi all, > > I've updated the JEP 277 text once again, this time focused on the policy for issuing deprecation warnings. See the revised JEP text in the bug report: > > https://bugs.openjdk.java.net/browse/JDK-8065614 > > Specifically the following sections have been rewritten: > > - Deprecation vs. Introduction of Warning Messages > - Impact of forRemoval on Warning Messages Policy > - Suppression of Deprecation Warnings > > The material in these sections is not actually new; the previous version talked about these issues, but it was so terse as to be unintelligible. > > TL;DR: If code uses an API deprecated with forRemoval=true, the resulting warnings are not suppressed with the currently defined > > @SuppressWarnings("deprecation") > > annotation. Instead, these warnings can be suppressed with a different annotation, > > @SuppressWarnings("removal") > > The reason is that, if a deprecation warning is already suppressed with @SW("deprecation"), and the API is then "upgraded" to have forRemoval=true, this change will go unnoticed at use sites. This could lead to errors. > > See the JEP text for further details. > > s'marks From jesper.wilhelmsson at oracle.com Tue Aug 23 11:07:33 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 23 Aug 2016 13:07:33 +0200 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga Message-ID: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. Yasumasa has contributed 47 changesets to JDK 9. In particular, he has been actively working in the serviceability area on serviceability tools and diagnostic commands. Votes are due by September 6, 2016. Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Three-Vote Consensus voting instructions, see [2]. /Jesper [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#reviewer-vote From jesper.wilhelmsson at oracle.com Tue Aug 23 11:09:02 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 23 Aug 2016 13:09:02 +0200 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: <2e80ebdb-4210-afe3-b4d6-170451898896@oracle.com> Vote: Yes /Jesper Den 23/8/16 kl. 13:07, skrev Jesper Wilhelmsson: > I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. > > Yasumasa has contributed 47 changesets to JDK 9. In particular, he has > been actively working in the serviceability area on serviceability tools > and diagnostic commands. > > Votes are due by September 6, 2016. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From vladimir.x.ivanov at oracle.com Tue Aug 23 11:26:24 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Tue, 23 Aug 2016 14:26:24 +0300 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: Vote: yes Best regards, Vladimir Ivanov On 8/23/16 2:07 PM, Jesper Wilhelmsson wrote: > I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. From volker.simonis at gmail.com Tue Aug 23 12:11:33 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 23 Aug 2016 14:11:33 +0200 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: Vote: yes Regards, Volker On Tue, Aug 23, 2016 at 1:07 PM, Jesper Wilhelmsson wrote: > I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. > > Yasumasa has contributed 47 changesets to JDK 9. In particular, he has > been actively working in the serviceability area on serviceability tools > and diagnostic commands. > > Votes are due by September 6, 2016. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From jesper.wilhelmsson at oracle.com Tue Aug 23 15:15:20 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Tue, 23 Aug 2016 17:15:20 +0200 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: I should have included the list of changes [3]. These are 39 more significant changes. To see the complete list is slightly complicated since Yasumasa used several email addresses when contributing changes and they are spread over the root repository, hotspot, and jdk. Thanks, /Jesper Den 23/8/16 kl. 13:07, skrev Jesper Wilhelmsson: > I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. > > Yasumasa has contributed 47 changesets to JDK 9. In particular, he has > been actively working in the serviceability area on serviceability tools > and diagnostic commands. > > Votes are due by September 6, 2016. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > [3] List of changes: [ 1] JDK-7015169: GC Cause not always set http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/c798c277ddd1 [ 2] JDK-8011934: sun.misc.PerfCounter calls Perf.createLong with incorrect parameters http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b81fac25d26 [ 3] JDK-6989981: jstack causes "fatal error: ExceptionMark destructor expects no pending exceptions" http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8ddc26f62476 [ 4] JDK-7090324: gclog rotation via external tool http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b5748753ad2f [ 5] JDK-8036003: Add --with-debug-symbols=[none|internal|external|zipped] http://hg.openjdk.java.net/jdk9/dev/rev/aa66642d2fff [ 6] JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2559e1d816ae [ 7] JDK-8049253: JVM crashes when GC log rotation is invoked with long path. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7923f573ee4c [ 8] JDK-8057556: JDP should better handle non-active interfaces http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 [ 9] JDK-8057746: Cannot handle JdpException in JMX agent initialization. http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 [10] JDK-8059586: hs_err report should treat redirected core pattern. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/30ed7423ae23 [11] JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5abc906fe3a8 [12] JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e51e9b3040c3 [13] JDK-8081295: Build failed with GCC 5.1.1 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7aaaac143eb0 [14] JDK-8081475: SystemTap does not work when JDK is compiled with GCC 5 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b1379cdd6933 [15] JDK-8140556: Add force rotation option to VM.log jcmd http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/37a97bb8b1ca [16] JDK-8144332: HSDB could not terminate when close button is pushed. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/2b1a65dd865e [17] JDK-8144965: Show oop pointer in call frame at HSDB. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4ca934c7547a [18] JDK-8147388: Add diagnostic commands to attach JVMTI agent. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/c364db766187 [19] JDK-8148659: Add all option to JSnap http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a074585a9f08 [20] JDK-8150723: HSDB toolbar icons are missing. http://hg.openjdk.java.net/jdk9/dev/rev/50a1521b75f9 [21] JDK-8151181: Add JSnap to jhsdb http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/508fcb923812 [22] JDK-8151674: STW phases at Concurrent GC should count in PerfCounter http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/252b571bbb86 [23] JDK-8151709: jhsdb should show help message in SALauncher. http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3635f6de52cf [24] JDK-8152435: (CL)HSDB should be started with no argument http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ce1d4d0683ed [25] JDK-8153073: UL: Set filesize option with k/m/g http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7647b778662d [26] JDK-8153074: UL: Show output option in VM.log jcmd http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/46fba2696985 [27] JDK-8153743: AllocateHeap() and ReallocateHeap() should use ALWAYSINLINE macro http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dffe59badb82 [28] JDK-8155089: UL: Remove trailing comma from log decoration list http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d525d1232cdc [29] JDK-8155730: HeapInfoDCmd should get Heap_lock http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a59a9a97bbda [30] JDK-8156033: jhsdb jmap cannot set heapdump name http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/22bf25cb9859 [31] JDK-8156133: FindCrashesAction in HSDB does not work except Solaris platform http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ae70ccde5447 [32] JDK-8156181: UL: File size limit on 32 bit Linux http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1b38b646e5c0 [33] JDK-8160294: Some client libraries cannot be bult with GCC 6 http://hg.openjdk.java.net/jdk9/client/jdk/rev/38185af88d22 [34] JDK-8160353: narrowing conversion error is occurred with GCC 6 http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/715b44fbeca1 [35] JDK-8160356: invalid suffix on literal warning is occurred with GCC 6 http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/5829c33488ad [36] JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/9674b6b8470f [37] JDK-8163185: jhsdb jstack cannot work with normal mode http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/56108f8bd06d [38] JDK-8163272: jhsdb jinfo cannot show system properties http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/48071f920ef6 [39] JDK-8163580: Cannot get Monitor Cache Dump in HSDB http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f37577c20a6b From vicente.romero at oracle.com Tue Aug 23 15:25:19 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Tue, 23 Aug 2016 11:25:19 -0400 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: <49b2dbb1-9435-6b9e-d3d6-72adcace16d9@oracle.com> vote: yes Vicente On 08/23/2016 11:15 AM, Jesper Wilhelmsson wrote: > I should have included the list of changes [3]. These are 39 more > significant changes. To see the complete list is slightly complicated > since Yasumasa used several email addresses when contributing changes > and they are spread over the root repository, hotspot, and jdk. > > Thanks, > /Jesper > > Den 23/8/16 kl. 13:07, skrev Jesper Wilhelmsson: >> I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. >> >> Yasumasa has contributed 47 changesets to JDK 9. In particular, he has >> been actively working in the serviceability area on serviceability tools >> and diagnostic commands. >> >> Votes are due by September 6, 2016. >> >> Only current JDK 9 Reviewers [1] are eligible to vote on this >> nomination. >> Votes must be cast in the open by replying to this mailing list. >> >> For Three-Vote Consensus voting instructions, see [2]. >> >> /Jesper >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#reviewer-vote >> > [3] List of changes: > > [ 1] JDK-7015169: GC Cause not always set > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/c798c277ddd1 > [ 2] JDK-8011934: sun.misc.PerfCounter calls Perf.createLong with > incorrect parameters > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b81fac25d26 > [ 3] JDK-6989981: jstack causes "fatal error: ExceptionMark destructor > expects no pending exceptions" > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/8ddc26f62476 > [ 4] JDK-7090324: gclog rotation via external tool > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b5748753ad2f > [ 5] JDK-8036003: Add > --with-debug-symbols=[none|internal|external|zipped] > http://hg.openjdk.java.net/jdk9/dev/rev/aa66642d2fff > [ 6] JDK-8017773: OpenJDK7 returns incorrect TrueType font metrics > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2559e1d816ae > [ 7] JDK-8049253: JVM crashes when GC log rotation is invoked with > long path. > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7923f573ee4c > [ 8] JDK-8057556: JDP should better handle non-active interfaces > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a1afd6e36f0 > [ 9] JDK-8057746: Cannot handle JdpException in JMX agent initialization. > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/37ac8a27a427 > [10] JDK-8059586: hs_err report should treat redirected core pattern. > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/30ed7423ae23 > [11] JDK-8068589: GCCause should distinguish jcmd GC.run from System.gc() > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/5abc906fe3a8 > [12] JDK-8076212: AllocateHeap() and ReallocateHeap() should be inlined. > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/e51e9b3040c3 > [13] JDK-8081295: Build failed with GCC 5.1.1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7aaaac143eb0 > [14] JDK-8081475: SystemTap does not work when JDK is compiled with GCC 5 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/b1379cdd6933 > [15] JDK-8140556: Add force rotation option to VM.log jcmd > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/37a97bb8b1ca > [16] JDK-8144332: HSDB could not terminate when close button is pushed. > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/2b1a65dd865e > [17] JDK-8144965: Show oop pointer in call frame at HSDB. > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/4ca934c7547a > [18] JDK-8147388: Add diagnostic commands to attach JVMTI agent. > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/c364db766187 > [19] JDK-8148659: Add all option to JSnap > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/a074585a9f08 > [20] JDK-8150723: HSDB toolbar icons are missing. > http://hg.openjdk.java.net/jdk9/dev/rev/50a1521b75f9 > [21] JDK-8151181: Add JSnap to jhsdb > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/508fcb923812 > [22] JDK-8151674: STW phases at Concurrent GC should count in PerfCounter > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/252b571bbb86 > [23] JDK-8151709: jhsdb should show help message in SALauncher. > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/3635f6de52cf > [24] JDK-8152435: (CL)HSDB should be started with no argument > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ce1d4d0683ed > [25] JDK-8153073: UL: Set filesize option with k/m/g > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/7647b778662d > [26] JDK-8153074: UL: Show output option in VM.log jcmd > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/46fba2696985 > [27] JDK-8153743: AllocateHeap() and ReallocateHeap() should use > ALWAYSINLINE macro > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/dffe59badb82 > [28] JDK-8155089: UL: Remove trailing comma from log decoration list > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/d525d1232cdc > [29] JDK-8155730: HeapInfoDCmd should get Heap_lock > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/a59a9a97bbda > [30] JDK-8156033: jhsdb jmap cannot set heapdump name > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/22bf25cb9859 > [31] JDK-8156133: FindCrashesAction in HSDB does not work except > Solaris platform > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/ae70ccde5447 > [32] JDK-8156181: UL: File size limit on 32 bit Linux > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/1b38b646e5c0 > [33] JDK-8160294: Some client libraries cannot be bult with GCC 6 > http://hg.openjdk.java.net/jdk9/client/jdk/rev/38185af88d22 > [34] JDK-8160353: narrowing conversion error is occurred with GCC 6 > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/715b44fbeca1 > [35] JDK-8160356: invalid suffix on literal warning is occurred with > GCC 6 > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/5829c33488ad > [36] JDK-8160361: SEGV occurred at JNIHandleBlock::oops_do(OopClosure*) > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/9674b6b8470f > [37] JDK-8163185: jhsdb jstack cannot work with normal mode > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/56108f8bd06d > [38] JDK-8163272: jhsdb jinfo cannot show system properties > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/48071f920ef6 > [39] JDK-8163580: Cannot get Monitor Cache Dump in HSDB > http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/f37577c20a6b From stuart.marks at oracle.com Tue Aug 23 17:27:02 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 23 Aug 2016 10:27:02 -0700 Subject: Moar updates to JEP 277 - Enhanced Deprecation - warnings policy In-Reply-To: References: <08ca2d08-3167-cc28-39a2-47da9ec60537@oracle.com> Message-ID: On 8/22/16 9:57 PM, Christoph Engelbert wrote: > Nice work, anyhow I wonder if there?s any idea how to deal with @SuppressWarnings(?all?) even though I hope people are not really using it. Is it handled like ?shoot yourself in the foot?? :-) Hi Chris, (I'm not sure that @SuppressWarnings("all") actually does anything. At least it doesn't do anything in javac. It might actually suppress all warnings in other compilers, though.) In any case, my main approach here is to try to prevent errors and accidents. The scenario about deprecations being "upgraded" to have forRemoval=true is happening in 9, so we want to make sure people are warned about pending removals, even if they've previously suppressed deprecation warnings. Now, if people deliberately shut off all warnings, then there isn't much we can do about that. So yes, we can't prevent people from shooting themselves in the foot, if they've deliberately disabled the safety. s'marks From jon.masamitsu at oracle.com Tue Aug 23 18:55:45 2016 From: jon.masamitsu at oracle.com (Jon Masamitsu) Date: Tue, 23 Aug 2016 11:55:45 -0700 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: <9660ec13-3c2f-b3e4-b458-9c59af93bc3e@oracle.com> Vote: yes On 8/23/2016 4:07 AM, Jesper Wilhelmsson wrote: > I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. > > Yasumasa has contributed 47 changesets to JDK 9. In particular, he has > been actively working in the serviceability area on serviceability tools > and diagnostic commands. > > Votes are due by September 6, 2016. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > From serguei.spitsyn at oracle.com Tue Aug 23 20:46:49 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Tue, 23 Aug 2016 13:46:49 -0700 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: <57BCB639.3050500@oracle.com> Vote: yes From john.r.rose at oracle.com Wed Aug 24 00:39:14 2016 From: john.r.rose at oracle.com (John Rose) Date: Tue, 23 Aug 2016 17:39:14 -0700 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> Message-ID: <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> On Aug 22, 2016, at 5:19 PM, David Holmes wrote: > > "exception" (lower-case 'e') is a general term, all of the objects that can be caught in a catch block are exceptions. If you want to refer to specific types of exceptions then it needs to be clear e.g. Throwable, Exception, Error, etc - actual type names with capitals. Yes, that's how the spec. works. I now think the spec. logic for wrapping BSME was written in error, partly because of the confusion between 'e' and 'E' exceptions. I.e., it's a design bug to fix in the spec. We need a tracking bug for this. >>> Or the spec is mostly right and (other than truly async exceptions like >>> ThreadDeath) any exception encountered due to the linking should be >>> wrapped. >> >> Why only have special cases for such types? To me "Error" in general should never-ever be wrapped! > > Async exceptions can be considered special cases as they are not caused by the code being executed. All unchecked exceptions (Errors) are special cases in that they are not cause by the specific API point that may throw them, but rather by some action of the JVM directly or indirectly triggered by the operation of an API. That's why SOE and OOME are synchronous but unchecked: They are not the product of any specific API point, even though they can leak through all API points. Async errors are obviously and severely unspecific like this, but every non-Exception has a similar character. Bottom line: We need stop wrapping non-Exceptions in BSME, and instead allow all non-Exceptions to percolate out of JVM runtime actions that happen behind bytecodes. Trying to distinguish "really unspecific" Errors from "specific though unchecked" Errors would be a losing game. (I know the JVMS seems to play that game by giving special status to some in JVMS 6.3, but the fact that it leaves out ThreadDeath means that list is incomplete. And there is no principle, in *any* spec., that would allow us to deduce that some subtype of java.lang.Error should be *excluded* from the 6.3 list.) ? John From stuart.marks at oracle.com Wed Aug 24 01:20:03 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 23 Aug 2016 18:20:03 -0700 Subject: RFR(m): 8145464: jdeprscan - java deprecation scanner (command-line tool) In-Reply-To: <7D1AD81E-2458-4A9E-B510-459DA8E40EBB@oracle.com> References: <4d01228b-a439-cb5d-6a21-c62d35bf67a5@oracle.com> <7D1AD81E-2458-4A9E-B510-459DA8E40EBB@oracle.com> Message-ID: <81f58c20-094c-19ac-cd2c-be88f7716e7f@oracle.com> Hi Paul, Thanks for the review and comments. All good stuff. I've pretty much updated everything as you proposed, with just a few comments and exceptions as noted below. > 224 if (! Files.isDirectory(Paths.get(dirname))) { > > Rogue space, or is that the style you prefer? Prevailing style seems to prefer no space, so I've adjusted my code accordingly. > 591 } catch (IOException | ConstantPoolException ex) { > > Sometimes you use spaces between the ?|? and other times not in other files. The majority of cases I saw had spaces around the "|" but the code base is somewhat inconsistent. As it happens I prefer the spaces, so I went along with the majority and made this code consistently uses spaces. > 100 final Set validReleases = Set.of("6", "7", "8", "9"); > 101 final Set noForRemovalReleases = Set.of("6", "7", "8?); > > Can we produce the sequence using upper bound that is the current runtime version. Generally it would be nice to avoid updating this and other related code on every major release, if indeed that is possible. This is fairly subtle, I think. The idea is to support the current version plus three old releases, as defined in JEP 182. [1] The obvious thing to do is to take the current runtime version and compute the three old releases from that. The release flag is basically passed straight to the compiler, but I don't know how the compiler determines its supported release. Simply computing the supported releases based on the runtime version might create a mismatch with the compiler (albeit a temporary one). Joe Darcy has a checklist of things that need to be done when the major version number is bumped. Either a manual step should be added to update jdeprscan, or jdeprscan should be modified to get the right information from somewhere and compute its supported releases from that. I'll have to check with Mr. Darcy. Meanwhile, I've filed JDK-8164700 [2] to track this. I've posted an updated webrev. [3] Thanks, s'marks [1] http://openjdk.java.net/jeps/182 [2] https://bugs.openjdk.java.net/browse/JDK-8164700 [3] http://cr.openjdk.java.net/~smarks/reviews/8145464/webrev.1/ On 8/19/16 11:15 AM, Paul Sandoz wrote: > Hi, > > Here is a quick review. > > The code in general looks well structured and documented. > > Paul. > > CSV.java > ? > > 74 static enum State { > > static is redundant > > > CSVParseException.java > ? > > 33 final String reason; > ... > 37 public CSVParseException(String reason, String input, int index) { > 38 super(reason); > 39 this.reason = reason; > ? > 53 public String getMessage() { > 54 return reason + " at index " + index + ": " + input; > 55 } > > Perhaps remove the reason field and use super.getMessage() ? > > > LoadProc.java > ? > > 65 List deprList = new ArrayList<>(); > > Make final? > > > Main.java > ? > > 100 final Set validReleases = Set.of("6", "7", "8", "9"); > 101 final Set noForRemovalReleases = Set.of("6", "7", "8?); > > Can we produce the sequence using upper bound that is the current runtime version. Generally it would be nice to avoid updating this and other related code on every major release, if indeed that is possible. > > > 224 if (! Files.isDirectory(Paths.get(dirname))) { > > Rogue space, or is that the style you prefer? > > > 372 .flatMap(list -> list.stream()) > > list::stream > > > Pretty > ? > > 204 static final Pattern descPat = Pattern.compile("(?.*)\\((?.*)\\)(?.*)"); > > DESC_PAT > > > 275 // public static void main(String[] args) { > 276 // System.out.println(depr("", false)); > 277 // System.out.println(depr("9", false)); > 278 // System.out.println(depr("", true)); > 279 // System.out.println(depr("9", true)); > 280 // > 281 // int[] pos = new int[] { 0 }; > 282 // String desc = "I[F[[Ljava/util/Map$Entry;Z"; > 283 // String t; > 284 // > 285 // while ((t = desc(desc, pos)) != null) { > 286 // System.out.println(t); > 287 // } > 288 // } > > Wanna keep that? > > > TraverseProc.java > ? > > 95 // printPublicTypes(publicTypes); > > Keep? > > > CPEntries.java > ? > > 48 List classes; > 49 List fieldRefs; > 50 List methodRefs; > 51 List interfaceMethodRefs; > > final? > > > MethodSig > ? > > 168 // public static void main(String[] args) { > 169 // System.out.println(fromDesc("([Ljava/rmi/RMISecurityManager;)Ljava/lang/Object;")); > 170 // System.out.println(fromDesc("([[IZLjava/lang/String;B[J)V")); > 171 // System.out.println(fromDesc("()Ljava/lang/Object;")); > 172 // System.out.println(fromDesc("(ISJZ)")); > 173 // } > > In tests? > > > Scan.java > ? > > 339 // if (! startClassName.equals(foundClassName)) { > 340 // System.err.printf(" method ref %s:%s%s resolved to %s%n", > 341 // startClassName, findName, findDesc, curClass.getName()); > 342 // } > > Remove? > > > 591 } catch (IOException | ConstantPoolException ex) { > > Sometimes you use spaces between the ?|? and other times not in other files. > > > TestScan > ? > > 66 public void test1() throws IOException { > > Better name for test? > > > > > >> On 21 Jul 2016, at 17:16, Stuart Marks wrote: >> >> Hi all, >> >> Please review the code for "jdeprscan", the new Java deprecation scanner command-line tool. This is part of JEP 277, Enhanced Deprecation. >> >> The only deprecation warnings provided up until now are those from by javac, emitted when compiling Java source code. If you don't have the source code, or if it's inconvenient to recompile, it's hard to find out what deprecated APIs a class might be using. The jdeprscan tool will scan class files for uses of APIs that are deprecated in the JDK. (A future enhancement will allow scanning for deprecated APIs from other class libraries.) >> >> For example, consider the following source file, which compiles without warnings on JDK 8: >> >> ----- >> package depr.example; >> >> import java.math.BigDecimal; >> >> public class Foo { >> BigDecimal x(BigDecimal num) { >> Runtime.getRuntime().traceInstructions(true); >> return num.divide(BigDecimal.TEN, BigDecimal.ROUND_HALF_DOWN); >> } >> } >> ----- >> >> It's possible to run jdeprscan over the compiled class file in order to detect uses of APIs newly deprecated in Java 9: >> >> ----- >> $ jdeprscan -cp build/classes depr.example.Foo >> class depr/example/Foo uses method java/lang/Runtime traceInstructions (Z)V deprecated FOR REMOVAL >> class depr/example/Foo uses method java/math/BigDecimal divide (Ljava/math/BigDecimal;I)Ljava/math/BigDecimal; deprecated >> ----- >> >> The output is somewhat cryptic and could stand to be cleaned up, but the information is all there. >> >> Here's the webrev: >> >> http://cr.openjdk.java.net/~smarks/reviews/8145464/webrev.0/ >> >> User-level documentation is currently a markdown file in the source code: >> >> http://cr.openjdk.java.net/~smarks/reviews/8145464/webrev.0/src/jdk.jdeps/share/classes/com/sun/tools/jdeprscan/readme.md.html >> >> (Eventually, of course, this will be migrated to the right location.) >> >> Most of the changes are in the langtools repository, shown by the webrev above. There is a small change to the jdk repository to build a launcher for jdeprscan. The patch for that is appended below. >> >> Thanks, >> >> s'marks >> >> >> >> diff -r b211a52a7439 make/launcher/Launcher-jdk.jdeps.gmk >> --- a/make/launcher/Launcher-jdk.jdeps.gmk Wed Jul 20 08:32:07 2016 -0700 >> +++ b/make/launcher/Launcher-jdk.jdeps.gmk Thu Jul 21 14:09:38 2016 -0700 >> @@ -36,3 +36,9 @@ >> CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS \ >> -DNEVER_ACT_AS_SERVER_CLASS_MACHINE, \ >> )) >> + >> +$(eval $(call SetupBuildLauncher, jdeprscan, \ >> + MAIN_CLASS := com.sun.tools.jdeprscan.Main, \ >> + CFLAGS := -DEXPAND_CLASSPATH_WILDCARDS \ >> + -DNEVER_ACT_AS_SERVER_CLASS_MACHINE, \ >> +)) > From forax at univ-mlv.fr Wed Aug 24 13:45:31 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Wed, 24 Aug 2016 15:45:31 +0200 (CEST) Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> Message-ID: <1714570337.573371.1472046331214.JavaMail.zimbra@u-pem.fr> Hi all, with my JSR 292 expert hat, i agree that the JSR 292 spec should be amended to not wraps errors in BSME but as far as i remember, the JLS doesn't has a reference to java.lang.Exception, only Throwable, Error and RuntimeException are mentioned in the spec. Throwable is the root of the checked exception, RuntimeException is the root of the unchecked one and Error is the root of the unchecked one that can be asynchronously thrown. IMHO, the spec should say that errors (subtyped of java.lang.Error) are not wrapped into BSME (like errors thrown in are not wrapped in ExceptionInInitializerError (see JLS 14.18)) and if in the future we add a new subtype to Throwable with some special ability, we will fix the spec for that. regards, R?mi ----- Mail original ----- > De: "John Rose" > ?: "David Holmes" > Cc: "Uwe Schindler" , "jdk9-dev" , "hotspot-dev" > > Envoy?: Mercredi 24 Ao?t 2016 02:39:14 > Objet: Re: Exceptions thrown when linking sig-poly methods and indy > On Aug 22, 2016, at 5:19 PM, David Holmes wrote: >> >> "exception" (lower-case 'e') is a general term, all of the objects that can be >> caught in a catch block are exceptions. If you want to refer to specific types >> of exceptions then it needs to be clear e.g. Throwable, Exception, Error, etc - >> actual type names with capitals. > > Yes, that's how the spec. works. I now think the spec. logic for wrapping BSME > was > written in error, partly because of the confusion between 'e' and 'E' > exceptions. > I.e., it's a design bug to fix in the spec. We need a tracking bug for this. > >>>> Or the spec is mostly right and (other than truly async exceptions like >>>> ThreadDeath) any exception encountered due to the linking should be >>>> wrapped. >>> >>> Why only have special cases for such types? To me "Error" in general should >>> never-ever be wrapped! >> >> Async exceptions can be considered special cases as they are not caused by the >> code being executed. > > All unchecked exceptions (Errors) are special cases in that they are not cause > by the specific > API point that may throw them, but rather by some action of the JVM directly or > indirectly > triggered by the operation of an API. That's why SOE and OOME are synchronous > but > unchecked: They are not the product of any specific API point, even though they > can > leak through all API points. Async errors are obviously and severely unspecific > like this, > but every non-Exception has a similar character. > > Bottom line: We need stop wrapping non-Exceptions in BSME, and instead allow > all non-Exceptions to percolate out of JVM runtime actions that happen behind > bytecodes. > > Trying to distinguish "really unspecific" Errors from "specific though > unchecked" Errors > would be a losing game. (I know the JVMS seems to play that game by giving > special > status to some in JVMS 6.3, but the fact that it leaves out ThreadDeath means > that > list is incomplete. And there is no principle, in *any* spec., that would allow > us to > deduce that some subtype of java.lang.Error should be *excluded* from the 6.3 > list.) > > ? John From paul.sandoz at oracle.com Wed Aug 24 17:04:32 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 24 Aug 2016 10:04:32 -0700 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> Message-ID: > On 23 Aug 2016, at 17:39, John Rose wrote: > > On Aug 22, 2016, at 5:19 PM, David Holmes wrote: >> >> "exception" (lower-case 'e') is a general term, all of the objects that can be caught in a catch block are exceptions. If you want to refer to specific types of exceptions then it needs to be clear e.g. Throwable, Exception, Error, etc - actual type names with capitals. > > Yes, that's how the spec. works. I now think the spec. logic for wrapping BSME was > written in error, partly because of the confusion between 'e' and 'E' exceptions. > I.e., it's a design bug to fix in the spec. We need a tracking bug for this. > Here it is: https://bugs.openjdk.java.net/browse/JDK-8164693 So we are talking about this kind of catch and re-throw pattern: try { x(); } catch (Throwable t) { if (t instanceof Error) { // Pass through any Error throw (Error) t; } // Wrap any Throwable that is not a subclass of Error throw new LinkageError(t.getMessage(), t); } Paul. From john.r.rose at oracle.com Wed Aug 24 17:18:36 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 24 Aug 2016 10:18:36 -0700 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> Message-ID: On Aug 24, 2016, at 10:04 AM, Paul Sandoz wrote: > > So we are talking about this kind of catch and re-throw pattern: > > try { > x(); > } catch (Throwable t) { > if (t instanceof Error) { > // Pass through any Error > throw (Error) t; > } > // Wrap any Throwable that is not a subclass of Error > throw new LinkageError(t.getMessage(), t); > } Yes. System-level methods should have "throws Throwable", in which case this equivalent formulation is slightly more future-proof IMO: try { x(); } catch (Throwable t) { if (!(t instanceof Exception)) { // Pass through any Error (or other non-Exception if such a thing exists) throw t; } // Wrap any Throwable that is not a subclass of Error throw new LinkageError(t.getMessage(), t); } From dean.long at oracle.com Wed Aug 24 18:37:00 2016 From: dean.long at oracle.com (dean.long at oracle.com) Date: Wed, 24 Aug 2016 11:37:00 -0700 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> Message-ID: On 8/24/16 10:18 AM, John Rose wrote: > On Aug 24, 2016, at 10:04 AM, Paul Sandoz wrote: >> So we are talking about this kind of catch and re-throw pattern: >> >> try { >> x(); >> } catch (Throwable t) { >> if (t instanceof Error) { >> // Pass through any Error >> throw (Error) t; >> } >> // Wrap any Throwable that is not a subclass of Error >> throw new LinkageError(t.getMessage(), t); >> } > Yes. > > System-level methods should have "throws Throwable", in which > case this equivalent formulation is slightly more future-proof IMO: > > try { > x(); > } catch (Throwable t) { > if (!(t instanceof Exception)) { > // Pass through any Error (or other non-Exception if such a thing exists) > throw t; > } > // Wrap any Throwable that is not a subclass of Error > throw new LinkageError(t.getMessage(), t); > } > Related to this, I always thought that java.lang.reflect.Method.invoke should do something similar when wrapping with InvocationTargetException. Does anyone think the Method.invoke spec or behavior also needs clarification? dl From lana.steuck at oracle.com Wed Aug 24 21:29:52 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 24 Aug 2016 21:29:52 GMT Subject: jdk9-b133: dev Message-ID: <201608242129.u7OLTqH6014884@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/be1218f792a4 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/3a924b820d02 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/7efa4b3477b2 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/3cdae27c90b5 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/05e99eefda2b http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/9490ba2e5e41 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a25e0fb60332 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/2021bfedf1c4 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-5080098 client-libs Page Range must be disabled on the common print dlg for Non serv-forma JDK-8039081 client-libs [TEST_BUG] Test java/awt/TrayIcon/PopupMenuLeakTest/PopupMenuLeakTest. JDK-8145014 client-libs "IIOException: Couldn't seek!" when calling TIFFImageReader.getNumImag JDK-8150154 client-libs AIOOB Exception during sequential write of TIFF images JDK-8152966 client-libs ClassCastException when adding IFD to the TIFFDirectory before the ima JDK-8155960 client-libs TIFF javadoc contains HTML entities inside {@code} tags JDK-8159638 client-libs Improve array caches and renderer stats in Marlin renderer JDK-8159696 client-libs java.beans.MethodRef#get throws NullPointerException JDK-8160696 client-libs IllegalArgumentException: adding a component to a container on a diffe JDK-8160986 client-libs Bad rendering of Swing UI controls with Metal L&F on HiDPI display JDK-8161483 client-libs Implement AccessibleAction interface in JList.AccessibleJList.Accessib JDK-8161664 client-libs Memory leak in com.apple.laf.AquaProgressBarUI: removed progress bar JDK-8162856 client-libs JSlider thumb is twice smaller on HiDPI display JDK-8162970 client-libs Merge error in the DefaultRowSorter.java JDK-8163177 client-libs Fix for 8152971 breaks builds with VS2010 JDK-8163238 client-libs Upgrade to harfbuzz 1.3.0 in JDK 9 JDK-8163583 client-libs [macosx] Press "To Back" button on the Dialog,the Dialog moves behind JDK-8163949 client-libs Cleanup of classes which are related to JavaSound JDK-8164515 client-libs Add back javadoc module description for java.se.ee JDK-7094818 core-libs closed/java/text/Format/DateFormat tests failed on Hindi JDK-8129555 core-libs DateFormatSymbols: month-related methods must refer to Calendar consta JDK-8132861 core-libs java/text/Format/DateFormat/Bug4845901.java failed in Thai locale JDK-8134733 core-libs java/util/Calendar/CalendarRegression.java failed in ar locale. JDK-8135055 core-libs java.util.Date.after(java.sql.Timestamp ) does not return correct resu JDK-8138661 core-libs Minor correction in Java API doc for DataSource JDK-8146602 core-libs jdk/test/sun/misc/URLClassPath/ClassnameCharTest.java test fails with JDK-8161965 core-libs Create initial javadoc description for modules JDK-8163350 core-libs LocaleProviderAdapter Preference list retrieved is wrong, when -Djava. JDK-8163517 core-libs Various cleanup in java.io code JDK-8163945 core-libs Honor Number type hint in toPrimitive on Numbers JDK-8164044 core-libs Generate corresponding simple DelegatingMethodHandles when generating JDK-8164102 core-libs MethodHandles.countedLoop/4 works incorrect for start/end = Integer.MA JDK-8164189 core-libs Collectors.toSet() parallel performance improvement JDK-8164216 core-libs Netbeans makefile for nashorn should use JDK_9 as platform JDK-8164260 core-libs readLine does not echo characters JDK-8164329 core-libs Problem list sun/rmi/runtime/Log/6409194/NoConsoleOutput.java on win JDK-8164394 core-libs JDK build fails after 8161965 JDK-8164432 core-libs java/nio/file/Files/probeContentType/Basic.java fails on windows for C JDK-8164451 core-libs Generate all zero and identity forms at link time JDK-8164485 core-libs Zero forms not properly generated JDK-8164525 core-libs Re-examine zero form link time pre-generation JDK-8164547 core-libs Make java.lang.reflect.ClassLoaderValue public for internal use JDK-8160833 core-svc ClassesByName2Test.java and RedefineCrossEvent.java failing with jtreg JDK-8163143 core-svc illegal bci error with interpreted frames in SA due to mirror being st JDK-8163185 core-svc jhsdb jstack cannot work with normal mode JDK-8163272 core-svc jhsdb jinfo cannot show system properties JDK-8163580 core-svc Cannot get Monitor Cache Dump in HSDB JDK-8148707 deploy [test]One case in javaws/EmbeddedCertificates couldn't find window wit JDK-8158206 deploy [TEST_BUG]Unable to launch "Java Runtime Environment Settings" dialog JDK-8158207 deploy At step2,Can not set security level from JCP->Security JDK-8162448 deploy [test] Some javaws cases that loading applet should be filtered out fo JDK-8162450 deploy [test] One case in JawsESLCertCheckTest failed due to the cert used to JDK-8162453 deploy [JCP] [Mac]Cannot launch JCP on Mac os with zh_CN, zh_TW locale JDK-8162463 deploy Resurrect remaining regression tests from com.sun.javaws.jnl JDK-8162503 deploy [test] JavawsCPBTest::testSignedAndUnsigned is very unstable JDK-8162957 deploy [test] Three cases in DialogFreqJawsTest failed due to fix of 8161468 JDK-8163117 deploy JCP - Delete files not working JDK-8163461 deploy [test] Need to evaluate SignedJNLPTest::testSimpleLiveConnectJNLPApple JDK-8163843 deploy [test] jp2launcher.exe has been renamed to jweblauncher.exe JDK-8163844 deploy dtjava - chrome / edge browser - "Java Plug-in is not supported by thi JDK-8158486 globalization remove wtpg id from jaxp resource files in JDK9 JDK-8029441 hotspot assert(!((nmethod*)_cb)->is_deopt_pc(_pc)) failed: invariant broken JDK-8030221 hotspot Checking for anonymous class should check for NULL as well as potentia JDK-8066115 hotspot tc04t001 fails intermittently in nightly testing JDK-8071770 hotspot G1 does not implement millis_since_last_gc which is needed by RMI GC JDK-8129523 hotspot java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java timeout JDK-8133740 hotspot NMT for Linux/x86/x64 and bsd/x64 slowdebug builds includes NativeCall JDK-8146697 hotspot VM crashes in test Test7005594 JDK-8157498 hotspot compiler/codecache/jmx/InitialAndMaxUsageTest.java times out on 32-bit JDK-8159461 hotspot bigapps/Kitchensink/stressExitCode hits assert: Must be VMThread or J JDK-8159917 hotspot Space character is missing in ClassLoaderData::print_value_on JDK-8160083 hotspot compiler.codecache.jmx.InitialAndMaxUsageTest can not be used w/ disab JDK-8160299 hotspot Test8015436 doesn't check which method was executed JDK-8161279 hotspot Various JMX-tests timed out JDK-8161652 hotspot Crash with assert(ft == _type) failed in PhiNode::Value() JDK-8161696 hotspot [TESTBUG] runtime/StackGuardPages/testme.sh uses invalid argument -Xss JDK-8162369 hotspot ppc: Wrong ucontext used after SIGTRAP while in HTM critical section JDK-8162477 hotspot [JVMCI] assert(wf.check_method_context(ctxk, m)) failed: proper contex JDK-8162553 hotspot Crash in class unloading due to null CLD having a zero _keep_alive val JDK-8162670 hotspot make of jtreg_tests fails if no tests are run, causing jprt test runs JDK-8162852 hotspot Mark stress compiler and gc tests with stress keyword JDK-8162881 hotspot Effect of -XX:CICompilerCount depends on ordering of other flags JDK-8162999 hotspot Build give extraneous find warnings JDK-8163018 hotspot Slow compiler tests in JPRT JDK-8163105 hotspot SIGSEGV: constantPoolHandle::constantPoolHandle(ConstantPool*) JDK-8163243 hotspot [TESTBUG] compiler/codecache/jmx/UsageThresholdIncreasedTest.java fail JDK-8163269 hotspot Testcase missed in push for JDK-8160817 JDK-8163289 hotspot Remove SA-JDI from tests JDK-8163313 hotspot assert(comp != __null) failed: compiler not available JDK-8163366 hotspot compiler/codecache/jmx/ThresholdNotificationsTest.java doesn't set -XX JDK-8163879 hotspot quarantine serviceability/sa/sadebugd/SADebugDTest.java since it hangs JDK-8163937 hotspot ActiveRecording recordingDuration unit says nanos, values is in millis JDK-8163970 hotspot [TESTBUG] Remove nsk/jvmti/Retransform/retransform001 test from coloca JDK-8164012 hotspot com/sun/jdi/CatchPatternTest.sh fails on jdk9/hs with Required output JDK-8069540 infrastructure Remove universal binaries support from hotspot build JDK-8164402 infrastructure key word 'requires' appearing in comment causing a build failure JDK-6482493 install installers fail when installed on mapped drive JDK-6977937 security-libs The SunJCE PBKDF2KeyImpl is requiring the MAC instance also be from Su JDK-8078661 security-libs [SunPKCS11] Fails to cast into RSAPrivateCrtKey after RSA KeyPair Gene JDK-8087144 security-libs sun/security/krb5/auto/MaxRetries.java fails with Retry count is -1 le JDK-8130181 security-libs Deprecate java.security.Provider(String, double, String), add Provider JDK-8141411 security-libs keytool can wrongly parse the start date value given by the -startdate JDK-8153146 security-libs sun/security/krb5/auto/MaxRetries.java failed with timeout JDK-8153438 security-libs Avoid repeated "Please insert a smart card" popup windows JDK-8156192 security-libs Provider#compute and #merge methods expect wrong permission & #compute JDK-8156841 security-libs sun.security.pkcs11.SunPKCS11 poller thread retains a strong reference JDK-8159964 security-libs Update Tests to verify JDK build for "JDK-8159488 Deprivilege java.xml JDK-8162484 security-libs javax/net/ssl/Stapling/SSLSocketWithStapling.java test fails intermitt JDK-8162808 security-libs Add references to the standard JSSE cipher suite names in javadoc JDK-8163896 security-libs Finalizing one key of a KeyPair invalidates the other key JDK-8164071 security-libs Default.policy file missing content for solaris JDK-8164100 security-libs com/sun/crypto/provider/KeyFactory/TestProviderLeak.java fails with ja JDK-8164397 security-libs Provide javadoc descriptions for the jdk.security.auth and jdk.securit JDK-8164437 security-libs Test for JDK-8042900 JDK-8164494 security-libs SunPKCS11 requires a non-empty PBE password JDK-8072052 tools
part of
list in javadoc should not be in monospace font JDK-8078561 tools Error message should be generated once when -source 6 is specified JDK-8080347 tools jshell tool: /vars when the status is other than Active JDK-8135291 tools [javadoc] broken link in Package com.sun.tools.jconsole JDK-8153391 tools an image created for "jdk.compiler" fails to run javac JDK-8154374 tools JShell: setContextClassLoader() for remote Snippet class loader JDK-8155995 tools Update javadoc to include module search JDK-8156911 tools JShell: file manager should be closed JDK-8157512 tools AssertionError in javac when module-info < v53.0 JDK-8157519 tools Error messages when compiling a malformed module-info.java confusing JDK-8158906 tools JShell: crashes with extremely long result value JDK-8159027 tools JShell API: SourceCodeAnalysis.Suggestion has constructor, ... JDK-8159305 tools Enhance the javadoc tool to support module related options JDK-8159713 tools Make the non-translated keywords clear to translator in jar.properties JDK-8162353 tools javadoc should provide a way to disable use of frames JDK-8162576 tools Missing doclint check missing for modules JDK-8163800 tools The fix for JDK-8072052 shows up other minor incorrect use of styles JDK-8163999 tools Workaround intermittent failures of TreePosTest.java due to C2 memory JDK-8164277 tools JShell API: Snippets are immutable and should be available for post-mo JDK-8164326 tools jrtfsviewer.js and jrtls.js does not work JDK-8164481 tools Remove jtreg run configurations from langtools idea project JDK-8164550 tools tools/javac/modules/InheritRuntimeEnvironmentTest.java fails on Window JDK-6211561 xml XPath.evaluate(String,Object,QName) throws exception if context node i JDK-8146961 xml Fix PermGen memory leaks caused by static final Exceptions From david.holmes at oracle.com Wed Aug 24 22:02:01 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Aug 2016 08:02:01 +1000 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> Message-ID: <3afa6372-0d46-b3a3-3526-d17207fc8b00@oracle.com> On 25/08/2016 4:37 AM, dean.long at oracle.com wrote: > On 8/24/16 10:18 AM, John Rose wrote: > >> On Aug 24, 2016, at 10:04 AM, Paul Sandoz wrote: >>> So we are talking about this kind of catch and re-throw pattern: >>> >>> try { >>> x(); >>> } catch (Throwable t) { >>> if (t instanceof Error) { >>> // Pass through any Error >>> throw (Error) t; >>> } >>> // Wrap any Throwable that is not a subclass of Error >>> throw new LinkageError(t.getMessage(), t); >>> } >> Yes. >> >> System-level methods should have "throws Throwable", in which >> case this equivalent formulation is slightly more future-proof IMO: >> >> try { >> x(); >> } catch (Throwable t) { >> if (!(t instanceof Exception)) { >> // Pass through any Error (or other non-Exception if such a >> thing exists) >> throw t; >> } >> // Wrap any Throwable that is not a subclass of Error >> throw new LinkageError(t.getMessage(), t); >> } >> > Related to this, I always thought that java.lang.reflect.Method.invoke > should do something similar when wrapping with > InvocationTargetException. Does anyone think the Method.invoke spec or > behavior also needs clarification? There is a long history of problems in this area - see Class.newInstance for example (which can throw undeclared checked exceptions!). Unfortunately for public API's the ship has sailed and we really can't do anything to change the existing behaviour. David > dl From john.r.rose at oracle.com Wed Aug 24 22:20:19 2016 From: john.r.rose at oracle.com (John Rose) Date: Wed, 24 Aug 2016 15:20:19 -0700 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <3afa6372-0d46-b3a3-3526-d17207fc8b00@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> <3afa6372-0d46-b3a3-3526-d17207fc8b00@oracle.com> Message-ID: <9384D0E3-6ABB-425E-B481-F7FC85CAFC0F@oracle.com> On Aug 24, 2016, at 3:02 PM, David Holmes wrote: > > There is a long history of problems in this area - see Class.newInstance for example (which can throw undeclared checked exceptions!). Unfortunately for public API's the ship has sailed and we really can't do anything to change the existing behaviour. That's true for checked exceptions. For unchecked errors, at least some of them, the implementation has always had the right to move them around. It would be reasonable, for example, for an implementation to vary in its choice to wrap, or not to wrap, a stack overflow error, or out of memory error, or thread-death, when passing through Method.invoke. That's what we are talking about. That said, a very old API like jli.Method::invoke is going to have a lot of folks placing a lot of unstated expectations on it. But a relatively new one like invokedynamic, which does not yet have a wide range of use cases, can be changed without breaking many bits of code. ? John From david.holmes at oracle.com Wed Aug 24 22:34:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 25 Aug 2016 08:34:39 +1000 Subject: Exceptions thrown when linking sig-poly methods and indy In-Reply-To: <9384D0E3-6ABB-425E-B481-F7FC85CAFC0F@oracle.com> References: <13048E4B-60B7-49C0-BDD7-E0AB4655C40C@oracle.com> <4a61f5f4-97eb-8b11-375c-49481f247eb3@oracle.com> <002401d1fcca$b8bc8150$2a3583f0$@apache.org> <0efedfb8-0fc6-ee42-9dea-4e1c79785af1@oracle.com> <4F341663-DBD0-4FC5-8739-2DB653EE48CB@oracle.com> <3afa6372-0d46-b3a3-3526-d17207fc8b00@oracle.com> <9384D0E3-6ABB-425E-B481-F7FC85CAFC0F@oracle.com> Message-ID: <8724c4cb-2188-36e7-7893-4429b729fb57@oracle.com> On 25/08/2016 8:20 AM, John Rose wrote: > On Aug 24, 2016, at 3:02 PM, David Holmes > wrote: >> >> There is a long history of problems in this area - see >> Class.newInstance for example (which can throw undeclared checked >> exceptions!). Unfortunately for public API's the ship has sailed and >> we really can't do anything to change the existing behaviour. > > That's true for checked exceptions. For unchecked errors, at least some > of them, > the implementation has always had the right to move them around. > It would be reasonable, for example, for an implementation to vary in > its choice > to wrap, or not to wrap, a stack overflow error, or out of memory error, > or thread-death, when passing through Method.invoke. That's what > we are talking about. > > That said, a very old API like jli.Method::invoke is going to have a lot > of folks placing a lot of unstated expectations on it. But a relatively That's exactly my point - for compatibility reasons we can't make changes to existing behaviour in these core APIs. > new one like invokedynamic, which does not yet have a wide range > of use cases, can be changed without breaking many bits of code. Presumably java.lang.invoke.* API's are in a similar position to java.lang.reflect etc - but I'm not very familiar with them. David ----- > ? John From paul.sandoz at oracle.com Thu Aug 25 17:52:38 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 25 Aug 2016 10:52:38 -0700 Subject: Result: New JDK9 Committer: Steve Drach Message-ID: <8DA727D3-B9F1-4362-BBE2-366761D5EE5E@oracle.com> Voting for Steve Drach is now closed [1] Yes: 19 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Paul. [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004611.html From stuart.marks at oracle.com Fri Aug 26 03:43:18 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 25 Aug 2016 20:43:18 -0700 Subject: RFR: 8164829 & 8164830: back out jdeprscan Message-ID: <4ef5047c-55ea-1fef-624f-872345dee60f@oracle.com> Sigh, I just pushed jdeprscan and our internal builds failed various source code checks. I haven't fully determined why, so meanwhile I'll just back everything out. Webrevs: langtools - http://cr.openjdk.java.net/~smarks/reviews/8164829/webrev.0/ jdk - http://cr.openjdk.java.net/~smarks/reviews/8164830/webrev.0/ Please review. Thanks. s'marks From joe.darcy at oracle.com Fri Aug 26 04:05:44 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 25 Aug 2016 21:05:44 -0700 Subject: RFR: 8164829 & 8164830: back out jdeprscan In-Reply-To: <4ef5047c-55ea-1fef-624f-872345dee60f@oracle.com> References: <4ef5047c-55ea-1fef-624f-872345dee60f@oracle.com> Message-ID: <5b51e4ad-8123-72d2-c630-892a083222a9@oracle.com> Hi Stuart, I've looked over the failures. Three tests fail: * One that checks that commands have a -version option. * One new jdeprscan test on windows. * A langtools tests that checks for consistency of APIs using annotations. Rather than backing out all of jdeprscan, I'd advise to instead add the jdeprscan command to the whitelist for the -version test and temporarily problem list the other two tests on affected platforms. I trust the two problem lists test failures should then be able to be resolved and returned into active service within a day or so. Thanks for being diligent on checking for test failures, -Joe On 8/25/2016 8:43 PM, Stuart Marks wrote: > Sigh, I just pushed jdeprscan and our internal builds failed various > source code checks. I haven't fully determined why, so meanwhile I'll > just back everything out. Webrevs: > > langtools - > > http://cr.openjdk.java.net/~smarks/reviews/8164829/webrev.0/ > > jdk - > > http://cr.openjdk.java.net/~smarks/reviews/8164830/webrev.0/ > > Please review. > > Thanks. > > s'marks From stuart.marks at oracle.com Fri Aug 26 04:36:25 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 25 Aug 2016 21:36:25 -0700 Subject: RFR: 8164829 & 8164830: back out jdeprscan In-Reply-To: <5b51e4ad-8123-72d2-c630-892a083222a9@oracle.com> References: <4ef5047c-55ea-1fef-624f-872345dee60f@oracle.com> <5b51e4ad-8123-72d2-c630-892a083222a9@oracle.com> Message-ID: <260b3bcd-b14d-4e5b-a92c-fbbd76756c2e@oracle.com> OK, great, thanks Joe, this will be a lot less disruptive. I've filed a few bugs: JDK-8164835 add a few tools tests to the problem list JDK-8164834 remove jdeprscan from tools/launcher/VersionCheck.java I'll post reviews shortly. s'marks On 8/25/16 9:05 PM, joe darcy wrote: > Hi Stuart, > > I've looked over the failures. Three tests fail: > > * One that checks that commands have a -version option. > > * One new jdeprscan test on windows. > > * A langtools tests that checks for consistency of APIs using annotations. > > Rather than backing out all of jdeprscan, I'd advise to instead add the > jdeprscan command to the whitelist for the -version test and temporarily problem > list the other two tests on affected platforms. > > I trust the two problem lists test failures should then be able to be resolved > and returned into active service within a day or so. > > Thanks for being diligent on checking for test failures, > > -Joe > > > On 8/25/2016 8:43 PM, Stuart Marks wrote: >> Sigh, I just pushed jdeprscan and our internal builds failed various source >> code checks. I haven't fully determined why, so meanwhile I'll just back >> everything out. Webrevs: >> >> langtools - >> >> http://cr.openjdk.java.net/~smarks/reviews/8164829/webrev.0/ >> >> jdk - >> >> http://cr.openjdk.java.net/~smarks/reviews/8164830/webrev.0/ >> >> Please review. >> >> Thanks. >> >> s'marks > From stuart.marks at oracle.com Fri Aug 26 04:39:21 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 25 Aug 2016 21:39:21 -0700 Subject: RFR(xs): 8164834: remove jdeprscan from tools/launcher/VersionCheck.java Message-ID: <496c2648-d118-d14b-2d73-0027a14288f9@oracle.com> One-line diff appended below. (This is adding to a blacklist, so it's effectively a removal.) Thanks, s'marks # HG changeset patch # User smarks # Date 1472186261 25200 # Thu Aug 25 21:37:41 2016 -0700 # Node ID e25d07a84bebf82616b2e84a469760757f2679b7 # Parent 7e21149a616e3e4f5c604a4ed25253e6e9ebdfa1 8164834: remove jdeprscan from tools/launcher/VersionCheck.java Reviewed-by: darcy diff -r 7e21149a616e -r e25d07a84beb test/tools/launcher/VersionCheck.java --- a/test/tools/launcher/VersionCheck.java Thu Aug 25 17:58:49 2016 -0700 +++ b/test/tools/launcher/VersionCheck.java Thu Aug 25 21:37:41 2016 -0700 @@ -82,6 +82,7 @@ "jcmd", "jconsole", "jcontrol", + "jdeprscan", "jdeps", "jimage", "jinfo", From sundararajan.athijegannathan at oracle.com Fri Aug 26 04:46:38 2016 From: sundararajan.athijegannathan at oracle.com (Sundararajan Athijegannathan) Date: Fri, 26 Aug 2016 10:16:38 +0530 Subject: RFR(xs): 8164834: remove jdeprscan from tools/launcher/VersionCheck.java In-Reply-To: <496c2648-d118-d14b-2d73-0027a14288f9@oracle.com> References: <496c2648-d118-d14b-2d73-0027a14288f9@oracle.com> Message-ID: +1 -Sundar On 8/26/2016 10:09 AM, Stuart Marks wrote: > One-line diff appended below. (This is adding to a blacklist, so it's > effectively a removal.) > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1472186261 25200 > # Thu Aug 25 21:37:41 2016 -0700 > # Node ID e25d07a84bebf82616b2e84a469760757f2679b7 > # Parent 7e21149a616e3e4f5c604a4ed25253e6e9ebdfa1 > 8164834: remove jdeprscan from tools/launcher/VersionCheck.java > Reviewed-by: darcy > > diff -r 7e21149a616e -r e25d07a84beb > test/tools/launcher/VersionCheck.java > --- a/test/tools/launcher/VersionCheck.java Thu Aug 25 17:58:49 > 2016 -0700 > +++ b/test/tools/launcher/VersionCheck.java Thu Aug 25 21:37:41 > 2016 -0700 > @@ -82,6 +82,7 @@ > "jcmd", > "jconsole", > "jcontrol", > + "jdeprscan", > "jdeps", > "jimage", > "jinfo", From stuart.marks at oracle.com Fri Aug 26 04:56:22 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 25 Aug 2016 21:56:22 -0700 Subject: RFR(xs): 8164835: add a few tools tests to the problem list Message-ID: <1913b504-3a89-00c8-1815-b14b7a374949@oracle.com> Please review a small change appended below to add to the problem list a few tests that were tickled by jdeprscan. Note, the diff may look weird because of line wrapping, but the file has really long lines. Thanks, s'marks # HG changeset patch # User smarks # Date 1472187222 25200 # Thu Aug 25 21:53:42 2016 -0700 # Node ID 3397ac219627fe059b93640d886e2d072a48e7ad # Parent 871b60b0c0917d9c657744a57dfa525b96bf5149 8164835: add a few tools tests to the problem list Reviewed-by: darcy diff -r 871b60b0c091 -r 3397ac219627 test/ProblemList.txt --- a/test/ProblemList.txt Thu Aug 25 17:58:39 2016 -0700 +++ b/test/ProblemList.txt Thu Aug 25 21:53:42 2016 -0700 @@ -78,3 +78,10 @@ # # jdeps +########################################################################### +# +# jdeprscan + +tools/all/RunCodingRules.java 8164836 generic-all fix @DefinedBy +tools/jdeprscan/tests/jdk/jdeprscan/TestLoad.java 8164837 windows-all probably line breaks or encoding +tools/jdeprscan/tests/jdk/jdeprscan/TestScan.java 8164837 windows-all probably line breaks or encoding From joe.darcy at oracle.com Fri Aug 26 05:00:25 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 25 Aug 2016 22:00:25 -0700 Subject: RFR(xs): 8164834: remove jdeprscan from tools/launcher/VersionCheck.java In-Reply-To: References: <496c2648-d118-d14b-2d73-0027a14288f9@oracle.com> Message-ID: +1 -Joe On 8/25/2016 9:46 PM, Sundararajan Athijegannathan wrote: > +1 > > -Sundar > > > On 8/26/2016 10:09 AM, Stuart Marks wrote: >> One-line diff appended below. (This is adding to a blacklist, so it's >> effectively a removal.) >> >> Thanks, >> >> s'marks >> >> # HG changeset patch >> # User smarks >> # Date 1472186261 25200 >> # Thu Aug 25 21:37:41 2016 -0700 >> # Node ID e25d07a84bebf82616b2e84a469760757f2679b7 >> # Parent 7e21149a616e3e4f5c604a4ed25253e6e9ebdfa1 >> 8164834: remove jdeprscan from tools/launcher/VersionCheck.java >> Reviewed-by: darcy >> >> diff -r 7e21149a616e -r e25d07a84beb >> test/tools/launcher/VersionCheck.java >> --- a/test/tools/launcher/VersionCheck.java Thu Aug 25 17:58:49 >> 2016 -0700 >> +++ b/test/tools/launcher/VersionCheck.java Thu Aug 25 21:37:41 >> 2016 -0700 >> @@ -82,6 +82,7 @@ >> "jcmd", >> "jconsole", >> "jcontrol", >> + "jdeprscan", >> "jdeps", >> "jimage", >> "jinfo", From joe.darcy at oracle.com Fri Aug 26 05:02:05 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 25 Aug 2016 22:02:05 -0700 Subject: RFR(xs): 8164835: add a few tools tests to the problem list In-Reply-To: <1913b504-3a89-00c8-1815-b14b7a374949@oracle.com> References: <1913b504-3a89-00c8-1815-b14b7a374949@oracle.com> Message-ID: <15f856ce-577d-8f8c-6c44-dab847f2ac49@oracle.com> Hi Stuart, I'll approve an amended version of the patch that doesn't list TestScan.java on two separate lines :-) Thanks, -Joe On 8/25/2016 9:56 PM, Stuart Marks wrote: > Please review a small change appended below to add to the problem list > a few tests that were tickled by jdeprscan. Note, the diff may look > weird because of line wrapping, but the file has really long lines. > > Thanks, > > s'marks > > # HG changeset patch > # User smarks > # Date 1472187222 25200 > # Thu Aug 25 21:53:42 2016 -0700 > # Node ID 3397ac219627fe059b93640d886e2d072a48e7ad > # Parent 871b60b0c0917d9c657744a57dfa525b96bf5149 > 8164835: add a few tools tests to the problem list > Reviewed-by: darcy > > diff -r 871b60b0c091 -r 3397ac219627 test/ProblemList.txt > --- a/test/ProblemList.txt Thu Aug 25 17:58:39 2016 -0700 > +++ b/test/ProblemList.txt Thu Aug 25 21:53:42 2016 -0700 > @@ -78,3 +78,10 @@ > # > # jdeps > > +########################################################################### > > +# > +# jdeprscan > + > +tools/all/RunCodingRules.java 8164836 generic-all fix @DefinedBy > +tools/jdeprscan/tests/jdk/jdeprscan/TestLoad.java 8164837 > windows-all probably line breaks or encoding > +tools/jdeprscan/tests/jdk/jdeprscan/TestScan.java 8164837 > windows-all probably line breaks or encoding From stuart.marks at oracle.com Fri Aug 26 05:15:35 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 25 Aug 2016 22:15:35 -0700 Subject: RFR(xs): 8164835: add a few tools tests to the problem list In-Reply-To: <15f856ce-577d-8f8c-6c44-dab847f2ac49@oracle.com> References: <1913b504-3a89-00c8-1815-b14b7a374949@oracle.com> <15f856ce-577d-8f8c-6c44-dab847f2ac49@oracle.com> Message-ID: <5a4ee299-0b7d-639b-b953-f766324236fd@oracle.com> There are two separate tests to be problem-listed, TestLoad.java and TestScan.java. I'm covering them with the same bug, though. s'marks On 8/25/16 10:02 PM, joe darcy wrote: > Hi Stuart, > > I'll approve an amended version of the patch that doesn't list TestScan.java on > two separate lines :-) > > Thanks, > > -Joe > > > On 8/25/2016 9:56 PM, Stuart Marks wrote: >> Please review a small change appended below to add to the problem list a few >> tests that were tickled by jdeprscan. Note, the diff may look weird because of >> line wrapping, but the file has really long lines. >> >> Thanks, >> >> s'marks >> >> # HG changeset patch >> # User smarks >> # Date 1472187222 25200 >> # Thu Aug 25 21:53:42 2016 -0700 >> # Node ID 3397ac219627fe059b93640d886e2d072a48e7ad >> # Parent 871b60b0c0917d9c657744a57dfa525b96bf5149 >> 8164835: add a few tools tests to the problem list >> Reviewed-by: darcy >> >> diff -r 871b60b0c091 -r 3397ac219627 test/ProblemList.txt >> --- a/test/ProblemList.txt Thu Aug 25 17:58:39 2016 -0700 >> +++ b/test/ProblemList.txt Thu Aug 25 21:53:42 2016 -0700 >> @@ -78,3 +78,10 @@ >> # >> # jdeps >> >> +########################################################################### >> +# >> +# jdeprscan >> + >> +tools/all/RunCodingRules.java 8164836 generic-all fix @DefinedBy >> +tools/jdeprscan/tests/jdk/jdeprscan/TestLoad.java 8164837 windows-all >> probably line breaks or encoding >> +tools/jdeprscan/tests/jdk/jdeprscan/TestScan.java 8164837 windows-all >> probably line breaks or encoding > From joe.darcy at oracle.com Fri Aug 26 05:33:07 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 25 Aug 2016 22:33:07 -0700 Subject: RFR(xs): 8164835: add a few tools tests to the problem list In-Reply-To: <5a4ee299-0b7d-639b-b953-f766324236fd@oracle.com> References: <1913b504-3a89-00c8-1815-b14b7a374949@oracle.com> <15f856ce-577d-8f8c-6c44-dab847f2ac49@oracle.com> <5a4ee299-0b7d-639b-b953-f766324236fd@oracle.com> Message-ID: <62d27377-5220-ac1b-7218-98432d89131c@oracle.com> Ah, okay -- missed that detail; a hazard of late-night reviewing! Thanks, -Joe On 8/25/2016 10:15 PM, Stuart Marks wrote: > There are two separate tests to be problem-listed, TestLoad.java and > TestScan.java. I'm covering them with the same bug, though. > > s'marks > > On 8/25/16 10:02 PM, joe darcy wrote: >> Hi Stuart, >> >> I'll approve an amended version of the patch that doesn't list >> TestScan.java on >> two separate lines :-) >> >> Thanks, >> >> -Joe >> >> >> On 8/25/2016 9:56 PM, Stuart Marks wrote: >>> Please review a small change appended below to add to the problem >>> list a few >>> tests that were tickled by jdeprscan. Note, the diff may look weird >>> because of >>> line wrapping, but the file has really long lines. >>> >>> Thanks, >>> >>> s'marks >>> >>> # HG changeset patch >>> # User smarks >>> # Date 1472187222 25200 >>> # Thu Aug 25 21:53:42 2016 -0700 >>> # Node ID 3397ac219627fe059b93640d886e2d072a48e7ad >>> # Parent 871b60b0c0917d9c657744a57dfa525b96bf5149 >>> 8164835: add a few tools tests to the problem list >>> Reviewed-by: darcy >>> >>> diff -r 871b60b0c091 -r 3397ac219627 test/ProblemList.txt >>> --- a/test/ProblemList.txt Thu Aug 25 17:58:39 2016 -0700 >>> +++ b/test/ProblemList.txt Thu Aug 25 21:53:42 2016 -0700 >>> @@ -78,3 +78,10 @@ >>> # >>> # jdeps >>> >>> +########################################################################### >>> >>> +# >>> +# jdeprscan >>> + >>> +tools/all/RunCodingRules.java 8164836 generic-all fix @DefinedBy >>> +tools/jdeprscan/tests/jdk/jdeprscan/TestLoad.java 8164837 windows-all >>> probably line breaks or encoding >>> +tools/jdeprscan/tests/jdk/jdeprscan/TestScan.java 8164837 windows-all >>> probably line breaks or encoding >> From zoltan.majo at oracle.com Fri Aug 26 09:30:20 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 26 Aug 2016 11:30:20 +0200 Subject: Result: New JDK 9 Committer: Doug Simon In-Reply-To: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: Voting for Doug Simon [1] is now closed. Yes: 22 Veto: 0 Abstain: 0|| || |According to the Bylaws definition of Lazy Consensus, this is||| |sufficient to approve the nomination.||| Zoltan Majo [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004595.html From zoltan.majo at oracle.com Fri Aug 26 09:39:26 2016 From: zoltan.majo at oracle.com (=?UTF-8?B?Wm9sdMOhbiBNYWrDsw==?=) Date: Fri, 26 Aug 2016 11:39:26 +0200 Subject: Result: New JDK 9 Committer: Doug Simon In-Reply-To: References: <31cbed63-b508-8d8c-956a-2ecda9c52247@oracle.com> Message-ID: <11fd774f-3482-07a8-e69e-3a4987a52527@oracle.com> Sorry for the formatting in my previous email. I explicitly removed all formatting and set the output to "Plain text". The result was nevertheless a wrongly formatted email. And the formatting was shown to me only after I've sent out the message. I'll try again, please see below. If it does not work again, I'll most likely have to switch to a different mail client (to one whose name does not start with 'T'). Sorry for the noise. Best regards, Zoltan ======================================= Voting for Doug Simon [1] is now closed. Yes: 22 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Zoltan Majo [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004595.html From mandy.chung at oracle.com Fri Aug 26 18:31:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Aug 2016 11:31:27 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline Message-ID: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> I hereby nominate Alexandre Iline to jdk9 Committer. Shura is the lead of the JDK quality team and has been contributing to the OpenJDK test development and execution. He has contributed at least 17 changes to jdk9/jdk and langtools since April 2014 [1] including the Jemmy library and analyzing the regression tests and update them to enable proper test selection and also to work with limited module availability. Votes are due by September 9, 2016 @ 12:00 pm PDT Only current JDK9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Mandy Chung [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 [2] http://openjdk.java.net/census#jdk9 [3] http://openjdk.java.net/projects#committer-vote From joe.darcy at oracle.com Fri Aug 26 18:51:28 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 26 Aug 2016 11:51:28 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <0fedc41f-481a-7709-d80e-263fdb57aada@oracle.com> Vote: yes -Joe On 8/26/2016 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From jonathan.gibbons at oracle.com Fri Aug 26 18:56:37 2016 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Fri, 26 Aug 2016 11:56:37 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <57C090E5.4000304@oracle.com> Vote: yes On 08/26/2016 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From vicente.romero at oracle.com Fri Aug 26 18:59:14 2016 From: vicente.romero at oracle.com (Vicente-Arturo Romero-Zaldivar) Date: Fri, 26 Aug 2016 14:59:14 -0400 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <40117113-5f9b-b70e-c11f-28c52fde2e8f@oracle.com> vote: yes Vicente On 08/26/2016 02:31 PM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From mandy.chung at oracle.com Fri Aug 26 19:03:18 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 26 Aug 2016 12:03:18 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes Mandy From chris.hegarty at oracle.com Fri Aug 26 19:04:24 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 26 Aug 2016 20:04:24 +0100 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: YES. -Chris. From philip.race at oracle.com Fri Aug 26 19:09:28 2016 From: philip.race at oracle.com (Phil Race) Date: Fri, 26 Aug 2016 12:09:28 -0700 Subject: CFV: New JDK 9 Reviewer: Vadim Pakhnushev Message-ID: <57C093E8.6000902@oracle.com> I hereby nominate Vadim Pakhnushev (openjdk id vadim) for the role of JDK9 reviewer. Vadim has worked in the JDK client team for more than 3 years, focusing initially on Java 2D and then splitting his time with JavaFX. Vadim is currently a JDK9 committer [1] and has contributed at least 38 changesets to OpenJDK [2]. And has already been active in helping act as a reviewer on the 2d-dev [3] mailing list. Votes are due by Sep 9, 2016. Only current JDK 9 Reviewers [4] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [5]. -phil. [1] http://openjdk.java.net/census#vadim [2] http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22vadim%22%29 [3] http://mail.openjdk.java.net/pipermail/2d-dev/ [4] http://openjdk.java.net/census [5] http://openjdk.java.net/projects/#reviewer-vote From philip.race at oracle.com Fri Aug 26 19:18:06 2016 From: philip.race at oracle.com (Philip Race) Date: Fri, 26 Aug 2016 12:18:06 -0700 Subject: CFV: New JDK 9 Reviewer: Vadim Pakhnushev In-Reply-To: <57C093E8.6000902@oracle.com> References: <57C093E8.6000902@oracle.com> Message-ID: <57C095EE.8000607@oracle.com> Vote: yes -phil From dmitry.fazunenko at oracle.com Fri Aug 26 19:22:03 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 26 Aug 2016 22:22:03 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <76ca59d1-51d4-db66-56fb-ea3302b9b9a0@oracle.com> Vote: yes -- Dima On 26.08.2016 21:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From artem.ananiev at oracle.com Fri Aug 26 19:31:36 2016 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 26 Aug 2016 12:31:36 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <57C09918.80804@oracle.com> Vote: yes. Artem On 8/26/16, 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From artem.ananiev at oracle.com Fri Aug 26 19:32:04 2016 From: artem.ananiev at oracle.com (Artem Ananiev) Date: Fri, 26 Aug 2016 12:32:04 -0700 Subject: CFV: New JDK 9 Reviewer: Vadim Pakhnushev In-Reply-To: <57C093E8.6000902@oracle.com> References: <57C093E8.6000902@oracle.com> Message-ID: <57C09934.9000409@oracle.com> Vote: yes Artem On 8/26/16, 12:09 PM, Phil Race wrote: > I hereby nominate Vadim Pakhnushev (openjdk id vadim) for the role of > JDK9 reviewer. > > Vadim has worked in the JDK client team for more than 3 years, focusing > initially on Java 2D and then splitting his time with JavaFX. > > Vadim is currently a JDK9 committer [1] and has contributed at least > 38 changesets to OpenJDK [2]. > > And has already been active in helping act as a reviewer on > the 2d-dev [3] mailing list. > > Votes are due by Sep 9, 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > [1] http://openjdk.java.net/census#vadim > > [2] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22vadim%22%29 > > > [3] http://mail.openjdk.java.net/pipermail/2d-dev/ > > [4] http://openjdk.java.net/census > > [5] http://openjdk.java.net/projects/#reviewer-vote From k.s.shefov at gmail.com Fri Aug 26 19:33:01 2016 From: k.s.shefov at gmail.com (Konstantin Shefov) Date: Fri, 26 Aug 2016 22:33:01 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes Konstantin 2016-08-26 21:31 GMT+03:00 Mandy Chung : > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > > -- Yours sincerely, Konstantin Shefov From Peter.Zhelezniakov at oracle.com Fri Aug 26 19:51:04 2016 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Fri, 26 Aug 2016 22:51:04 +0300 Subject: CFV: New JDK 9 Reviewer: Vadim Pakhnushev In-Reply-To: <57C093E8.6000902@oracle.com> References: <57C093E8.6000902@oracle.com> Message-ID: vote: yes From Peter.Zhelezniakov at oracle.com Fri Aug 26 19:51:42 2016 From: Peter.Zhelezniakov at oracle.com (Peter Zhelezniakov) Date: Fri, 26 Aug 2016 22:51:42 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <76ca59d1-51d4-db66-56fb-ea3302b9b9a0@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> <76ca59d1-51d4-db66-56fb-ea3302b9b9a0@oracle.com> Message-ID: Vote: yes From brian.burkhalter at oracle.com Fri Aug 26 19:53:52 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 26 Aug 2016 12:53:52 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes Brian On Aug 26, 2016, at 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. From huizhe.wang at oracle.com Fri Aug 26 19:55:49 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 26 Aug 2016 12:55:49 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <57C09EC5.8090304@oracle.com> Vote: yes Joe (joehw) On 8/26/16, 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. From artem.smotrakov at oracle.com Fri Aug 26 20:03:55 2016 From: artem.smotrakov at oracle.com (Artem Smotrakov) Date: Fri, 26 Aug 2016 13:03:55 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes Artem On 08/26/2016 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From naoto.sato at oracle.com Fri Aug 26 20:06:36 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 26 Aug 2016 13:06:36 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <2a2d6958-3f36-b323-d9b5-b4d0d149d2fe@oracle.com> Vote: yes Naoto On 8/26/16 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From serguei.spitsyn at oracle.com Fri Aug 26 20:07:08 2016 From: serguei.spitsyn at oracle.com (serguei.spitsyn at oracle.com) Date: Fri, 26 Aug 2016 13:07:08 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <57C0A16C.1020003@oracle.com> Vote: yes From daniel.fuchs at oracle.com Fri Aug 26 20:22:27 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 26 Aug 2016 21:22:27 +0100 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes -- daniel On 26/08/16 19:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From stuart.marks at oracle.com Fri Aug 26 20:25:47 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Fri, 26 Aug 2016 13:25:47 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <2db8eb77-172e-bcbc-78fb-e6c4164c4ea8@oracle.com> Vote: yes On 8/26/16 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From vladimir.x.ivanov at oracle.com Fri Aug 26 20:36:08 2016 From: vladimir.x.ivanov at oracle.com (Vladimir Ivanov) Date: Fri, 26 Aug 2016 23:36:08 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <88963126-f57b-6c23-ffc8-922f59bd4569@oracle.com> Vote: yes Best regards, Vladimir Ivanov On 8/26/16 9:31 PM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. From brent.christian at oracle.com Fri Aug 26 20:36:00 2016 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 26 Aug 2016 13:36:00 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <3521479d-26fc-ed5a-1ef3-5ea37895a5ec@oracle.com> Vote: Yes -Brent On 8/26/16 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From james.laskey at oracle.com Fri Aug 26 20:59:06 2016 From: james.laskey at oracle.com (James Laskey) Date: Fri, 26 Aug 2016 17:59:06 -0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <6AC1ECA1-6C4B-4772-96B3-95D90B09204A@oracle.com> Vote: yes Sent from my iPhone > On Aug 26, 2016, at 3:31 PM, Mandy Chung wrote: > > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From ivan.gerasimov at oracle.com Fri Aug 26 22:26:12 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sat, 27 Aug 2016 01:26:12 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: Yes Ivan On 26.08.2016 21:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > > From prasanta.sadhukhan at oracle.com Sat Aug 27 05:12:13 2016 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Sat, 27 Aug 2016 10:42:13 +0530 Subject: CFV: New JDK 9 Reviewer: Vadim Pakhnushev In-Reply-To: <57C093E8.6000902@oracle.com> References: <57C093E8.6000902@oracle.com> Message-ID: <57C1212D.80006@oracle.com> Vote: yes Regards Prasanta On 8/27/2016 12:39 AM, Phil Race wrote: > I hereby nominate Vadim Pakhnushev (openjdk id vadim) for the role of > JDK9 reviewer. > > Vadim has worked in the JDK client team for more than 3 years, focusing > initially on Java 2D and then splitting his time with JavaFX. > > Vadim is currently a JDK9 committer [1] and has contributed at least > 38 changesets to OpenJDK [2]. > > And has already been active in helping act as a reviewer on > the 2d-dev [3] mailing list. > > Votes are due by Sep 9, 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > [1] http://openjdk.java.net/census#vadim > > [2] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22vadim%22%29 > > [3] http://mail.openjdk.java.net/pipermail/2d-dev/ > > [4] http://openjdk.java.net/census > > [5] http://openjdk.java.net/projects/#reviewer-vote From Alan.Bateman at oracle.com Sat Aug 27 05:59:34 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 27 Aug 2016 06:59:34 +0100 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <0766db29-26d4-1d5d-ac40-61260ceb1efd@oracle.com> Vote: yes From igor.ignatyev at oracle.com Sat Aug 27 06:56:06 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Sat, 27 Aug 2016 09:56:06 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <5A56BD02-FF3B-410A-9911-5F98E4200C6E@oracle.com> Vote: yes ? Igor > On Aug 26, 2016, at 9:31 PM, Mandy Chung wrote: > > I hereby nominate Alexandre Iline to jdk9 Committer. From amy.lu at oracle.com Sat Aug 27 07:25:23 2016 From: amy.lu at oracle.com (Amy Lu) Date: Sat, 27 Aug 2016 15:25:23 +0800 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <3406e610-777a-79ff-ac51-5ef40530be47@oracle.com> Vote: Yes /Amy On 8/27/16 2:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. From aleksej.efimov at oracle.com Sat Aug 27 19:47:29 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Sat, 27 Aug 2016 22:47:29 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes On 26/08/16 21:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From erik.gahlin at oracle.com Sat Aug 27 19:51:52 2016 From: erik.gahlin at oracle.com (Erik Gahlin) Date: Sat, 27 Aug 2016 21:51:52 +0200 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <57C1EF58.4080709@oracle.com> Vote: yes Erik On 2016-08-26 20:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From vyom.tewari at oracle.com Sun Aug 28 04:03:41 2016 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Sun, 28 Aug 2016 09:33:41 +0530 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <9c60c88c-dd07-3dfa-6692-7f79940e9410@oracle.com> Vote: yes On Saturday 27 August 2016 12:01 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From felix.yang at oracle.com Sun Aug 28 13:38:36 2016 From: felix.yang at oracle.com (Felix Yang) Date: Sun, 28 Aug 2016 21:38:36 +0800 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <3feb7429-64b5-6ef3-01d3-9773da53f675@oracle.com> Vote: yes. -Felix On 2016/8/27 2:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From weijun.wang at oracle.com Sun Aug 28 14:14:58 2016 From: weijun.wang at oracle.com (Weijun Wang) Date: Sun, 28 Aug 2016 22:14:58 +0800 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <17502900-57b9-0464-5fa7-38ba954a3b97@oracle.com> Vote: yes --weijun On 8/27/2016 2:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. From claes.redestad at oracle.com Sun Aug 28 15:23:29 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 28 Aug 2016 17:23:29 +0200 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <57C301F1.6000404@oracle.com> Vote: yes From filipp.zhinkin at gmail.com Sun Aug 28 15:53:10 2016 From: filipp.zhinkin at gmail.com (Filipp Zhinkin) Date: Sun, 28 Aug 2016 18:53:10 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes On Fri, Aug 26, 2016 at 9:31 PM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From alejandro.murillo at oracle.com Sun Aug 28 17:58:16 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Sun, 28 Aug 2016 11:58:16 -0600 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: vote: yes Alejandro On 8/26/2016 12:31 PM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > -- Alejandro From huaming.li at oracle.com Mon Aug 29 01:59:23 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 29 Aug 2016 09:59:23 +0800 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <8f74e09d-71cd-c6ce-1995-c42a65923d3f@oracle.com> Vote: yes -Hamlin On 2016/8/27 2:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From nadeesh.tv at oracle.com Mon Aug 29 06:16:21 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Mon, 29 Aug 2016 11:46:21 +0530 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <57C3D335.2070301@oracle.com> Vote : Yes On 8/27/2016 12:01 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > -- Thanks and Regards, Nadeesh TV From yuri.nesterenko at oracle.com Mon Aug 29 06:37:17 2016 From: yuri.nesterenko at oracle.com (Yuri Nesterenko) Date: Mon, 29 Aug 2016 09:37:17 +0300 Subject: CFV: New JDK 9 Reviewer: Vadim Pakhnushev In-Reply-To: <57C093E8.6000902@oracle.com> References: <57C093E8.6000902@oracle.com> Message-ID: <344cbab5-8960-162e-9e17-f9861517722e@oracle.com> Vote: yes -yan On 08/26/2016 10:09 PM, Phil Race wrote: > I hereby nominate Vadim Pakhnushev (openjdk id vadim) for the role of > JDK9 reviewer. > > Vadim has worked in the JDK client team for more than 3 years, focusing > initially on Java 2D and then splitting his time with JavaFX. > > Vadim is currently a JDK9 committer [1] and has contributed at least > 38 changesets to OpenJDK [2]. > > And has already been active in helping act as a reviewer on > the 2d-dev [3] mailing list. > > Votes are due by Sep 9, 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > [1] http://openjdk.java.net/census#vadim > > [2] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22vadim%22%29 > > > [3] http://mail.openjdk.java.net/pipermail/2d-dev/ > > [4] http://openjdk.java.net/census > > [5] http://openjdk.java.net/projects/#reviewer-vote From semyon.sadetsky at oracle.com Mon Aug 29 06:58:02 2016 From: semyon.sadetsky at oracle.com (Semyon Sadetsky) Date: Mon, 29 Aug 2016 09:58:02 +0300 Subject: CFV: New JDK 9 Reviewer: Vadim Pakhnushev In-Reply-To: <57C093E8.6000902@oracle.com> References: <57C093E8.6000902@oracle.com> Message-ID: Vote: yes --Semyon On 26.08.2016 22:09, Phil Race wrote: > I hereby nominate Vadim Pakhnushev (openjdk id vadim) for the role of > JDK9 reviewer. > > Vadim has worked in the JDK client team for more than 3 years, focusing > initially on Java 2D and then splitting his time with JavaFX. > > Vadim is currently a JDK9 committer [1] and has contributed at least > 38 changesets to OpenJDK [2]. > > And has already been active in helping act as a reviewer on > the 2d-dev [3] mailing list. > > Votes are due by Sep 9, 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > [1] http://openjdk.java.net/census#vadim > > [2] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22vadim%22%29 > > [3] http://mail.openjdk.java.net/pipermail/2d-dev/ > > [4] http://openjdk.java.net/census > > [5] http://openjdk.java.net/projects/#reviewer-vote From sibabrata.sahoo at oracle.com Mon Aug 29 07:28:26 2016 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 29 Aug 2016 00:28:26 -0700 (PDT) Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <6ae35480-6713-475b-aada-e0ad0b0dcc19@default> Vote: yes -----Original Message----- From: Mandy Chung Sent: Saturday, August 27, 2016 12:01 AM To: jdk9-dev Subject: CFV: New jdk9 Committer: Alexandre Iline I hereby nominate Alexandre Iline to jdk9 Committer. Shura is the lead of the JDK quality team and has been contributing to the OpenJDK test development and execution. He has contributed at least 17 changes to jdk9/jdk and langtools since April 2014 [1] including the Jemmy library and analyzing the regression tests and update them to enable proper test selection and also to work with limited module availability. Votes are due by September 9, 2016 @ 12:00 pm PDT Only current JDK9 Committers [2] are eligible to vote on this nomination. Votes must be cast in the open by replying to this mailing list. For Lazy Consensus voting instructions, see [3]. Thanks, Mandy Chung [1] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 [2] http://openjdk.java.net/census#jdk9 [3] http://openjdk.java.net/projects#committer-vote From dmitry.dmitriev at oracle.com Mon Aug 29 09:31:56 2016 From: dmitry.dmitriev at oracle.com (Dmitry Dmitriev) Date: Mon, 29 Aug 2016 12:31:56 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <9234e894-ceaf-dd0c-0cf2-bc4f2d361e4c@oracle.com> Vote: yes Dmitry On 26.08.2016 21:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From dalibor.topic at oracle.com Mon Aug 29 11:32:00 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 29 Aug 2016 13:32:00 +0200 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <6deac057-b02f-b53f-be3f-5db7e25f512b@oracle.com> Vote: Yes. cheers, dalibor topic -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From neugens.limasoftware at gmail.com Mon Aug 29 11:42:22 2016 From: neugens.limasoftware at gmail.com (Mario Torre) Date: Mon, 29 Aug 2016 13:42:22 +0200 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: Yes, Cheers, Mario 2016-08-26 20:31 GMT+02:00 Mandy Chung : > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > -- pgp key: http://subkeys.pgp.net/ PGP Key ID: 80F240CF Fingerprint: BA39 9666 94EC 8B73 27FA FC7C 4086 63E3 80F2 40CF Java Champion - Blog: http://neugens.wordpress.com - Twitter: @neugens Proud GNU Classpath developer: http://www.classpath.org/ OpenJDK: http://openjdk.java.net/projects/caciocavallo/ Please, support open standards: http://endsoftpatents.org/ From Sergey.Bylokhov at oracle.com Mon Aug 29 14:30:08 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Aug 2016 17:30:08 +0300 Subject: CFV: New JDK 9 Reviewer: Vadim Pakhnushev In-Reply-To: <57C093E8.6000902@oracle.com> References: <57C093E8.6000902@oracle.com> Message-ID: <279502b2-deb7-86a8-aa0b-c9fdd1613902@oracle.com> Vote: yes On 26.08.16 22:09, Phil Race wrote: > I hereby nominate Vadim Pakhnushev (openjdk id vadim) for the role of > JDK9 reviewer. > > Vadim has worked in the JDK client team for more than 3 years, focusing > initially on Java 2D and then splitting his time with JavaFX. > > Vadim is currently a JDK9 committer [1] and has contributed at least > 38 changesets to OpenJDK [2]. > > And has already been active in helping act as a reviewer on > the 2d-dev [3] mailing list. > > Votes are due by Sep 9, 2016. > > Only current JDK 9 Reviewers [4] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Lazy Consensus voting instructions, see [5]. > > -phil. > > [1] http://openjdk.java.net/census#vadim > > [2] > http://hg.openjdk.java.net/jdk9/dev/jdk/log?revcount=1000&rev=author%28%22vadim%22%29 > > > [3] http://mail.openjdk.java.net/pipermail/2d-dev/ > > [4] http://openjdk.java.net/census > > [5] http://openjdk.java.net/projects/#reviewer-vote -- Best regards, Sergey. From Sergey.Bylokhov at oracle.com Mon Aug 29 15:39:02 2016 From: Sergey.Bylokhov at oracle.com (Sergey Bylokhov) Date: Mon, 29 Aug 2016 18:39:02 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <12e32e16-4444-c0b5-32c3-f70a4513c943@oracle.com> Vote: yes On 26.08.16 21:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > -- Best regards, Sergey. From omajid at redhat.com Mon Aug 29 18:08:45 2016 From: omajid at redhat.com (Omair Majid) Date: Mon, 29 Aug 2016 14:08:45 -0400 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: <20160829180844.GE14418@redhat.com> Vote: Yes * Jesper Wilhelmsson [2016-08-23 07:08]: > I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. Thanks, Omair -- PGP Key: 66484681 (http://pgp.mit.edu/) Fingerprint = F072 555B 0A17 3957 4E95 0056 F286 F14F 6648 4681 From kumar.x.srinivasan at oracle.com Mon Aug 29 23:46:30 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Mon, 29 Aug 2016 16:46:30 -0700 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <57C4C956.9070605@oracle.com> Vote: Yes On 8/26/2016 11:31 AM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From li.jiang at oracle.com Tue Aug 30 08:29:11 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 30 Aug 2016 16:29:11 +0800 Subject: RFR: 8145952: 8164784: Currency update for ISO 4217 Amendment #161 162 Message-ID: <81e70e92-9013-b68e-b57e-bee50092fd16@oracle.com> Hi all, Please review the change for Currency data update for ISO 4217 Amendment #161 162. Bugs: https://bugs.openjdk.java.net/browse/JDK-8145952 https://bugs.openjdk.java.net/browse/JDK-8164784 Please refer these docs for currency changes. http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_161.pdf http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_162.pdf Have run the builds and test jdk_text for all platform, passed. Regards, Leo From li.jiang at oracle.com Tue Aug 30 08:31:17 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Tue, 30 Aug 2016 16:31:17 +0800 Subject: RFR: 8145952: 8164784: Currency update for ISO 4217 Amendment #161 162 In-Reply-To: <81e70e92-9013-b68e-b57e-bee50092fd16@oracle.com> References: <81e70e92-9013-b68e-b57e-bee50092fd16@oracle.com> Message-ID: <357c0cf4-d7ac-f2a6-65e9-98265d6bddc6@oracle.com> Sorry Webrev: http://cr.openjdk.java.net/~ljiang/8145952/webrev.00/ Thanks, Leo On 08/30/2016 04:29 PM, Leo Jiang wrote: > Hi all, > > Please review the change for Currency data update for ISO 4217 Amendment #161 162. > > Bugs: > > https://bugs.openjdk.java.net/browse/JDK-8145952 > https://bugs.openjdk.java.net/browse/JDK-8164784 > > Please refer these docs for currency changes. > http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_161.pdf > http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_162.pdf > > Have run the builds and test jdk_text for all platform, passed. > > Regards, > Leo From doko at ubuntu.com Tue Aug 30 11:49:47 2016 From: doko at ubuntu.com (Matthias Klose) Date: Tue, 30 Aug 2016 13:49:47 +0200 Subject: jdk9 builds failing with: java.io.IOException: Mount point not found Message-ID: <476205fe-d831-52d5-7f62-9fcd50ca75f1@ubuntu.com> In some build environments jdk9 builds fail with Error: jdk.tools.jlink.plugin.PluginException: java.io.IOException: Mount point not found complete build log e.g. at https://launchpadlibrarian.net/281693434/buildlog_ubuntu-yakkety-arm64.openjdk-9_9~b133-1ubuntu1_BUILDING.txt.gz The issue is not new, popped up earlier as seen in http://mail.openjdk.java.net/pipermail/nio-dev/2009-May/000547.html However for some reason this code is not called during 7 and 8 builds, only for 9. The problem is that LinuxFileStore.findMountEntry() tries to look up the file system by looking up /etc/mtab (which doesn't exist), and then trying to look up /proc/mounts which only has: $ cat /proc/mounts none /proc proc rw,relatime 0 0 none /dev/pts devpts rw,relatime,gid=5,mode=620,ptmxmode=000 0 0 none /sys sysfs rw,relatime 0 0 none /dev/shm tmpfs rw,relatime 0 0 it's about the entry for the top of the chroot fs namespace is missing. You can reproduce this with a 3.19 or newer kernel by taking a random chroot and doing "sudo mount -t proc none $CHROOT/proc; sudo chroot $CHROOT cat /proc/mounts; sudo umount $CHROOT/proc" Maybe this worked in 2009, but apparently due to a kernel change in 2014, this entry for the top of the chroot namespace is not always visible: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=9d4d65748a5ca26ea8650e50ba521295549bf4e3 The alternative would be to use the f_fsid field in the the statvfs information to get a handle for the file system / the file storage. $ sudo mount -t proc none /var/lib/schroot/chroots/xenial-amd64/proc; sudo chroot /var/lib/schroot/chroots/xenial-amd64 stat -f /bin/ls; sudo umount /var/lib/schroot/chroots/xenial-amd64/proc File: "/bin/ls" ID: ee43128f92e561ac Namelen: 255 Type: ext2/ext3 Block size: 4096 Fundamental block size: 4096 Blocks: Total: 113075671 Free: 10105058 Available: 4355386 Inodes: Total: 28729344 Free: 21572152 As a work around, is it possible to disable this check as it's done for OpenJDK-8? Matthias From Alan.Bateman at oracle.com Tue Aug 30 11:57:35 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Tue, 30 Aug 2016 12:57:35 +0100 Subject: jdk9 builds failing with: java.io.IOException: Mount point not found In-Reply-To: <476205fe-d831-52d5-7f62-9fcd50ca75f1@ubuntu.com> References: <476205fe-d831-52d5-7f62-9fcd50ca75f1@ubuntu.com> Message-ID: <1272a9a5-0289-90b1-1d76-25101fa4a8a1@oracle.com> On 30/08/2016 12:49, Matthias Klose wrote: > In some build environments jdk9 builds fail with > > Error: jdk.tools.jlink.plugin.PluginException: java.io.IOException: Mount point > not found > > complete build log e.g. at > https://launchpadlibrarian.net/281693434/buildlog_ubuntu-yakkety-arm64.openjdk-9_9~b133-1ubuntu1_BUILDING.txt.gz > > The issue is not new, popped up earlier as seen in > http://mail.openjdk.java.net/pipermail/nio-dev/2009-May/000547.html > > However for some reason this code is not called during 7 and 8 builds, only for 9. Can you submit a bug on this? It's possible that there hasn't been much testing in chroot environments. As to why you are seeing this with JDK 9 builds then it is because the build runs jlink to create the run-time image. In JDK 8 and older then it was done by recipes in the build. -Alan From daniel.daugherty at oracle.com Tue Aug 30 15:41:21 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Tue, 30 Aug 2016 09:41:21 -0600 Subject: CFV: New JDK 9 Reviewer: Yasumasa Suenaga In-Reply-To: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> References: <509c3919-178a-75d8-04ae-ded95765800c@oracle.com> Message-ID: Vote: yes Dan On 8/23/16 5:07 AM, Jesper Wilhelmsson wrote: > I hereby nominate Yasumasa Suenaga (ysuenaga) to JDK 9 Reviewer. > > Yasumasa has contributed 47 changesets to JDK 9. In particular, he has > been actively working in the serviceability area on serviceability tools > and diagnostic commands. > > Votes are due by September 6, 2016. > > Only current JDK 9 Reviewers [1] are eligible to vote on this nomination. > Votes must be cast in the open by replying to this mailing list. > > For Three-Vote Consensus voting instructions, see [2]. > > /Jesper > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#reviewer-vote > > From kirill.zhaldybin at oracle.com Tue Aug 30 16:50:57 2016 From: kirill.zhaldybin at oracle.com (Kirill Zhaldybin) Date: Tue, 30 Aug 2016 19:50:57 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <2461cf06-7c59-885a-f14f-9ee593f72d5f@oracle.com> Vote: yes Regards, Kirill On 26.08.2016 21:31, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From tatiana.pivovarova at oracle.com Tue Aug 30 17:07:21 2016 From: tatiana.pivovarova at oracle.com (Tatiana Pivovarova) Date: Tue, 30 Aug 2016 20:07:21 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes -- Tatiana On 08/26/2016 09:31 PM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From naoto.sato at oracle.com Tue Aug 30 17:22:13 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 30 Aug 2016 10:22:13 -0700 Subject: RFR: 8145952: 8164784: Currency update for ISO 4217 Amendment #161 162 In-Reply-To: <357c0cf4-d7ac-f2a6-65e9-98265d6bddc6@oracle.com> References: <81e70e92-9013-b68e-b57e-bee50092fd16@oracle.com> <357c0cf4-d7ac-f2a6-65e9-98265d6bddc6@oracle.com> Message-ID: Hi Leo, Here are my comments: - CurrencyData.properties/tablea1.txt: Since it is already past the transition date (7/1/16), I think we don't need to use the transition format. "BY=BYN" should suffice. - CurrencyNames.properties: the English name for BYR is now "Belarusian Ruble (2000?2016)" in the latest CLDR data. Naoto On 8/30/16 1:31 AM, Leo Jiang wrote: > Sorry > Webrev: http://cr.openjdk.java.net/~ljiang/8145952/webrev.00/ > > Thanks, > Leo > > On 08/30/2016 04:29 PM, Leo Jiang wrote: >> Hi all, >> >> Please review the change for Currency data update for ISO 4217 >> Amendment #161 162. >> >> Bugs: >> >> https://bugs.openjdk.java.net/browse/JDK-8145952 >> https://bugs.openjdk.java.net/browse/JDK-8164784 >> >> Please refer these docs for currency changes. >> http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_161.pdf >> >> http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_162.pdf >> >> >> Have run the builds and test jdk_text for all platform, passed. >> >> Regards, >> Leo From alexandr.scherbatiy at oracle.com Wed Aug 31 08:06:17 2016 From: alexandr.scherbatiy at oracle.com (Alexandr Scherbatiy) Date: Wed, 31 Aug 2016 11:06:17 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: Vote: yes Thanks, Alexandr. On 8/26/2016 9:31 PM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From mark.reinhold at oracle.com Wed Aug 31 14:57:30 2016 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 31 Aug 2016 07:57:30 -0700 Subject: JDK 9 Rampdown Phase 1: Process proposal Message-ID: <20160831075730.384142787eggemoggin.niobe.net> Per the JDK 9 schedule [1], the first phase of the Rampdown process starts tomorrow. The overall goal of this process is to ensure that we're fixing the bugs that need to be fixed, and that we understand why we're not fixing some bugs that ought to be fixed. For this release I propose that our specific goals for this phase should be: - Fix all P1-P3 bugs that are new in JDK 9, - Fix additional P1-P3 bugs targeted to JDK 9 as time permits, and - Explicitly defer any P1-P2 bugs that are new in JDK 9 but will not, for good reason, be fixed in JDK 9. P4-P5 bugs should, in general, be left to future releases unless they only affect documentation, demos, or tests, in which case they should be identified as such with the "noreg-doc", "noreg-demo", and "noreg-self" labels, respectively. The current list of candidate Rampdown Phase 1 (RDP1) bugs can be found here: http://j.mp/jdk9-rdp1 . If you're responsible for a bug on this list then you can take one of the following actions: - Fix the bug (preferred), or - If the bug is not new in JDK 9 (check the "Affects Version" field) then you can un-target it from JDK 9 by clearing the "Fix Version" field or setting that field to some future release, or - If the bug is new in JDK 9 and is P1 or P2 but it cannot be fixed in time then you can request that the bug be deferred from the release. In any case, do not change the priority of a bug in order to remove it from the list. The priority of a bug should reflect the importance of fixing it independent of any particular release, as has been standard practice for the JDK for many years. To document the reason for deferring a P1 or P2 bug I propose the following process: - Request a deferral by updating the JBS issue to add a comment whose first line is "Deferral Request". In that comment briefly describe the reason for the deferral (e.g., insufficient time, complexity or risk of fix, etc.). Add the label "jdk9-defer-request" to the issue. - The Area Leads, relevant Group Leads, and the JDK 9 Project Lead will review such requests on a regular basis, at least weekly if not more often. One of them will take one of the following actions: - Approve the request by adding the label "jdk9-defer-yes". - Reject the request by adding the label "jdk9-defer-no", along with a comment describing the reason for this action. - Request more information by adding the label "jdk9-defer-nmi" ("nmi" = "needs more information"), along with a comment describing what information is requested. - If you're asked to provide more information for a deferral request then please do so in a new comment in the issue, and then remove the "jdk9-defer-nmi" label so that we see that it's ready for re-review. - If your request is approved then clear the issue's "Fix Version" field or set it to some future release. - In any case, do not remove the original "jdk9-defer-request" label. Deferrals will not be granted for TCK issues identified by the label "tck-red-9" [2]. Deferrals are also unlikely for bugs that prevent release testing. For the record, the Area Leads are Mikael Vidstedt (VM), Brian Goetz (Language and Libraries), and Kevin Rushforth (Client Libraries). The relevant Group Leads are as follows, per the Census [3]: Sergey Bylokhov - AWT Tim Bell - Build Jonathan Gibbons - Compiler Alan Bateman - Core Libraries Vladimir Kozlov - HotSpot Masayoshi Okutsu - Internationalization Michael McMahon - Networking Dalibor Topic - Porters Sean Mullan - Security Staffan Larsen - Serviceability Alexander Scherbatiy - Swing Phil Race - 2D Graphics & Sound JDK 9 Committers are invited to comment on this process proposal. If no serious objections are raised in one week's time, by 15:00 UTC next Wednesday, 7 September 2016, then this is the process that we'll use. In anticipation that we'll use this process, more or less, owners of bugs on the RDP1 candidate list are encouraged to proceed as outlined above. This will allow us to move quickly once the process is in place. - Mark [1] http://openjdk.java.net/projects/jdk9/ [2] https://bugs.openjdk.java.net/issues/?filter=18893 [3] http://openjdk.java.net/census From alexander.v.stepanov at oracle.com Wed Aug 31 15:32:14 2016 From: alexander.v.stepanov at oracle.com (Alexander Stepanov) Date: Wed, 31 Aug 2016 18:32:14 +0300 Subject: CFV: New jdk9 Committer: Alexandre Iline In-Reply-To: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> References: <40AC2912-1B98-47DC-BA54-9DC009E6E4C2@oracle.com> Message-ID: <3629e129-19f4-120c-87f6-9daba5e7b167@oracle.com> Vote: yes Regards, Alexander On 8/26/2016 9:31 PM, Mandy Chung wrote: > I hereby nominate Alexandre Iline to jdk9 Committer. > > Shura is the lead of the JDK quality team and has been contributing > to the OpenJDK test development and execution. He has contributed > at least 17 changes to jdk9/jdk and langtools since April 2014 [1] > including the Jemmy library and analyzing the regression tests > and update them to enable proper test selection and also to work > with limited module availability. > > Votes are due by September 9, 2016 @ 12:00 pm PDT > > Only current JDK9 Committers [2] are eligible to vote on this > nomination. Votes must be cast in the open by replying to this > mailing list. > > For Lazy Consensus voting instructions, see [3]. > > Thanks, > Mandy Chung > > [1] > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/eeef9a64af04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a13f1f59f8f4 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31a2e3bd54fe > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ce592cf6d7d3 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/21b1b5d178ff > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/0df4fcfad601 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ed8ca9167d66 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/232843a54696 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/31d97a109d04 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/25b577ea72d5 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/2e63fa2efdb1 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b3cc1d52ebb0 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/3b50efed107a > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/7a2e220a737d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/1993af50385d > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b97dc13c55b2 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/b2a69d66dc65 > http://hg.openjdk.java.net/jdk9/dev/langtools/rev/203a9e1b82b6 > > [2] http://openjdk.java.net/census#jdk9 > [3] http://openjdk.java.net/projects#committer-vote > From jesper.wilhelmsson at oracle.com Wed Aug 31 16:18:53 2016 From: jesper.wilhelmsson at oracle.com (Jesper Wilhelmsson) Date: Wed, 31 Aug 2016 18:18:53 +0200 Subject: JDK 9 Rampdown Phase 1: Process proposal In-Reply-To: <20160831075730.384142787eggemoggin.niobe.net> References: <20160831075730.384142787eggemoggin.niobe.net> Message-ID: <8e45a18b-28bb-e231-2e79-9770b5ced231@oracle.com> Hi, Please note that removing the fix version is not an option for bugs on the Hotspot component. Hotspot bugs should always have a fix version set and currently we are deferring by setting the fix version to 10. Thanks, /Jesper Den 31/8/16 kl. 16:57, skrev mark.reinhold at oracle.com: > Per the JDK 9 schedule [1], the first phase of the Rampdown process > starts tomorrow. The overall goal of this process is to ensure that > we're fixing the bugs that need to be fixed, and that we understand why > we're not fixing some bugs that ought to be fixed. For this release I > propose that our specific goals for this phase should be: > > - Fix all P1-P3 bugs that are new in JDK 9, > > - Fix additional P1-P3 bugs targeted to JDK 9 as time permits, and > > - Explicitly defer any P1-P2 bugs that are new in JDK 9 but will not, > for good reason, be fixed in JDK 9. > > P4-P5 bugs should, in general, be left to future releases unless they > only affect documentation, demos, or tests, in which case they should be > identified as such with the "noreg-doc", "noreg-demo", and "noreg-self" > labels, respectively. > > The current list of candidate Rampdown Phase 1 (RDP1) bugs can be found > here: http://j.mp/jdk9-rdp1 . If you're responsible for a bug on this > list then you can take one of the following actions: > > - Fix the bug (preferred), or > > - If the bug is not new in JDK 9 (check the "Affects Version" field) > then you can un-target it from JDK 9 by clearing the "Fix Version" > field or setting that field to some future release, or > > - If the bug is new in JDK 9 and is P1 or P2 but it cannot be fixed in > time then you can request that the bug be deferred from the release. > > In any case, do not change the priority of a bug in order to remove it > from the list. The priority of a bug should reflect the importance of > fixing it independent of any particular release, as has been standard > practice for the JDK for many years. > > To document the reason for deferring a P1 or P2 bug I propose the > following process: > > - Request a deferral by updating the JBS issue to add a comment whose > first line is "Deferral Request". In that comment briefly describe > the reason for the deferral (e.g., insufficient time, complexity or > risk of fix, etc.). Add the label "jdk9-defer-request" to the issue. > > - The Area Leads, relevant Group Leads, and the JDK 9 Project Lead will > review such requests on a regular basis, at least weekly if not more > often. One of them will take one of the following actions: > > - Approve the request by adding the label "jdk9-defer-yes". > > - Reject the request by adding the label "jdk9-defer-no", along > with a comment describing the reason for this action. > > - Request more information by adding the label "jdk9-defer-nmi" > ("nmi" = "needs more information"), along with a comment > describing what information is requested. > > - If you're asked to provide more information for a deferral request > then please do so in a new comment in the issue, and then remove the > "jdk9-defer-nmi" label so that we see that it's ready for re-review. > > - If your request is approved then clear the issue's "Fix Version" > field or set it to some future release. > > - In any case, do not remove the original "jdk9-defer-request" label. > > Deferrals will not be granted for TCK issues identified by the label > "tck-red-9" [2]. Deferrals are also unlikely for bugs that prevent > release testing. > > For the record, the Area Leads are Mikael Vidstedt (VM), Brian Goetz > (Language and Libraries), and Kevin Rushforth (Client Libraries). > The relevant Group Leads are as follows, per the Census [3]: > > Sergey Bylokhov - AWT > Tim Bell - Build > Jonathan Gibbons - Compiler > Alan Bateman - Core Libraries > Vladimir Kozlov - HotSpot > Masayoshi Okutsu - Internationalization > Michael McMahon - Networking > Dalibor Topic - Porters > Sean Mullan - Security > Staffan Larsen - Serviceability > Alexander Scherbatiy - Swing > Phil Race - 2D Graphics & Sound > > JDK 9 Committers are invited to comment on this process proposal. If > no serious objections are raised in one week's time, by 15:00 UTC next > Wednesday, 7 September 2016, then this is the process that we'll use. > > In anticipation that we'll use this process, more or less, owners of > bugs on the RDP1 candidate list are encouraged to proceed as outlined > above. This will allow us to move quickly once the process is in > place. > > - Mark > > > [1] http://openjdk.java.net/projects/jdk9/ > [2] https://bugs.openjdk.java.net/issues/?filter=18893 > [3] http://openjdk.java.net/census > From li.jiang at oracle.com Wed Aug 31 18:34:38 2016 From: li.jiang at oracle.com (Leo Jiang) Date: Thu, 1 Sep 2016 02:34:38 +0800 Subject: RFR: 8145952: 8164784: Currency update for ISO 4217 Amendment #161 162 In-Reply-To: References: <81e70e92-9013-b68e-b57e-bee50092fd16@oracle.com> <357c0cf4-d7ac-f2a6-65e9-98265d6bddc6@oracle.com> Message-ID: <10c0f9ac-2244-9ce8-7c0a-3a6dc37c8b08@oracle.com> Thank you Naoto! Updated webrev: http://cr.openjdk.java.net/~ljiang/8145952/webrev.01/ Regards, Leo On 08/31/2016 01:22 AM, Naoto Sato wrote: > Hi Leo, > > Here are my comments: > > - CurrencyData.properties/tablea1.txt: Since it is already past the transition date (7/1/16), I think we don't need to > use the transition format. "BY=BYN" should suffice. > > - CurrencyNames.properties: the English name for BYR is now "Belarusian Ruble (2000?2016)" in the latest CLDR data. > > Naoto > > On 8/30/16 1:31 AM, Leo Jiang wrote: >> Sorry >> Webrev: http://cr.openjdk.java.net/~ljiang/8145952/webrev.00/ >> >> Thanks, >> Leo >> >> On 08/30/2016 04:29 PM, Leo Jiang wrote: >>> Hi all, >>> >>> Please review the change for Currency data update for ISO 4217 >>> Amendment #161 162. >>> >>> Bugs: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8145952 >>> https://bugs.openjdk.java.net/browse/JDK-8164784 >>> >>> Please refer these docs for currency changes. >>> http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_161.pdf >>> >>> http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_162.pdf >>> >>> >>> Have run the builds and test jdk_text for all platform, passed. >>> >>> Regards, >>> Leo From lana.steuck at oracle.com Wed Aug 31 20:26:48 2016 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 31 Aug 2016 20:26:48 GMT Subject: jdk9-b134: dev Message-ID: <201608312026.u7VKQmub016363@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/065724348690 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/e05400ba9357 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/f08683786207 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/803adcd526d7 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/ab1d78d395d4 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/1c6c21d87aa4 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/b8b694c6b4d2 http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/1a497f5ca0cf --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-7068008 core-libs closed/java/util/Calendar/CalendarTestScripts/JapaneseRollTests.sh exe JDK-7180225 core-libs SecurityExceptions not defined in some class loader methods JDK-8005068 core-libs HttpCookie does not correctly handle negative maxAge values JDK-8066943 core-libs (fs) Path.relativize() gives incorrect result for ".." JDK-8145464 core-libs implement deprecation static analysis tool JDK-8160971 core-libs Re-enable VarHandle tests quarantined by JDK-8160690 JDK-8163126 core-libs Fix @modules in some of jdk/* tests JDK-8163136 core-libs Add print statements to java/nio/file/WatchService/LotsOfCancels.java JDK-8163353 core-libs NPE in ConcurrentHashMap.removeAll() JDK-8163371 core-libs Enable tracing which JLI classes can be pre-generated JDK-8163561 core-libs Add a test for Proxy Authentication in HTTP/2 Client API JDK-8164061 core-libs Fix @since for javax.sql.rowset.BaseRowSet and javax.sql.CommonDataSou JDK-8164159 core-libs java/nio/file/WatchService/UpdateInterference.java test leaves daemon JDK-8164166 core-libs Make sure java/nio/channels tests shutdown asynchronous channel groups JDK-8164366 core-libs ZoneOffset.ofHoursMinutesSeconds() does not reject invalid input JDK-8164389 core-libs jdk.nio.zipfs.JarFileSystem does not completely traverse the versioned JDK-8164483 core-libs Generate field lambda forms at link time JDK-8164524 core-libs Correct inconsistencies in floating-point abs spec JDK-8164556 core-libs Drop AAC and FLAC from content type check in java/nio/file/Files/probe JDK-8164569 core-libs Generate non-customized invoker forms at link time JDK-8164585 core-libs JarFile::isMultiRelease does not return true in all cases where it sho JDK-8164589 core-libs Remove sun/rmi/runtime/Log/6409194/NoConsoleOutput.java from ProblemL JDK-8164592 core-libs java/net/MulticastSocket/NoLoopbackPackets.java tests may leave a daem JDK-8164618 core-libs add documentation for NativeNumber and NativeBoolean JDK-8164649 core-libs Cleanup of test java/nio/channels/FileChannel/Lock.java JDK-8164669 core-libs Lazier initialization of java.time JDK-8164698 core-libs modify jdk makefiles to build jdeprscan JDK-8164739 core-libs Remove computation of predefined interpreter forms JDK-8164748 core-libs Edit pad crashes when calling function JDK-8164834 core-libs remove jdeprscan from tools/launcher/VersionCheck.java JDK-8164835 core-libs add a few tools tests to the problem list JDK-8164866 core-libs tools/jlink/plugins/GenerateJLIClassesPluginTest.java can't compile af JDK-8164124 hotspot [BACKOUT] G1 does not implement millis_since_last_gc which is needed b JDK-8024714 security-libs In java.security file, ocsp.responderCertSubjectName should not contai JDK-8061842 security-libs Package jurisdiction policy files as something other than JAR JDK-8074838 security-libs Resolve disabled warnings for libj2pkcs11 JDK-8150530 security-libs Improve javax.crypto.BadPaddingException messages JDK-8151893 security-libs Add security property to configure XML Signature secure validation mod JDK-8164533 security-libs sun/security/ssl/SSLSocketImpl/CloseSocket.java failed with "Error whi JDK-8164656 security-libs krb5 does not retry if TCP connection timeouts JDK-8047338 tools javac is not correctly filtering non-members methods to obtain the fun JDK-8066577 tools Cleanup and make better use of the stream API in the jrtfs code JDK-8147491 tools module graph consistency checks after jlink plugins operate on module JDK-8153897 tools jshell tool: "not active" must be pulled from resource file JDK-8156984 tools JShell tool: for (FormatCase e : EnumSet.allOf(FormatCase.class)) JDK-8157349 tools Missing doc-files in javadoc documentation JDK-8158738 tools jshell tool: Save does not affect jshell if started from another edito JDK-8159004 tools jlink attempts to create launcher scripts when root/bin dir does not e JDK-8160089 tools jshell tool: use new double-dash long-form command-line options JDK-8161501 tools JSR269 jigsaw update: javax.lang.model.element.ModuleElement.getEnclos JDK-8163793 tools jlink has typo in copy-files plugin help text example JDK-8163991 tools Fix license and copyright headers under test/jdk/javadoc/ and test/too JDK-8164130 tools Simplify doclet IOException handling JDK-8164399 tools inference of thrown variable does not work correctly JDK-8164596 tools jshell tool: jdk repo module pages to allow double-dash fix to access JDK-8164598 tools Problem list TestIOException.java JDK-8164745 tools javac -Xmodule compiles the module in a way that reads the unnamed mod JDK-8164747 tools allclasses-frame broken after JDK-8162353 JDK-8164800 tools Cross targeting Windows JDK-8164836 tools TEST_BUG: adjust scope of the DefinedByAnalyzer in tools/all/RunCoding JDK-8164887 tools update tests to remove use of old-style options JDK-8157797 xml SAX Parser throws incorrect error on invalid xml JDK-8163232 xml Catalog API: Consolidating CatalogResolver to support all XML Resolver From naoto.sato at oracle.com Wed Aug 31 20:29:35 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 31 Aug 2016 13:29:35 -0700 Subject: RFR: 8145952: 8164784: Currency update for ISO 4217 Amendment #161 162 In-Reply-To: <10c0f9ac-2244-9ce8-7c0a-3a6dc37c8b08@oracle.com> References: <81e70e92-9013-b68e-b57e-bee50092fd16@oracle.com> <357c0cf4-d7ac-f2a6-65e9-98265d6bddc6@oracle.com> <10c0f9ac-2244-9ce8-7c0a-3a6dc37c8b08@oracle.com> Message-ID: <390af4f5-f2e6-51ab-3795-321ef131ec42@oracle.com> Hi Leo, I noticed that "tablea1.txt" has the modified entry for "BY", but it seems to be delimited by a single space character instead of a tab. Now I just wonder, does the test "test/java/util/Currency/ValidateISO4217.java" pass? Furthermore, the test itself needs to be modified as well because "BYN" should be added in "otherCodes" field. I also noticed that the English name for "BYB" is now "Belarusian Ruble (1994?1999)". Note that "New" has been removed. Naoto On 8/31/16 11:34 AM, Leo Jiang wrote: > Thank you Naoto! > > Updated webrev: > http://cr.openjdk.java.net/~ljiang/8145952/webrev.01/ > > Regards, > Leo > > On 08/31/2016 01:22 AM, Naoto Sato wrote: >> Hi Leo, >> >> Here are my comments: >> >> - CurrencyData.properties/tablea1.txt: Since it is already past the >> transition date (7/1/16), I think we don't need to >> use the transition format. "BY=BYN" should suffice. >> >> - CurrencyNames.properties: the English name for BYR is now >> "Belarusian Ruble (2000?2016)" in the latest CLDR data. >> >> Naoto >> >> On 8/30/16 1:31 AM, Leo Jiang wrote: >>> Sorry >>> Webrev: http://cr.openjdk.java.net/~ljiang/8145952/webrev.00/ >>> >>> Thanks, >>> Leo >>> >>> On 08/30/2016 04:29 PM, Leo Jiang wrote: >>>> Hi all, >>>> >>>> Please review the change for Currency data update for ISO 4217 >>>> Amendment #161 162. >>>> >>>> Bugs: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8145952 >>>> https://bugs.openjdk.java.net/browse/JDK-8164784 >>>> >>>> Please refer these docs for currency changes. >>>> http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_161.pdf >>>> >>>> >>>> http://www.currency-iso.org/dam/isocy/downloads/dl_currency_iso_amendment_162.pdf >>>> >>>> >>>> >>>> Have run the builds and test jdk_text for all platform, passed. >>>> >>>> Regards, >>>> Leo From alejandro.murillo at oracle.com Wed Aug 31 21:02:08 2016 From: alejandro.murillo at oracle.com (Alejandro Murillo) Date: Wed, 31 Aug 2016 15:02:08 -0600 Subject: jdk9-dev: HotSpot Message-ID: jdk9-hs-2016-08-26 has been integrated into jdk9-dev. http://hg.openjdk.java.net/jdk9/dev/rev/f497fafdc02e http://hg.openjdk.java.net/jdk9/dev/corba/rev/1a497f5ca0cf http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/c1471e013d89 http://hg.openjdk.java.net/jdk9/dev/jaxp/rev/2bb277192648 http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/ab1d78d395d4 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/85acda36fccb http://hg.openjdk.java.net/jdk9/dev/langtools/rev/d2959c941df3 http://hg.openjdk.java.net/jdk9/dev/nashorn/rev/e05400ba9357 Component : VM Status : Go for integration Date : 08/30/2016 at 20:00 MSK Tested By : VM SQE &dmitry.fazunenko at oracle.com Bundles : 2016-08-26-170438.amurillo.jdk9-hs-2016-08-26-snapshot Testing: 217 new failures, 3050 known failures, 1441756 passed. Issues and Notes: No stoppers have been detected so far. Go for integration CRs for testing: 8037138: x86: problem with JVMTI breakpoint 8038797: JVMTI FollowReferences does not report roots reachable from nmethods 8061219: Implement unit-tests for UL 8145964: NoClassDefFound error in transforming lambdas 8151345: compiler/codecache/jmx/PeakUsageTest.java is failing on jdk9/dev for JPRT -testset hotspot 8152849: share/vm/runtime/mutex.cpp:1161 assert(((uintptr_t(_owner))|(uintptr_t(_LockWord.FullWord))|(uintptr_t(_EntryList))|(uintptr_t(_WaitSet))|(uintptr_t(_OnDeck))) == 0) failed 8155043: BitMap set operations assume clear bits beyond unaligned end 8155964: Create a set of tests for verifying the Minimal VM 8156659: assert(CodeCache::find_blob_unsafe(_pc) == _cb) failed: inconsistent 8157236: attach on ARMv7 fails with com.sun.tools.attach.AttachNotSupportedException: Unable to open socket file 8157904: Atomic::cmpxchg for jbyte is missing a fence on initial failure 8157907: Incorrect inclusion of atomic.hpp instead of atomic.inline.hpp 8157957: ClassNotFoundException: jdk.test.lib.JDKToolFinder 8158628: test/java/lang/instrument/NativeMethodPrefixAgent.java: Error occurred during initialization of VM: Failed to start tracing backend. 8161598: Kitchensink fails: assert(nm->insts_contains(original_pc)) failed: original PC must be in nmethod/CompiledMethod 8162530: src/jdk.management/share/native/libmanagement_ext/GcInfoBuilder.c doesn't handle JNI exceptions properly 8163146: Remove os::check_heap on Windows 8163413: gc/metaspace/TestMetaspacePerfCounters failure 8163808: Fix asserts and logging for old classfile vtable construction 8163962: [JVMCI] integrate VarHandles 8163973: VM Anonymous classes should not call Class File Load Hooks 8164035: compiler/profiling/spectrapredefineclass_classloaders/Launcher.java failing with Agent JAR not found or no Agent-Class attribute 8164091: VM fails during startup with "assert(resolved_method->method_holder()->is_linked()) failed: must be linked" 8164103: C2: Broken cmpxchgb encoding on x86 8164113: AArch64: follow-up the fix for 8161598 8164208: Update tests with redefine classes UL options and tags? 8164297: Jtreg test exeinvoke fails to link on Ubuntu 8164319: CLHSDB dumpcodecache throws StackOverflowError 8164520: java/lang/ProcessHandle/Basic.java is missing @library tag 8164521: compiler/rangechecks/TestRangeCheckSmearing.java is missing @build for sun.hotspot.WhiteBox 8164523: Clean up metadata for event based tracing -- Alejandro