From ramanand.patil at oracle.com Wed Jan 4 07:19:56 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Tue, 3 Jan 2017 23:19:56 -0800 (PST) Subject: CFV: New JDK 9 Committer: Manajit Halder In-Reply-To: <2D7158B9-F25F-4354-B64C-6BA4FE9BC8B0@oracle.com> References: <2D7158B9-F25F-4354-B64C-6BA4FE9BC8B0@oracle.com> Message-ID: Vote: yes -----Original Message----- From: Sergey Bylokhov Sent: Monday, December 26, 2016 8:06 PM To: jdk9-dev at openjdk.java.net Subject: CFV: New JDK 9 Committer: Manajit Halder I hereby nominate Manajit Halder to JDK 9 Committer. Manajit is currently a JDK 9 Author and a member of the client team at Oracle. He has made 17 contributions to the JDK 9: http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=mhalder&revcount=160 Votes are due by Jan 15, 2017. 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 nadeesh.tv at oracle.com Wed Jan 4 07:24:33 2017 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 04 Jan 2017 12:54:33 +0530 Subject: CFV: New JDK 9 Committer: Manajit Halder In-Reply-To: References: <2D7158B9-F25F-4354-B64C-6BA4FE9BC8B0@oracle.com> Message-ID: <586CA331.2060905@oracle.com> Vote : Yes -- Thanks and Regards, Nadeesh TV On 1/4/2017 12:49 PM, Ramanand Patil wrote: > Vote: yes > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, December 26, 2016 8:06 PM > To: jdk9-dev at openjdk.java.net > Subject: CFV: New JDK 9 Committer: Manajit Halder > > I hereby nominate Manajit Halder to JDK 9 Committer. > > Manajit is currently a JDK 9 Author and a member of the client team at Oracle. He has made 17 contributions to the JDK 9: > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=mhalder&revcount=160 > > Votes are due by Jan 15, 2017. > > 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 vladimir.kozlov at oracle.com Wed Jan 4 19:30:38 2017 From: vladimir.kozlov at oracle.com (Vladimir Kozlov) Date: Wed, 4 Jan 2017 11:30:38 -0800 Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now In-Reply-To: References: <586BF343.7040608@oracle.com> Message-ID: <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com> On 1/4/17 2:23 AM, Volker Simonis wrote: > On Tue, Jan 3, 2017 at 7:53 PM, Vladimir Kozlov > wrote: >> We are currently in "Rampdown" phase for jdk 9 which allows only P1-P3 bugs >> fixes. Note for Hotspot it started week ago. >> >> http://openjdk.java.net/projects/jdk9/ >> >> Please, make sure bugs you are planning to fix have P1-P3 priority and "fix >> version" is jdk 9. I just updated JDK-8171266 [1] for that. >> > > Thanks a lot Vladimir. I'll push it today. > > Just for clarification: do the "Rampdown phase rules" also apply to > non-Oracle platforms like ppc64 or s390x? In the past, we were allowed > to push non P1-P3 bugs or enhancements even in later phases as long as > they didn't touch shared code. Is this still allowed or do we now have > to strictly conform to the process even for ppc64/s390x-only changes? JDK 9 schedule was approved by all, including Java Community outside Oracle. I looked on original Mark's email about "JDK 9 Rampdown Phase 1" and there were no exceptions listed: http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html But I understand that JDK 9 schedule reflects the process inside Oracle and may not be applied directly to your process. I will try to clarify situation with your ports regarding JDK 9 schedule and inform you. Regards, Vladimir > > Thanks a lot and best regards, > Volker > >> You can rise priority to P3 if you think a bug must be fixed in jdk 9 or >> defer it to jdk 10 - set "fix version" to 10. >> >> I see 3 aarch64 P4-P5 bugs which should be updated accordingly: >> >> https://bugs.openjdk.java.net/browse/JDK-8170101 >> https://bugs.openjdk.java.net/browse/JDK-8170103 >> https://bugs.openjdk.java.net/browse/JDK-8165058 >> >> Thanks, >> Vladimir >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8171266 >> "PPC64: Add support to -XX:RTMSpinLoopCount=0" >> From lana.steuck at oracle.com Wed Jan 4 21:01:42 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 4 Jan 2017 21:01:42 GMT Subject: jdk9-b151: dev Message-ID: <201701042101.v04L1gdk005880@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/71a766d4c180 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/2a0437036a64 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/4f348bd05341 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/d27bab22ff62 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/c48b4d4768b1 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/13c6906bfc86 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/2a2ac7d9f52c http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/77f827f5bbad --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8039273 client-libs Font related files should not be modified in ${java.home}/lib JDK-8074883 client-libs Tab key should move to focused button in a button group JDK-8131347 client-libs new @BeanProperty annotation: inconsistent behavior for "enumerationVa JDK-8134612 client-libs clipboard.getData(dataFlavor) can throw UnsupportedFlavorException for JDK-8170798 client-libs Fix minor issues in java2d and sound coding. JDK-8171074 client-libs Test api/javax_swing/UIManager/index.html\#Methods is failing JDK-8171363 client-libs [PIT] Four Windows-specific tests fail with InaccessibleObjectExceptio JDK-8029360 core-libs java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently JDK-8029459 core-libs (reflect) getMethods returns methods that are not members of the class JDK-8056205 core-libs (fs) Potential for NPE in Files.walkFileTree if closing directory fail JDK-8061950 core-libs Class.getMethods() exhibits quadratic time complexity JDK-8062389 core-libs Class.getMethod() is inconsistent with Class.getMethods() results JDK-8073080 core-libs TEST_BUG: sun/rmi/transport/tcp/DeadCachedConnection.java fails due to JDK-8145633 core-libs Adjacent value parsing not supported for Localized Patterns JDK-8151994 core-libs test/script/basic/JDK-8141209.js fails JDK-8160036 core-libs Java API doc for method minusMonths in LocalDateTime class needs corre JDK-8165664 core-libs (ch) sun.nio.ch.SocketAdaptor does not respect timeout in case of syst JDK-8167143 core-libs CLDR timezone parsing does not work for all locales JDK-8168840 core-libs InetAddress.getByName() throws java.net.UnknownHostException no such i JDK-8170484 core-libs Miscellaneous changes imported from jsr166 CVS 2016-12 JDK-8170977 core-libs SparseArrayData should not grow its underlying dense array data JDK-8171051 core-libs LinkedBlockingQueue spliterator needs to support node self-linking JDK-8171824 core-libs Remove OpenNonIntegralNumberOfSampleframes.java and ServerIdentityTest JDK-8171849 core-libs Can't unambiguously select between fixed arity signatures [(java.util JDK-8171906 core-libs Changes for 8148023 break AIX build JDK-8171940 core-libs Incorrect statement about an absolute value of months unit after perio JDK-8171988 core-libs Backout of fix for 8062389, 8029459, 8061950 JDK-8159127 core-svc hprof heap dumps broken for lambda classdata JDK-8153808 deploy Revamped JCP: High Contrast Mode JDK-8162590 deploy [test] InteropTest::testCorba failed due to "java.lang.NoClassDefFound JDK-8170380 deploy Fail to remove the specific application by "javaws -uninstall URL" JDK-8170806 deploy [jcp] User/system toggle buttons should be fixed JDK-8171897 docs Remove third party readme files left from JDK-8169925 JDK-8139566 hotspot need proper sync for adding default read edges JDK-8150563 hotspot LoadAgentDcmdTest.java can't find libinstrument.so JDK-8165496 hotspot assert(_exception_caught == false) failed: _exception_caught is out of JDK-8167586 hotspot Replace com.oracle.jfr.types.StringConstant with java.lang.String in t JDK-8169177 hotspot aarch64: SIGSEGV when "-XX:+ZeroTLAB" is specified along with GC optio JDK-8169373 hotspot Work around linux NPTL stack guard error JDK-8169938 hotspot [AOT] SIGSEGV at ~BufferBlob::vtable chunks JDK-8170464 hotspot Remove shell script from compiler/c2/cr7005594/Test7005594.java JDK-8170548 hotspot VM may crash at startup because StdoutLog/StderrLog logging stream can JDK-8170655 hotspot [posix] Fix minimum stack size computations JDK-8170767 hotspot Zero fastdebug build triggers assertion JDK-8170886 hotspot compiler/ciReplay/TestSAServer.java intermittently throws NumberFormat JDK-8170919 hotspot LogStreamTest tests crash if they are run first JDK-8170936 hotspot Logging: LogFileOutput.invalid_file_test crashes when executed twice. JDK-8171011 hotspot convert some CDS dump time warning and error messages to informational JDK-8171092 hotspot C1's Math.fma() intrinsic doesn't correctly process its inputs JDK-8171129 hotspot [aarch64] hs_err logs do not print register mappings JDK-8171155 hotspot Scanning method file for initialized final field updates can fail for JDK-8171225 hotspot [aix] Fix gtests compile error on AIX 7.1 with xlC 12 JDK-8171236 hotspot RTM/HTM jtreg tests regression after transition to the new GNU-style o JDK-8171244 hotspot PPC64: Make interpreter's math entries consistent with C1 and C2 and s JDK-8171394 hotspot [AOT] failed AOT compilation in compiler/aot/RecompilationTest.java JDK-8171398 hotspot s390x Make interpreter's math entries consistent with C1 and C2 and su JDK-8171408 hotspot [aix] TOC overflow when linking the gtest libjvm.so JDK-8171410 hotspot aarch64: long multiplyExact shifts by 31 instead of 63 JDK-8171417 hotspot post jigsaw review cleanup in the jtreg jvmti tests JDK-8171433 hotspot [aix] switch on gtest AIX build JDK-8171517 hotspot test_logMessageTest.cpp has "ac_heapanied" instead of "accompanied" in JDK-8171537 hotspot aarch64: compiler/c1/Test6849574.java generates guarantee failure in C JDK-8171807 hotspot 8170761 fix should be applied to ARM code after 8168503 JDK-8171815 hotspot [TESTBUG] Update expected failure message in runtime/modules/IgnoreMod JDK-8170741 infrastructure Enable uploading of built artifacts through Jib JDK-8171310 infrastructure Gtest libjvm.so is always stripped JDK-8171548 infrastructure JDK bundles changes sym links incorrectly in the legal directory JDK-8171859 infrastructure Configure check for modular boot jdk needs to be updated JDK-8171978 infrastructure docs should use CSS-friendly instead of JDK-6972386 security-libs issues with String.toLowerCase/toUpperCase JDK-8161232 security-libs AsyncSSLSocketClose.java test fails timeout. JDK-8168935 security-libs sun/security/ssl/SSLContextImpl/TrustTrustedCert.java failed Intermitt JDK-8171443 security-libs (spec) An ALPN callback function may also ignore ALPN JDK-8172048 security-libs Re-examine use of AtomicReference in java.security.Policy JDK-8168615 tools JShell API: jdk.jshell.spi should be a pluggable ServiceLoader SPI JDK-8169091 tools Method reference T::methodName for generic type T does not compile any JDK-8170618 tools jmod should validate if any exported or open package is missing JDK-8171132 tools Improve class reading of invalid or out-of-range ConstantValue attribu JDK-8171387 tools jshell tool: message inconsistencies JDK-8171892 tools JShell: incorrect printing of multidemensional arrays JDK-8172102 tools jshell tool: remove print method forwarding to System.out from default JDK-8172155 tools jshell tool (make): include built-in startup scripts in image JDK-8067237 xml [TESTBUG] javax/xml/ws/xsanymixed/Test.java failed on compilation From aph at redhat.com Thu Jan 5 09:59:34 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 5 Jan 2017 09:59:34 +0000 Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now In-Reply-To: <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com> References: <586BF343.7040608@oracle.com> <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com> Message-ID: <532669d5-0a2a-06d3-c931-3ba423a4f7df@redhat.com> On 04/01/17 19:30, Vladimir Kozlov wrote: > On 1/4/17 2:23 AM, Volker Simonis wrote: >> >> Just for clarification: do the "Rampdown phase rules" also apply to >> non-Oracle platforms like ppc64 or s390x? In the past, we were allowed >> to push non P1-P3 bugs or enhancements even in later phases as long as >> they didn't touch shared code. Is this still allowed or do we now have >> to strictly conform to the process even for ppc64/s390x-only changes? > > JDK 9 schedule was approved by all, including Java Community outside Oracle. My opinion is that we want the non-Oracle targets to be just as reliable as the Oracle ones, so it's not in the community's interest to relax the rules very much. s390x is perhaps different in that it's very new, so might need a more flexible approach. Andrew. From Rony.Flatscher at wu.ac.at Thu Jan 5 18:42:07 2017 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 5 Jan 2017 19:42:07 +0100 Subject: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException Message-ID: Trying to run a program that gets the screen dimensions using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively. On a 64-bit Ubuntu the returned Toolkit is of type sun.awt.X11.XToolkit. Reflectively invoking its method getScreenSize() causes the following exception to be thrown on 9-ea+134: java.lang.reflect.InaccessibleObjectException: unable to make member of class sun.awt.SunToolkit accessible: module java.desktop does not export sun.awt to unnamed module ... A little bit baffled as this is from a script that has been working flawlessly throughout more than a decade on various Java versions and which employs documented public methods only (the sun.awt object is returned by java.awt.Toolkit). Is this a known "legacy"problem :) that I could circumvent somehow or a bug that needs to be reported? ---rony From Rony.Flatscher at wu.ac.at Thu Jan 5 19:03:02 2017 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 5 Jan 2017 20:03:02 +0100 Subject: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException In-Reply-To: References: Message-ID: Experimenting with further scripts indicates that this is a systematic problem whenever the official APIs return members that are not made available to an unnamed module: e.g. JavaFX some "com.sun.javafx.collections.VetoableListDecorator" or in a "plain" awt/swing app some "sun.java2d.SungGraphics2D". ---rony On 05.01.2017 19:42, Rony G. Flatscher wrote: > Trying to run a program that gets the screen dimensions using > java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively. > > On a 64-bit Ubuntu the returned Toolkit is of type sun.awt.X11.XToolkit. Reflectively invoking its > method getScreenSize() causes the following exception to be thrown on 9-ea+134: > > java.lang.reflect.InaccessibleObjectException: unable to make member of class sun.awt.SunToolkit > accessible: module java.desktop does not export sun.awt to unnamed module ... > > A little bit baffled as this is from a script that has been working flawlessly throughout more than > a decade on various Java versions and which employs documented public methods only (the sun.awt > object is returned by java.awt.Toolkit). Is this a known "legacy"problem :) that I could circumvent > somehow or a bug that needs to be reported? > > ---rony > From forax at univ-mlv.fr Thu Jan 5 19:31:50 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Thu, 5 Jan 2017 20:31:50 +0100 (CET) Subject: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException In-Reply-To: References: Message-ID: <1418373649.1608685.1483644710375.JavaMail.zimbra@u-pem.fr> In your script, when you execute a.b().c(), you should not call getClass() on the result of a.b() but using the return type of b() like the compiler do. it will solve your issue. cheers, R?mi ----- Mail original ----- > De: "Rony G. Flatscher" > ?: jdk9-dev at openjdk.java.net > Envoy?: Jeudi 5 Janvier 2017 20:03:02 > Objet: Re: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException > Experimenting with further scripts indicates that this is a systematic problem > whenever the official > APIs return members that are not made available to an unnamed module: e.g. > JavaFX some > "com.sun.javafx.collections.VetoableListDecorator" or in a "plain" awt/swing app > some > "sun.java2d.SungGraphics2D". > > ---rony > > On 05.01.2017 19:42, Rony G. Flatscher wrote: >> Trying to run a program that gets the screen dimensions using >> java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively. >> >> On a 64-bit Ubuntu the returned Toolkit is of type sun.awt.X11.XToolkit. >> Reflectively invoking its >> method getScreenSize() causes the following exception to be thrown on 9-ea+134: >> >> java.lang.reflect.InaccessibleObjectException: unable to make member of class >> sun.awt.SunToolkit >> accessible: module java.desktop does not export sun.awt to unnamed module ... >> >> A little bit baffled as this is from a script that has been working flawlessly >> throughout more than >> a decade on various Java versions and which employs documented public methods >> only (the sun.awt >> object is returned by java.awt.Toolkit). Is this a known "legacy"problem :) that >> I could circumvent >> somehow or a bug that needs to be reported? >> >> ---rony From naoto.sato at oracle.com Thu Jan 5 21:23:52 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 5 Jan 2017 13:23:52 -0800 Subject: CFV: New jdk9 Committer: Rachna Goel Message-ID: I hereby nominate Rachna Goel to jdk9 Committer. Rachna is currently a JDK 9 Author and a member of the Internationalization team at Oracle. She has made 22 contributions to JDK 9 [3], and here are the significant contributions among them [4]. Votes are due by Jan 19, 2017. Only current jdk9 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]. Naoto Sato [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for "AN", "BU" and "CS" country codes. 8075577: java.time does not support HOST provider 8146750: java.time.Month.getDisplayName() return incorrect narrow names with JRE provider on locale de,de_DE,en_US. 8163362: Reconsider reflection usage in java.awt.font.JavaAWTFontAccessImpl class 8135055: java.util.Date.after(java.sql.Timestamp ) does not return correct results 8163350: LocaleProviderAdapter Preference list retrieved is wrong, when -Djava.locale.providers=COMPAT 8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS 8154797: Localization data for "GMT" 8158504: test/sun/util/locale/provider/Bug8038436.java: non English locale(s) included in available locales 8145136: Upgrade CLDR locale data From Rony.Flatscher at wu.ac.at Thu Jan 5 21:27:34 2017 From: Rony.Flatscher at wu.ac.at (Rony G. Flatscher) Date: Thu, 5 Jan 2017 22:27:34 +0100 Subject: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException In-Reply-To: <1418373649.1608685.1483644710375.JavaMail.zimbra@u-pem.fr> References: <1418373649.1608685.1483644710375.JavaMail.zimbra@u-pem.fr> Message-ID: <4a9de385-ea1d-3861-b902-500e5627aeb7@wu.ac.at> Just realized that the emails get divided now to jdk9-dev and jigsaw-dev (where most replies occurred). Hence added a reply-to to jigsaw-dev. --- On 05.01.2017 20:31, Remi Forax wrote: > In your script, > when you execute a.b().c(), > you should not call getClass() on the result of a.b() but using the return type of b() like the compiler do. > > it will solve your issue. if I knew which return type to use programmatically as Phil Race pointed out. Taking your example and executing it in an interpreter causes two invocations: res=a.b() whatever b() returned will be stored in the Map and the key (a string) is returned to Rexx. In the next step this string is supplied to the Java bridge with the method c to execute, hence (unlike the compiler) no context available on the Java bridge at the time of the next invocation res.c() ---rony > ----- Mail original ----- >> De: "Rony G. Flatscher" >> ?: jdk9-dev at openjdk.java.net >> Envoy?: Jeudi 5 Janvier 2017 20:03:02 >> Objet: Re: Using java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively causes InaccessibleObjectException >> Experimenting with further scripts indicates that this is a systematic problem >> whenever the official >> APIs return members that are not made available to an unnamed module: e.g. >> JavaFX some >> "com.sun.javafx.collections.VetoableListDecorator" or in a "plain" awt/swing app >> some >> "sun.java2d.SungGraphics2D". >> >> ---rony >> >> On 05.01.2017 19:42, Rony G. Flatscher wrote: >>> Trying to run a program that gets the screen dimensions using >>> java.awt.Toolkit.getDefaultToolkit().getScreenSize() reflectively. >>> >>> On a 64-bit Ubuntu the returned Toolkit is of type sun.awt.X11.XToolkit. >>> Reflectively invoking its >>> method getScreenSize() causes the following exception to be thrown on 9-ea+134: >>> >>> java.lang.reflect.InaccessibleObjectException: unable to make member of class >>> sun.awt.SunToolkit >>> accessible: module java.desktop does not export sun.awt to unnamed module ... >>> >>> A little bit baffled as this is from a script that has been working flawlessly >>> throughout more than >>> a decade on various Java versions and which employs documented public methods >>> only (the sun.awt >>> object is returned by java.awt.Toolkit). Is this a known "legacy"problem :) that >>> I could circumvent >>> somehow or a bug that needs to be reported? >>> >>> ---rony From nishit.jain at oracle.com Fri Jan 6 05:56:46 2017 From: nishit.jain at oracle.com (Nishit Jain) Date: Fri, 6 Jan 2017 11:26:46 +0530 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: <6a6ec00b-dfd1-7034-f407-cc9c6210632c@oracle.com> Vote: Yes Regards, Nishit Jain On 06-01-2017 02:53, Naoto Sato wrote: > I hereby nominate Rachna Goel to jdk9 Committer. > > Rachna is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. She has made 22 contributions to > JDK 9 [3], and here are the significant contributions among them [4]. > > Votes are due by Jan 19, 2017. > > Only current jdk9 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]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) > [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for > "AN", "BU" and "CS" country codes. > 8075577: java.time does not support HOST provider > 8146750: java.time.Month.getDisplayName() return incorrect narrow > names with JRE provider on locale de,de_DE,en_US. > 8163362: Reconsider reflection usage in > java.awt.font.JavaAWTFontAccessImpl class > 8135055: java.util.Date.after(java.sql.Timestamp ) does not return > correct results > 8163350: LocaleProviderAdapter Preference list retrieved is wrong, > when -Djava.locale.providers=COMPAT > 8066652: Default TimeZone is GMT not local if user.timezone is invalid > on Mac OS > 8154797: Localization data for "GMT" > 8158504: test/sun/util/locale/provider/Bug8038436.java: non English > locale(s) included in available locales > 8145136: Upgrade CLDR locale data From goetz.lindenmaier at sap.com Fri Jan 6 07:54:04 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 6 Jan 2017 07:54:04 +0000 Subject: Only P1-P3 bugs fixes are allowed to push into jdk9 now In-Reply-To: <532669d5-0a2a-06d3-c931-3ba423a4f7df@redhat.com> References: <586BF343.7040608@oracle.com> <3fa78b65-93cc-1c9c-d39c-e7eafa82ce20@oracle.com> <532669d5-0a2a-06d3-c931-3ba423a4f7df@redhat.com> Message-ID: Hi, I think we need a bit relaxed rules for the ports because we often lag behind a bit. So I only managed to implement the reserved stack zone recently. Other features pushed short before the deadline might need work in the ports we can only do once the main change is pushed. We would like to deliver a VM that implements all the new features x86 does on ppc and s390. But I think it can be considered a bug if a new feature is not implemented. By the way, I think aarch does not yet implement the reserved stack zone (JEP 270). Best regards, Goetz > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Andrew Haley > Sent: Donnerstag, 5. Januar 2017 12:00 > To: jdk9-dev at openjdk.java.net > Subject: Re: Only P1-P3 bugs fixes are allowed to push into jdk9 now > > On 04/01/17 19:30, Vladimir Kozlov wrote: > > On 1/4/17 2:23 AM, Volker Simonis wrote: > >> > >> Just for clarification: do the "Rampdown phase rules" also apply to > >> non-Oracle platforms like ppc64 or s390x? In the past, we were allowed > >> to push non P1-P3 bugs or enhancements even in later phases as long as > >> they didn't touch shared code. Is this still allowed or do we now have > >> to strictly conform to the process even for ppc64/s390x-only changes? > > > > JDK 9 schedule was approved by all, including Java Community outside > Oracle. > > My opinion is that we want the non-Oracle targets to be just as > reliable as the Oracle ones, so it's not in the community's interest > to relax the rules very much. > > s390x is perhaps different in that it's very new, so might need a more > flexible approach. > > Andrew. From vyom.tewari at oracle.com Fri Jan 6 09:46:12 2017 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Fri, 6 Jan 2017 15:16:12 +0530 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: <4c095c29-b292-aff2-8388-d24028599516@oracle.com> Vote: Yes Vyom On Friday 06 January 2017 02:53 AM, Naoto Sato wrote: > I hereby nominate Rachna Goel to jdk9 Committer. > > Rachna is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. She has made 22 contributions to > JDK 9 [3], and here are the significant contributions among them [4]. > > Votes are due by Jan 19, 2017. > > Only current jdk9 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]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) > [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for > "AN", "BU" and "CS" country codes. > 8075577: java.time does not support HOST provider > 8146750: java.time.Month.getDisplayName() return incorrect narrow > names with JRE provider on locale de,de_DE,en_US. > 8163362: Reconsider reflection usage in > java.awt.font.JavaAWTFontAccessImpl class > 8135055: java.util.Date.after(java.sql.Timestamp ) does not return > correct results > 8163350: LocaleProviderAdapter Preference list retrieved is wrong, > when -Djava.locale.providers=COMPAT > 8066652: Default TimeZone is GMT not local if user.timezone is invalid > on Mac OS > 8154797: Localization data for "GMT" > 8158504: test/sun/util/locale/provider/Bug8038436.java: non English > locale(s) included in available locales > 8145136: Upgrade CLDR locale data From christoph.langer at sap.com Mon Jan 9 05:52:31 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Mon, 9 Jan 2017 05:52:31 +0000 Subject: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: Vote:yes Christoph > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Naoto Sato > Sent: Donnerstag, 5. Januar 2017 22:24 > To: jdk9-dev > Subject: CFV: New jdk9 Committer: Rachna Goel > > I hereby nominate Rachna Goel to jdk9 Committer. > > Rachna is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. She has made 22 contributions to > JDK 9 [3], and here are the significant contributions among them [4]. > > Votes are due by Jan 19, 2017. > > Only current jdk9 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]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22 > rachna.goel%40oracle.com%22)+or+author(rgoel)) > [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for > "AN", "BU" and "CS" country codes. > 8075577: java.time does not support HOST provider > 8146750: java.time.Month.getDisplayName() return incorrect narrow names > with JRE provider on locale de,de_DE,en_US. > 8163362: Reconsider reflection usage in > java.awt.font.JavaAWTFontAccessImpl class > 8135055: java.util.Date.after(java.sql.Timestamp ) does not return > correct results > 8163350: LocaleProviderAdapter Preference list retrieved is wrong, when > -Djava.locale.providers=COMPAT > 8066652: Default TimeZone is GMT not local if user.timezone is invalid > on Mac OS > 8154797: Localization data for "GMT" > 8158504: test/sun/util/locale/provider/Bug8038436.java: non English > locale(s) included in available locales > 8145136: Upgrade CLDR locale data From rahul.v.raghavan at oracle.com Mon Jan 9 05:58:54 2017 From: rahul.v.raghavan at oracle.com (Rahul Raghavan) Date: Sun, 8 Jan 2017 21:58:54 -0800 (PST) Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: Vote: Yes -Rahul > -----Original Message----- > From: Naoto Sato > Sent: Friday, January 06, 2017 2:54 AM > To: jdk9-dev > Subject: CFV: New jdk9 Committer: Rachna Goel > > I hereby nominate Rachna Goel to jdk9 Committer. > > Rachna is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. She has made 22 contributions to > JDK 9 [3], and here are the significant contributions among them [4]. > > Votes are due by Jan 19, 2017. > > Only current jdk9 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]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) > [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for > "AN", "BU" and "CS" country codes. > 8075577: java.time does not support HOST provider > 8146750: java.time.Month.getDisplayName() return incorrect narrow names > with JRE provider on locale de,de_DE,en_US. > 8163362: Reconsider reflection usage in > java.awt.font.JavaAWTFontAccessImpl class > 8135055: java.util.Date.after(java.sql.Timestamp ) does not return > correct results > 8163350: LocaleProviderAdapter Preference list retrieved is wrong, when > -Djava.locale.providers=COMPAT > 8066652: Default TimeZone is GMT not local if user.timezone is invalid > on Mac OS > 8154797: Localization data for "GMT" > 8158504: test/sun/util/locale/provider/Bug8038436.java: non English > locale(s) included in available locales > 8145136: Upgrade CLDR locale data From harsha.wardhana.b at oracle.com Mon Jan 9 06:27:41 2017 From: harsha.wardhana.b at oracle.com (Harsha Wardhana B) Date: Mon, 9 Jan 2017 11:57:41 +0530 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: Vote: Yes -Harsha On Monday 09 January 2017 11:28 AM, Rahul Raghavan wrote: > Vote: Yes > > -Rahul > >> -----Original Message----- >> From: Naoto Sato >> Sent: Friday, January 06, 2017 2:54 AM >> To: jdk9-dev >> Subject: CFV: New jdk9 Committer: Rachna Goel >> >> I hereby nominate Rachna Goel to jdk9 Committer. >> >> Rachna is currently a JDK 9 Author and a member of the >> Internationalization team at Oracle. She has made 22 contributions to >> JDK 9 [3], and here are the significant contributions among them [4]. >> >> Votes are due by Jan 19, 2017. >> >> Only current jdk9 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]. >> >> Naoto Sato >> >> [1] http://openjdk.java.net/census >> [2] http://openjdk.java.net/projects/#committer-vote >> [3] >> http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) >> [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for >> "AN", "BU" and "CS" country codes. >> 8075577: java.time does not support HOST provider >> 8146750: java.time.Month.getDisplayName() return incorrect narrow names >> with JRE provider on locale de,de_DE,en_US. >> 8163362: Reconsider reflection usage in >> java.awt.font.JavaAWTFontAccessImpl class >> 8135055: java.util.Date.after(java.sql.Timestamp ) does not return >> correct results >> 8163350: LocaleProviderAdapter Preference list retrieved is wrong, when >> -Djava.locale.providers=COMPAT >> 8066652: Default TimeZone is GMT not local if user.timezone is invalid >> on Mac OS >> 8154797: Localization data for "GMT" >> 8158504: test/sun/util/locale/provider/Bug8038436.java: non English >> locale(s) included in available locales >> 8145136: Upgrade CLDR locale data From jamsheed.c.m at oracle.com Mon Jan 9 10:27:03 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Mon, 9 Jan 2017 15:57:03 +0530 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: <63642751-081c-0473-2bed-3819c7ac48a3@oracle.com> Vote: Yes Best Regards, Jamsheed On 1/6/2017 2:53 AM, Naoto Sato wrote: > I hereby nominate Rachna Goel to jdk9 Committer. > > Rachna is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. She has made 22 contributions to > JDK 9 [3], and here are the significant contributions among them [4]. > > Votes are due by Jan 19, 2017. > > Only current jdk9 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]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) > [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for > "AN", "BU" and "CS" country codes. > 8075577: java.time does not support HOST provider > 8146750: java.time.Month.getDisplayName() return incorrect narrow > names with JRE provider on locale de,de_DE,en_US. > 8163362: Reconsider reflection usage in > java.awt.font.JavaAWTFontAccessImpl class > 8135055: java.util.Date.after(java.sql.Timestamp ) does not return > correct results > 8163350: LocaleProviderAdapter Preference list retrieved is wrong, > when -Djava.locale.providers=COMPAT > 8066652: Default TimeZone is GMT not local if user.timezone is invalid > on Mac OS > 8154797: Localization data for "GMT" > 8158504: test/sun/util/locale/provider/Bug8038436.java: non English > locale(s) included in available locales > 8145136: Upgrade CLDR locale data From sibabrata.sahoo at oracle.com Tue Jan 10 05:46:26 2017 From: sibabrata.sahoo at oracle.com (Sibabrata Sahoo) Date: Mon, 9 Jan 2017 21:46:26 -0800 (PST) Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: <61940d7a-676f-4e01-bd39-f40616b37240@default> Vote: Yes -----Original Message----- From: Naoto Sato Sent: Friday, January 06, 2017 2:54 AM To: jdk9-dev Subject: CFV: New jdk9 Committer: Rachna Goel I hereby nominate Rachna Goel to jdk9 Committer. Rachna is currently a JDK 9 Author and a member of the Internationalization team at Oracle. She has made 22 contributions to JDK 9 [3], and here are the significant contributions among them [4]. Votes are due by Jan 19, 2017. Only current jdk9 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]. Naoto Sato [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for "AN", "BU" and "CS" country codes. 8075577: java.time does not support HOST provider 8146750: java.time.Month.getDisplayName() return incorrect narrow names with JRE provider on locale de,de_DE,en_US. 8163362: Reconsider reflection usage in java.awt.font.JavaAWTFontAccessImpl class 8135055: java.util.Date.after(java.sql.Timestamp ) does not return correct results 8163350: LocaleProviderAdapter Preference list retrieved is wrong, when -Djava.locale.providers=COMPAT 8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS 8154797: Localization data for "GMT" 8158504: test/sun/util/locale/provider/Bug8038436.java: non English locale(s) included in available locales 8145136: Upgrade CLDR locale data From avik.niyogi at oracle.com Wed Jan 11 10:47:21 2017 From: avik.niyogi at oracle.com (Avik Niyogi) Date: Wed, 11 Jan 2017 16:17:21 +0530 Subject: CFV: New JDK 9 Committer: Manajit Halder In-Reply-To: References: Message-ID: <8F138DAE-8310-4B85-BBB1-A6FC8477719D@oracle.com> Vote: yes > On 05-Jan-2017, at 2:31 am, jdk9-dev-request at openjdk.java.net wrote: > > -----Original Message----- > From: Sergey Bylokhov > Sent: Monday, December 26, 2016 8:06 PM > To: jdk9-dev at openjdk.java.net > Subject: CFV: New JDK 9 Committer: Manajit Halder > > I hereby nominate Manajit Halder to JDK 9 Committer. > > Manajit is currently a JDK 9 Author and a member of the client team at Oracle. He has made 17 contributions to the JDK 9: > > http://hg.openjdk.java.net/jdk9/client/jdk/search/?rev=mhalder&revcount=160 > > Votes are due by Jan 15, 2017. > > 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 nadeesh.tv at oracle.com Wed Jan 11 11:06:45 2017 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 11 Jan 2017 16:36:45 +0530 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: <587611C5.1050006@oracle.com> vote : yes -- Thanks and Regards, Nadeesh TV On 1/6/2017 2:53 AM, Naoto Sato wrote: > I hereby nominate Rachna Goel to jdk9 Committer. > > Rachna is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. She has made 22 contributions to > JDK 9 [3], and here are the significant contributions among them [4]. > > Votes are due by Jan 19, 2017. > > Only current jdk9 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]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) > [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for > "AN", "BU" and "CS" country codes. > 8075577: java.time does not support HOST provider > 8146750: java.time.Month.getDisplayName() return incorrect narrow > names with JRE provider on locale de,de_DE,en_US. > 8163362: Reconsider reflection usage in > java.awt.font.JavaAWTFontAccessImpl class > 8135055: java.util.Date.after(java.sql.Timestamp ) does not return > correct results > 8163350: LocaleProviderAdapter Preference list retrieved is wrong, > when -Djava.locale.providers=COMPAT > 8066652: Default TimeZone is GMT not local if user.timezone is invalid > on Mac OS > 8154797: Localization data for "GMT" > 8158504: test/sun/util/locale/provider/Bug8038436.java: non English > locale(s) included in available locales > 8145136: Upgrade CLDR locale data From Roger.Riggs at Oracle.com Wed Jan 11 15:53:59 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 11 Jan 2017 10:53:59 -0500 Subject: CFV: New JDK 9 Committer: Manajit Halder In-Reply-To: <2D7158B9-F25F-4354-B64C-6BA4FE9BC8B0@oracle.com> References: <2D7158B9-F25F-4354-B64C-6BA4FE9BC8B0@oracle.com> Message-ID: Vote: Yes On 12/26/2016 9:36 AM, Sergey Bylokhov wrote: > I hereby nominate Manajit Halder to JDK 9 Committer. From Roger.Riggs at Oracle.com Wed Jan 11 16:07:28 2017 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 11 Jan 2017 11:07:28 -0500 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: Vote: Yes On 1/5/2017 4:23 PM, Naoto Sato wrote: > I hereby nominate Rachna Goel to jdk9 Committer. From prasanta.sadhukhan at oracle.com Wed Jan 11 16:22:03 2017 From: prasanta.sadhukhan at oracle.com (Prasanta Sadhukhan) Date: Wed, 11 Jan 2017 21:52:03 +0530 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: <61940d7a-676f-4e01-bd39-f40616b37240@default> References: <61940d7a-676f-4e01-bd39-f40616b37240@default> Message-ID: <5ab442a6-69bc-d11b-d091-a0bbf5d77d94@oracle.com> Vote: yes Regards Prasanta > -----Original Message----- > From: Naoto Sato > Sent: Friday, January 06, 2017 2:54 AM > To: jdk9-dev > Subject: CFV: New jdk9 Committer: Rachna Goel > > I hereby nominate Rachna Goel to jdk9 Committer. > > Rachna is currently a JDK 9 Author and a member of the Internationalization team at Oracle. She has made 22 contributions to JDK 9 [3], and here are the significant contributions among them [4]. > > Votes are due by Jan 19, 2017. > > Only current jdk9 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]. > > Naoto Sato > > [1] http://openjdk.java.net/census > [2] http://openjdk.java.net/projects/#committer-vote > [3] > http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) > [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for "AN", "BU" and "CS" country codes. > 8075577: java.time does not support HOST provider > 8146750: java.time.Month.getDisplayName() return incorrect narrow names with JRE provider on locale de,de_DE,en_US. > 8163362: Reconsider reflection usage in java.awt.font.JavaAWTFontAccessImpl class > 8135055: java.util.Date.after(java.sql.Timestamp ) does not return correct results > 8163350: LocaleProviderAdapter Preference list retrieved is wrong, when -Djava.locale.providers=COMPAT > 8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS > 8154797: Localization data for "GMT" > 8158504: test/sun/util/locale/provider/Bug8038436.java: non English > locale(s) included in available locales > 8145136: Upgrade CLDR locale data From brent.christian at oracle.com Wed Jan 11 18:42:31 2017 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 11 Jan 2017 10:42:31 -0800 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: <58767C97.4040405@oracle.com> Vote: Yes -Brent On 01/05/2017 01:23 PM, Naoto Sato wrote: > I hereby nominate Rachna Goel to jdk9 Committer. > > Rachna is currently a JDK 9 Author and a member of the > Internationalization team at Oracle. She has made 22 contributions to > JDK 9 [3], and here are the significant contributions among them [4]. > > Votes are due by Jan 19, 2017. > > Only current jdk9 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]. > > Naoto Sato From lana.steuck at oracle.com Wed Jan 11 21:28:14 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 11 Jan 2017 21:28:14 GMT Subject: jdk9-b152: dev Message-ID: <201701112128.v0BLSEZg001911@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/ef056360ddf3 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/ddc52e727570 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/5b6f12de6f91 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/a20f2cf90762 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/6f8fb1cf7e5f http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/7e3da313b174 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/31f1d26c60df http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/ff8cb43c07c0 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8030175 core-libs java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due JDK-8164391 core-libs Provide a javadoc description for jdk.scripting.nashorn JDK-8164923 core-libs Error in the documentation for java.lang.Random JDK-8169480 core-libs Inconsistencies across Format class hierarchy in their API spec and ac JDK-8169482 core-libs java.time.DateTimeFormatter javadoc: F is not week-of-month JDK-8170566 core-libs incorrect phrase usage in javadocs documentation JDK-8170641 core-libs sun/net/www/protocol/https/HttpsURLConnection/PostThruProxy.sh fails w JDK-8170653 core-libs The javadoc of ZoneRules.previousTransition() is wrong JDK-8170785 core-libs Excessive allocation in ParseUtil.encodePath JDK-8170900 core-libs Issue with FilePermission::implies for wildcard flag(-) JDK-8171348 core-libs Incorrect documentation for DateTimeFormatter letter 'k' JDK-8171452 core-libs (ch) linux io_util_md: Operation not supported exception after 8168628 JDK-8172183 core-libs Provide a javadoc description for jdk.dynalink module JDK-8172190 core-libs Re-apply the fix for bugs 8062389, 8029459, 8061950 JDK-8172200 core-libs Mark StressLoopback.java as intermittently failing JDK-8172201 core-libs Replace assert of return type in VarHandle.AccessMode with test JDK-8172254 core-libs Typo in DriverManager implNote JDK-8171500 infrastructure Explicitly set --with-target-bits=64 in 64bit jib profiles JDK-8171929 infrastructure "make docs" in clean forest is broken JDK-8172037 infrastructure Change log message of SetupCopyFiles JDK-8129988 security-libs JSSE should create a single instance of the cacerts KeyStore JDK-8168769 security-libs javax/net/ssl/TLSv12/DisabledShortRSAKeys.java timed out JDK-8170732 security-libs GssKrb5Client sends non-zero buffer size when qop is "auth" JDK-8172003 security-libs getInstance() with unknown provider throws NPE JDK-8172217 security-libs Need debug log for the intermittent failure of AnonCipherWithWantClien JDK-8172273 security-libs SSLEngine.unwrap fails with ArrayIndexOutOfBoundsException JDK-8026699 tools test test/tools/javac/lambda/T8024947/PotentiallyAmbiguousWarningTest. JDK-8065800 tools javac, fix diagnostic position for statement-bodied lambdas JDK-8144066 tools StackOverflowException when computing glb JDK-8148100 tools Convert lambda most specific positive tests to check runtime behavior JDK-8165405 tools jshell tool: /classpath is inconsistent JDK-8171977 tools Add support for latest messages from 'tidy' JDK-8172103 tools JShell: crash in TaskFactory$WrapSourceHandler.diag JDK-8172158 tools Annotation processor not run with -source <= 8 JDK-8172212 tools jdeps --require and --check should detect the specified module in the JDK-8172214 tools typo in 'intersection types in cast are not supported' message JDK-8172215 tools java launcher no longer accepts -cp "" empty string JDK-8172220 tools Mark UserInputTest.java as intermittently failing and problem list it JDK-8172260 tools remove tests from ProblemList JDK-8172287 tools improve intellij logging to cover javac internal errors JDK-8172311 tools MostSpecific09.java and PotentiallyAmbiguousWarningTest.java failing a From jamsheed.c.m at oracle.com Thu Jan 12 03:18:21 2017 From: jamsheed.c.m at oracle.com (Jamsheed C m) Date: Thu, 12 Jan 2017 08:48:21 +0530 Subject: CFV: New JDK 9 Committer: Manajit Halder In-Reply-To: References: <2D7158B9-F25F-4354-B64C-6BA4FE9BC8B0@oracle.com> Message-ID: Vote: Yes Best Regards, Jamsheed From staffan.larsen at oracle.com Thu Jan 12 10:43:46 2017 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Jan 2017 11:43:46 +0100 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 Message-ID: jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. Thanks, /Staffan diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js --- a/common/conf/jib-profiles.js +++ b/common/conf/jib-profiles.js @@ -870,7 +870,7 @@ jtreg: { server: "javare", revision: "4.2", - build_number: "b04", + build_number: "b05", checksum_file: "MD5_VALUES", file: "jtreg_bin-4.2.zip", environment_name: "JT_HOME", From chris.hegarty at oracle.com Thu Jan 12 10:44:54 2017 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 12 Jan 2017 10:44:54 +0000 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: <58905D7B-71CE-4FE7-9DCE-3F981F528FF4@oracle.com> > On 12 Jan 2017, at 10:43, Staffan Larsen wrote: > > jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. > > Thanks, > /Staffan > > > diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js > +++ b/common/conf/jib-profiles.js > @@ -870,7 +870,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b04", > + build_number: "b05", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", Looks fine. Thanks Staffan. -Chris. From erik.joelsson at oracle.com Thu Jan 12 11:44:18 2017 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Thu, 12 Jan 2017 12:44:18 +0100 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: <817cab3a-97b2-ff22-d1df-f1128c0a8790@oracle.com> Looks good. /Erik On 2017-01-12 11:43, Staffan Larsen wrote: > jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. > > Thanks, > /Staffan > > > diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js > +++ b/common/conf/jib-profiles.js > @@ -870,7 +870,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b04", > + build_number: "b05", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", From Alan.Bateman at oracle.com Thu Jan 12 11:51:05 2017 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 12 Jan 2017 11:51:05 +0000 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: On 12/01/2017 10:43, Staffan Larsen wrote: > jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. > > Thanks, > /Staffan > > > diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js > --- a/common/conf/jib-profiles.js > +++ b/common/conf/jib-profiles.js > @@ -870,7 +870,7 @@ > jtreg: { > server: "javare", > revision: "4.2", > - build_number: "b04", > + build_number: "b05", > checksum_file: "MD5_VALUES", > file: "jtreg_bin-4.2.zip", > environment_name: "JT_HOME", This looks okay for infrastructure that uses this file but don't you need to bump the requiredVersion in each test root to force its usage in other contexts? -Alan From staffan.larsen at oracle.com Thu Jan 12 11:56:07 2017 From: staffan.larsen at oracle.com (Staffan Larsen) Date: Thu, 12 Jan 2017 12:56:07 +0100 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: <1A1EFC90-CB04-4BCE-BDE4-7B0A58AE4084@oracle.com> > On 12 Jan 2017, at 12:51, Alan Bateman wrote: > > > > On 12/01/2017 10:43, Staffan Larsen wrote: >> jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. >> >> Thanks, >> /Staffan >> >> >> diff --git a/common/conf/jib-profiles.js b/common/conf/jib-profiles.js >> --- a/common/conf/jib-profiles.js >> +++ b/common/conf/jib-profiles.js >> @@ -870,7 +870,7 @@ >> jtreg: { >> server: "javare", >> revision: "4.2", >> - build_number: "b04", >> + build_number: "b05", >> checksum_file: "MD5_VALUES", >> file: "jtreg_bin-4.2.zip", >> environment_name: "JT_HOME", > This looks okay for infrastructure that uses this file but don't you need to bump the requiredVersion in each test root to force its usage in other contexts? I don?t know if there are any tests that rely on functionality in 4.2 b05. If there are, we need to bump requireVersion, yes. I only know that the infrastructure needs 4.2 b05. /Staffan From doko at ubuntu.com Thu Jan 12 13:36:30 2017 From: doko at ubuntu.com (Matthias Klose) Date: Thu, 12 Jan 2017 14:36:30 +0100 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: Message-ID: <82e5a8b2-8cf8-49bf-bb73-e7d856c413db@ubuntu.com> On 12.01.2017 11:43, Staffan Larsen wrote: > jtreg 4.2 b05 was recently promoted with some important fixes. Please review the change below to upgrade jdk9-dev to the new version. I have run jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not see any new test failures. according to http://openjdk.java.net/jtreg/ https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ doesn't yet mention this new release. Matthias From daniel.fuchs at oracle.com Thu Jan 12 14:05:42 2017 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 12 Jan 2017 14:05:42 +0000 Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: <6e177f0c-12c6-9ec0-532a-fc9f2cdd36ed@oracle.com> Vote: Yes best regards, -- daniel On 05/01/17 21:23, Naoto Sato wrote: > I hereby nominate Rachna Goel to jdk9 Committer. From christoph.langer at sap.com Thu Jan 12 15:11:40 2017 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 12 Jan 2017 15:11:40 +0000 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: <82e5a8b2-8cf8-49bf-bb73-e7d856c413db@ubuntu.com> References: <82e5a8b2-8cf8-49bf-bb73-e7d856c413db@ubuntu.com> Message-ID: Hi, the tag in http://hg.openjdk.java.net/code-tools/jtreg still says jtreg4.2-b04. See: http://hg.openjdk.java.net/code-tools/jtreg/file/4b0cd55e7741/.hgtags Wouldn't that need some adoption first? Best regards Christoph > -----Original Message----- > From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of > Matthias Klose > Sent: Donnerstag, 12. Januar 2017 14:37 > To: Staffan Larsen ; build-dev at openjdk.java.net > build-dev ; jdk9-dev dev at openjdk.java.net> > Subject: Re: RFR: 8172709 Upgrade to jtreg 4.2 b05 > > On 12.01.2017 11:43, Staffan Larsen wrote: > > jtreg 4.2 b05 was recently promoted with some important fixes. Please > review the change below to upgrade jdk9-dev to the new version. I have run > jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not > see any new test failures. > > according to http://openjdk.java.net/jtreg/ > https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ > doesn't yet mention this new release. > > Matthias From jonathan.gibbons at oracle.com Thu Jan 12 15:23:05 2017 From: jonathan.gibbons at oracle.com (Jonathan Gibbons) Date: Thu, 12 Jan 2017 07:23:05 -0800 Subject: RFR: 8172709 Upgrade to jtreg 4.2 b05 In-Reply-To: References: <82e5a8b2-8cf8-49bf-bb73-e7d856c413db@ubuntu.com> Message-ID: b05 is not yet officially announced or tagged, although I'll get to that today. I'm not aware that any tests require any new functionality (yet), but as Staffan mentioned, there are fixes in the handling for timeout handling that are important for some systems using jtreg. -- Jon On 1/12/17 7:11 AM, Langer, Christoph wrote: > Hi, > > the tag in http://hg.openjdk.java.net/code-tools/jtreg still says jtreg4.2-b04. > > See: http://hg.openjdk.java.net/code-tools/jtreg/file/4b0cd55e7741/.hgtags > > Wouldn't that need some adoption first? > > Best regards > Christoph > >> -----Original Message----- >> From: jdk9-dev [mailto:jdk9-dev-bounces at openjdk.java.net] On Behalf Of >> Matthias Klose >> Sent: Donnerstag, 12. Januar 2017 14:37 >> To: Staffan Larsen ; build-dev at openjdk.java.net >> build-dev ; jdk9-dev > dev at openjdk.java.net> >> Subject: Re: RFR: 8172709 Upgrade to jtreg 4.2 b05 >> >> On 12.01.2017 11:43, Staffan Larsen wrote: >>> jtreg 4.2 b05 was recently promoted with some important fixes. Please >> review the change below to upgrade jdk9-dev to the new version. I have run >> jdk-tier1, jdk-tier2 and jdk-tier3 on linux and os x with this change and did not >> see any new test failures. >> >> according to http://openjdk.java.net/jtreg/ >> https://adopt-openjdk.ci.cloudbees.com/job/jtreg/lastSuccessfulBuild/artifact/ >> doesn't yet mention this new release. >> >> Matthias From sergey.bylokhov at oracle.com Thu Jan 12 16:27:39 2017 From: sergey.bylokhov at oracle.com (Sergey Bylokhov) Date: Thu, 12 Jan 2017 19:27:39 +0300 Subject: Result: New JDK 9 Committer: Manajit Halder Message-ID: Voting for Manajit Halder [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-December/005452.html -- Best regards, Sergey. From henri.tremblay at gmail.com Fri Jan 13 15:41:22 2017 From: henri.tremblay at gmail.com (Henri Tremblay) Date: Fri, 13 Jan 2017 10:41:22 -0500 Subject: JDK9 and Objenesis Message-ID: Hi, I did a release of Objenesis yesterday to provide Java 9 (151 jigsaw) support. It has been on and off so far but the serialization part seemed to be permanently broken so I fixed it. For those who don't know, Objenesis a library dedicated to create objects without calling a constructor. A hidden and forbidden feature of Java that allowed mocks (EasyMock, Mockito) and proxies (Spring, JBoss) to thrive. Objenesis has many instantiator and I have a little test to see which are working on a given JVM. I tried to instantiate a JDK class (ArrayList) and a class in my project. There are 3 types of instantiator: - *Standard:* Just create the class without any constructor - *Serializable:* Creates an object like Java serialization will do (calling readObject and so on) - *Not compliant:* Instantiate a class but not respecting the rules of the 2 above (for instance, a constructor might be called). Those are used for test and as a sad fallback Here are the current results so you can check if everything is as expected: - *AccessibleInstantiator (NOT_COMPLIANT):* Still working! Just turn accessible the default constructor. I was surprised it worked - *MagicInstantiator(STANDARD):* Not working anymore! This one is generating and instantiator that extends MagicAccessorImpl to be allowed to call `new Object()` on a class without the class loader complaining - *ObjectStreamClassInstantiator(SERIALIZATION):* Not working anymore! This is the one that was used so far. Because it's the fastest one for serialization. It doesn't work because setAccessible on ObjectStreamClass.newInstance doesn't work anymore. My personal take is that this method is so useful for serialization framework that it should have been public for years - *SunReflectionFactoryInstantiator (STANDARD):* Still working! This is the current default for hotspot and openjdk. It uses sun.reflect.ReflectionFactory*SunReflectionFactorySerializationInstantiator (SERIALIZATION): *Still working! This is the new default for serialization on Java 9. It wasn't the default so far for performance reasons - *UnsafeFactoryInstantiator (STANDARD):* Still working! Call Unsafe.allocateInstance. Happily still working. It is not the default for Hotspot because it is slower than SunReflectionFactoryInstantiator So the good news are that it is still working without reinventing the wheel. Henri From forax at univ-mlv.fr Fri Jan 13 17:26:59 2017 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 13 Jan 2017 18:26:59 +0100 (CET) Subject: JDK9 and Objenesis In-Reply-To: References: Message-ID: <1698784038.2225125.1484328419832.JavaMail.zimbra@u-pem.fr> And Unsafe.allocateInstance ?? R?mi ----- Mail original ----- > De: "Henri Tremblay" > ?: "jdk9-dev" > Envoy?: Vendredi 13 Janvier 2017 16:41:22 > Objet: JDK9 and Objenesis > Hi, > > I did a release of Objenesis yesterday to provide Java 9 (151 jigsaw) > support. It has been on and off so far but the serialization part seemed to > be permanently broken so I fixed it. > > For those who don't know, Objenesis a library dedicated to create objects > without calling a constructor. A hidden and forbidden feature of Java that > allowed mocks (EasyMock, Mockito) and proxies (Spring, JBoss) to thrive. > > Objenesis has many instantiator and I have a little test to see which are > working on a given JVM. I tried to instantiate a JDK class (ArrayList) and > a class in my project. > > There are 3 types of instantiator: > > - *Standard:* Just create the class without any constructor > - *Serializable:* Creates an object like Java serialization will do > (calling readObject and so on) > - *Not compliant:* Instantiate a class but not respecting the rules of > the 2 above (for instance, a constructor might be called). Those are used > for test and as a sad fallback > > Here are the current results so you can check if everything is as expected: > > - *AccessibleInstantiator (NOT_COMPLIANT):* Still working! Just turn > accessible the default constructor. I was surprised it worked > - *MagicInstantiator(STANDARD):* Not working anymore! This one is > generating and instantiator that extends MagicAccessorImpl to be allowed to > call `new Object()` on a class without the class loader complaining > - *ObjectStreamClassInstantiator(SERIALIZATION):* Not working anymore! This > is the one that was used so far. Because it's the fastest one for > serialization. It doesn't work because setAccessible on > ObjectStreamClass.newInstance doesn't work anymore. My personal take is > that this method is so useful for serialization framework that it should > have been public for years > - *SunReflectionFactoryInstantiator (STANDARD):* Still working! This is > the current default for hotspot and openjdk. It uses > sun.reflect.ReflectionFactory*SunReflectionFactorySerializationInstantiator > (SERIALIZATION): *Still working! This is the new default for > serialization on Java 9. It wasn't the default so far for performance > reasons > - *UnsafeFactoryInstantiator (STANDARD):* Still working! Call > Unsafe.allocateInstance. Happily still working. It is not the default for > Hotspot because it is slower than SunReflectionFactoryInstantiator > > So the good news are that it is still working without reinventing the wheel. > > Henri From forax at univ-mlv.fr Fri Jan 13 19:45:43 2017 From: forax at univ-mlv.fr (forax at univ-mlv.fr) Date: Fri, 13 Jan 2017 20:45:43 +0100 (CET) Subject: JDK9 and Objenesis In-Reply-To: References: <1698784038.2225125.1484328419832.JavaMail.zimbra@u-pem.fr> Message-ID: <1830366576.2246940.1484336743707.JavaMail.zimbra@u-pem.fr> doh, sorry, miss you last bullet point. I wonder why it's slower than the ObjectStreamClassInstantiator ? R?mi > De: "Henri Tremblay" > ?: "Remi Forax" > Cc: "jdk9-dev" > Envoy?: Vendredi 13 Janvier 2017 20:28:49 > Objet: Re: JDK9 and Objenesis > What about it? This is the UnsafeFactoryInstantiator. It works. It is the > default if Objenesis encounters an unknown JVM (because it is pretty much > everywhere). > On 13 January 2017 at 12:26, Remi Forax < forax at univ-mlv.fr > wrote: >> And Unsafe.allocateInstance ?? >> R?mi >> ----- Mail original ----- >> > De: "Henri Tremblay" < henri.tremblay at gmail.com > >> > ?: "jdk9-dev" < jdk9-dev at openjdk.java.net > >> > Envoy?: Vendredi 13 Janvier 2017 16:41:22 >> > Objet: JDK9 and Objenesis >> > Hi, >> > I did a release of Objenesis yesterday to provide Java 9 (151 jigsaw) >> > support. It has been on and off so far but the serialization part seemed to >> > be permanently broken so I fixed it. >> > For those who don't know, Objenesis a library dedicated to create objects >> > without calling a constructor. A hidden and forbidden feature of Java that >> > allowed mocks (EasyMock, Mockito) and proxies (Spring, JBoss) to thrive. >> > Objenesis has many instantiator and I have a little test to see which are >> > working on a given JVM. I tried to instantiate a JDK class (ArrayList) and >> > a class in my project. >> > There are 3 types of instantiator: >> > - *Standard:* Just create the class without any constructor >> > - *Serializable:* Creates an object like Java serialization will do >> > (calling readObject and so on) >> > - *Not compliant:* Instantiate a class but not respecting the rules of >> > the 2 above (for instance, a constructor might be called). Those are used >> > for test and as a sad fallback >> > Here are the current results so you can check if everything is as expected: >> > - *AccessibleInstantiator (NOT_COMPLIANT):* Still working! Just turn >> > accessible the default constructor. I was surprised it worked >> > - *MagicInstantiator(STANDARD):* Not working anymore! This one is >> > generating and instantiator that extends MagicAccessorImpl to be allowed to >> > call `new Object()` on a class without the class loader complaining >> > - *ObjectStreamClassInstantiator(SERIALIZATION):* Not working anymore! This >> > is the one that was used so far. Because it's the fastest one for >> > serialization. It doesn't work because setAccessible on >> > ObjectStreamClass.newInstance doesn't work anymore. My personal take is >> > that this method is so useful for serialization framework that it should >> > have been public for years >> > - *SunReflectionFactoryInstantiator (STANDARD):* Still working! This is >> > the current default for hotspot and openjdk. It uses >> > sun.reflect.ReflectionFactory*SunReflectionFactorySerializationInstantiator >> > (SERIALIZATION): *Still working! This is the new default for >> > serialization on Java 9. It wasn't the default so far for performance >> > reasons >> > - *UnsafeFactoryInstantiator (STANDARD):* Still working! Call >> > Unsafe.allocateInstance. Happily still working. It is not the default for >> > Hotspot because it is slower than SunReflectionFactoryInstantiator >> > So the good news are that it is still working without reinventing the wheel. >> > Henri From henri.tremblay at gmail.com Fri Jan 13 19:28:49 2017 From: henri.tremblay at gmail.com (Henri Tremblay) Date: Fri, 13 Jan 2017 14:28:49 -0500 Subject: JDK9 and Objenesis In-Reply-To: <1698784038.2225125.1484328419832.JavaMail.zimbra@u-pem.fr> References: <1698784038.2225125.1484328419832.JavaMail.zimbra@u-pem.fr> Message-ID: What about it? This is the UnsafeFactoryInstantiator. It works. It is the default if Objenesis encounters an unknown JVM (because it is pretty much everywhere). On 13 January 2017 at 12:26, Remi Forax wrote: > And Unsafe.allocateInstance ?? > > R?mi > > ----- Mail original ----- > > De: "Henri Tremblay" > > ?: "jdk9-dev" > > Envoy?: Vendredi 13 Janvier 2017 16:41:22 > > Objet: JDK9 and Objenesis > > > Hi, > > > > I did a release of Objenesis yesterday to provide Java 9 (151 jigsaw) > > support. It has been on and off so far but the serialization part seemed > to > > be permanently broken so I fixed it. > > > > For those who don't know, Objenesis a library dedicated to create objects > > without calling a constructor. A hidden and forbidden feature of Java > that > > allowed mocks (EasyMock, Mockito) and proxies (Spring, JBoss) to thrive. > > > > Objenesis has many instantiator and I have a little test to see which are > > working on a given JVM. I tried to instantiate a JDK class (ArrayList) > and > > a class in my project. > > > > There are 3 types of instantiator: > > > > - *Standard:* Just create the class without any constructor > > - *Serializable:* Creates an object like Java serialization will do > > (calling readObject and so on) > > - *Not compliant:* Instantiate a class but not respecting the rules of > > the 2 above (for instance, a constructor might be called). Those are > used > > for test and as a sad fallback > > > > Here are the current results so you can check if everything is as > expected: > > > > - *AccessibleInstantiator (NOT_COMPLIANT):* Still working! Just turn > > accessible the default constructor. I was surprised it worked > > - *MagicInstantiator(STANDARD):* Not working anymore! This one is > > generating and instantiator that extends MagicAccessorImpl to be > allowed to > > call `new Object()` on a class without the class loader complaining > > - *ObjectStreamClassInstantiator(SERIALIZATION):* Not working > anymore! This > > is the one that was used so far. Because it's the fastest one for > > serialization. It doesn't work because setAccessible on > > ObjectStreamClass.newInstance doesn't work anymore. My personal take is > > that this method is so useful for serialization framework that it > should > > have been public for years > > - *SunReflectionFactoryInstantiator (STANDARD):* Still working! This > is > > the current default for hotspot and openjdk. It uses > > sun.reflect.ReflectionFactory*SunReflectionFactorySerializat > ionInstantiator > > (SERIALIZATION): *Still working! This is the new default for > > serialization on Java 9. It wasn't the default so far for performance > > reasons > > - *UnsafeFactoryInstantiator (STANDARD):* Still working! Call > > Unsafe.allocateInstance. Happily still working. It is not the default > for > > Hotspot because it is slower than SunReflectionFactoryInstantiator > > > > So the good news are that it is still working without reinventing the > wheel. > > > > Henri > From mark.reinhold at oracle.com Wed Jan 18 17:17:35 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Wed, 18 Jan 2017 09:17:35 -0800 Subject: JEP proposed to target JDK 9 (2016/12/8) In-Reply-To: <20161208135028.94721715@eggemoggin.niobe.net> References: <20161208135028.94721715@eggemoggin.niobe.net> Message-ID: <20170118091735.772206765@eggemoggin.niobe.net> 2016/12/8 13:50:28 -0800, mark.reinhold at oracle.com: > The following JEP has been placed into the "Proposed to Target" > state by its owner after discussion and review: > > 298: Remove Demos and Samples > http://openjdk.java.net/jeps/298 > > Feedback on this proposal is welcome, as are reasoned objections. > If no such objections are raised by 22:00 UTC next Thursday, 15 > December, 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 lana.steuck at oracle.com Wed Jan 18 22:23:59 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 18 Jan 2017 22:23:59 GMT Subject: jdk9-b153: dev Message-ID: <201701182223.v0IMNx50009763@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/816a6d03a7c4 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/19aaaf2d02b7 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/03f48cd283f5 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/1c4411322327 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/7a532a9a2271 http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/1384504d2cd0 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/217ba81b9a4c http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/68a8e8658511 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8130737 client-libs [macosx] AffineTransformOp can't handle child raster with non-zero x-o JDK-8133919 client-libs [macosx] JTable grid lines are incorrectly positioned on HiDPI display JDK-8140266 client-libs Performance loss between jdk8 and jdk9 on Maskfill JDK-8154314 client-libs [TEST_BUG] java/awt/datatransfer/DragImage/MultiResolutionDragImageTes JDK-8166111 client-libs [PIT] possible regression: java/awt/font/GlyphVector/TestLayoutFlags.j JDK-8167652 client-libs Making a frame/dialog resizeble/unresizeble shifts its position on Uni JDK-8169900 client-libs The code which use Applets should be deprecated JDK-8170349 client-libs The printed content is beyond the borders. JDK-8170352 client-libs The collate option is not checked JDK-8170579 client-libs The "Banner page" checkbox is disabled JDK-8171845 client-libs The bold font doesn't change when switch "Dialog","Serif" and "Monospa JDK-8172009 client-libs [TEST_BUG] increase timeout in java/awt/print/PaintSetEnabledDeadlock/ JDK-8172153 client-libs Create workaround for failure to use ICC profile contained in a TIFF f JDK-8172558 client-libs [PIT][TEST_BUG] Bad filename for javax/swing/JTable/8133919/DrawGridLi JDK-8172559 client-libs [PIT][TEST_BUG] Move @test to be 1st annotation in java/awt/image/Rast JDK-8030950 core-libs TEST_BUG: java/rmi/registry/classPathCodebase/ClassPathCodebase.java f JDK-8075884 core-libs Test task: Create tests to check runtime usage with Multi-Release jar JDK-8152272 core-libs Unable to create temporary file using createTempFile method if System. JDK-8153250 core-libs java.io.File does not handle Windows paths of the form "D:" (no path) JDK-8156595 core-libs java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64 JDK-8163449 core-libs Allow per protocol setting for URLConnection defaultUseCaches JDK-8166187 core-libs Regression: NPE during reparse when using persistent code cache and op JDK-8166365 core-libs Small immutable collections should provide optimized implementations w JDK-8170544 core-libs Fix code scan findings in libnet JDK-8170781 core-libs PropertyMapIterator throws NoSuchElementException on last element JDK-8171386 core-libs jshell tool: paging of javadoc output broken on Windows JDK-8171958 core-libs Several tests from java/time/test/java/time/format requiring jdk.local JDK-8172221 core-libs Directorate of Time has been superseded JDK-8172253 core-libs SetIfModifiedSince.java test fails with http return code 404 JDK-8172314 core-libs java/rmi/registry/altSecurityManager/AltSecurityManager.java fails wit JDK-8172347 core-libs Refactoring src/java.rmi/share/classes/sun/rmi/registry/RegistryImpl.j JDK-8172458 core-libs Make javax.lang.model javadoc HTML 5 compliant JDK-8172475 core-libs Remove usage from Class and ClassLoader JDK-8172493 core-libs Nashorn FX example 3-4 using load for fx: scripts fails to run with la JDK-8172531 core-libs Correct misstatements in javax.lang.model visitor documentation JDK-8172720 core-libs Collections.SingletonList::hashCode not spec-compliant JDK-8170805 deploy [jcp] [windows] Icon missing for main JCP window JDK-8170809 deploy [jcp] Correct ComboBox position for "Temporary Files" tab JDK-8171936 deploy The warning message in java trace is changed for weakly signed jnlp JDK-8171937 deploy The messgae on blocked dialog changed for weakly signed jnlp JDK-8171955 deploy The dialog title is wrong for some tests in Javaws8167370Test JDK-8171956 deploy After step3,there will pop-up JavaUpdate Needed dialog JDK-8171964 deploy At step13: The "Security Warning" dialog always shows here when unsele JDK-8172086 deploy At step 3:An unsigned dialog shown up,and there is no security warning JDK-8172114 deploy At step2.It's failed to launched the applet. JDK-8172115 deploy At step2.No jfxrt.jar can be found in JAVA_HOME\lib. JDK-8172117 deploy At step6,there is no authenticated pop-up dialog from Java(Javafx base JDK-8172135 deploy No security level can be found in the JCP->security JDK-8162750 infrastructure -D__solaris__ added twice JDK-8170862 infrastructure VarDeps breaks when a file with overridden CFLAGS has the same name as JDK-8171409 infrastructure Create a smoother configure experience on macosx JDK-8171932 infrastructure unresolved macro in javadoc command JDK-8172241 infrastructure Cleanup mistakes in jib publish support change JDK-8172562 infrastructure Changing log level on Javadoc causes total rebuild JDK-8172577 infrastructure Builds for OS X after build 149 does not include Java Mission Control. JDK-8172702 infrastructure Remove left-over OPENJDK_TARGET_CPU_JLI_CFLAGS JDK-8172709 infrastructure Upgrade to jtreg 4.2 b05 JDK-8172712 infrastructure configure should check that grep handles empty pattern correctly JDK-8172714 infrastructure Remove unused and unexpanded variables from spec.gmk.in JDK-8172842 infrastructure Invoke lldb with --batch from failure handler JDK-8167146 security-libs sun/security/pkcs11/sslecc/ClientJSSEServerJSSE.java failed with "Remo JDK-8171423 security-libs Relocate /test/lib/security/SecurityTools.java JDK-8160286 tools jmod hash is creating unlinkable modules. JDK-8168149 tools Examine the behavior of jmod command-line options - repeating vs last JDK-8169197 tools Improve error reporting for compiling against unexported package JDK-8171325 tools NPE in Check.clearLocalClassNameIndexes JDK-8171332 tools NPE in MembersPhase.finishClass JDK-8171385 tools jshell tool: unresponsive to ctrl-C in input wait on Windows JDK-8171528 tools Crash in Annotate with duplicate package-info declarations JDK-8171830 tools jar tool should validate if any exported or open package is missing JDK-8171981 tools JShell: Fails compilation: new Object().getClass().getSuperclass() JDK-8171993 tools AssertionError when compiling method reference with generic code and v JDK-8172213 tools Remove unused and partially implemented JavacElements#getSourcePositio JDK-8172255 tools JShell API: ExecutionControl/LoaderDelegate: Remove unused/unimplement JDK-8172262 tools packages missing from docs build JDK-8172411 tools -XDnoModules must be removed JDK-8172414 tools jshell not working in exploded JDK build JDK-8172432 tools jar cleanup/update for module and mrm jar JDK-8172474 tools javac should enable doclint checking for HTML 5 JDK-8172530 tools JShell: TypeProjection .stream().map(...).collect(...) must be replace JDK-8172668 tools NPE in jdk.compiler/com.sun.tools.javac.comp.TypeEnter$ImportsPhase.im JDK-8172678 tools JShell Tests: Disable CompletionSuggestionTest.testBrokenClassFile2() JDK-8172761 tools Test change in tools/jar/InputFilesTest.java for JDK-8172432 is missin JDK-8172767 tools a bulk of tests failed with FileSystemException on Windows JDK-8159058 xml SAXParseException when sending soap message JDK-8169631 xml [JAXP] XALAN: transformation of XML via namespace-unaware SAX input yi JDK-8171243 xml CatalogManager.catalogResolver throws FileSystemNotFoundException with JDK-8172957 tools Problem list JmodTest.java on windows until JDK-8172870 is fixed From mark.reinhold at oracle.com Thu Jan 19 22:28:38 2017 From: mark.reinhold at oracle.com (mark.reinhold at oracle.com) Date: Thu, 19 Jan 2017 14:28:38 -0800 Subject: JDK 9 is Feature Complete -- now it's time to ramp down Message-ID: <20170119142838.578911177@eggemoggin.niobe.net> We achieved the Feature Extension Complete milestone [1] in late December. All JEPs and small enhancements granted extensions [2] have been integrated into the JDK 9 master forest. Thanks to everyone for all your hard work leading up to this milestone! We're now in the first phase of the rampdown process, in which we aim to fix the bugs that need to be fixed and understand why we're not going to fix some bugs that perhaps ought to be fixed. We'll use the process that I previously proposed [3], which is now also documented under the JDK 9 Project page [4][5]. The overall feature set is, at this point, frozen. It's highly unlikely that any further JEPs will be targeted to the release. Small enhancements to new features will be considered, but the bar is now much higher. Please request approval for such enhancements via the existing FC-extension process [2]. Low-risk enhancements that add small bits of missing functionality or improve usability may be approved, especially when justified by developer feedback. Enhancements that add significant new functionality will require very strong justification. Enhancements to tests or documentation do not require advance approval. - Mark [1] http://openjdk.java.net/projects/jdk9/#Feature_Extension_Complete [2] http://openjdk.java.net/projects/jdk9/fc-extension-process [3] http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html [4] http://openjdk.java.net/projects/jdk9/rdp-1 [5] http://openjdk.java.net/projects/jdk9/bug-deferral-process From sadhak001 at gmail.com Thu Jan 19 23:31:54 2017 From: sadhak001 at gmail.com (Mani Sarkar) Date: Thu, 19 Jan 2017 23:31:54 +0000 Subject: JDK 9 is Feature Complete -- now it's time to ramp down In-Reply-To: <20170119142838.578911177@eggemoggin.niobe.net> References: <20170119142838.578911177@eggemoggin.niobe.net> Message-ID: Great news Mark! On Thu, 19 Jan 2017 at 22:28 wrote: > We achieved the Feature Extension Complete milestone [1] in late > December. All JEPs and small enhancements granted extensions [2] have > been integrated into the JDK 9 master forest. Thanks to everyone for > all your hard work leading up to this milestone! > > We're now in the first phase of the rampdown process, in which we aim to > fix the bugs that need to be fixed and understand why we're not going to > fix some bugs that perhaps ought to be fixed. We'll use the process that > I previously proposed [3], which is now also documented under the JDK 9 > Project page [4][5]. > > The overall feature set is, at this point, frozen. It's highly unlikely > that any further JEPs will be targeted to the release. > > Small enhancements to new features will be considered, but the bar is > now much higher. Please request approval for such enhancements via the > existing FC-extension process [2]. Low-risk enhancements that add small > bits of missing functionality or improve usability may be approved, > especially when justified by developer feedback. Enhancements that add > significant new functionality will require very strong justification. > Enhancements to tests or documentation do not require advance approval. > > - Mark > > > [1] http://openjdk.java.net/projects/jdk9/#Feature_Extension_Complete > [2] http://openjdk.java.net/projects/jdk9/fc-extension-process > [3] > http://mail.openjdk.java.net/pipermail/jdk9-dev/2016-August/004777.html > [4] http://openjdk.java.net/projects/jdk9/rdp-1 > [5] http://openjdk.java.net/projects/jdk9/bug-deferral-process > -- @theNeomatrix369 * | **Blog ** | *LJC Associate & LJC Advocate (@adoptopenjdk & @adoptajsr programs) *Meet-a-Project - *MutabilityDetector * | **Bitbucket * * | **Github * * | **LinkedIn * *Come to Devoxx UK 2017:* http://www.devoxx.co.uk/ *Don't chase success, rather aim for "Excellence", and success will come chasing after you!* From martinrb at google.com Fri Jan 20 04:09:13 2017 From: martinrb at google.com (Martin Buchholz) Date: Thu, 19 Jan 2017 20:09:13 -0800 Subject: jdk-9+153 tarballs have packaging error Message-ID: I noticed I couldn't use an exploded jdk tarball because some files were not world readable. tar tvzf jdk-9-ea+153_linux-x64_bin.tar.gz ... -rw-r--r-- java_re/java_re 73955 2017-01-18 17:59 jdk-9/include/jni.h -rw-r--r-- java_re/java_re 824 2017-01-18 17:59 jdk-9/include/linux/jni_md.h -rw-r--r-- java_re/java_re 968 2017-01-18 17:59 jdk-9/include/linux/jawt_md.h -rw------- java_re/java_re 535839 2017-01-18 17:59 jdk-9/jmods/jdk.jshell.jmod -rw------- java_re/java_re 2116660 2017-01-18 17:59 jdk-9/jmods/jdk.plugin.jmod -rw------- java_re/java_re 119739 2017-01-18 17:59 jdk-9/jmods/java.logging.jmod -rw------- java_re/java_re 131409 2017-01-18 17:59 jdk-9/jmods/jdk.jdwp.agent.jmod -rw------- java_re/java_re 23723724 2017-01-18 17:59 jdk-9/jmods/javafx.web.jmod A final step in building files suitable for distribution is chmod -R a+rX From ramanand.patil at oracle.com Fri Jan 20 06:31:20 2017 From: ramanand.patil at oracle.com (Ramanand Patil) Date: Thu, 19 Jan 2017 22:31:20 -0800 (PST) Subject: CFV: New jdk9 Committer: Rachna Goel In-Reply-To: References: Message-ID: Vote: Yes Regards, Ramanand. -----Original Message----- From: Naoto Sato Sent: Friday, January 06, 2017 2:54 AM To: jdk9-dev Subject: CFV: New jdk9 Committer: Rachna Goel I hereby nominate Rachna Goel to jdk9 Committer. Rachna is currently a JDK 9 Author and a member of the Internationalization team at Oracle. She has made 22 contributions to JDK 9 [3], and here are the significant contributions among them [4]. Votes are due by Jan 19, 2017. Only current jdk9 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]. Naoto Sato [1] http://openjdk.java.net/census [2] http://openjdk.java.net/projects/#committer-vote [3] http://hg.openjdk.java.net/jdk9/jdk9/jdk/log?revcount=100&rev=(keyword(%22rachna.goel%40oracle.com%22)+or+author(rgoel)) [4] 8071929: Locale.getISOCountries() has inconsistent behaviour for "AN", "BU" and "CS" country codes. 8075577: java.time does not support HOST provider 8146750: java.time.Month.getDisplayName() return incorrect narrow names with JRE provider on locale de,de_DE,en_US. 8163362: Reconsider reflection usage in java.awt.font.JavaAWTFontAccessImpl class 8135055: java.util.Date.after(java.sql.Timestamp ) does not return correct results 8163350: LocaleProviderAdapter Preference list retrieved is wrong, when -Djava.locale.providers=COMPAT 8066652: Default TimeZone is GMT not local if user.timezone is invalid on Mac OS 8154797: Localization data for "GMT" 8158504: test/sun/util/locale/provider/Bug8038436.java: non English locale(s) included in available locales 8145136: Upgrade CLDR locale data From mandy.chung at oracle.com Fri Jan 20 06:43:57 2017 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 19 Jan 2017 22:43:57 -0800 Subject: jdk-9+153 tarballs have packaging error In-Reply-To: References: Message-ID: <3E5AD6E8-EDC2-4DC2-B4D8-5063313B48BE@oracle.com> Thanks for the report. We also uncover this regression: https://bugs.openjdk.java.net/browse/JDK-8173096 Mandy > On Jan 19, 2017, at 8:09 PM, Martin Buchholz wrote: > > I noticed I couldn't use an exploded jdk tarball because some files were > not world readable. > tar tvzf jdk-9-ea+153_linux-x64_bin.tar.gz > ... > -rw-r--r-- java_re/java_re 73955 2017-01-18 17:59 jdk-9/include/jni.h > -rw-r--r-- java_re/java_re 824 2017-01-18 17:59 > jdk-9/include/linux/jni_md.h > -rw-r--r-- java_re/java_re 968 2017-01-18 17:59 > jdk-9/include/linux/jawt_md.h > -rw------- java_re/java_re 535839 2017-01-18 17:59 > jdk-9/jmods/jdk.jshell.jmod > -rw------- java_re/java_re 2116660 2017-01-18 17:59 > jdk-9/jmods/jdk.plugin.jmod > -rw------- java_re/java_re 119739 2017-01-18 17:59 > jdk-9/jmods/java.logging.jmod > -rw------- java_re/java_re 131409 2017-01-18 17:59 > jdk-9/jmods/jdk.jdwp.agent.jmod > -rw------- java_re/java_re 23723724 2017-01-18 17:59 > jdk-9/jmods/javafx.web.jmod > > A final step in building files suitable for distribution is > chmod -R a+rX From naoto.sato at oracle.com Fri Jan 20 18:28:28 2017 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 20 Jan 2017 10:28:28 -0800 Subject: Result: New jdk9 Committer: Rachna Goel Message-ID: Voting for Rachna Goel [1] is now closed. Yes: 13 Veto: 0 Abstain: 0 According to the Bylaws definition of Lazy Consensus, this is sufficient to approve the nomination. Naoto Sato [1] http://mail.openjdk.java.net/pipermail/jdk9-dev/2017-January/005471.html From doug.simon at oracle.com Mon Jan 23 21:56:58 2017 From: doug.simon at oracle.com (Doug Simon) Date: Mon, 23 Jan 2017 22:56:58 +0100 Subject: RFR: 8145337: [JVMCI] JVMCI initialization with SecurityManager installed fails: java.security.AccessControlException: access denied Message-ID: <9E737664-1D12-4E3B-B1D6-BED53E581067@oracle.com> Both jdk.vm.ci and jdk.vm.compiler require a number of permissions when a security manager is present. Since neither of these modules is accessible to application code, it should be ok to give them all permissions. This seems to be the approach for a number of other modules including jdk.scripting.nashorn, jdk.dynalink, jdk.jsobject etc. Please review this small change that configures this proposed permission level. http://cr.openjdk.java.net/~dnsimon/8145337/webrev/ https://bugs.openjdk.java.net/browse/JDK-8145337 -Doug From lana.steuck at oracle.com Wed Jan 25 22:22:33 2017 From: lana.steuck at oracle.com (lana.steuck at oracle.com) Date: Wed, 25 Jan 2017 22:22:33 GMT Subject: jdk9-b154: dev Message-ID: <201701252222.v0PMMXZV001959@scaaa563.us.oracle.com> http://hg.openjdk.java.net/jdk9/jdk9/rev/8d26916eaa21 http://hg.openjdk.java.net/jdk9/jdk9/nashorn/rev/a84b49cfee63 http://hg.openjdk.java.net/jdk9/jdk9/langtools/rev/6a9dd3d893b0 http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/c97e7a8b8da0 http://hg.openjdk.java.net/jdk9/jdk9/jaxws/rev/34af95c7dbff http://hg.openjdk.java.net/jdk9/jdk9/jaxp/rev/7fa738305436 http://hg.openjdk.java.net/jdk9/jdk9/hotspot/rev/a9fdfd55835e http://hg.openjdk.java.net/jdk9/jdk9/corba/rev/078ebe23b584 --- All the fixes will be tested during promotion (no PIT testing at this point): List of all fixes: =================== JDK-8171456 client-libs Upgrade harfbuzz in JDK 9 to v1.4.1 JDK-8171909 client-libs [PIT] on Windows, failure of java/awt/Dialog/DialogAboveFrame/DialogAb JDK-8171910 client-libs [TEST_BUG] The last column header does not contain "...". JDK-8172012 client-libs [TEST_BUG] delays needed in javax/swing/JTree/4633594/bug4633594.java JDK-8037325 core-libs Class.getConstructor() performance regression JDK-8071566 core-libs Improve testing for multi-version JAR file maker tool JDK-8160710 core-libs Enable Thread to grant VarHandle field access to ThreadLocalRandom/Str JDK-8171139 core-libs Simplify ResourceBundle.CacheKey and ClassLoader may not be needed JDK-8171140 core-libs Re-examine ResourceBundle::clearCache method JDK-8172350 core-libs Typo in java.sql.Timestamp.toString() method Javadoc. JDK-8172547 core-libs (se) Selector.select(Long.MAX_VALUE) fires repeatedly JDK-8172686 core-libs Use less aggressive deprecation of utility visitors JDK-8172886 core-libs Add a test that shows how the LogManager can be implemented by a modul JDK-8172905 core-libs Minor startup cleanup of CallSite and MethodType JDK-8172910 core-libs Use default methods as appropriate for language model visitors JDK-8172921 core-libs Zip filesystem performance improvement and code cleanup JDK-8173072 core-libs zipfs fails to handle incorrect info-zip "extended timestamp extra fie JDK-8173083 core-libs VarHandle usages in LockSupport and ThreadLocalRandom result in circul JDK-8173159 core-libs Problem list java/rmi/activation/ActivationGroup/downloadActivationGro JDK-8173164 core-libs Resolve remaining HTML5 issues in javax.lang.model.* JDK-8173197 core-libs (se) WindowsSelectorImpl.c does not compile with VS2010 JDK-8173201 core-libs java/lang/reflect/PublicMethods/PublicMethodsTest.java fails because JDK-8172971 core-svc java.management could use System.Logger JDK-8172085 deploy At step7: There is a blocked dialog shown up and JARSigningException t JDK-8172113 deploy At step5,There is no dialog with update, block or later shows up. JDK-8172116 deploy At step6,The applet open a new tab. JDK-8172838 deploy [test] httpsTest::testhttps_inside2 need to be updated JDK-8172959 deploy [test] Need to update cleanup-after target in buildjavawsmanual.xml JDK-8170863 infrastructure Always pass MAKE_ARGS to MAKE in Main.gmk JDK-8172973 infrastructure Remove add exports from ModuleSummary build JDK-8173085 infrastructure Warning module name in --add-exports not found: jdk.jdeps when compili JDK-8173107 infrastructure Fix autoconf/spec.gmk mismatches JDK-8173120 infrastructure Preserve command line at build failure JDK-8055206 security-libs Update SecurityManager::checkPackageAccess to restrict non-exported JD JDK-8172527 security-libs Rename jdk.crypto.token to jdk.crypto.cryptoki JDK-8172529 security-libs Use PKIXValidator in jarsigner JDK-8172975 security-libs SecurityTools.keytool() needs to accept user input JDK-8173024 security-libs Replace direct use of AuthResources resource bundle from jdk.security. JDK-8173066 security-libs More verbose debug output for selection of X509 certs JDK-8173082 security-libs java/bean/* tests fail since change of JDK-8055206 JDK-8173134 security-libs Add failing java/bean tests in JDK-8173082 to the ProblemList JDK-8147414 tools java.nio.file.ClosedFileSystemException in javadoc JDK-8157611 tools field visiblePackages is null for the unnamed module producing NPE whe JDK-8160881 tools Remove jvisualvm from JDK9 JDK-8165102 tools incorrect message from javac JDK-8168254 tools Detect duplicated resources in packaged modules JDK-8169608 tools Compiler Tree API's Doctrees.getDocTreePath needs to accept a PackageE JDK-8170250 tools update/improve testing of classfile module attribute JDK-8170692 tools inconsistent check of module-related options against target version JDK-8171098 tools NPE when --add-modules java.corba is used JDK-8171130 tools jshell tool: /edit adds empty statement to brace terminated snippet JDK-8171177 tools Compiler should issue a warning for incubating modules that are resolv JDK-8171322 tools AssertionError in TypeSymbol.getAnnotationTypeMetadata JDK-8171380 tools Remove all exports from jdk.jlink JDK-8172179 tools jshell tool: builtin startup settings should be by reference not conte JDK-8172659 tools PluginException("TargetPlatform attribute is missing ...") - should be JDK-8172753 tools Improve style of left-side index pages JDK-8172809 tools Error compiling javafx modules after fix for JDK-8169197 JDK-8172870 tools test/tools/jmod/JmodTest.java fails on windows with AccessDeniedExcep JDK-8172982 tools tools/jlink/ResourceDuplicateCheckTest.java requires jdk.tools.jlink.p JDK-8173007 tools JShell Tests: ToolFormatTest takes too long JDK-8173073 tools jshell tool: blank lines removed from multiline snippets JDK-8173096 tools jmod files are not world-readable JDK-8173117 tools Compilation significantly slower after JDK-8169197 JDK-8173141 tools tools/javac/classreader/FileSystemClosedTest.java fails on Windows JDK-8173156 tools Remove JmodTest.java from the probelm list on windows From adinn at redhat.com Thu Jan 26 16:24:57 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 26 Jan 2017 16:24:57 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations Message-ID: The following webrev against jdk9-dev fixes the AArch64 stack size computation as JDK-8173339 required by in line with changes made for the bug which caused it JDK-8170655 http://cr.openjdk.java.net/~adinn/8173339/webrev.0/ This is proposed for inclusion jdk9 because it is a serious crasher bug. I'll need reviewers and a sponsor. regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Thu Jan 26 16:36:03 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Jan 2017 16:36:03 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: Message-ID: <61c4db2d-6a70-b390-f12a-d7e8f1540526@redhat.com> On 26/01/17 16:24, Andrew Dinn wrote: > I'll need reviewers and a sponsor. OK. AArhc64 only: you can push it yourself. Andrew. From adinn at redhat.com Thu Jan 26 16:55:16 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 26 Jan 2017 16:55:16 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: <61c4db2d-6a70-b390-f12a-d7e8f1540526@redhat.com> References: <61c4db2d-6a70-b390-f12a-d7e8f1540526@redhat.com> Message-ID: On 26/01/17 16:36, Andrew Haley wrote: > On 26/01/17 16:24, Andrew Dinn wrote: >> I'll need reviewers and a sponsor. > > OK. AArhc64 only: you can push it yourself. Can I? I am not a JDK9 committer regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Thu Jan 26 16:57:08 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 26 Jan 2017 16:57:08 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: <61c4db2d-6a70-b390-f12a-d7e8f1540526@redhat.com> Message-ID: On 26/01/17 16:55, Andrew Dinn wrote: > > > On 26/01/17 16:36, Andrew Haley wrote: >> On 26/01/17 16:24, Andrew Dinn wrote: >>> I'll need reviewers and a sponsor. >> >> OK. AArhc64 only: you can push it yourself. > > Can I? I am not a JDK9 committer Oh, of course I am (doh sorry for the noise:-) regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From edward.nevill at gmail.com Thu Jan 26 17:34:34 2017 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 26 Jan 2017 17:34:34 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: Message-ID: <1485452074.7559.20.camel@gmail.com> Just one question about this -#define DEFAULT_STACK_SHADOW_PAGES (4 DEBUG_ONLY(+5)) +// Java_java_net_SocketOutputStream_socketWrite0() uses a 64k buffer on the +// stack if compiled for unix and LP64. To pass stack overflow tests we need +// 20 shadow pages. +#define DEFAULT_STACK_SHADOW_PAGES (20 DEBUG_ONLY(+5)) Is that 20 4K pages or 20 64K pages? If 64K pages we end up allocating 1.2M? All the best, Ed. On Thu, 2017-01-26 at 16:24 +0000, Andrew Dinn wrote: > The following webrev against jdk9-dev fixes the AArch64 stack size > computation as JDK-8173339 required by in line with changes made for the > bug which caused it JDK-8170655 > > ? http://cr.openjdk.java.net/~adinn/8173339/webrev.0/ > > This is proposed for inclusion jdk9 because it is a serious crasher bug. > From aph at redhat.com Thu Jan 26 17:37:49 2017 From: aph at redhat.com (Andrew Haley) Date: Thu, 26 Jan 2017 17:37:49 +0000 Subject: [aarch64-port-dev ] 8173339: AArch64: Fix minimum stack size computations In-Reply-To: <1485452074.7559.20.camel@gmail.com> References: <1485452074.7559.20.camel@gmail.com> Message-ID: <59d30051-82c4-d971-9f96-011ac573440e@redhat.com> On 26/01/17 17:34, Edward Nevill wrote: > Is that 20 4K pages or 20 64K pages? If 64K pages we end up allocating 1.2M? I think it gets adjusted for non-4k pages. Andrew. From adinn at redhat.com Thu Jan 26 17:41:27 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 26 Jan 2017 17:41:27 +0000 Subject: [aarch64-port-dev ] 8173339: AArch64: Fix minimum stack size computations In-Reply-To: <59d30051-82c4-d971-9f96-011ac573440e@redhat.com> References: <1485452074.7559.20.camel@gmail.com> <59d30051-82c4-d971-9f96-011ac573440e@redhat.com> Message-ID: <78e79c14-3fa0-c285-f1a4-14008111316c@redhat.com> On 26/01/17 17:37, Andrew Haley wrote: > On 26/01/17 17:34, Edward Nevill wrote: >> Is that 20 4K pages or 20 64K pages? If 64K pages we end up allocating 1.2M? > > I think it gets adjusted for non-4k pages. A quick grep shows hotspot/src/share/vm/runtime/os.cpp: JavaThread::set_stack_shadow_zone_size (align_size_up(StackShadowPages * 4 * K, vm_page_size())); regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From edward.nevill at gmail.com Thu Jan 26 18:03:56 2017 From: edward.nevill at gmail.com (Edward Nevill) Date: Thu, 26 Jan 2017 18:03:56 +0000 Subject: [aarch64-port-dev ] 8173339: AArch64: Fix minimum stack size computations In-Reply-To: <78e79c14-3fa0-c285-f1a4-14008111316c@redhat.com> References: <1485452074.7559.20.camel@gmail.com> <59d30051-82c4-d971-9f96-011ac573440e@redhat.com> <78e79c14-3fa0-c285-f1a4-14008111316c@redhat.com> Message-ID: <1485453836.7559.23.camel@gmail.com> On Thu, 2017-01-26 at 17:41 +0000, Andrew Dinn wrote: > > On 26/01/17 17:37, Andrew Haley wrote: > > > > On 26/01/17 17:34, Edward Nevill wrote: > > >? > hotspot/src/share/vm/runtime/os.cpp: > JavaThread::set_stack_shadow_zone_size > (align_size_up(StackShadowPages > * 4 * K, vm_page_size())); > > regards, OK, thanks, its just named badly, Ed. From goetz.lindenmaier at sap.com Thu Jan 26 19:05:31 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 26 Jan 2017 19:05:31 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: Message-ID: Hi Andrew, Yes this should go to 9. Looks Good. Does the TooSmallStackSize Test pass? It might be affected by my previous changes, too. Best regards, G?tz > Am 26.01.2017 um 18:26 schrieb Andrew Dinn : > > The following webrev against jdk9-dev fixes the AArch64 stack size > computation as JDK-8173339 required by in line with changes made for the > bug which caused it JDK-8170655 > > http://cr.openjdk.java.net/~adinn/8173339/webrev.0/ > > This is proposed for inclusion jdk9 because it is a serious crasher bug. > > I'll need reviewers and a sponsor. > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Thu Jan 26 20:18:19 2017 From: adinn at redhat.com (Andrew Dinn) Date: Thu, 26 Jan 2017 20:18:19 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: Message-ID: On 26/01/17 19:05, Lindenmaier, Goetz wrote: > Hi Andrew, > > Yes this should go to 9. Looks Good. > > Does the TooSmallStackSize Test pass? > It might be affected by my previous changes, too. Yes, I am afraid it does indeed fail. When passed -Xss16K the VM reports that it needs a minimum stack size of 320K. However running the program fails with a StackOverflow when you provide that value. n.b. execution does work with a stack size of 360K. Do you have an explanation as to why the value reported by -Xss hits a StackOverflow (while 360K does not)? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From goetz.lindenmaier at sap.com Fri Jan 27 06:10:22 2017 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 27 Jan 2017 06:10:22 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: Message-ID: Hi Andrew, You need to adapt these for aarch in os_cpu_linux_aarch.cpp size_t os::Posix::_compiler_thread_min_stack_allowed = 32 * K; size_t os::Posix::_java_thread_min_stack_allowed = 32 * K; size_t os::Posix::_vm_internal_thread_min_stack_allowed = 64 * K; See also http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c7a256349729 Try with -XX:ThreadStackSize -XX:CompilerThreadStackSize -XX:VMThreadStackSize You probably need to increase the values by 40K as you pass 320 but need 360K. Guard pages are added to these values. Best regards, Goetz > -----Original Message----- > From: Andrew Dinn [mailto:adinn at redhat.com] > Sent: Donnerstag, 26. Januar 2017 22:18 > To: Lindenmaier, Goetz > Cc: aarch64-port-dev at openjdk.java.net; jdk9-dev at openjdk.java.net > Subject: Re: 8173339: AArch64: Fix minimum stack size computations > > On 26/01/17 19:05, Lindenmaier, Goetz wrote: > > Hi Andrew, > > > > Yes this should go to 9. Looks Good. > > > > Does the TooSmallStackSize Test pass? > > It might be affected by my previous changes, too. > > Yes, I am afraid it does indeed fail. > > When passed -Xss16K the VM reports that it needs a minimum stack size of > 320K. However running the program fails with a StackOverflow when you > provide that value. > > n.b. execution does work with a stack size of 360K. Do you have an > explanation as to why the value reported by -Xss hits a StackOverflow > (while 360K does not)? > > regards, > > > Andrew Dinn > ----------- > Senior Principal Software Engineer > Red Hat UK Ltd > Registered in England and Wales under Company Registration No. 03798903 > Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From adinn at redhat.com Fri Jan 27 11:21:43 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 Jan 2017 11:21:43 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: Message-ID: On 27/01/17 06:10, Lindenmaier, Goetz wrote: > You need to adapt these for aarch in os_cpu_linux_aarch.cpp > size_t os::Posix::_compiler_thread_min_stack_allowed = 32 * K; > size_t os::Posix::_java_thread_min_stack_allowed = 32 * K; > size_t os::Posix::_vm_internal_thread_min_stack_allowed = 64 * K; > > See also http://hg.openjdk.java.net/jdk9/hs/hotspot/rev/c7a256349729 > Try with > -XX:ThreadStackSize > -XX:CompilerThreadStackSize > -XX:VMThreadStackSize > You probably need to increase the values by 40K as you pass 320 but need 360K. > Guard pages are added to these values. Ah, ok. I saw that part of your patch (where you lowered the ppc values) but I had assumed that the numbers for AArch64 would still be reasonable (it uses 64k for vm threads but only 32k for java and compiler threads). Fixing this turned out to be a bit of a black art but bumping them all up to 72K works. I found that the transition point where java -Xss Hello switches from failing with a StackOverflow to running successfully happens when rising from n=340K to n=344K. So, it seemed that an increase of >= 24K would suffice. Hence, I reasoned that upping the java and compiler min_stack sizes to 64K (increase by 32K) ought to fix the test failure. However, with that patch in place nothing actually changes: -Xss16 still reports that 320K is the minimum required stack test TooSmallStackSize still fails Hello still transitions from StackOverflow to ok at 340K --> 344K So, I then followed your advice and upped all 3 min_stack sizes to 72K -Xss16 now reports that 384K (??) is the minimum required stack test TooSmallStackSize passes The VM rejects Hello run with -Xss380K but it runs ok with -Xss384K So, it looks like we are stuck with a Java thread stack minimum of 384K. I have raised JDK-8173473 to fix this. I could post a patch against jdk9-dev but I'm unsure whether it is ok for it to go into JDK9 or whether it needs to wait for JDK10? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Fri Jan 27 12:50:04 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Jan 2017 12:50:04 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: Message-ID: <2b90d965-519d-5455-c78f-003ba1b594a1@redhat.com> On 27/01/17 11:21, Andrew Dinn wrote: > I have raised JDK-8173473 to fix this. I could post a patch against > jdk9-dev but I'm unsure whether it is ok for it to go into JDK9 or > whether it needs to wait for JDK10? Do it now, please. Andrew. From adinn at redhat.com Fri Jan 27 13:14:24 2017 From: adinn at redhat.com (Andrew Dinn) Date: Fri, 27 Jan 2017 13:14:24 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: <2b90d965-519d-5455-c78f-003ba1b594a1@redhat.com> References: <2b90d965-519d-5455-c78f-003ba1b594a1@redhat.com> Message-ID: On 27/01/17 12:50, Andrew Haley wrote: > On 27/01/17 11:21, Andrew Dinn wrote: >> I have raised JDK-8173473 to fix this. I could post a patch against >> jdk9-dev but I'm unsure whether it is ok for it to go into JDK9 or >> whether it needs to wait for JDK10? > > Do it now, please. Here is the webrev. http://cr.openjdk.java.net/~adinn/8173474/webrev.00/ Ok to push? regards, Andrew Dinn ----------- Senior Principal Software Engineer Red Hat UK Ltd Registered in England and Wales under Company Registration No. 03798903 Directors: Michael Cunningham, Michael ("Mike") O'Neill, Eric Shander From aph at redhat.com Fri Jan 27 13:39:21 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Jan 2017 13:39:21 +0000 Subject: 8173339: AArch64: Fix minimum stack size computations In-Reply-To: References: <2b90d965-519d-5455-c78f-003ba1b594a1@redhat.com> Message-ID: On 27/01/17 13:14, Andrew Dinn wrote: > Here is the webrev. > > http://cr.openjdk.java.net/~adinn/8173474/webrev.00/ > > Ok to push? OK. Thanks, Andrew. From swpalmer at gmail.com Fri Jan 27 17:20:00 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 27 Jan 2017 12:20:00 -0500 Subject: String indexOf Performance Message-ID: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> I?m not sure if this is the right list, please redirect me if it is not. I was looking into optimizing some code and was surprised to find that String.indexOf(char) was significantly slower than String.indexOf(String) for a single character search. (E.g. I?m looking for a slash / in a path.) The seems counter intuitive, but on Java 8 I saw String.indexOf(char) was about 30% slower than String.indexOf(String). Then I tested on Java 9 and found the performance difference was actually greater because indesOf(String) was now faster, but indexOf(char) was about the same speed. I presume this is related to the new compact strings. Am I missing something or should I not expect indexOf(char) to be as fast or faster than indexOf(String) for a string of length 1? Regards, Scott From aph at redhat.com Fri Jan 27 17:37:12 2017 From: aph at redhat.com (Andrew Haley) Date: Fri, 27 Jan 2017 17:37:12 +0000 Subject: String indexOf Performance In-Reply-To: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> Message-ID: <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> On 27/01/17 17:20, Scott Palmer wrote: > I?m not sure if this is the right list, please redirect me if it is not. > > I was looking into optimizing some code and was surprised to find that String.indexOf(char) was significantly slower than String.indexOf(String) for a single character search. (E.g. I?m looking for a slash / in a path.) > The seems counter intuitive, but on Java 8 I saw String.indexOf(char) was about 30% slower than String.indexOf(String). Then I tested on Java 9 and found the performance difference was actually greater because indesOf(String) was now faster, but indexOf(char) was about the same speed. I presume this is related to the new compact strings. > > Am I missing something or should I not expect indexOf(char) to be as fast or faster than indexOf(String) for a string of length 1? What hardware? The hardware matters because intrinsics use SSE 4.2. And how long were the strings? Andrew. From shade at redhat.com Fri Jan 27 17:47:27 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 27 Jan 2017 18:47:27 +0100 Subject: String indexOf Performance In-Reply-To: <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> Message-ID: On 01/27/2017 06:37 PM, Andrew Haley wrote: > On 27/01/17 17:20, Scott Palmer wrote: >> I?m not sure if this is the right list, please redirect me if it is not. >> >> I was looking into optimizing some code and was surprised to find that String.indexOf(char) was significantly slower than String.indexOf(String) for a single character search. (E.g. I?m looking for a slash / in a path.) >> The seems counter intuitive, but on Java 8 I saw String.indexOf(char) was about 30% slower than String.indexOf(String). Then I tested on Java 9 and found the performance difference was actually greater because indesOf(String) was now faster, but indexOf(char) was about the same speed. I presume this is related to the new compact strings. >> >> Am I missing something or should I not expect indexOf(char) to be as fast or faster than indexOf(String) for a string of length 1? > > What hardware? The hardware matters because intrinsics use SSE 4.2. > > And how long were the strings? Better yet, just show your benchmark :) -Aleksey From swpalmer at gmail.com Fri Jan 27 18:22:59 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 27 Jan 2017 13:22:59 -0500 Subject: String indexOf Performance In-Reply-To: References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> Message-ID: On Fri, Jan 27, 2017 at 12:47 PM, Aleksey Shipilev wrote: > On 01/27/2017 06:37 PM, Andrew Haley wrote: > > On 27/01/17 17:20, Scott Palmer wrote: > >> I?m not sure if this is the right list, please redirect me if it is not. > >> > >> I was looking into optimizing some code and was surprised to find that > String.indexOf(char) was significantly slower than String.indexOf(String) > for a single character search. (E.g. I?m looking for a slash / in a path.) > >> The seems counter intuitive, but on Java 8 I saw String.indexOf(char) > was about 30% slower than String.indexOf(String). Then I tested on Java 9 > and found the performance difference was actually greater because > indesOf(String) was now faster, but indexOf(char) was about the same > speed. I presume this is related to the new compact strings. > >> > >> Am I missing something or should I not expect indexOf(char) to be as > fast or faster than indexOf(String) for a string of length 1? > > > > What hardware? The hardware matters because intrinsics use SSE 4.2. > > > > And how long were the strings? > > Better yet, just show your benchmark :) > > -Aleksey > I'm running on an Intel Core i7 950. Windows 10. With my test I generated 1000 strings of various lengths, around 6 to 32 characters. Every other string had a '/' somewhere in it. Then I looped through the array to count how many times I found a '/'. Testing three ways, contains(String), indexOf(char) > -1, and indexOf(String) > -1. I looped through those 100,000 times. I should do a proper JMH benchmark, but for now here's a link to the code: http://pastebin.com/dWcf7rQJ Regards, Scott From shade at redhat.com Fri Jan 27 18:37:06 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 27 Jan 2017 19:37:06 +0100 Subject: String indexOf Performance In-Reply-To: References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> Message-ID: <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> On 01/27/2017 07:22 PM, Scott Palmer wrote: > I looped through those 100,000 times. I should do a proper JMH benchmark, but > for now here's a link to the code: > > http://pastebin.com/dWcf7rQJ Ah, OK. There's no reason to dive into the performance of this particular benchmark. Please isolate the behavior you are seeing with JMH, and possibly see the generated code with -prof perfasm (or xperfasm, since you're on Windows). Thanks, -Aleksey From reto.merz at abacus.ch Fri Jan 27 18:43:54 2017 From: reto.merz at abacus.ch (Reto Merz) Date: Fri, 27 Jan 2017 19:43:54 +0100 Subject: String indexOf Performance In-Reply-To: <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> Message-ID: <8d3e3497-db0a-320c-223d-c8d571a5a9e0@abacus.ch> I have seen a big difference in 2014. Another dev has also confirmed this: https://sourceforge.net/p/findbugs/feature-requests/300/#cb7f In my case I have also used JITWatch to make sure that C2/HotSpot was really able to optimize/inline hot paths. Reto On 27.01.2017 19:37, Aleksey Shipilev wrote: > On 01/27/2017 07:22 PM, Scott Palmer wrote: >> I looped through those 100,000 times. I should do a proper JMH benchmark, but >> for now here's a link to the code: >> >> http://pastebin.com/dWcf7rQJ > Ah, OK. There's no reason to dive into the performance of this particular > benchmark. Please isolate the behavior you are seeing with JMH, and possibly see > the generated code with -prof perfasm (or xperfasm, since you're on Windows). > > Thanks, > -Aleksey > From vitalyd at gmail.com Fri Jan 27 18:56:47 2017 From: vitalyd at gmail.com (Vitaly Davidovich) Date: Fri, 27 Jan 2017 13:56:47 -0500 Subject: String indexOf Performance In-Reply-To: <8d3e3497-db0a-320c-223d-c8d571a5a9e0@abacus.ch> References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> <8d3e3497-db0a-320c-223d-c8d571a5a9e0@abacus.ch> Message-ID: IIRC, it used to be that indexOf() had an intrinsic with a fastpath, but not indexOf(char). But it looks like java 9 has an intrinsic for indexOf(char). On Fri, Jan 27, 2017 at 1:43 PM, Reto Merz wrote: > I have seen a big difference in 2014. Another dev has also confirmed this: > https://sourceforge.net/p/findbugs/feature-requests/300/#cb7f > > In my case I have also used JITWatch to make sure that C2/HotSpot > was really able to optimize/inline hot paths. > > Reto > > > > On 27.01.2017 19:37, Aleksey Shipilev wrote: > >> On 01/27/2017 07:22 PM, Scott Palmer wrote: >> >>> I looped through those 100,000 times. I should do a proper JMH >>> benchmark, but >>> for now here's a link to the code: >>> >>> http://pastebin.com/dWcf7rQJ >>> >> Ah, OK. There's no reason to dive into the performance of this particular >> benchmark. Please isolate the behavior you are seeing with JMH, and >> possibly see >> the generated code with -prof perfasm (or xperfasm, since you're on >> Windows). >> >> Thanks, >> -Aleksey >> >> > From swpalmer at gmail.com Fri Jan 27 20:14:06 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 27 Jan 2017 15:14:06 -0500 Subject: String indexOf Performance In-Reply-To: <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> Message-ID: On Fri, Jan 27, 2017 at 1:37 PM, Aleksey Shipilev wrote: > > On 01/27/2017 07:22 PM, Scott Palmer wrote: > > I looped through those 100,000 times. I should do a proper JMH benchmark, but > > for now here's a link to the code: > > > > http://pastebin.com/dWcf7rQJ > > Ah, OK. There's no reason to dive into the performance of this particular > benchmark. Please isolate the behavior you are seeing with JMH, and possibly see > the generated code with -prof perfasm (or xperfasm, since you're on Windows). > > Thanks, > -Aleksey > JMH results: Benchmark Mode Cnt Score Error Units IndexOfBenchmark.StringIndexOfChar thrpt 200 45387.001 ? 175.235 ops/s IndexOfBenchmark.StringIndexOfString thrpt 200 81835.195 ? 157.637 ops/s My test methods are simple: static final String [] paths = new String[1000]; static { for (int i = 0; i < paths.length; i++) { paths[i] = ((i & 1) == 0) ? randomName() : randomNameWithSlash(); } } @Benchmark public static int StringIndexOfChar() { int acc = 0; for (String s : paths) { if (s.indexOf('/') > -1) { acc++; } } return acc; } @Benchmark public static int StringIndexOfString() { int acc = 0; for (String s : paths) { if (s.indexOf("/") > -1) { acc++; } } return acc; } I'm not set up to run xperfasm. It appears non-trivial to do. Regards, Scott From swpalmer at gmail.com Fri Jan 27 20:18:16 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 27 Jan 2017 15:18:16 -0500 Subject: String indexOf Performance In-Reply-To: <8d3e3497-db0a-320c-223d-c8d571a5a9e0@abacus.ch> References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> <8d3e3497-db0a-320c-223d-c8d571a5a9e0@abacus.ch> Message-ID: On Fri, Jan 27, 2017 at 1:43 PM, Reto Merz wrote: > I have seen a big difference in 2014. Another dev has also confirmed this: > https://sourceforge.net/p/findbugs/feature-requests/300/#cb7f > > In my case I have also used JITWatch to make sure that C2/HotSpot > was really able to optimize/inline hot paths. > > Reto Note the link above indicates the opposite of my observations. They wrote: "After I change indexOf(".", int) to indexOf('.', int) the total execution time decreased by 23%." In my case indexOf('.', int) is quite a bit SLOWER. I brought it up here because it was so counter-intuitive. Regards, Scott > > > > On 27.01.2017 19:37, Aleksey Shipilev wrote: >> >> On 01/27/2017 07:22 PM, Scott Palmer wrote: >>> >>> I looped through those 100,000 times. I should do a proper JMH >>> benchmark, but >>> for now here's a link to the code: >>> >>> http://pastebin.com/dWcf7rQJ >> >> Ah, OK. There's no reason to dive into the performance of this particular >> benchmark. Please isolate the behavior you are seeing with JMH, and >> possibly see >> the generated code with -prof perfasm (or xperfasm, since you're on >> Windows). >> >> Thanks, >> -Aleksey >> > From shade at redhat.com Fri Jan 27 20:19:01 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 27 Jan 2017 21:19:01 +0100 Subject: String indexOf Performance In-Reply-To: References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> Message-ID: <0b186828-6a0d-4966-739b-cd395a11bc7c@redhat.com> On 01/27/2017 09:14 PM, Scott Palmer wrote: > JMH results: > > Benchmark Mode Cnt Score Error Units > IndexOfBenchmark.StringIndexOfChar thrpt 200 45387.001 ? 175.235 ops/s > IndexOfBenchmark.StringIndexOfString thrpt 200 81835.195 ? 157.637 ops/s > > > My test methods are simple: > > static final String [] paths = new String[1000]; > static { > for (int i = 0; i < paths.length; i++) { > paths[i] = ((i & 1) == 0) ? randomName() : randomNameWithSlash(); > } > } > > @Benchmark > public static int StringIndexOfChar() { > int acc = 0; > for (String s : paths) { > if (s.indexOf('/') > -1) { > acc++; > } > } > return acc; > } > > @Benchmark > public static int StringIndexOfString() { > int acc = 0; > for (String s : paths) { > if (s.indexOf("/") > -1) { > acc++; > } > } > return acc; > } Please post the full test somewhere. The randomName() and randomNameWithSlash() are important (missing) parts of it. -Aleksey From swpalmer at gmail.com Fri Jan 27 20:21:56 2017 From: swpalmer at gmail.com (Scott Palmer) Date: Fri, 27 Jan 2017 15:21:56 -0500 Subject: String indexOf Performance In-Reply-To: <0b186828-6a0d-4966-739b-cd395a11bc7c@redhat.com> References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> <0b186828-6a0d-4966-739b-cd395a11bc7c@redhat.com> Message-ID: On Fri, Jan 27, 2017 at 3:19 PM, Aleksey Shipilev wrote: > On 01/27/2017 09:14 PM, Scott Palmer wrote: >> JMH results: >> >> Benchmark Mode Cnt Score Error Units >> IndexOfBenchmark.StringIndexOfChar thrpt 200 45387.001 ? 175.235 ops/s >> IndexOfBenchmark.StringIndexOfString thrpt 200 81835.195 ? 157.637 ops/s >> >> >> My test methods are simple: >> >> static final String [] paths = new String[1000]; >> static { >> for (int i = 0; i < paths.length; i++) { >> paths[i] = ((i & 1) == 0) ? randomName() : randomNameWithSlash(); >> } >> } >> >> @Benchmark >> public static int StringIndexOfChar() { >> int acc = 0; >> for (String s : paths) { >> if (s.indexOf('/') > -1) { >> acc++; >> } >> } >> return acc; >> } >> >> @Benchmark >> public static int StringIndexOfString() { >> int acc = 0; >> for (String s : paths) { >> if (s.indexOf("/") > -1) { >> acc++; >> } >> } >> return acc; >> } > > Please post the full test somewhere. The randomName() and randomNameWithSlash() > are important (missing) parts of it. > > -Aleksey Sorry (they were the same as in the previous code I linked). Here is the full source: http://pastebin.com/zRXKwD64 Regards, Scott From shade at redhat.com Fri Jan 27 20:56:46 2017 From: shade at redhat.com (Aleksey Shipilev) Date: Fri, 27 Jan 2017 21:56:46 +0100 Subject: String indexOf Performance In-Reply-To: References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> <85c67990-5b3b-f126-8f7b-355e942d25bf@redhat.com> <0b186828-6a0d-4966-739b-cd395a11bc7c@redhat.com> Message-ID: <156b5432-37b6-dc15-f4fc-07c645afc7ae@redhat.com> On 01/27/2017 09:21 PM, Scott Palmer wrote: > http://pastebin.com/zRXKwD64 Okay: Benchmark Mode Cnt Score Error Units # JDK 8u121 IndexOfBenchmark.StringIndexOfChar thrpt 5 141857.332 ? 5530.472 ops/s IndexOfBenchmark.StringIndexOfString thrpt 5 113091.517 ? 2241.533 ops/s # JDK 9b152 IndexOfBenchmark.StringIndexOfChar thrpt 5 154525.343 ? 3796.818 ops/s IndexOfBenchmark.StringIndexOfString thrpt 5 185917.059 ? 3391.230 ops/s Perfasm for 9b152: http://cr.openjdk.java.net/~shade/scratch/indexOf.perfasm It does indeed look like indexOf(String) is backed by the intrinsic (notice "vpcmpestri $0xc,(%rbx),%xmm0"), while indexOf(char) does the Java code (notice how real locations in bytecode are mapped onto generated code). This is further corroborated by StringLatin1.indexOf not having @HotspotIntrinsicCandidate: http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/e4b19b8d4bbf/src/java.base/share/classes/java/lang/StringLatin1.java#l181 Submitted: https://bugs.openjdk.java.net/browse/JDK-8173585 Think about it this way: you have the improvement for both cases in JDK 9 due to Compact Strings, but it somewhat twisted the performance model to be less intuitive. Continue using indexOf(char) in the code, and wait for JDK to catch up. Thanks, -Aleksey From dalibor.topic at oracle.com Mon Jan 30 11:15:02 2017 From: dalibor.topic at oracle.com (dalibor topic) Date: Mon, 30 Jan 2017 12:15:02 +0100 Subject: String indexOf Performance In-Reply-To: References: <98A89717-0694-4F98-9B07-05934976AC71@gmail.com> <25b98d8f-7ab9-428e-5076-ef787552d19e@redhat.com> Message-ID: <1603b790-7d2a-d75d-cbc2-db190dc5b342@oracle.com> On 27.01.2017 19:22, Scott Palmer wrote: > I looped through those 100,000 times. I should do a proper JMH benchmark, > but for now here's a link to the code: > > http://pastebin.com/dWcf7rQJ As a meta point, in the future please send such benchmarks directly to the mailing list inline in your message, if possible, instead of putting them up on pastebin or a different third party hosting site. There are two problems with the latter approach: a) some Participants may not want to visit third party sites for their own reasons, such as https://www.google.com/transparencyreport/safebrowsing/diagnostic/index.html#url=http://pastebin.com/ "Some pages on this website install malware on visitors' computers." b) some Participants may not be able to visit third party sites due to extrinsic reasons, such as a particular site being blocked by their country, ISP, etc. - for example https://duckduckgo.com/?q=%22pastebin+blocked+in%22&bext=wcr&atb=v33-7__&ia=web 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 manishmotwani at gmail.com Sun Jan 29 03:09:34 2017 From: manishmotwani at gmail.com (Manish Motwani) Date: Sat, 28 Jan 2017 21:09:34 -0600 Subject: Compiler support for private interface methods. Message-ID: Hi, This is in reference to: http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001981.html Thanks for fixing this! Is there also a plan to allow "*private static*" fields on interfaces? "public" and "package protected" static fields are already allowed, but private static fields can also be useful in default methods on interfaces. Thanks, Manish From alex.buckley at oracle.com Mon Jan 30 19:22:26 2017 From: alex.buckley at oracle.com (Alex Buckley) Date: Mon, 30 Jan 2017 11:22:26 -0800 Subject: Compiler support for private interface methods. In-Reply-To: References: Message-ID: <588F9272.3080703@oracle.com> On 1/28/2017 7:09 PM, Manish Motwani wrote: > This is in reference to: > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001981.html > > Thanks for fixing this! > > Is there also a plan to allow "*private static*" fields on interfaces? Private methods in interfaces were supported by the JVM in Java SE 8, and the Java language is catching up with that in Java SE 9. Nothing changed for fields in interfaces in Java SE 8, nor in Java SE 9. > "public" and "package protected" static fields are already allowed, but > private static fields can also be useful in default methods on interfaces. Every field in an interface is public. Alex From david.holmes at oracle.com Mon Jan 30 20:33:52 2017 From: david.holmes at oracle.com (David Holmes) Date: Tue, 31 Jan 2017 06:33:52 +1000 Subject: Compiler support for private interface methods. In-Reply-To: References: Message-ID: <2ea9476e-889d-59f3-c7c7-450a487eb4c0@oracle.com> Alex already answered but to clarify one part ... On 29/01/2017 1:09 PM, Manish Motwani wrote: > Hi, > > This is in reference to: > http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-March/001981.html > > Thanks for fixing this! > > Is there also a plan to allow "*private static*" fields on interfaces? > "public" and "package protected" static fields are already allowed, but I think you are taking lack of an access modifier as implying "package" access, but that is not the case in interfaces, where the implied accessibility is public. David ----- > private static fields can also be useful in default methods on interfaces. > > Thanks, > Manish >