From xueming.shen at oracle.com Thu Dec 1 00:48:30 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 30 Nov 2016 16:48:30 -0800 Subject: RFR JDK-8167328: jar -d m.jar hangs Message-ID: <583F735E.6030409@oracle.com> Hi, Please help review the change for #8167328 issue: https://bugs.openjdk.java.net/browse/JDK-8167328 webrev: http://cr.openjdk.java.net/~sherman/8167328 It appears the desired behavior is to throw the error + help msg if the option "--print-module-descriptor"/ "-d" is specified with some extra file names. Thanks, Sherman From lance.andersen at oracle.com Thu Dec 1 01:06:43 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 30 Nov 2016 20:06:43 -0500 Subject: RFR JDK-8167328: jar -d m.jar hangs In-Reply-To: <583F735E.6030409@oracle.com> References: <583F735E.6030409@oracle.com> Message-ID: looks OK sherman > On Nov 30, 2016, at 7:48 PM, Xueming Shen wrote: > > Hi, > > Please help review the change for #8167328 > > issue: https://bugs.openjdk.java.net/browse/JDK-8167328 > webrev: http://cr.openjdk.java.net/~sherman/8167328 > > It appears the desired behavior is to throw the error + help msg if the > option "--print-module-descriptor"/ "-d" is specified with some extra > file names. > > Thanks, > Sherman > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From lance.andersen at oracle.com Thu Dec 1 01:07:38 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 30 Nov 2016 20:07:38 -0500 Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192 In-Reply-To: <583F42D0.2000703@oracle.com> References: <583F42D0.2000703@oracle.com> Message-ID: <48BEEEAD-3E5B-45A7-B551-B7C3938AADBF@oracle.com> Hi Joe Looks OK. I might suggest a separate issue for the cleanup and just have this bug address the bug fix Best Lance > On Nov 30, 2016, at 4:21 PM, Joe Wang wrote: > > Hi, > > Please review an one-line fix and a bunch of cleanups. > > The reported issue was caused by a missed setting when the XMLStreamReader initializes the XML 1.1 scanner, so while the changeset involved 350 lines, the fix is really just the following: > > XMLStreamReaderImpl.java: > @@ -605,11 +604,12 @@ > ... > + fEntityScanner.registerListener(fScanner); > > > All other changes are cleanups, warnings. And BTW, warnings in the jaxp repo have come down from 5230 in 2015 to 3265, a result of a bit of cleanups here and there when we touch those classes. Still a long way to go, and it shows we may need to have a few dedicated patches. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8167340 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ > > Thanks, > Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From felix.yang at oracle.com Thu Dec 1 01:40:51 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Dec 2016 09:40:51 +0800 Subject: RFR 8170559, Incorrect bug id in problem list Message-ID: <7f56390d-c593-c45e-96f9-ffbda6b1d52e@oracle.com> Hi there, please review the change to correct a mistake. An incorrect bug id was incidentally used in problem list. Bug: https://bugs.openjdk.java.net/browse/JDK-8170559 Thanks, Felix diff -r a563aaa85446 test/ProblemList.txt --- a/test/ProblemList.txt Wed Nov 30 17:15:58 2016 -0800 +++ b/test/ProblemList.txt Wed Nov 30 17:23:24 2016 -0800 @@ -305,6 +305,6 @@ # jdk_other com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 linux-i586,macosx-all,windows-x64 -javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8170248 linux-all +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java 8169737 linux-all ############################################################################ From huaming.li at oracle.com Thu Dec 1 01:45:23 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 1 Dec 2016 09:45:23 +0800 Subject: RFR of JDK-8019538: TEST_BUG: java/rmi/activation/rmidViaInheritedChannel tests may fail In-Reply-To: <48868038-F478-4CC4-B74B-B40DE7803242@oracle.com> References: <73753d7c-9d58-8632-da37-10e12e13e400@oracle.com> <9658e687-9e58-be70-cc58-6bf6dc3ea76c@Oracle.com> <453b4744-6e6c-733f-281a-508b9bf03295@oracle.com> <327ba64a-1e9f-8965-4a19-b0ad0fb643ff@Oracle.com> <48868038-F478-4CC4-B74B-B40DE7803242@oracle.com> Message-ID: <98bcd6fd-c12c-72bd-75ef-f37cbe59f614@oracle.com> Hi Roger, Chris, Thank you for reviewing. Got it, it's removed and code is pushed. Thank you -Hamlin p.s. In fact, my first thought is to just remove it, my second thought is to keep it because I'm afraid that some day inherited channel fix might be substituted with some other things, but now I think I thought too much, the possibility to substitute inherited channel fix is very very low, so my third thought is to remove it. On 2016/12/1 4:48, Chris Hegarty wrote: >> On 30 Nov 2016, at 19:08, Roger Riggs wrote: >> >> Hi Hamlin, >> >> I would just remove it. > Removal is fine with me. This area is now well tested. > > -Chris. > >> Stuart? Chris? Zyx >> >> Roger >> >> p.s. If you think there might be a reason to resurrect it later, attach the current webrev to the issue >> before updating it to remove. >> >> >> >> >> On 11/29/2016 9:25 PM, Hamlin Li wrote: >>> Hi Roger, >>> >>> Thank you for reviewing. please check the comments in line. >>> >>> >>> On 2016/11/30 0:50, Roger Riggs wrote: >>>> Hi Hamlin, >>>> >>>> The changes proposed are fine as far as they go, but... >>>> >>>> I think this test can be completely removed. >>>> The recent change to use inherited channel for many of the rmid tests makes this test redundant. >>>> It does not add anything over other activation/RMID tests. >>>> >>>> The test before the changes, was successful because it launched the daemon with >>>> a specific selector provider whose only action was to notify that it was launched successfully >>>> (by invoking a method on an object registered in the registry) and was successful if the invoking >>>> test program received the notification. >>>> >>>> That function is now replaced by RMID.createRMIDonEphemeralPort(). >>>> If it succeeds to launch and retrieve the port number, then the InheritedChannel mechanism is fully working. >>>> >>>> So I think the test can be removed entirely. >>>> Make sense? >>> Agree, I had the same thought. It might be useful to keep it, even if it looks like do no more test. It's specifically checking inherited channel, and it's can be a sanity test for RMID+RMIDSelectorProvider test library. >>> I can do either way. Please let me know your final thought. >>> >>> Thank you >>> -Hamlin >>> >>>> Thanks, Roger >>>> >>>> On 11/23/2016 4:49 AM, Hamlin Li wrote: >>>>> Would you please review the fix for below bug? >>>>> >>>>> bug: https://bugs.openjdk.java.net/browse/JDK-8019538 >>>>> webrev: http://cr.openjdk.java.net/~mli/8019538/webrev.00/ >>>>> >>>>> There are 4 issues in the bug, >>>>> 2 in RmidViaInheritedChannel.java: "port in use" in registry, "port in use" in rmid start. >>>>> 2 InheritedChannelNotServerSocket.java: "port in use" in registry, "port in use" in rmid start. >>>>> >>>>> This patch fixes 2 issues in RmidViaInheritedChannel, and only "port in use" in registry in InheritedChannelNotServerSocket. >>>>> The "port in use" in rmid in InheritedChannelNotServerSocket is little bit hard, as it intends to test rmid when inherited channel not work. Currently the only solution in my mind is to retry when rmid fails with "port in use", but as we discussed earlier, it's not a good solution as it might impact other programs or tests, and it's not efficient. >>>>> So I hope to push the fix for the other issues first to improve the stability of RMI tests, and keep studying if there are other better solutions for the "port in use" in rmid in InheritedChannelNotServerSocket. >>>>> >>>>> Thank you >>>>> -Hamlin From huaming.li at oracle.com Thu Dec 1 02:27:19 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 1 Dec 2016 10:27:19 +0800 Subject: RFR of JDK-8049316: TEST_BUG: java/nio/channels/Selector/Wakeup.java fails in same binary run b19 In-Reply-To: References: <55b7c230-6f1a-57fd-847b-6ee79728f67c@oracle.com> <0d58f7a4-aec3-5190-2240-ef75d9733944@Oracle.com> Message-ID: <6f42f16c-f589-0ec7-31ea-8a0212ac11a3@oracle.com> Hi Roger, Thank you for reviewing, fixed timeout scale and pushed. Thank you -Hamlin On 2016/12/1 3:49, Roger Riggs wrote: > Hi Hamlin, > > > On 11/29/2016 9:09 PM, Hamlin Li wrote: >> Hi Roger, >> >> Thank you for reviewing, please check comments in line. >> >> webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.01/ >> >> >> On 2016/11/30 0:03, Roger Riggs wrote: >>> Hi Hamlin, >>> >>> Wakeup.java: >>> >>> - Some refactoring may make it easier to understand. >>> Perhaps moving waitSleeper to be a method on Sleeper. >>> The use of cyclicBarrier seems fine but could use a comment >>> somewhere saying what >>> threads/functions are being coordinated; putting them both in >>> Sleeper would make it easier to see. >>> >>> - line 126,127: Add a Sleeper constructor to initialize these as >>> needed. >>> >>> - Some of the test stimulus is buried in the newSleeper methods that >>> was previously >>> in line in main. It seemed clearer what case was being tested in >>> the original. >>> They are buried in static factory 'newSleeper' functions with >>> uninformative names. >>> lines 112, 116, 120. >> All above fixed. > I was thinking that the createSleeper(sel, want, before) method forced > two cases together that > didn't need to be in the same method and could be separated in the > newSleeperWantInterrupt and > newSleeperWithInterruptBeforeSelect factory methods. > > > line 104: the timeout value should be scaled by > jdk/testlibrary/Utils.adjustTimeout (test.timeout.factor). > >>> >>> - If I read it right, some cases where events don't happen that >>> used to be reported as exceptions >>> ("Interrupt never delivered") will now be reported as the test >>> timing out. (infinite loop at line 85). >> No, it will finally checked by a time sleeper.finish(0). At first, I >> don't want to depends on a specific time, because I don't know what >> exact timeout we should use, but as you asked, I think it's ok to >> finish(20_000), it should be long enough. > > Otherwise is fine. > > Thanks, Roger > >> >> Thank you >> -Hamlin >>> >>> Thanks, Roger >>> >>> On 11/29/2016 4:23 AM, Hamlin Li wrote: >>>> Would you please review the below patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8049316 >>>> webrev: http://cr.openjdk.java.net/~mli/8049316/webrev.00/ >>>> >>>> Root cause: >>>> 1. it depends on sleeping time to check failure, which is not >>>> reliable in some extreme situation >>>> 2. it mix several tests together with a loop in Sleeper >>>> >>>> Solution: >>>> 1. synchronize between threads. >>>> 2. isolate tests. >>>> >>>> Thank you >>>> Hamlin >>> >> > From christoph.langer at sap.com Thu Dec 1 07:40:24 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 1 Dec 2016 07:40:24 +0000 Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192 In-Reply-To: <583F42D0.2000703@oracle.com> References: <583F42D0.2000703@oracle.com> Message-ID: <6827111172944d99b699601a63ed1808@DEWDFE13DE03.global.corp.sap> Hi Joe, to me this looks good. Did you already remove the cleanups from http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ ? I can't see a lot of them any more... A few minor points: It seems you still have left some debugging code in test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/StreamReaderTest.java: 59 while (xmlStreamReader.hasNext()) { 60 int event = xmlStreamReader.next(); 61 if (event == XMLStreamConstants.START_ELEMENT) { 62 if (xmlStreamReader.getLocalName().equals("body"))// && bMessage) -> remove the && bMessage) 63 { 64 String elementText = xmlStreamReader.getElementText(); 65 //System.out.println("elementText=" + elementText + "EndOfElementText"); -> the commented System.out.println statement should be removed at all, I suggest 66 // fail if elementText contains "" 67 Assert.assertTrue(!elementText.contains(""), "Fail: elementText contains "); 68 } 69 } 70 } Other than that I'm wondering if the 80 chars line limit shall be held which is not completely true in StreamReaderTest.java. But I know how difficult that is, while keeping the code still readable. Especially with the long speaking Class and method names ;-) Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Joe Wang > Sent: Mittwoch, 30. November 2016 22:21 > To: core-libs-dev at openjdk.java.net > Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt > content when size of element is > 8192 > > Hi, > > Please review an one-line fix and a bunch of cleanups. > > The reported issue was caused by a missed setting when the > XMLStreamReader initializes the XML 1.1 scanner, so while the changeset > involved 350 lines, the fix is really just the following: > > XMLStreamReaderImpl.java: > @@ -605,11 +604,12 @@ > ... > + fEntityScanner.registerListener(fScanner); > > > All other changes are cleanups, warnings. And BTW, warnings in the jaxp > repo have come down from 5230 in 2015 to 3265, a result of a bit of > cleanups here and there when we touch those classes. Still a long way to > go, and it shows we may need to have a few dedicated patches. > > JBS: https://bugs.openjdk.java.net/browse/JDK-8167340 > webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ > > Thanks, > Joe From christoph.dreis at freenet.de Thu Dec 1 07:41:13 2016 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Thu, 1 Dec 2016 08:41:13 +0100 Subject: [NEW BUG]: Small enhancement for Class.isAnonymousClass() Message-ID: <000301d24ba6$4af88120$e0e98360$@freenet.de> Hey, I'm currently getting familiar with the source code to eventually contribute something more in the future. While doing so I noticed some smaller enhancements where I don't know if they even justify a mail. Please let me know how you handle such tiny improvements based on the following: One of the arguably small improvements was Class.isAnonymousClass() which checks for emptiness with "".equals(getSimpleName()) instead of getSimpleName().isEmpty() and I see no way of getSimpleName() returning null (I might miss something though). Anyhow, the latter is slightly faster and a bit more verbose: MyBenchmark.testEmpty thrpt 20 364479649,385 ? 5805392,007 ops/s MyBenchmark.testEquals thrpt 20 287935443,484 ? 2895104,850 ops/s Again - if this is too small please let me know and excuse the disturbance. Cheers, Christoph =========== PATCH ============ # User Christoph Dreis Small enhancement for Class.isAnonymousClass() diff --git a/src/java.base/share/classes/java/lang/Class.java b/src/java.base/share/classes/java/lang/Class.java --- a/src/java.base/share/classes/java/lang/Class.java +++ b/src/java.base/share/classes/java/lang/Class.java @@ -1596,7 +1596,7 @@ * @since 1.5 */ public boolean isAnonymousClass() { - return "".equals(getSimpleName()); + return getSimpleName().isEmpty(); } From felix.yang at oracle.com Thu Dec 1 09:47:40 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Dec 2016 17:47:40 +0800 Subject: RFR 8162521, java/net/Authenticator/B4933582.sh fails intermittently with BindException Message-ID: <8f8aeb9a-580e-0b72-274c-33ca06102fdb@oracle.com> Hi, please review the following patch. The code was converted from shell script to plain Java. Since it is by-design to bind on a prior-used port, add a few of re-tries for possible BindException. Bug: https://bugs.openjdk.java.net/browse/JDK-8162521 Webrev: http://cr.openjdk.java.net/~xiaofeya/8162521/webrev.00/ Thanks, Felix From daniel.fuchs at oracle.com Thu Dec 1 10:25:46 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 1 Dec 2016 10:25:46 +0000 Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192 In-Reply-To: <6827111172944d99b699601a63ed1808@DEWDFE13DE03.global.corp.sap> References: <583F42D0.2000703@oracle.com> <6827111172944d99b699601a63ed1808@DEWDFE13DE03.global.corp.sap> Message-ID: <7cfdb1af-3773-5672-baca-cf3c9b1e0ef2@oracle.com> Hi Joe, I agree with Christoph's comments below. +1 best regards, -- daniel On 01/12/16 07:40, Langer, Christoph wrote: > Hi Joe, > > to me this looks good. > > Did you already remove the cleanups from http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ ? I can't see a lot of them any more... > > A few minor points: > > It seems you still have left some debugging code in test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/StreamReaderTest.java: > > 59 while (xmlStreamReader.hasNext()) { > 60 int event = xmlStreamReader.next(); > 61 if (event == XMLStreamConstants.START_ELEMENT) { > 62 if (xmlStreamReader.getLocalName().equals("body"))// && bMessage) > > -> remove the && bMessage) > > 63 { > 64 String elementText = xmlStreamReader.getElementText(); > 65 //System.out.println("elementText=" + elementText + "EndOfElementText"); > > -> the commented System.out.println statement should be removed at all, I suggest > > 66 // fail if elementText contains "" > 67 Assert.assertTrue(!elementText.contains(""), "Fail: elementText contains "); > 68 } > 69 } > 70 } > > Other than that I'm wondering if the 80 chars line limit shall be held which is not completely true in StreamReaderTest.java. But I know how difficult that is, while keeping the code still readable. Especially with the long speaking Class and method names ;-) > > Best regards > Christoph > > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Joe Wang >> Sent: Mittwoch, 30. November 2016 22:21 >> To: core-libs-dev at openjdk.java.net >> Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt >> content when size of element is > 8192 >> >> Hi, >> >> Please review an one-line fix and a bunch of cleanups. >> >> The reported issue was caused by a missed setting when the >> XMLStreamReader initializes the XML 1.1 scanner, so while the changeset >> involved 350 lines, the fix is really just the following: >> >> XMLStreamReaderImpl.java: >> @@ -605,11 +604,12 @@ >> ... >> + fEntityScanner.registerListener(fScanner); >> >> >> All other changes are cleanups, warnings. And BTW, warnings in the jaxp >> repo have come down from 5230 in 2015 to 3265, a result of a bit of >> cleanups here and there when we touch those classes. Still a long way to >> go, and it shows we may need to have a few dedicated patches. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8167340 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ >> >> Thanks, >> Joe From claes.redestad at oracle.com Thu Dec 1 10:37:17 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 11:37:17 +0100 Subject: [NEW BUG]: Small enhancement for Class.isAnonymousClass() In-Reply-To: <000301d24ba6$4af88120$e0e98360$@freenet.de> References: <000301d24ba6$4af88120$e0e98360$@freenet.de> Message-ID: <70a36757-d0f7-f37b-dc9e-038fa1313e8e@oracle.com> Hi Christoph, nothing wrong with tiny code changes when they actually matter (and Class.isAnonymousClass is rather widely used internally and in reflection libraries, so I'd say any significant improvement is worth considering). I'm a bit surprised by the large improvement from your suggested change though, since it seems the largest cost by far here seems to be the call to getSimpleName(). Care to share your micro? Looking at Class.isAnonymousClass it seems like we could do even better by digging a bit deeper and breaking some rules of abstraction: Current: public boolean isAnonymousClass() { return "".equals(getSimpleName()); } Clazz.isAnonymousClass avgt 5 124.861 ? 37.689 ns/op public boolean isAnonymousClass() { return !isArray() && getEnclosingMethod0() != null && getSimpleBinaryName0() == null; } Clazz.isAnonymousClass avgt 5 45.079 ? 12.238 ns/op Thanks! /Claes Clazz.java: package org.openjdk; import org.openjdk.jmh.annotations.Benchmark; import org.openjdk.jmh.annotations.BenchmarkMode; import org.openjdk.jmh.annotations.Mode; import org.openjdk.jmh.annotations.OutputTimeUnit; @BenchmarkMode(Mode.AverageTime) @OutputTimeUnit(TimeUnit.NANOSECONDS) public class Clazz { public static Class c = String.class; @Benchmark public boolean isAnonymousClass() { return c.isAnonymousClass(); } } On 2016-12-01 08:41, Christoph Dreis wrote: > Hey, > > I'm currently getting familiar with the source code to eventually contribute > something more in the future. While doing so I noticed some smaller > enhancements where I don't know if they even justify a mail. Please let me > know how you handle such tiny improvements based on the following: > > One of the arguably small improvements was Class.isAnonymousClass() which > checks for emptiness with "".equals(getSimpleName()) instead of > getSimpleName().isEmpty() and I see no way of getSimpleName() returning null > (I might miss something though). Anyhow, the latter is slightly faster and a > bit more verbose: > > MyBenchmark.testEmpty thrpt 20 364479649,385 ? 5805392,007 ops/s > MyBenchmark.testEquals thrpt 20 287935443,484 ? 2895104,850 ops/s > > Again - if this is too small please let me know and excuse the disturbance. > > Cheers, > Christoph > > =========== PATCH ============ > # User Christoph Dreis > Small enhancement for Class.isAnonymousClass() > > diff --git a/src/java.base/share/classes/java/lang/Class.java > b/src/java.base/share/classes/java/lang/Class.java > --- a/src/java.base/share/classes/java/lang/Class.java > +++ b/src/java.base/share/classes/java/lang/Class.java > @@ -1596,7 +1596,7 @@ > * @since 1.5 > */ > public boolean isAnonymousClass() { > - return "".equals(getSimpleName()); > + return getSimpleName().isEmpty(); > } > From daniel.fuchs at oracle.com Thu Dec 1 10:58:57 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 1 Dec 2016 10:58:57 +0000 Subject: RFR 8162521, java/net/Authenticator/B4933582.sh fails intermittently with BindException In-Reply-To: <8f8aeb9a-580e-0b72-274c-33ca06102fdb@oracle.com> References: <8f8aeb9a-580e-0b72-274c-33ca06102fdb@oracle.com> Message-ID: <65834093-fecb-f017-c1cb-9d25916afb6f@oracle.com> Hi Felix, Good to see one more script converted to java. I wonder if the fact that the test use to run two separate JVMs was significant. Hopefully it's not. The changes in TestHttpServer seem OK - this class is shared by many other tests - so any modifications here is to be taken with care. I trust you ran all the jdk_net tests? In B4933582.java: maybe MyAuthenticator.count should be made volatile (or AtomicInteger). I don't think it's strictly necessary as I believe our implementation will only call it in the client thread (which is always the main thread here) - but it may be a better idea to use AtomicInteger anyway: just make no assumption :-) I'd also suggest to use try-with-resource to close in CacheImpl (int port) and CacheImpl::writeMap to make sure the file is always properly closed. best regards, -- daniel On 01/12/16 09:47, Felix Yang wrote: > Hi, > > please review the following patch. The code was converted from shell > script to plain Java. Since it is by-design to bind on a prior-used > port, add a few of re-tries for possible BindException. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8162521 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8162521/webrev.00/ > > Thanks, > Felix From rachna.goel at oracle.com Thu Dec 1 13:20:04 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Thu, 1 Dec 2016 18:50:04 +0530 Subject: RFR: JDK-8075577: java.time does not support HOST provider In-Reply-To: <2ee441e3-eda4-fd36-171c-8ebdf1d6c65c@Oracle.com> References: <59be845e-7afa-45c7-a7b1-6fe6e01c4edc@oracle.com> <2ee441e3-eda4-fd36-171c-8ebdf1d6c65c@Oracle.com> Message-ID: Hi Roger, Thanks for the review. Updated patch is : http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.02/ Please find some of my comments inlined. On 30/11/16 10:17 PM, Roger Riggs wrote: > Hi Rachna, > > macosx//HostLocaleProviderAdapterImpl.java: > > - line 172-177, might be a good place to use the new > ConcurrentMap.computeIfAbsent I could have replaced those lines with : dateFormatPatternsMap.computeIfAbsent(locale, k -> new SoftReference<>(new AtomicReferenceArray<>(5 * 5))); But, there are two check made on line no 173. (ref == null ) which will be checked by computeIfAbsent, But about second (dateFormatPatterns = ref.get()) == null) will not be checked, if those lines replaced. > > - line 197: you could pre-size the StringBuilder since the target > length can be estimated > (unless they are all less than the default 16) pre-sized it with initial " jrepattern" string. > > macosx && windows//HostLocaleProviderAdapterImpl.java > - toJavaTimeDateTimePattern() - is there a way to avoid having two > copies of this function? > Perhaps as a static method in JavaTimeDateTimePatternImpl.java. There seems to be no way to avoid having two copies. Implementations of "HostLocaleProviderAdapterImpl" for different HOST Environments are loaded at run time by HOSTLocaleProviderAdapter. JavaTimeDateTimePatternImpl is an implementation of "JavaTimeDateTimePatternProvider" for JRE LocaleProviderAdapter. > > The noreg-hard label on issue indicates testing is difficult and > specific to OS and host > configuration but it also seems unusual to have this much code and not > have a regression test. > I am in touch with I18n SQE on writing tests for HOST Providers. But testing scope, Golden data are yet to be discussed. > If Masayoshi is satisfied and you have tested it in the target > configuration then > perhaps it is not worthwhile to invest in a special case regression test. > > Thanks, Roger > > On 11/30/2016 4:39 AM, Masayoshi Okutsu wrote: >> Looks good to me. >> >> Masayoshi >> >> >> On 11/22/2016 6:30 PM, Rachna Goel wrote: >>> Hi, >>> >>> Please review fix for JDK-8075577. >>> >>> Bug : https://bugs.openjdk.java.net/browse/JDK-8075577 >>> >>> webrev : http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.01/ >>> >>> Fix is to introduce new private spi >>> "sun.text.spi.JavaTimeDateTimePatternProvider.java" to retrieve >>> LocaleProvider specific Date/Time Patterns for "java.time" . >>> >>> Thanks, >>> Rachna >>> >>> >>> >> > From jbluettduncan at gmail.com Thu Dec 1 13:39:26 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 1 Dec 2016 13:39:26 +0000 Subject: Enhancements to Java Collections API In-Reply-To: References: Message-ID: Hi John, I'm not sure about most of the suggestions you've made, especially the Bidi* ones, but I understand that something like your suggestion for an enhanced `Optional getIfPresent(K key)` is (or was) being investigated by Mr. Goetz himself and other people over at Project Valhalla . However, I can't seem to find the archived email where it was announced... Kind regards, Jonathan On 29 November 2016 at 20:13, John Platts wrote: > There are many features that are missing from the Java Collections API > that should be added to the Java Collections API, including the following: > > * Bidirectional iterators for collections other than lists > * New interfaces > * BidiIterator - bidirectional iterator > * extended by ListIterator interface > * has hasPrevious() and previous() methods > * ReverseIterable - reverse iterable > * extends Iterable > * extended by List, Deque, NavigableSet, and BidiIterable > * has descendingIterator() and reverseForEach(Consumer super T>) methods > * BidiIterable - bidirectional iterable > * extends ReverseIterable > * bidiIterator() returns a BidiIterator > * bidiIteratorFromEnd() returns a BidiIterator that is > positioned just past the last element in the collection > * extended by List, BidiIterableCollection, BidiIterableSet, > BidiIterableNavigableSet, and BidiIterableDeque > * BidiIterableCollection - bidirectional iterable collection, > extends BidiIterable and Collection > * extended by List, BidiIterableSet, > BidiIterableNavigableSet, and BidiIterableDeque > * default implementation of bidiIterator() method added to > the java.util.List interface that delegates to java.util.List.listIterator() > * default implementation of bidiIteratorFromEnd() method > added to the java.util.List interface that delegates to > java.util.List.listIterator(size()) > * BidiIterableSet - bidirectional iterable set, extends > BidiCollection and Set > * BidiIterableNavigableSet - bidirectional iterable navigable > iterable set, extends BidiIterableSet and NavigableSet > * subSet(), headSet(), and tailSet() all return > BidiIterableNavigableSet instances > * BidiIterableDeque - bidirectional iterable deque, extends > BidiCollection and Deque > * BidiIterableMap - bidirectional iterable map > * extends Map > * keySet() and entrySet() return BidiIterableSet > * values() returns BidiCollection > * has reverseForEach(BiConsumer) method > * BidiIterableNavigableMap - bidirectional iterable navigable map > * extends BidiIterableMap and NavigableMap > * keySet(), navigableKeySet(), and descendingKeySet() all > return BidiNavigableSet > * entrySet() returns BidiIterableSet > * values() returns BidiCollection > * subMap(), headMap() and tailMap() all return > BidiIterableNavigableMap instances > * BidiIterableDeque interface implemented on java.util.ArrayDeque, > java.util.concurrent.ConcurrentLinkedDeque, java.util.concurrent.LinkedBlockingDeque, > and java.util.LinkedList > * BidiIterableSet interface implemented on java.util.LinkedHashSet, > java.util.TreeSet, and java.util.concurrent.ConcurrentSkipListSet > * BidiIterableNavigableSet interface implemented on > java.util.TreeSet and java.util.concurrent.ConcurrentSkipListSet > * BidiIterableMap interface implemented on java.util.LinkedHashMap, > java.util.TreeMap, and java.util.concurrent.ConcurrentSkipListMap > * BidiIterableNavigableMap interface implemented on > java.util.TreeMap and java.util.concurrent.ConcurrentSkipListMap > * Pollable interface > * Extended by the Queue, Deque, and NavigableSet interfaces > * Also implemented by the java.lang.ref.ReferenceQueue class > * Contains the poll() method, which is already defined by the Queue > and Deque interfaces > * BidiPollable interface > * Extends the Pollable interface > * Extended by the Deque and NavigableSet interfaces > * Contains the pollFirst() and pollLast() methods, which are > already defined in both the Deque and NavigableSet interfaces > * Navigable versions of java.util.EnumMap and java.util.EnumSet > * Option #1: Implement the NavigableMap interface on top of > java.util.EnumMap and java.util.EnumSet > * Option #2: Implement separate java.util.NavigableEnumMap and > java.util.NavigableEnumSet classes that behave similarly to the existing > java.util.EnumMap and java.util.EnumSet classes, except that the > java.util.NavigableEnumMap class has the functionality of the > java.util.NavigableMap interface and that the java.util.NavigableEnumSet > class has the functionality of the java.util.NavigableSet interface. > * Under both options, the comparator() method of the navigable > versions of EnumMap and EnumSet would return null > * Navigable versions of EnumMap and EnumSet are possible since all > enum types implement the Comparable interface > * New enhanced map and set implementations > * Support for hash maps and hash sets with custom hashcode function > and custom equality predicate > * Enhanced map interface that defines a Optional getIfPresent(K > key) method that returns the following: > * A non-empty optional if the key is contained in the map and > the value is non-null > * An empty optional if the key is contained in the map, but the > value is null > * null if the map does not contain key > > Will these enhancements ever make it into Java SE 10 or Java SE 11? > > * > From claes.redestad at oracle.com Thu Dec 1 13:38:23 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 14:38:23 +0100 Subject: RFR: 8170595: Optimize Class.isAnonymousClass Message-ID: <617953b0-2398-c931-931e-3370e96f2b07@oracle.com> Hi, due to recent interest to optimize Class.isAnonymousClass[1] I took a look at the implementation and found that we can further improve performance of this method, especially when asking non-anonymous classes[2]. As such calls are a common occurrence during startup and bootstrap of lambdas this actually appears rather worthwhile: Webrev: http://cr.openjdk.java.net/~redestad/8170595/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8170595 Thanks! /Claes [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045116.html [2] Benchmark Mode Cnt Score Error Units Clazz.isAnonymousClass_Anon avgt 50 200.900 ? 15.503 ns/op Clazz.isAnonymousClass_Regular avgt 50 136.896 ? 9.605 ns/op Clazz.isAnonymousClass_Anon avgt 50 186.564 ? 12.219 ns/op Clazz.isAnonymousClass_Regular avgt 50 33.878 ? 1.524 ns/op See bug for benchmark source From Roger.Riggs at Oracle.com Thu Dec 1 14:36:18 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Dec 2016 09:36:18 -0500 Subject: RFR 8170559, Incorrect bug id in problem list In-Reply-To: <7f56390d-c593-c45e-96f9-ffbda6b1d52e@oracle.com> References: <7f56390d-c593-c45e-96f9-ffbda6b1d52e@oracle.com> Message-ID: <39a21a39-aab1-0095-adfd-65ae66f326e3@Oracle.com> Looks fine On 11/30/2016 8:40 PM, Felix Yang wrote: > Hi there, > > please review the change to correct a mistake. An incorrect bug id > was incidentally used in problem list. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170559 > > Thanks, > > Felix > > > diff -r a563aaa85446 test/ProblemList.txt > --- a/test/ProblemList.txt Wed Nov 30 17:15:58 2016 -0800 > +++ b/test/ProblemList.txt Wed Nov 30 17:23:24 2016 -0800 > @@ -305,6 +305,6 @@ > # jdk_other > > com/sun/jndi/ldap/DeadSSLLdapTimeoutTest.java 8169942 > linux-i586,macosx-all,windows-x64 > -javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java > 8170248 linux-all > +javax/rmi/PortableRemoteObject/8146975/RmiIiopReturnValueTest.java > 8169737 linux-all > > ############################################################################ > > From felix.yang at oracle.com Thu Dec 1 14:40:20 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 1 Dec 2016 22:40:20 +0800 Subject: RFR 8162521, java/net/Authenticator/B4933582.sh fails intermittently with BindException In-Reply-To: <65834093-fecb-f017-c1cb-9d25916afb6f@oracle.com> References: <8f8aeb9a-580e-0b72-274c-33ca06102fdb@oracle.com> <65834093-fecb-f017-c1cb-9d25916afb6f@oracle.com> Message-ID: <8a1c3c8b-a915-bed4-3f0a-b47657f8e53a@oracle.com> Hi Daniel, please review the new webrev: http://cr.openjdk.java.net/~xiaofeya/8162521/webrev.01/ Thanks, Felix On 2016/12/1 18:58, Daniel Fuchs wrote: > Hi Felix, > > Good to see one more script converted to java. > > I wonder if the fact that the test use to run two separate > JVMs was significant. Hopefully it's not. According original bug (https://bugs.openjdk.java.net/browse/JDK-4933582), I didn't find out a strong reason to run with two different JVMs. But original TestHttpServe.terminate() cannot free ports on Windows, that is why the shutdown section was adjusted. This could be a possible reason. -Felix > > The changes in TestHttpServer seem OK - this class is shared > by many other tests - so any modifications here is to be taken > with care. I trust you ran all the jdk_net tests? Yes, tested on all platforms. -Felix > > In B4933582.java: > > maybe MyAuthenticator.count should be made volatile (or AtomicInteger). > I don't think it's strictly necessary as I believe our implementation > will only call it in the client thread (which is always the main thread > here) - but it may be a better idea to use AtomicInteger anyway: just > make no assumption :-) > > I'd also suggest to use try-with-resource to close in > CacheImpl (int port) and CacheImpl::writeMap to make sure > the file is always properly closed. Updated all the history codes, as you suggested Thanks, Felix > best regards, > > -- daniel > > > On 01/12/16 09:47, Felix Yang wrote: >> Hi, >> >> please review the following patch. The code was converted from shell >> script to plain Java. Since it is by-design to bind on a prior-used >> port, add a few of re-tries for possible BindException. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8162521 >> >> Webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8162521/webrev.00/ >> >> Thanks, >> Felix > From daniel.fuchs at oracle.com Thu Dec 1 14:48:16 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 1 Dec 2016 14:48:16 +0000 Subject: RFR 8162521, java/net/Authenticator/B4933582.sh fails intermittently with BindException In-Reply-To: <8a1c3c8b-a915-bed4-3f0a-b47657f8e53a@oracle.com> References: <8f8aeb9a-580e-0b72-274c-33ca06102fdb@oracle.com> <65834093-fecb-f017-c1cb-9d25916afb6f@oracle.com> <8a1c3c8b-a915-bed4-3f0a-b47657f8e53a@oracle.com> Message-ID: <9d489719-cd92-7eb9-ddce-825517427d7a@oracle.com> On 01/12/16 14:40, Felix Yang wrote: > Hi Daniel, > > please review the new webrev: > > http://cr.openjdk.java.net/~xiaofeya/8162521/webrev.01/ Looks good Felix! -- daniel > > Thanks, > Felix > On 2016/12/1 18:58, Daniel Fuchs wrote: >> Hi Felix, >> >> Good to see one more script converted to java. >> >> I wonder if the fact that the test use to run two separate >> JVMs was significant. Hopefully it's not. > According original bug > (https://bugs.openjdk.java.net/browse/JDK-4933582), I didn't find out a > strong reason to run with two different JVMs. > But original TestHttpServe.terminate() cannot free ports on Windows, > that is why the shutdown section was adjusted. This could be a possible > reason. > > -Felix >> >> The changes in TestHttpServer seem OK - this class is shared >> by many other tests - so any modifications here is to be taken >> with care. I trust you ran all the jdk_net tests? > Yes, tested on all platforms. > > -Felix >> >> In B4933582.java: >> >> maybe MyAuthenticator.count should be made volatile (or AtomicInteger). >> I don't think it's strictly necessary as I believe our implementation >> will only call it in the client thread (which is always the main thread >> here) - but it may be a better idea to use AtomicInteger anyway: just >> make no assumption :-) >> >> I'd also suggest to use try-with-resource to close in >> CacheImpl (int port) and CacheImpl::writeMap to make sure >> the file is always properly closed. > Updated all the history codes, as you suggested > Thanks, > Felix >> best regards, >> >> -- daniel >> >> >> On 01/12/16 09:47, Felix Yang wrote: >>> Hi, >>> >>> please review the following patch. The code was converted from shell >>> script to plain Java. Since it is by-design to bind on a prior-used >>> port, add a few of re-tries for possible BindException. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8162521 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~xiaofeya/8162521/webrev.00/ >>> >>> Thanks, >>> Felix >> > From chris.hegarty at oracle.com Thu Dec 1 15:02:04 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Thu, 1 Dec 2016 15:02:04 +0000 Subject: RFR JDK-8167328: jar -d m.jar hangs In-Reply-To: <583F735E.6030409@oracle.com> References: <583F735E.6030409@oracle.com> Message-ID: Thank you Sherman, this looks good. -Chris. > On 1 Dec 2016, at 00:48, Xueming Shen wrote: > > Hi, > > Please help review the change for #8167328 > > issue: https://bugs.openjdk.java.net/browse/JDK-8167328 > webrev: http://cr.openjdk.java.net/~sherman/8167328 > > It appears the desired behavior is to throw the error + help msg if the > option "--print-module-descriptor"/ "-d" is specified with some extra > file names. > > Thanks, > Sherman > From claes.redestad at oracle.com Thu Dec 1 15:33:28 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 16:33:28 +0100 Subject: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection Message-ID: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> Hi, recent changes to FilePermissionCollection to use a lambda in place of an explicit BiFunction cause a quite noticeable startup and footprint regression on small applications due to a bootstrap dependency. Therefore I'd like to revert this particular change. Bug: https://bugs.openjdk.java.net/browse/JDK-8170602 Webrev: http://cr.openjdk.java.net/~redestad/8170602/webrev.01/ Thanks! /Claes From Roger.Riggs at Oracle.com Thu Dec 1 16:13:12 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 1 Dec 2016 11:13:12 -0500 Subject: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection In-Reply-To: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> References: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> Message-ID: <5ad67819-a7bc-a594-7b5c-fda27876e95a@Oracle.com> Looks fine, very straight-forward. On 12/1/2016 10:33 AM, Claes Redestad wrote: > Hi, > > recent changes to FilePermissionCollection to use a lambda in place of > an explicit > BiFunction cause a quite noticeable startup and footprint regression > on small > applications due to a bootstrap dependency. Therefore I'd like to > revert this > particular change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170602 > Webrev: http://cr.openjdk.java.net/~redestad/8170602/webrev.01/ > > Thanks! > > /Claes From mandy.chung at oracle.com Thu Dec 1 16:57:28 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Dec 2016 08:57:28 -0800 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: <617953b0-2398-c931-931e-3370e96f2b07@oracle.com> References: <617953b0-2398-c931-931e-3370e96f2b07@oracle.com> Message-ID: Hi Claes, What is the performance difference if this method calls getSimpleBinaryName? Your patch exposes the implementation details and sensitive to the change there, if any. Mandy > On Dec 1, 2016, at 5:38 AM, Claes Redestad wrote: > > Hi, > > due to recent interest to optimize Class.isAnonymousClass[1] I took > a look at the implementation and found that we can further improve > performance of this method, especially when asking non-anonymous > classes[2]. > > As such calls are a common occurrence during startup and bootstrap > of lambdas this actually appears rather worthwhile: > > Webrev: http://cr.openjdk.java.net/~redestad/8170595/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8170595 > > Thanks! > > /Claes > > [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045116.html > [2] > Benchmark Mode Cnt Score Error Units > Clazz.isAnonymousClass_Anon avgt 50 200.900 ? 15.503 ns/op > Clazz.isAnonymousClass_Regular avgt 50 136.896 ? 9.605 ns/op > > Clazz.isAnonymousClass_Anon avgt 50 186.564 ? 12.219 ns/op > Clazz.isAnonymousClass_Regular avgt 50 33.878 ? 1.524 ns/op > > See bug for benchmark source From huizhe.wang at oracle.com Thu Dec 1 17:01:16 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 01 Dec 2016 09:01:16 -0800 Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192 In-Reply-To: <48BEEEAD-3E5B-45A7-B551-B7C3938AADBF@oracle.com> References: <583F42D0.2000703@oracle.com> <48BEEEAD-3E5B-45A7-B551-B7C3938AADBF@oracle.com> Message-ID: <5840575C.6000101@oracle.com> Thanks Lance! I've re-created the webrev with the one-line change: webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ I'll use https://bugs.openjdk.java.net/browse/JDK-8170556 for the cleanup, will expand to cover the stream package, but leave the impl package for a later time. Thanks, Joe On 11/30/16, 5:07 PM, Lance Andersen wrote: > Hi Joe > > Looks OK. > > I might suggest a separate issue for the cleanup and just have this > bug address the bug fix > > Best > Lance >> On Nov 30, 2016, at 4:21 PM, Joe Wang > > wrote: >> >> Hi, >> >> Please review an one-line fix and a bunch of cleanups. >> >> The reported issue was caused by a missed setting when the >> XMLStreamReader initializes the XML 1.1 scanner, so while the >> changeset involved 350 lines, the fix is really just the following: >> >> XMLStreamReaderImpl.java: >> @@ -605,11 +604,12 @@ >> ... >> + fEntityScanner.registerListener(fScanner); >> >> >> All other changes are cleanups, warnings. And BTW, warnings in the >> jaxp repo have come down from 5230 in 2015 to 3265, a result of a bit >> of cleanups here and there when we touch those classes. Still a long >> way to go, and it shows we may need to have a few dedicated patches. >> >> JBS: https://bugs.openjdk.java.net/browse/JDK-8167340 >> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ >> >> >> Thanks, >> Joe > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From christoph.dreis at freenet.de Thu Dec 1 16:58:39 2016 From: christoph.dreis at freenet.de (christoph.dreis at freenet.de) Date: Thu, 01 Dec 2016 17:58:39 +0100 Subject: RFR: 8170595: Optimize Class.isAnonymousClass Message-ID: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> Hey, since I created the original mail I hope you don't mind my interest/comments. What about using !isArray() && isLocalOrAnonymousClass() &&getSimpleBinaryName0() == null;to increase readability a bit? Thanks for investigating my initial interest on that level! Cheers, Christoph > Hi, > > due to recent interest to optimize Class.isAnonymousClass[1] I took > a look at the implementation and found that we can further improve > performance of this method, especially when asking non-anonymous > classes[2]. > > As such calls are a common occurrence during startup and bootstrap > of lambdas this actually appears rather worthwhile: > > Webrev: http://cr.openjdk.java.net/~redestad/8170595/webrev.01/ > Bug: https://bugs.openjdk.java.net/browse/JDK-8170595 > > Thanks! > > /Claes > > [1] >http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045116.html > [2] > Benchmark Mode Cnt Score Error Units > Clazz.isAnonymousClass_Anon avgt 50 200.900 ? 15.503 ns/op > Clazz.isAnonymousClass_Regular avgt 50 136.896 ? 9.605 ns/op > > Clazz.isAnonymousClass_Anon avgt 50 186.564 ? 12.219 ns/op > Clazz.isAnonymousClass_Regular avgt 50 33.878 ? 1.524 ns/op > > See bug for benchmark source > > > -----Urspr?ngliche Nachricht Ende----- --- Die Bundesliga hat begonnen! Alle Tore, alle Ergebnisse, alle News: Pocket Liga jetzt im https://app.adjust.com/dpynzd oder https://app.adjust.com/dpynzd herunterladen - kostenlos! From claes.redestad at oracle.com Thu Dec 1 17:04:19 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 18:04:19 +0100 Subject: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection In-Reply-To: <5ad67819-a7bc-a594-7b5c-fda27876e95a@Oracle.com> References: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> <5ad67819-a7bc-a594-7b5c-fda27876e95a@Oracle.com> Message-ID: Roger, thanks for reviewing! /Claes On 2016-12-01 17:13, Roger Riggs wrote: > Looks fine, very straight-forward. > > On 12/1/2016 10:33 AM, Claes Redestad wrote: >> Hi, >> >> recent changes to FilePermissionCollection to use a lambda in place >> of an explicit >> BiFunction cause a quite noticeable startup and footprint regression >> on small >> applications due to a bootstrap dependency. Therefore I'd like to >> revert this >> particular change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170602 >> Webrev: http://cr.openjdk.java.net/~redestad/8170602/webrev.01/ >> >> Thanks! >> >> /Claes > From Alan.Bateman at oracle.com Thu Dec 1 17:10:01 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 1 Dec 2016 17:10:01 +0000 Subject: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection In-Reply-To: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> References: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> Message-ID: <8b7a23d8-3477-a935-a3db-737d7da2cbce@oracle.com> On 01/12/2016 15:33, Claes Redestad wrote: > Hi, > > recent changes to FilePermissionCollection to use a lambda in place of > an explicit > BiFunction cause a quite noticeable startup and footprint regression > on small > applications due to a bootstrap dependency. Therefore I'd like to > revert this > particular change. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170602 > Webrev: http://cr.openjdk.java.net/~redestad/8170602/webrev.01/ Looks okay but I hope we don't have to do too many of these. -Alan From claes.redestad at oracle.com Thu Dec 1 17:19:31 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 18:19:31 +0100 Subject: RFR: 8170602: Startup regression due to introduction of lambda in java.io.FilePermissionCollection In-Reply-To: <8b7a23d8-3477-a935-a3db-737d7da2cbce@oracle.com> References: <76d19fa0-e7d5-e965-7dfb-359a64139ae2@oracle.com> <8b7a23d8-3477-a935-a3db-737d7da2cbce@oracle.com> Message-ID: <901edb87-42ed-9ba1-4a72-144732e91fe8@oracle.com> On 2016-12-01 18:10, Alan Bateman wrote: > On 01/12/2016 15:33, Claes Redestad wrote: > >> Hi, >> >> recent changes to FilePermissionCollection to use a lambda in place >> of an explicit >> BiFunction cause a quite noticeable startup and footprint regression >> on small >> applications due to a bootstrap dependency. Therefore I'd like to >> revert this >> particular change. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170602 >> Webrev: http://cr.openjdk.java.net/~redestad/8170602/webrev.01/ > Looks okay but I hope we don't have to do too many of these. Thanks for the review, Alan. Hope so too. We've done a lot to improve java.lang.invoke and lambda bootstrap in 9, but there are cases like this that are still too costly to have on the startup path. A few more improvements to the --generate-jli-classes jlink plugin might change things...? :-) Thanks! /Claes > > -Alan From huizhe.wang at oracle.com Thu Dec 1 17:25:02 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 01 Dec 2016 09:25:02 -0800 Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192 In-Reply-To: <7cfdb1af-3773-5672-baca-cf3c9b1e0ef2@oracle.com> References: <583F42D0.2000703@oracle.com> <6827111172944d99b699601a63ed1808@DEWDFE13DE03.global.corp.sap> <7cfdb1af-3773-5672-baca-cf3c9b1e0ef2@oracle.com> Message-ID: <58405CEE.1040803@oracle.com> Thanks Christoph, Daniel! I've updated the test, removing the comments. As for 80 chars line limit, or slightly longer than that is fine with me. Given our codebase, it would be an enormous undertaking. I'm therefore fine with taking care of only the extremely long ones or any that impedes the reviews, that is, side-by-side view. Best, Joe On 12/1/16, 2:25 AM, Daniel Fuchs wrote: > Hi Joe, > > I agree with Christoph's comments below. > > +1 > > best regards, > > -- daniel > > On 01/12/16 07:40, Langer, Christoph wrote: >> Hi Joe, >> >> to me this looks good. >> >> Did you already remove the cleanups from >> http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ ? I can't see >> a lot of them any more... >> >> A few minor points: >> >> It seems you still have left some debugging code in >> test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/StreamReaderTest.java: >> >> 59 while (xmlStreamReader.hasNext()) { >> 60 int event = xmlStreamReader.next(); >> 61 if (event == XMLStreamConstants.START_ELEMENT) { >> 62 if >> (xmlStreamReader.getLocalName().equals("body"))// && bMessage) >> >> -> remove the && bMessage) >> >> 63 { >> 64 String elementText = >> xmlStreamReader.getElementText(); >> 65 //System.out.println("elementText=" + >> elementText + "EndOfElementText"); >> >> -> the commented System.out.println statement should be removed at >> all, I suggest >> >> 66 // fail if elementText contains "" >> 67 >> Assert.assertTrue(!elementText.contains(""), "Fail: >> elementText contains "); >> 68 } >> 69 } >> 70 } >> >> Other than that I'm wondering if the 80 chars line limit shall be >> held which is not completely true in StreamReaderTest.java. But I >> know how difficult that is, while keeping the code still readable. >> Especially with the long speaking Class and method names ;-) >> >> Best regards >> Christoph >> >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] >>> On Behalf >>> Of Joe Wang >>> Sent: Mittwoch, 30. November 2016 22:21 >>> To: core-libs-dev at openjdk.java.net >>> Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return >>> corrupt >>> content when size of element is > 8192 >>> >>> Hi, >>> >>> Please review an one-line fix and a bunch of cleanups. >>> >>> The reported issue was caused by a missed setting when the >>> XMLStreamReader initializes the XML 1.1 scanner, so while the changeset >>> involved 350 lines, the fix is really just the following: >>> >>> XMLStreamReaderImpl.java: >>> @@ -605,11 +604,12 @@ >>> ... >>> + fEntityScanner.registerListener(fScanner); >>> >>> >>> All other changes are cleanups, warnings. And BTW, warnings in the jaxp >>> repo have come down from 5230 in 2015 to 3265, a result of a bit of >>> cleanups here and there when we touch those classes. Still a long >>> way to >>> go, and it shows we may need to have a few dedicated patches. >>> >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8167340 >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ >>> >>> Thanks, >>> Joe > From claes.redestad at oracle.com Thu Dec 1 17:34:18 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 18:34:18 +0100 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: References: <617953b0-2398-c931-931e-3370e96f2b07@oracle.com> Message-ID: <53196beb-30c8-eee7-bb4f-59a8bda4dd1f@oracle.com> Hi, sadly, avoiding getSimpleBinaryName is where most of the gain comes from, avoiding getSimpleName only improves marginally on the baseline: Benchmark Mode Cnt Score Error Units Clazz.isAnonymousClass_Anon avgt 10 192.522 ? 33.214 ns/op Clazz.isAnonymousClass_Regular avgt 10 115.770 ? 19.953 ns/op Wrapping the checkPermission call inside getEnclosingMethod so that Reflection.getCallerClass() doesn't happening improves things a bit, but still not close: Clazz.isAnonymousClass_Anon avgt 10 187.074 ? 38.128 ns/op Clazz.isAnonymousClass_Regular avgt 10 96.196 ? 15.709 ns/op /Claes On 2016-12-01 17:57, Mandy Chung wrote: > Hi Claes, > > What is the performance difference if this method calls getSimpleBinaryName? Your patch exposes the implementation details and sensitive to the change there, if any. > > Mandy > >> On Dec 1, 2016, at 5:38 AM, Claes Redestad wrote: >> >> Hi, >> >> due to recent interest to optimize Class.isAnonymousClass[1] I took >> a look at the implementation and found that we can further improve >> performance of this method, especially when asking non-anonymous >> classes[2]. >> >> As such calls are a common occurrence during startup and bootstrap >> of lambdas this actually appears rather worthwhile: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8170595/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170595 >> >> Thanks! >> >> /Claes >> >> [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045116.html >> [2] >> Benchmark Mode Cnt Score Error Units >> Clazz.isAnonymousClass_Anon avgt 50 200.900 ? 15.503 ns/op >> Clazz.isAnonymousClass_Regular avgt 50 136.896 ? 9.605 ns/op >> >> Clazz.isAnonymousClass_Anon avgt 50 186.564 ? 12.219 ns/op >> Clazz.isAnonymousClass_Regular avgt 50 33.878 ? 1.524 ns/op >> >> See bug for benchmark source From claes.redestad at oracle.com Thu Dec 1 17:52:40 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 18:52:40 +0100 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> References: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> Message-ID: Hi, good suggestion, this tidies up a bit while not affecting score: http://cr.openjdk.java.net/~redestad/8170595/webrev.02 Thanks! /Claes On 2016-12-01 17:58, christoph.dreis at freenet.de wrote: > Hey, > > since I created the original mail I hope you don't mind my interest/comments. What about using > !isArray() && isLocalOrAnonymousClass() &&getSimpleBinaryName0() == null;to increase readability a bit? > > Thanks for investigating my initial interest on that level! > > Cheers, > Christoph > >> Hi, >> >> due to recent interest to optimize Class.isAnonymousClass[1] I took >> a look at the implementation and found that we can further improve >> performance of this method, especially when asking non-anonymous >> classes[2]. >> >> As such calls are a common occurrence during startup and bootstrap >> of lambdas this actually appears rather worthwhile: >> >> Webrev: http://cr.openjdk.java.net/~redestad/8170595/webrev.01/ >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170595 >> >> Thanks! >> >> /Claes >> >> [1] >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045116.html >> [2] >> Benchmark Mode Cnt Score Error Units >> Clazz.isAnonymousClass_Anon avgt 50 200.900 ? 15.503 ns/op >> Clazz.isAnonymousClass_Regular avgt 50 136.896 ? 9.605 ns/op >> >> Clazz.isAnonymousClass_Anon avgt 50 186.564 ? 12.219 ns/op >> Clazz.isAnonymousClass_Regular avgt 50 33.878 ? 1.524 ns/op >> >> See bug for benchmark source >> >> >> -----Urspr?ngliche Nachricht Ende----- > > > > --- > Die Bundesliga hat begonnen! Alle Tore, alle Ergebnisse, alle News: Pocket Liga jetzt im https://app.adjust.com/dpynzd oder https://app.adjust.com/dpynzd herunterladen - kostenlos! > From mandy.chung at oracle.com Thu Dec 1 18:21:49 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Dec 2016 10:21:49 -0800 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: References: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> Message-ID: > On Dec 1, 2016, at 9:52 AM, Claes Redestad wrote: > > Hi, > > good suggestion, this tidies up a bit while not affecting score: > > http://cr.openjdk.java.net/~redestad/8170595/webrev.02 I like this better. It may be useful to add a private isTopLevel Class() for getSimpleBinaryName to call that will benefit getSimpleName and isMemberClass? Mandy From xueming.shen at oracle.com Thu Dec 1 19:17:32 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 01 Dec 2016 11:17:32 -0800 Subject: RFR 8170155: StringBuffer and StringBuilder stream methods are not late-binding In-Reply-To: <4504A2AF-A44C-4853-8308-6FB52060FBD7@oracle.com> References: <58362CB0.6050109@oracle.com> <583816AA.6080101@oracle.com> <4504A2AF-A44C-4853-8308-6FB52060FBD7@oracle.com> Message-ID: <5840774C.6070008@oracle.com> On 11/28/2016 11:27 AM, Paul Sandoz wrote: >> On 25 Nov 2016, at 02:47, Tobias Hartmann wrote: >> >>> I'm not sure if it is still desired to do the same boundary check in case of LATIN1 >>> for the benefit of consistency. Assume there might be concurrent access/operation >>> between val = this.value and count = this.count; (for StringBuilder) for example, >>> the this.value got doubled and the this.count got increased. One will end up with >>> StringIndexOutOfBoundsException() from checkOffset, but the other will be ioobe >>> from vm? >> You mean when hitting a check in an intrinsic compared to when hitting a check in the Java wrapper? >> > Not quite. There is a spliterator implementation for each coder, in the case of the LATIN1 coder there are no associated intrinsics. I think it?s ok just to perform the explicit bounds check for the UTF16 coder, since for the LATIN1 bounds checks will be performed by baloads. > > However, i think there is bug. The coder could change from LATIN1 to UTF16, while holding a reference to a byte[] value as LATIN1. > > For StringBuilder i could fix that by atomically reading the value/count/coder, but there is still an issue with StringBuffer. Thus, in the UTF16 coder spliterator we need to perform the explicit bounds before *every* StringUTF16.getChar(). > > Webrev updated: > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/ > > Paul. > Hi Paul, Seems like we do have a bug here. But I think to use "charAt()" might not be the desired/correct approach here? For StringBuffer, since we have to guarantee the correctness in concurrent use scenario, I would assume we need a synchronized version of getSupplier(...) to return a late binding and thread-safe Supplier in StringBuffer, similar to "getBytes(...)" (we have a un-synced version of getBytes() in AbstractStringBuilder and a synced version at the bottom of the StringBuffer.java). This should be for the latin1 case as well. For StringBuilder, since the only concern is the bounds check, I think the existing checkOffset(...) should be good enough, even in case the coder changes from latin1 to utf16, as the checkOffset(...) checks the "count" against "val.length >> coder" on the local copy, the getChar() access after that should be safe (though might not be correct, if it's a utf16 coder on a latin1 byte[]). Sherman >> Actually, bound checks should always be done in the Java wrapper method that calls the (unchecked) intrinsic. In general, the unchecked intrinsic should not be called directly. StringUTF16.putChar/getChar() is an exception because there are places where we we need to omit the check for performance reasons. >> >> I'm planning to revisit this with JDK-8156534 in JDK 10. >> >> Best regards, >> Tobias >> >>> Sherman >>> >>> >>>> If so i propose the following to make this clearer: >>>> >>>> return StreamSupport.intStream( >>>> () -> { >>>> byte[] val = this.value; int count = this.count; >>>> if (coder == LATIN1) { >>>> return new StringLatin1.CharsSpliterator(val, 0, count, 0); >>>> } else { >>>> // Perform an explicit bounds check since HotSpot >>>> // intrinsics to access UTF-16 characters in the byte[] >>>> // array will not perform bounds checks >>>> checkOffset(count, val.length>> coder); >>>> return new StringUTF16.CharsSpliterator(val, 0, count, 0); >>>> } >>>> }, >>>> Spliterator.ORDERED | Spliterator.SIZED | Spliterator.SUBSIZED, >>>> false); >>>> >>>> Paul. From mandy.chung at oracle.com Thu Dec 1 19:58:18 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Dec 2016 11:58:18 -0800 Subject: RFR JDK-8167328: jar -d m.jar hangs In-Reply-To: <583F735E.6030409@oracle.com> References: <583F735E.6030409@oracle.com> Message-ID: <7AA6CCDE-1FA5-4AAF-83AA-C73C73D1E0EC@oracle.com> > On Nov 30, 2016, at 4:48 PM, Xueming Shen wrote: > > Hi, > > Please help review the change for #8167328 > > issue: https://bugs.openjdk.java.net/browse/JDK-8167328 > webrev: http://cr.openjdk.java.net/~sherman/8167328 > > It appears the desired behavior is to throw the error + help msg if the > option "--print-module-descriptor"/ "-d" is specified with some extra > file names. This looks good. It may be useful to include the arguments in the error message: 48 '-d, --print-module-descriptor' option requires no input files to be specified! Mandy From paul.sandoz at oracle.com Thu Dec 1 20:05:34 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 1 Dec 2016 12:05:34 -0800 Subject: RFR 8170155: StringBuffer and StringBuilder stream methods are not late-binding In-Reply-To: <5840774C.6070008@oracle.com> References: <58362CB0.6050109@oracle.com> <583816AA.6080101@oracle.com> <4504A2AF-A44C-4853-8308-6FB52060FBD7@oracle.com> <5840774C.6070008@oracle.com> Message-ID: <1D52867E-BBE3-4B36-A05B-87D8579D3D0B@oracle.com> > On 1 Dec 2016, at 11:17, Xueming Shen wrote: > > On 11/28/2016 11:27 AM, Paul Sandoz wrote: >>> On 25 Nov 2016, at 02:47, Tobias Hartmann wrote: >>> >>>> I'm not sure if it is still desired to do the same boundary check in case of LATIN1 >>>> for the benefit of consistency. Assume there might be concurrent access/operation >>>> between val = this.value and count = this.count; (for StringBuilder) for example, >>>> the this.value got doubled and the this.count got increased. One will end up with >>>> StringIndexOutOfBoundsException() from checkOffset, but the other will be ioobe >>>> from vm? >>> You mean when hitting a check in an intrinsic compared to when hitting a check in the Java wrapper? >>> >> Not quite. There is a spliterator implementation for each coder, in the case of the LATIN1 coder there are no associated intrinsics. I think it?s ok just to perform the explicit bounds check for the UTF16 coder, since for the LATIN1 bounds checks will be performed by baloads. >> >> However, i think there is bug. The coder could change from LATIN1 to UTF16, while holding a reference to a byte[] value as LATIN1. >> >> For StringBuilder i could fix that by atomically reading the value/count/coder, but there is still an issue with StringBuffer. Thus, in the UTF16 coder spliterator we need to perform the explicit bounds before *every* StringUTF16.getChar(). >> >> Webrev updated: >> >> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/ >> >> Paul. >> > > Hi Paul, > > Seems like we do have a bug here. But I think to use "charAt()" might not be the > desired/correct approach here? > I think the patch is correct for both StringBuffer and StringBuilder. It is specified that buffer must remain constant during execution of the stream terminal operation otherwise the results are undefined. Such an undefined result might be the throwing of an IndexOutOfBounds. > For StringBuffer, since we have to guarantee the correctness in concurrent use scenario, > I would assume we need a synchronized version of getSupplier(...) to return a late binding > and thread-safe Supplier in StringBuffer, similar to "getBytes(...)" (we have a un-synced > version of getBytes() in AbstractStringBuilder and a synced version at the bottom of the > StringBuffer.java). This should be for the latin1 case as well. > I did ponder that, and moving the stream returning methods into the concrete builder classes. I opted for the sneakier approach :-) what do you prefer? > For StringBuilder, since the only concern is the bounds check, I think the existing > checkOffset(...) should be good enough, even in case the coder changes from latin1 > to utf16, as the checkOffset(...) checks the "count" against "val.length >> coder" on > the local copy, the getChar() access after that should be safe (though might not be > correct, if it's a utf16 coder on a latin1 byte[]). > Yes, i was being very conservative (I mistakenly thought the original code read the coder field twice). If we go with the single wider bounds check i think we should place it in the a root spliterator constructor if possible. Paul. From xueming.shen at oracle.com Thu Dec 1 20:48:17 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 01 Dec 2016 12:48:17 -0800 Subject: RFR 8170155: StringBuffer and StringBuilder stream methods are not late-binding In-Reply-To: <1D52867E-BBE3-4B36-A05B-87D8579D3D0B@oracle.com> References: <58362CB0.6050109@oracle.com> <583816AA.6080101@oracle.com> <4504A2AF-A44C-4853-8308-6FB52060FBD7@oracle.com> <5840774C.6070008@oracle.com> <1D52867E-BBE3-4B36-A05B-87D8579D3D0B@oracle.com> Message-ID: <58408C91.9010003@oracle.com> On 12/01/2016 12:05 PM, Paul Sandoz wrote: >> On 1 Dec 2016, at 11:17, Xueming Shen wrote: >> >> On 11/28/2016 11:27 AM, Paul Sandoz wrote: >>>> On 25 Nov 2016, at 02:47, Tobias Hartmann wrote: >>>> >>>>> I'm not sure if it is still desired to do the same boundary check in case of LATIN1 >>>>> for the benefit of consistency. Assume there might be concurrent access/operation >>>>> between val = this.value and count = this.count; (for StringBuilder) for example, >>>>> the this.value got doubled and the this.count got increased. One will end up with >>>>> StringIndexOutOfBoundsException() from checkOffset, but the other will be ioobe >>>>> from vm? >>>> You mean when hitting a check in an intrinsic compared to when hitting a check in the Java wrapper? >>>> >>> Not quite. There is a spliterator implementation for each coder, in the case of the LATIN1 coder there are no associated intrinsics. I think it?s ok just to perform the explicit bounds check for the UTF16 coder, since for the LATIN1 bounds checks will be performed by baloads. >>> >>> However, i think there is bug. The coder could change from LATIN1 to UTF16, while holding a reference to a byte[] value as LATIN1. >>> >>> For StringBuilder i could fix that by atomically reading the value/count/coder, but there is still an issue with StringBuffer. Thus, in the UTF16 coder spliterator we need to perform the explicit bounds before *every* StringUTF16.getChar(). >>> >>> Webrev updated: >>> >>> http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8170155-string-buffer-builder-late-binding/webrev/ >>> >>> Paul. >>> >> Hi Paul, >> >> Seems like we do have a bug here. But I think to use "charAt()" might not be the >> desired/correct approach here? >> > I think the patch is correct for both StringBuffer and StringBuilder. > > It is specified that buffer must remain constant during execution of the stream terminal operation otherwise the results are undefined. Such an undefined result might be the throwing of an IndexOutOfBounds. Ok, if the spec does not require to guarantee the correctness in , then the patch is fine. It might be a small surprise for some of the StringBuffer users with the false assumption that StringBuffer is thread-safe so the returned stream is kinda thread-safe as well. I'm fine with either way you think is appropriate from "stream" point of view. Sherman > >> For StringBuffer, since we have to guarantee the correctness in concurrent use scenario, >> I would assume we need a synchronized version of getSupplier(...) to return a late binding >> and thread-safe Supplier in StringBuffer, similar to "getBytes(...)" (we have a un-synced >> version of getBytes() in AbstractStringBuilder and a synced version at the bottom of the >> StringBuffer.java). This should be for the latin1 case as well. >> > I did ponder that, and moving the stream returning methods into the concrete builder classes. I opted for the sneakier approach :-) what do you prefer? > > >> For StringBuilder, since the only concern is the bounds check, I think the existing >> checkOffset(...) should be good enough, even in case the coder changes from latin1 >> to utf16, as the checkOffset(...) checks the "count" against "val.length>> coder" on >> the local copy, the getChar() access after that should be safe (though might not be >> correct, if it's a utf16 coder on a latin1 byte[]). >> > Yes, i was being very conservative (I mistakenly thought the original code read the coder field twice). > > If we go with the single wider bounds check i think we should place it in the a root spliterator constructor if possible. > > Paul. From claes.redestad at oracle.com Thu Dec 1 21:25:25 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 1 Dec 2016 13:25:25 -0800 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: References: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> Message-ID: <58409545.4070803@oracle.com> On 12/01/2016 10:21 AM, Mandy Chung wrote: >> On Dec 1, 2016, at 9:52 AM, Claes Redestad wrote: >> >> Hi, >> >> good suggestion, this tidies up a bit while not affecting score: >> >> http://cr.openjdk.java.net/~redestad/8170595/webrev.02 > I like this better. It may be useful to add a private isTopLevel Class() for getSimpleBinaryName to call that will benefit getSimpleName and isMemberClass? Good idea, but this seems like an independent optimization we should do as a separate follow-up, no? /Claes > > Mandy From patrick at reini.net Thu Dec 1 21:58:05 2016 From: patrick at reini.net (Patrick Reinhart) Date: Thu, 1 Dec 2016 22:58:05 +0100 Subject: On what issues could I help clean up for JDK 9 Message-ID: <0B0F98E4-B3F7-48E4-B294-76BA66ACD0AB@reini.net> Hi there, I wanted to ask if there is a simple JBS query to find small clean up parts to help with? Seems to me a good starting point for some ?hacking-on-the-OpenJDK-sessions? -Patrick From xueming.shen at oracle.com Thu Dec 1 22:47:50 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 01 Dec 2016 14:47:50 -0800 Subject: RFR JDK-8167328: jar -d m.jar hangs In-Reply-To: <7AA6CCDE-1FA5-4AAF-83AA-C73C73D1E0EC@oracle.com> References: <583F735E.6030409@oracle.com> <7AA6CCDE-1FA5-4AAF-83AA-C73C73D1E0EC@oracle.com> Message-ID: <5840A896.8060009@oracle.com> Mandy, webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8167328/ Thanks, Sherman On 12/01/2016 11:58 AM, Mandy Chung wrote: >> On Nov 30, 2016, at 4:48 PM, Xueming Shen wrote: >> >> Hi, >> >> Please help review the change for #8167328 >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8167328 >> webrev: http://cr.openjdk.java.net/~sherman/8167328 >> >> It appears the desired behavior is to throw the error + help msg if the >> option "--print-module-descriptor"/ "-d" is specified with some extra >> file names. > This looks good. > > It may be useful to include the arguments in the error message: > > 48 '-d, --print-module-descriptor' option requires no input files to be specified! > > Mandy > From mandy.chung at oracle.com Thu Dec 1 23:21:51 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 1 Dec 2016 15:21:51 -0800 Subject: RFR JDK-8167328: jar -d m.jar hangs In-Reply-To: <5840A896.8060009@oracle.com> References: <583F735E.6030409@oracle.com> <7AA6CCDE-1FA5-4AAF-83AA-C73C73D1E0EC@oracle.com> <5840A896.8060009@oracle.com> Message-ID: > On Dec 1, 2016, at 2:47 PM, Xueming Shen wrote: > > Mandy, > > webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/8167328/ +1 Mandy From kumar.x.srinivasan at oracle.com Fri Dec 2 00:17:22 2016 From: kumar.x.srinivasan at oracle.com (Kumar Srinivasan) Date: Thu, 01 Dec 2016 16:17:22 -0800 Subject: RFR: 8166189: Fix for Bug 8165524 breaks AIX build In-Reply-To: References: <2ac072c0bd564ca2889e8906c7550c31@DEWDFE13DE11.global.corp.sap> <57E28D3D.5040802@oracle.com> <57EBBF9A.6010103@oracle.com> <389F5342-B5FA-4C83-A646-6703C8910416@oracle.com> <2993770b-b888-0762-cec2-0e7250a9e797@oracle.com> <583E6132.7090103@oracle.com> Message-ID: <5840BD92.7030002@oracle.com> Hi Volker, >> Hi Volker et. al., >> >> Was a bug opened to track this ? I still see these files around >> http://hg.openjdk.java.net/jdk9/dev/jdk/file/ff45c582ca8a/src/java.base/aix/native/libjli >> > Hi Kumar, > > no, as far as I know there's no bug for this issue until now. Have created a bug for you: https://bugs.openjdk.java.net/browse/JDK-8170635 > The current situation is not ideal, but it works and it doesn't impact > any other platform except AIX. Yes there are 2 or more instances of this in the JDK repo, this poses a greater problem to maintain the integrity of this function. > So there's no reason for us to address this with high priority and > surely not within the jdk9 time frame. > > I think ideally, this could be addressed the next time we see a > similar problem, otherwise it is probably always too much at the > bottom of the priority list :) It may not be high priority, but it needs to be fixed, for this reason I have created a JDK10 bug, but at the very least we need to track it. Thanks Kumar > > Thank you and best regards, > Volker > >> Would you like me to create a bug for you ? >> >> Thanks >> Kumar >> >> >> On 9/29/2016 9:59 AM, Volker Simonis wrote: >>> On Thu, Sep 29, 2016 at 5:25 PM, Erik Joelsson >>> wrote: >>>> >>>> On 2016-09-29 16:54, Alan Burlison wrote: >>>>> On 29/09/2016 08:03, Volker Simonis wrote: >>>>> >>>>>> Sorry, but that doesn't sound like a solution to me at all. I think we >>>>>> should keep the OpenJDK sources self-contained. I don't want to depend >>>>>> on yet another non-standard, third party library which doesn't even >>>>>> exist now. >>>>> >>>>> Unless I'm completely misunderstanding, that's not what is being >>>>> proposed. >>>>> What is being proposed is refactoring code that's currently duplicated >>>>> across the JVM & JDK into a common library. Such a library would be a >>>>> standard Java component, not non-standard and not third-party. I can't >>>>> see >>>>> what the problem is, to be honest. >>>>> >>>> Volker's comment above was directed at the suggestion of taking the >>>> problematic AIX specific code out of the OpenJDK repositories and create >>>> a >>>> separate library with a separate lifecycle somewhere else that OpenJDK >>>> for >>>> AIX would then need to depend on. Volker was instead proposing what you >>>> describe. >>>> >>> Thanks Erik, this is exactly what I meant :) >>> >>> And I think the solution you ssketched in your previous mail is the >>> right way to address this problem. >>> >>> Regards, >>> Volker >>> >>> >>>> /Erik >> From christoph.langer at sap.com Fri Dec 2 08:15:40 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 2 Dec 2016 08:15:40 +0000 Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192 In-Reply-To: <58405CEE.1040803@oracle.com> References: <583F42D0.2000703@oracle.com> <6827111172944d99b699601a63ed1808@DEWDFE13DE03.global.corp.sap> <7cfdb1af-3773-5672-baca-cf3c9b1e0ef2@oracle.com> <58405CEE.1040803@oracle.com> Message-ID: Hi Joe, thanks, looks fine now. In test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/StreamReaderTest.java, the brace in line 63 could still move one line up, but this really is nit-picking ;-) Best regards Christoph > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Sent: Donnerstag, 1. Dezember 2016 18:25 > To: Daniel Fuchs > Cc: Langer, Christoph ; core-libs- > dev at openjdk.java.net > Subject: Re: RFR (JAXP) 8167340: XMLStreamReader.getElementText return > corrupt content when size of element is > 8192 > > Thanks Christoph, Daniel! I've updated the test, removing the comments. > > As for 80 chars line limit, or slightly longer than that is fine with > me. Given our codebase, it would be an enormous undertaking. I'm > therefore fine with taking care of only the extremely long ones or any > that impedes the reviews, that is, side-by-side view. > > Best, > Joe > > On 12/1/16, 2:25 AM, Daniel Fuchs wrote: > > Hi Joe, > > > > I agree with Christoph's comments below. > > > > +1 > > > > best regards, > > > > -- daniel > > > > On 01/12/16 07:40, Langer, Christoph wrote: > >> Hi Joe, > >> > >> to me this looks good. > >> > >> Did you already remove the cleanups from > >> http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ ? I can't see > >> a lot of them any more... > >> > >> A few minor points: > >> > >> It seems you still have left some debugging code in > >> > test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/StreamReaderTest > .java: > >> > >> 59 while (xmlStreamReader.hasNext()) { > >> 60 int event = xmlStreamReader.next(); > >> 61 if (event == XMLStreamConstants.START_ELEMENT) { > >> 62 if > >> (xmlStreamReader.getLocalName().equals("body"))// && bMessage) > >> > >> -> remove the && bMessage) > >> > >> 63 { > >> 64 String elementText = > >> xmlStreamReader.getElementText(); > >> 65 //System.out.println("elementText=" + > >> elementText + "EndOfElementText"); > >> > >> -> the commented System.out.println statement should be removed at > >> all, I suggest > >> > >> 66 // fail if elementText contains "" > >> 67 > >> Assert.assertTrue(!elementText.contains(""), "Fail: > >> elementText contains "); > >> 68 } > >> 69 } > >> 70 } > >> > >> Other than that I'm wondering if the 80 chars line limit shall be > >> held which is not completely true in StreamReaderTest.java. But I > >> know how difficult that is, while keeping the code still readable. > >> Especially with the long speaking Class and method names ;-) > >> > >> Best regards > >> Christoph > >> > >> > >>> -----Original Message----- > >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] > >>> On Behalf > >>> Of Joe Wang > >>> Sent: Mittwoch, 30. November 2016 22:21 > >>> To: core-libs-dev at openjdk.java.net > >>> Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return > >>> corrupt > >>> content when size of element is > 8192 > >>> > >>> Hi, > >>> > >>> Please review an one-line fix and a bunch of cleanups. > >>> > >>> The reported issue was caused by a missed setting when the > >>> XMLStreamReader initializes the XML 1.1 scanner, so while the changeset > >>> involved 350 lines, the fix is really just the following: > >>> > >>> XMLStreamReaderImpl.java: > >>> @@ -605,11 +604,12 @@ > >>> ... > >>> + fEntityScanner.registerListener(fScanner); > >>> > >>> > >>> All other changes are cleanups, warnings. And BTW, warnings in the jaxp > >>> repo have come down from 5230 in 2015 to 3265, a result of a bit of > >>> cleanups here and there when we touch those classes. Still a long > >>> way to > >>> go, and it shows we may need to have a few dedicated patches. > >>> > >>> JBS: https://bugs.openjdk.java.net/browse/JDK-8167340 > >>> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ > >>> > >>> Thanks, > >>> Joe > > From huaming.li at oracle.com Fri Dec 2 08:25:17 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 2 Dec 2016 16:25:17 +0800 Subject: RFR of JDK-8170644: java/rmi/registry/interfaceHash/InterfaceHash.java failed intermittently with "Port already in use" Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170644 webrev: http://cr.openjdk.java.net/~mli/8170644/webrev.00/ Thank you -Hamlin From huaming.li at oracle.com Fri Dec 2 08:42:45 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 2 Dec 2016 16:42:45 +0800 Subject: RFR of JDK-8153916: com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java failed with BindException Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8153916 webrev: http://cr.openjdk.java.net/~mli/8153916/webrev.00/ Thank you -Hamlin ------------------------------------------------------------------------ diff -r 35c87712682f test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java --- a/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Fri Dec 02 10:56:46 2016 +0800 +++ b/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java Fri Dec 02 00:39:44 2016 -0800 @@ -37,7 +37,7 @@ public class ContextWithNullProperties { public static void main(String[] args) throws Exception { - Registry registry = TestLibrary.createRegistryOnUnusedPort(); + Registry registry = TestLibrary.createRegistryOnEphemeralPort(); int registryPort = TestLibrary.getRegistryPort(registry); System.out.println("Connecting to the default Registry..."); // Connect to the default Registry. From chris.hegarty at oracle.com Fri Dec 2 08:44:56 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 2 Dec 2016 08:44:56 +0000 Subject: RFR of JDK-8153916: com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java failed with BindException In-Reply-To: References: Message-ID: <36fb8337-4b5c-31b2-ddb8-4083f713af74@oracle.com> On 02/12/16 08:42, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8153916 > webrev: http://cr.openjdk.java.net/~mli/8153916/webrev.00/ Looks good. Thanks Hamlin. -Chris. > Thank you > -Hamlin > ------------------------------------------------------------------------ > diff -r 35c87712682f > test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java > > --- > a/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java > Fri Dec 02 10:56:46 2016 +0800 > +++ > b/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java > Fri Dec 02 00:39:44 2016 -0800 > @@ -37,7 +37,7 @@ > > public class ContextWithNullProperties { > public static void main(String[] args) throws Exception { > - Registry registry = TestLibrary.createRegistryOnUnusedPort(); > + Registry registry = TestLibrary.createRegistryOnEphemeralPort(); > int registryPort = TestLibrary.getRegistryPort(registry); > System.out.println("Connecting to the default Registry..."); > // Connect to the default Registry. > From huaming.li at oracle.com Fri Dec 2 09:06:42 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 2 Dec 2016 17:06:42 +0800 Subject: RFR of JDK-8080550: java/rmi/server/useCustomRef/UseCustomRef.java failed with java.net.BindException intermittently Message-ID: <4b185c71-0bd1-66cc-a050-a2c41602d0e5@oracle.com> Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8080550 webrev: http://cr.openjdk.java.net/~mli/8080550/ Thank you -Hamlin ------------------------------------------------------------------------ diff -r 99dd72e05060 test/java/rmi/server/useCustomRef/UseCustomRef.java --- a/test/java/rmi/server/useCustomRef/UseCustomRef.java Fri Dec 02 00:47:00 2016 -0800 +++ b/test/java/rmi/server/useCustomRef/UseCustomRef.java Fri Dec 02 01:05:36 2016 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -86,7 +86,7 @@ System.err.println("creating Registry..."); - registry = TestLibrary.createRegistryOnUnusedPort(); + registry = TestLibrary.createRegistryOnEphemeralPort(); int port = TestLibrary.getRegistryPort(registry); /* * create object with custom ref and bind in registry From chris.hegarty at oracle.com Fri Dec 2 09:10:18 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 2 Dec 2016 09:10:18 +0000 Subject: RFR of JDK-8080550: java/rmi/server/useCustomRef/UseCustomRef.java failed with java.net.BindException intermittently In-Reply-To: <4b185c71-0bd1-66cc-a050-a2c41602d0e5@oracle.com> References: <4b185c71-0bd1-66cc-a050-a2c41602d0e5@oracle.com> Message-ID: <3a5e8575-08c5-6983-f7fa-fb67fc1d89be@oracle.com> On 02/12/16 09:06, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8080550 > webrev: http://cr.openjdk.java.net/~mli/8080550/ Looks good Hamlin. -Chris. > Thank you > -Hamlin > > ------------------------------------------------------------------------ > diff -r 99dd72e05060 test/java/rmi/server/useCustomRef/UseCustomRef.java > --- a/test/java/rmi/server/useCustomRef/UseCustomRef.java Fri Dec 02 > 00:47:00 2016 -0800 > +++ b/test/java/rmi/server/useCustomRef/UseCustomRef.java Fri Dec 02 > 01:05:36 2016 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2012, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -86,7 +86,7 @@ > > System.err.println("creating Registry..."); > > - registry = TestLibrary.createRegistryOnUnusedPort(); > + registry = TestLibrary.createRegistryOnEphemeralPort(); > int port = TestLibrary.getRegistryPort(registry); > /* > * create object with custom ref and bind in registry > From magnus.ihse.bursie at oracle.com Fri Dec 2 09:24:28 2016 From: magnus.ihse.bursie at oracle.com (Magnus Ihse Bursie) Date: Fri, 2 Dec 2016 10:24:28 +0100 Subject: RFR: JDK-8170629 Remove code duplication in test makefiles Message-ID: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com> There is a lot of common code that has been duplicated in */test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the code in the corresponding files are identical. (The odd-man-out is langtools which is quite different.) These files should be unified to share a single code base, to facilitate further improvements to the test makefiles. The intent of this bug is a pure refactoring. The duplication should go, but all functionality should remain exactly the same. This will leave room for some future improvements to the code, but sets a clear limit for this first step. The consolidated code base thus contains a fair amount of if-blocks, but I hope to be able to address most of these later on, by adjusting the individual component to adhere more to the standard behavior. To minimize the amount of ifdefs in the shared code, I allowed for a few changes in behavior. I do not believe these will cause any changes in the real world, and to the extent that they do, they could be considered bug fixes. Behavior that have changed due to unification: * jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk. * jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists. * jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA} * hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it exists. * hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists. Bug: https://bugs.openjdk.java.net/browse/JDK-8170629 WebRev: http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01 /Magnus From huaming.li at oracle.com Fri Dec 2 09:39:44 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 2 Dec 2016 17:39:44 +0800 Subject: RFR of JDK-8078587: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java fails intermittently with Port already in use Message-ID: <6f4be13b-79be-6432-0cd9-26ef9dd5c9e2@oracle.com> Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8078587 webrev: http://cr.openjdk.java.net/~mli/8078587/webrev.00/ Thank you -Hamlin ------------------------------------------------------------------------ diff -r 08f81d321087 test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java --- a/test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java Fri Dec 02 01:11:33 2016 -0800 +++ b/test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java Fri Dec 02 01:35:59 2016 -0800 @@ -43,7 +43,6 @@ * java.rmi/sun.rmi.transport.tcp * @build TestLibrary JavaVM LeaseCheckInterval_Stub SelfTerminator * @run main/othervm LeaseCheckInterval - * @key intermittent */ import java.rmi.Remote; @@ -88,9 +87,8 @@ UnicastRemoteObject.exportObject(obj); System.err.println("exported remote object"); - int registryPort = TestLibrary.getUnusedRandomPort(); - Registry localRegistry = - LocateRegistry.createRegistry(registryPort); + Registry localRegistry = TestLibrary.createRegistryOnEphemeralPort(); + int registryPort = TestLibrary.getRegistryPort(localRegistry); System.err.println("created local registry"); localRegistry.bind(BINDING, obj); From chris.hegarty at oracle.com Fri Dec 2 09:42:55 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 2 Dec 2016 09:42:55 +0000 Subject: RFR of JDK-8078587: java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java fails intermittently with Port already in use In-Reply-To: <6f4be13b-79be-6432-0cd9-26ef9dd5c9e2@oracle.com> References: <6f4be13b-79be-6432-0cd9-26ef9dd5c9e2@oracle.com> Message-ID: <344a33d5-7ad2-02b7-7f66-477e4acf6dc9@oracle.com> On 02/12/16 09:39, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8078587 > webrev: http://cr.openjdk.java.net/~mli/8078587/webrev.00/ Reviewed. -Chris. > Thank you > -Hamlin > ------------------------------------------------------------------------ > > diff -r 08f81d321087 > test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java > > --- > a/test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java > Fri Dec 02 01:11:33 2016 -0800 > +++ > b/test/java/rmi/server/Unreferenced/leaseCheckInterval/LeaseCheckInterval.java > Fri Dec 02 01:35:59 2016 -0800 > @@ -43,7 +43,6 @@ > * java.rmi/sun.rmi.transport.tcp > * @build TestLibrary JavaVM LeaseCheckInterval_Stub SelfTerminator > * @run main/othervm LeaseCheckInterval > - * @key intermittent > */ > > import java.rmi.Remote; > @@ -88,9 +87,8 @@ > UnicastRemoteObject.exportObject(obj); > System.err.println("exported remote object"); > > - int registryPort = TestLibrary.getUnusedRandomPort(); > - Registry localRegistry = > - LocateRegistry.createRegistry(registryPort); > + Registry localRegistry = > TestLibrary.createRegistryOnEphemeralPort(); > + int registryPort = TestLibrary.getRegistryPort(localRegistry); > System.err.println("created local registry"); > > localRegistry.bind(BINDING, obj); > From chris.hegarty at oracle.com Fri Dec 2 09:52:49 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 2 Dec 2016 09:52:49 +0000 Subject: RFR: 8169495: Add a method to set an Authenticator on a HttpURLConnection. In-Reply-To: <014ecda5-f37c-7a5a-8dfc-36f924f47bd3@oracle.com> References: <014ecda5-f37c-7a5a-8dfc-36f924f47bd3@oracle.com> Message-ID: On 10/11/16 15:12, Daniel Fuchs wrote: > Hi, > > Please find below a patch for: > > https://bugs.openjdk.java.net/browse/JDK-8169495 > 8169495: Add a method to set an Authenticator on a HttpURLConnection. Thank you Daniel. This addresses a long standing request to have a per-instance Authenticator. > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8169495/webrev.00 We exchanged a few mails off-line, and I am happy with what is in the latest webrev. -Chris. > The public API changes are in java.net.HttpURLConnection and > java.net.Authenticator. For backward compatibility reason the > new HttpURLConnection::setAuthenticator method is not abstract, > but is instead implemented to throw UOE unless overridden. > > Again for compatibility reasons, if no authenticator is explicitly > supplied to the connection then the behavior is unchanged: the > default authenticator will be invoked, if needed, at the time > credentials are requested through the HTTP protocol. > > Here is the description of the new HttpURLConnection::setAuthenticator > method: > > /** > + * Supplies an {@link java.net.Authenticator Authenticator} to be used > + * when authentication is requested through the HTTP protocol for > + * this {@code HttpURLConnection}. > + * If no authenticator is supplied, the > + * {@linkplain Authenticator#setDefault(java.net.Authenticator) > default > + * authenticator} will be used. > + * > + * @implNote The default behavior of this method is to throw > + * {@link UnsupportedOperationException}. Concrete > + * implementations of {@code HttpURLConnection} > + * which support supplying an {@code Authenticator} for a > + * specific {@code HttpURLConnection} instance should > + * override this method to implement a different behavior. > + * > + * @implSpec Depending on authentication schemes, an implementation > + * may or may not need to use the provided authenticator > + * to obtain a password. For instance, an implementation > that > + * relies on third-party security libraries may still > invoke the > + * default authenticator if these libraries are configured > + * to do so. > + * Likewise, an implementation that supports transparent > + * NTLM authentication may let the system attempt > + * to connect using the system user credentials first, > + * before invoking the provided authenticator. > + *
> + * However, if an authenticator is specifically provided, > + * then the underlying connection may only be reused for > + * {@code HttpURLConnection} instances which share the same > + * {@code Authenticator} instance, and authentication > information, > + * if cached, may only be reused for an {@code > HttpURLConnection} > + * sharing that same {@code Authenticator}. > + * > + * @param auth The {@code Authenticator} that should be used by this > + * {@code HttpURLConnection}. > + * > + * @throws UnsupportedOperationException if setting an > Authenticator is > + * not supported by the underlying implementation. > + * @throws IllegalStateException if URLConnection is already > connected. > + * @throws NullPointerException if the supplied {@code auth} is > {@code null}. > + * @since 9 > + */ > + public void setAuthenticator(Authenticator auth) { > + throw new UnsupportedOperationException("Supplying an > authenticator" > + + " is not supported by " + this.getClass()); > + } > > > best regards, > > -- daniel From daniel.fuchs at oracle.com Fri Dec 2 10:03:40 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 2 Dec 2016 10:03:40 +0000 Subject: RFR of JDK-8170644: java/rmi/registry/interfaceHash/InterfaceHash.java failed intermittently with "Port already in use" In-Reply-To: References: Message-ID: <3128b589-77fd-7f06-455a-af4a38d6fd52@oracle.com> Hi Hamlin, Looks good to me! best regards, -- daniel On 02/12/16 08:25, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8170644 > webrev: http://cr.openjdk.java.net/~mli/8170644/webrev.00/ > > Thank you > -Hamlin From daniel.fuchs at oracle.com Fri Dec 2 10:08:21 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 2 Dec 2016 10:08:21 +0000 Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return corrupt content when size of element is > 8192 In-Reply-To: <58405CEE.1040803@oracle.com> References: <583F42D0.2000703@oracle.com> <6827111172944d99b699601a63ed1808@DEWDFE13DE03.global.corp.sap> <7cfdb1af-3773-5672-baca-cf3c9b1e0ef2@oracle.com> <58405CEE.1040803@oracle.com> Message-ID: <84a3801e-8935-c3ee-79e9-4824e7f127d1@oracle.com> On 01/12/16 17:25, Joe Wang wrote: > Thanks Christoph, Daniel! I've updated the test, removing the comments. > > As for 80 chars line limit, or slightly longer than that is fine with > me. Given our codebase, it would be an enormous undertaking. I'm > therefore fine with taking care of only the extremely long ones or any > that impedes the reviews, that is, side-by-side view. +1 best regards, -- daniel > > Best, > Joe > > On 12/1/16, 2:25 AM, Daniel Fuchs wrote: >> Hi Joe, >> >> I agree with Christoph's comments below. >> >> +1 >> >> best regards, >> >> -- daniel >> >> On 01/12/16 07:40, Langer, Christoph wrote: >>> Hi Joe, >>> >>> to me this looks good. >>> >>> Did you already remove the cleanups from >>> http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ ? I can't see >>> a lot of them any more... >>> >>> A few minor points: >>> >>> It seems you still have left some debugging code in >>> test/javax/xml/jaxp/unittest/stream/XMLStreamReaderTest/StreamReaderTest.java: >>> >>> >>> 59 while (xmlStreamReader.hasNext()) { >>> 60 int event = xmlStreamReader.next(); >>> 61 if (event == XMLStreamConstants.START_ELEMENT) { >>> 62 if >>> (xmlStreamReader.getLocalName().equals("body"))// && bMessage) >>> >>> -> remove the && bMessage) >>> >>> 63 { >>> 64 String elementText = >>> xmlStreamReader.getElementText(); >>> 65 //System.out.println("elementText=" + >>> elementText + "EndOfElementText"); >>> >>> -> the commented System.out.println statement should be removed at >>> all, I suggest >>> >>> 66 // fail if elementText contains "" >>> 67 >>> Assert.assertTrue(!elementText.contains(""), "Fail: >>> elementText contains "); >>> 68 } >>> 69 } >>> 70 } >>> >>> Other than that I'm wondering if the 80 chars line limit shall be >>> held which is not completely true in StreamReaderTest.java. But I >>> know how difficult that is, while keeping the code still readable. >>> Especially with the long speaking Class and method names ;-) >>> >>> Best regards >>> Christoph >>> >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] >>>> On Behalf >>>> Of Joe Wang >>>> Sent: Mittwoch, 30. November 2016 22:21 >>>> To: core-libs-dev at openjdk.java.net >>>> Subject: RFR (JAXP) 8167340: XMLStreamReader.getElementText return >>>> corrupt >>>> content when size of element is > 8192 >>>> >>>> Hi, >>>> >>>> Please review an one-line fix and a bunch of cleanups. >>>> >>>> The reported issue was caused by a missed setting when the >>>> XMLStreamReader initializes the XML 1.1 scanner, so while the changeset >>>> involved 350 lines, the fix is really just the following: >>>> >>>> XMLStreamReaderImpl.java: >>>> @@ -605,11 +604,12 @@ >>>> ... >>>> + fEntityScanner.registerListener(fScanner); >>>> >>>> >>>> All other changes are cleanups, warnings. And BTW, warnings in the jaxp >>>> repo have come down from 5230 in 2015 to 3265, a result of a bit of >>>> cleanups here and there when we touch those classes. Still a long >>>> way to >>>> go, and it shows we may need to have a few dedicated patches. >>>> >>>> JBS: https://bugs.openjdk.java.net/browse/JDK-8167340 >>>> webrevs: http://cr.openjdk.java.net/~joehw/jdk9/8167340/webrev/ >>>> >>>> Thanks, >>>> Joe >> From martijnverburg at gmail.com Fri Dec 2 10:45:55 2016 From: martijnverburg at gmail.com (Martijn Verburg) Date: Fri, 2 Dec 2016 10:45:55 +0000 Subject: On what issues could I help clean up for JDK 9 In-Reply-To: <0B0F98E4-B3F7-48E4-B294-76BA66ACD0AB@reini.net> References: <0B0F98E4-B3F7-48E4-B294-76BA66ACD0AB@reini.net> Message-ID: There's no JBS query that I know of (I think in the distant past we discussed adding a low hanging fruit 'Duke' tag?). Cheers, Martijn On 1 December 2016 at 21:58, Patrick Reinhart wrote: > Hi there, > > I wanted to ask if there is a simple JBS query to find small clean up > parts to help with? > > Seems to me a good starting point for some ?hacking-on-the-OpenJDK- > sessions? > > > -Patrick From erik.joelsson at oracle.com Fri Dec 2 11:56:58 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Fri, 2 Dec 2016 12:56:58 +0100 Subject: RFR: JDK-8170629 Remove code duplication in test makefiles In-Reply-To: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com> References: <94a50a91-f8d7-a957-5c13-8d1e75ec864e@oracle.com> Message-ID: <5d130cb7-794f-9fec-51aa-6ecd432847da@oracle.com> Looks good. /Erik On 2016-12-02 10:24, Magnus Ihse Bursie wrote: > There is a lot of common code that has been duplicated in > */test/Makefile. For jdk, hotspot, jaxp and nashorn, most of the code > in the corresponding files are identical. (The odd-man-out is > langtools which is quite different.) > > These files should be unified to share a single code base, to > facilitate further improvements to the test makefiles. > > The intent of this bug is a pure refactoring. The duplication should > go, but all functionality should remain exactly the same. This will > leave room for some future improvements to the code, but sets a clear > limit for this first step. The consolidated code base thus contains a > fair amount of if-blocks, but I hope to be able to address most of > these later on, by adjusting the individual component to adhere more > to the standard behavior. > > To minimize the amount of ifdefs in the shared code, I allowed for a > few changes in behavior. I do not believe these will cause any changes > in the real world, and to the extent that they do, they could be > considered bug fixes. > > Behavior that have changed due to unification: > * jaxp now defaults ABS_JDK_IMAGE to images/jdk instead of j2sdk. > * jaxp now sets TEST_SELECTION to $(TESTDIRS) if it exists. > * jaxp and hotspot now get additional option e:JDK8_HOME=${JT_JAVA} > * hotspot now sets JAVA_VM_ARGS to $(JPRT_PRODUCT_VM_ARGS) if it exists. > * hotspot now sets JAVA_ARGS to $(JPRT_PRODUCT_ARGS) if it exists. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170629 > WebRev: > http://cr.openjdk.java.net/~ihse/JDK-8170629-remove-test-makefile-duplication/webrev.01 > > /Magnus From patrick at reini.net Fri Dec 2 12:53:37 2016 From: patrick at reini.net (Patrick Reinhart) Date: Fri, 2 Dec 2016 13:53:37 +0100 Subject: On what issues could I help clean up for JDK 9 In-Reply-To: References: <0B0F98E4-B3F7-48E4-B294-76BA66ACD0AB@reini.net> Message-ID: What was the outcome of that discussion? I seem to miss that one. My question comes from the past presentation I gave about contributing to the OpenJDK. And one of the main things was not only to do some local hacking but instead try to solve some small issues, that else would not be fixed because of other more important things. -Patrick > Am 02.12.2016 um 11:45 schrieb Martijn Verburg : > > There's no JBS query that I know of (I think in the distant past we discussed adding a low hanging fruit 'Duke' tag?). > > Cheers, > Martijn From claes.redestad at oracle.com Fri Dec 2 13:12:15 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 2 Dec 2016 14:12:15 +0100 Subject: On what issues could I help clean up for JDK 9 In-Reply-To: <0B0F98E4-B3F7-48E4-B294-76BA66ACD0AB@reini.net> References: <0B0F98E4-B3F7-48E4-B294-76BA66ACD0AB@reini.net> Message-ID: Hi, I'd suggest start looking at requests for code cleanup, performance optimizations or similar that doesn't alter any public semantics (such as adding public APIs or subtly changing the behavior of existing ones). A few simple JBS searches lists at least some things that look tempting: "Cleanup": https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22Cleanup%22%20%26%26%20status%20in%20(Open)%20and%20assignee%20is%20EMPTY "Optimize": https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22Cleanup%22%20%26%26%20status%20in%20(Open)%20and%20assignee%20is%20EMPTY Some, mostly hotspot engineers, use the "starter" label to mark issues thought to be good candidates for someone new to the project (this doesn't necessarily mean "easy"): https://bugs.openjdk.java.net/issues/?jql=labels%20in%20(%22starter%22)%20%26%26%20status%20in%20(Open) Hope this helps! /Claes On 2016-12-01 22:58, Patrick Reinhart wrote: > Hi there, > > I wanted to ask if there is a simple JBS query to find small clean up parts to help with? > > Seems to me a good starting point for some ?hacking-on-the-OpenJDK-sessions? > > > -Patrick From goetz.lindenmaier at sap.com Fri Dec 2 13:56:14 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 2 Dec 2016 13:56:14 +0000 Subject: potential error in fdlibm asin Message-ID: Hi, I'm looking at some strange code in the asin implementation: Basically the code in http://hg.openjdk.java.net/jdk9/dev/jdk/file/bc6c31fd98cf/src/java.base/share/native/libfdlibm/e_asin.c after line 101 is indented wrong. But I think in truth the "else" statement should be deleted. "t = x*x" is only executed if "if (ix<0x3e400000)" is wrong. If "if (ix<0x3e400000)" is true and "if(huge+x>one)" is wrong, t=0 is used for statement "p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))" resulting in p=0. In fdlibm of netlib the initialization t=0 is missing, but it has the same strange indentation. http://www.netlib.org/fdlibm/e_asin.c I found one copy of this code in the internet where the "else" is removed, but it's not completely the same: https://github.com/jerryscript-project/jerryscript/blob/master/jerry-libm/asin.c Does anybody have the knowledge to tell me what's wrong? Does anybody know how to contribute a fix to netlib fdlibm? Thanks for your help, Goetz. From goetz.lindenmaier at sap.com Fri Dec 2 14:24:04 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 2 Dec 2016 14:24:04 +0000 Subject: potential error in fdlibm asin Message-ID: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> [resent after subscribing core-libs-dev] Hi, I'm looking at some strange code in the asin implementation: Basically the code in http://hg.openjdk.java.net/jdk9/dev/jdk/file/bc6c31fd98cf/src/java.base/share/native/libfdlibm/e_asin.c after line 101 is indented wrong. But I think in truth the "else" statement should be deleted. "t = x*x" is only executed if "if (ix<0x3e400000)" is wrong. If "if (ix<0x3e400000)" is true and "if(huge+x>one)" is wrong, t=0 is used for statement "p = t*(pS0+t*(pS1+t*(pS2+t*(pS3+t*(pS4+t*pS5))))" resulting in p=0. In fdlibm of netlib the initialization t=0 is missing, but it has the same strange indentation. http://www.netlib.org/fdlibm/e_asin.c I found one copy of this code in the internet where the "else" is removed, but it's not completely the same: https://github.com/jerryscript-project/jerryscript/blob/master/jerry-libm/asin.c Does anybody have the knowledge to tell me what's wrong? Does anybody know how to contribute a fix to netlib fdlibm? Thanks for your help, Goetz. From claes.redestad at oracle.com Fri Dec 2 14:29:04 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 2 Dec 2016 15:29:04 +0100 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: <58409545.4070803@oracle.com> References: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> <58409545.4070803@oracle.com> Message-ID: <3ebaac19-48dd-9292-f5f5-8e6d822e9d38@oracle.com> Hi, On 2016-12-01 22:25, Claes Redestad wrote: > On 12/01/2016 10:21 AM, Mandy Chung wrote: >>> On Dec 1, 2016, at 9:52 AM, Claes Redestad >>> wrote: >>> >>> Hi, >>> >>> good suggestion, this tidies up a bit while not affecting score: >>> >>> http://cr.openjdk.java.net/~redestad/8170595/webrev.02 >> I like this better. It may be useful to add a private isTopLevel >> Class() for getSimpleBinaryName to call that will benefit >> getSimpleName and isMemberClass? > > Good idea, but this seems like an independent optimization we should > do as a separate follow-up, no? Found that both isMemberClass and isLocalClass can be optimized in a vein very similar to isAnonymousClass. isTopLevelClass helps getSimpleBinaryName a bit, and makes sense to implement for completeness. After deeper testing it's clear that one of the costlier operations in this code is getDeclaringClass0, which may spend plenty of time (~30ns/op for String.class) in the VM walking the list of inner classes to find the enclosing class - if any. A very small improvement can also be attained by restructuring code so that we don't instantiate the EnclosingMethodInfo unless it's needed, but keep the checking to keep semantically identical behavior: http://cr.openjdk.java.net/~redestad/8170595/webrev.03/ This brings significant improvements to some variants: Baseline: Benchmark Mode Cnt Score Error Units Clazz.isAnonymousClass_Anon avgt 25 211.010 ? 22.974 ns/op Clazz.isAnonymousClass_Regular avgt 25 132.198 ? 23.817 ns/op Clazz.isMemberClass_Anon avgt 25 336.149 ? 43.215 ns/op Clazz.isMemberClass_Regular avgt 25 92.502 ? 9.804 ns/op Clazz.isLocalClass_Anon avgt 25 326.158 ? 34.051 ns/op Clazz.isLocalClass_Regular avgt 25 32.086 ? 2.750 ns/op Patch: Benchmark Mode Cnt Score Error Units Clazz.isAnonymousClass_Anon avgt 25 174.526 ? 16.292 ns/op Clazz.isAnonymousClass_Regular avgt 25 33.136 ? 2.636 ns/op Clazz.isMemberClass_Anon avgt 25 115.029 ? 9.464 ns/op Clazz.isMemberClass_Regular avgt 25 85.706 ? 3.984 ns/op Clazz.isLocalClass_Anon avgt 25 177.411 ? 22.927 ns/op Clazz.isLocalClass_Regular avgt 25 31.940 ? 2.346 ns/op Since the changes are all similar but still not too expansive, I'm leaning towards just keeping this change in one bug. Thanks! From dalibor.topic at oracle.com Fri Dec 2 15:08:44 2016 From: dalibor.topic at oracle.com (dalibor topic) Date: Fri, 2 Dec 2016 16:08:44 +0100 Subject: On what issues could I help clean up for JDK 9 In-Reply-To: References: <0B0F98E4-B3F7-48E4-B294-76BA66ACD0AB@reini.net> Message-ID: <9a639b82-d066-36d1-08dc-abf10cc0085d@oracle.com> Community-wide 'starter issues' are a better idea in theory, then they are in practice. Typically the theory behind them is to mark some low priority issues for someone else to fix. But in practice, not all low priority fixes are welcome at all times. See http://mail.openjdk.java.net/pipermail/adoption-discuss/2016-August/001422.html for a longer explanation why that's the case. In practice, it's a better idea to focus new contributors' attention not on what they can do for the large projects with schedules, processes and all that good, complicated stuff that enables releases to happen, like JDK 9 or JDK 8 Updates, but on what they can do in the projects that are in a more exploratory phase, such as Valhalla. Beside exploration of new ideas being more fun for new contributors, they are also often eager for the kind of feedback on the new ideas and designs, that comes from playing with the new toys and often enough, breaking them in interesting ways. cheers, dalibor topic On 02.12.2016 13:53, Patrick Reinhart wrote: > What was the outcome of that discussion? > > I seem to miss that one. My question comes from the past presentation I gave about contributing to the OpenJDK. And one of the main things was not only to do some local hacking but instead try to solve some small issues, that else would not be fixed because of other more important things. > > -Patrick > >> Am 02.12.2016 um 11:45 schrieb Martijn Verburg : >> >> There's no JBS query that I know of (I think in the distant past we discussed adding a low hanging fruit 'Duke' tag?). >> >> Cheers, >> Martijn > -- Dalibor Topic | Principal Product Manager Phone: +494089091214 | Mobile: +491737185961 ORACLE Deutschland B.V. & Co. KG | K?hneh?fe 5 | 22761 Hamburg ORACLE Deutschland B.V. & Co. KG Hauptverwaltung: Riesstr. 25, D-80992 M?nchen Registergericht: Amtsgericht M?nchen, HRA 95603 Komplement?rin: ORACLE Deutschland Verwaltung B.V. Hertogswetering 163/167, 3543 AS Utrecht, Niederlande Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697 Gesch?ftsf?hrer: Alexander van der Ven, Jan Schultheiss, Val Maher Oracle is committed to developing practices and products that help protect the environment From Roger.Riggs at Oracle.com Fri Dec 2 15:35:26 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 2 Dec 2016 10:35:26 -0500 Subject: RFR: JDK-8075577: java.time does not support HOST provider In-Reply-To: References: <59be845e-7afa-45c7-a7b1-6fe6e01c4edc@oracle.com> <2ee441e3-eda4-fd36-171c-8ebdf1d6c65c@Oracle.com> Message-ID: Hi Rachna, Ok, looks fine. Thanks, Roger On 12/1/2016 8:20 AM, Rachna Goel wrote: > > Hi Roger, > > Thanks for the review. Updated patch is : > http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.02/ > > Please find some of my comments inlined. > > > On 30/11/16 10:17 PM, Roger Riggs wrote: >> Hi Rachna, >> >> macosx//HostLocaleProviderAdapterImpl.java: >> >> - line 172-177, might be a good place to use the new >> ConcurrentMap.computeIfAbsent > I could have replaced those lines with : > dateFormatPatternsMap.computeIfAbsent(locale, > k -> new SoftReference<>(new > AtomicReferenceArray<>(5 * 5))); > > But, there are two check made on line no 173. (ref == null ) which > will be checked by computeIfAbsent, But about second > (dateFormatPatterns = ref.get()) == null) > will not be checked, if those lines replaced. >> >> - line 197: you could pre-size the StringBuilder since the target >> length can be estimated >> (unless they are all less than the default 16) > pre-sized it with initial " jrepattern" string. >> >> macosx && windows//HostLocaleProviderAdapterImpl.java >> - toJavaTimeDateTimePattern() - is there a way to avoid having two >> copies of this function? >> Perhaps as a static method in JavaTimeDateTimePatternImpl.java. > There seems to be no way to avoid having two copies. > Implementations of "HostLocaleProviderAdapterImpl" for different HOST > Environments are loaded at run time by HOSTLocaleProviderAdapter. > JavaTimeDateTimePatternImpl is an implementation of > "JavaTimeDateTimePatternProvider" for JRE LocaleProviderAdapter. > >> >> The noreg-hard label on issue indicates testing is difficult and >> specific to OS and host >> configuration but it also seems unusual to have this much code and >> not have a regression test. >> > I am in touch with I18n SQE on writing tests for HOST Providers. But > testing scope, Golden data are yet to be discussed. >> If Masayoshi is satisfied and you have tested it in the target >> configuration then >> perhaps it is not worthwhile to invest in a special case regression >> test. >> >> Thanks, Roger >> >> On 11/30/2016 4:39 AM, Masayoshi Okutsu wrote: >>> Looks good to me. >>> >>> Masayoshi >>> >>> >>> On 11/22/2016 6:30 PM, Rachna Goel wrote: >>>> Hi, >>>> >>>> Please review fix for JDK-8075577. >>>> >>>> Bug : https://bugs.openjdk.java.net/browse/JDK-8075577 >>>> >>>> webrev : http://cr.openjdk.java.net/~rgoel/JDK-8075577/webrev.01/ >>>> >>>> Fix is to introduce new private spi >>>> "sun.text.spi.JavaTimeDateTimePatternProvider.java" to retrieve >>>> LocaleProvider specific Date/Time Patterns for "java.time" . >>>> >>>> Thanks, >>>> Rachna >>>> >>>> >>>> >>> >> > From mandy.chung at oracle.com Fri Dec 2 17:27:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Dec 2016 09:27:37 -0800 Subject: Review Request: JDK-8170660 RMI regression test failures due to missing @build TestLibrary Message-ID: <5E90AA32-D800-4BBF-B869-9CEB44E67A61@oracle.com> @build TestLibrary in ContextWithNullProperties test was inadvertently removed from JDK-8169231 [1]. This patch puts it back. diff --git a/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java b/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java --- a/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java +++ b/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java @@ -28,6 +28,7 @@ * @modules jdk.naming.rmi/com.sun.jndi.rmi.registry java.rmi/sun.rmi.registry * java.rmi/sun.rmi.server java.rmi/sun.rmi.transport java.rmi/sun.rmi.transport.tcp * @library ../../../../../../java/rmi/testlibrary + * @build TestLibrary * @compile --add-modules jdk.naming.rmi ContextWithNullProperties.java * @run main ContextWithNullProperties */ Mandy [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7ee327a10059 From lance.andersen at oracle.com Fri Dec 2 17:28:22 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Fri, 2 Dec 2016 12:28:22 -0500 Subject: Review Request: JDK-8170660 RMI regression test failures due to missing @build TestLibrary In-Reply-To: <5E90AA32-D800-4BBF-B869-9CEB44E67A61@oracle.com> References: <5E90AA32-D800-4BBF-B869-9CEB44E67A61@oracle.com> Message-ID: <3F6B2804-8E13-453A-988C-76F82DC4E016@oracle.com> +1 > On Dec 2, 2016, at 12:27 PM, Mandy Chung wrote: > > @build TestLibrary in ContextWithNullProperties test was inadvertently removed from JDK-8169231 [1]. This patch puts it back. > > > diff --git a/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java b/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java > --- a/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java > +++ b/test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java > @@ -28,6 +28,7 @@ > * @modules jdk.naming.rmi/com.sun.jndi.rmi.registry java.rmi/sun.rmi.registry > * java.rmi/sun.rmi.server java.rmi/sun.rmi.transport java.rmi/sun.rmi.transport.tcp > * @library ../../../../../../java/rmi/testlibrary > + * @build TestLibrary > * @compile --add-modules jdk.naming.rmi ContextWithNullProperties.java > * @run main ContextWithNullProperties > */ > > Mandy > [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/rev/7ee327a10059 Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From christoph.dreis at freenet.de Fri Dec 2 17:31:29 2016 From: christoph.dreis at freenet.de (Christoph Dreis) Date: Fri, 2 Dec 2016 18:31:29 +0100 Subject: [NEW BUG]: Reduce allocations in sun.reflect.annotation.AnnotationInvocationHandler.invoke() In-Reply-To: <5fa34815-f0e9-d08b-1dce-f16794911a3a@oracle.com> References: <01a401d24984$b1fcc850$15f658f0$@freenet.de> <5fa34815-f0e9-d08b-1dce-f16794911a3a@oracle.com> Message-ID: <003201d24cc1$eafc7b60$c0f57220$@freenet.de> Hey, >>> doing a bit of digging it appears a similar improvement - along with a >>> lot of other things - was suggested and filed a few years back: >>> https://bugs.openjdk.java.net/browse/JDK-8029019 >> Really sorry for missing that! >> If https://bugs.openjdk.java.net/browse/JDK-8029019 is decided to be solved I'd like to add the following addition to that: ========= PATCH =========== # User Christoph Dreis Avoid allocations in AnnotationType constructor coming from Method.getParameterTypes() diff --git a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java --- a/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java +++ b/src/java.base/share/classes/sun/reflect/annotation/AnnotationType.java @@ -121,7 +121,7 @@ if (Modifier.isPublic(method.getModifiers()) && Modifier.isAbstract(method.getModifiers()) && !method.isSynthetic()) { - if (method.getParameterTypes().length != 0) { + if (method.getParameterCount() != 0) { throw new IllegalArgumentException(method + " has params"); } String name = method.getName(); From mandy.chung at oracle.com Fri Dec 2 17:39:47 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 2 Dec 2016 09:39:47 -0800 Subject: Review Request: JDK-8170633 backslashes in gensrc/module-info.java comments need escaping Message-ID: The build tool generating module-info.java includes the path name of the source files in the comment for diagnosis where backslash character needs escaping. This patch prints URI rather than file path. Mandy diff --git a/make/src/classes/build/tools/module/GenModuleInfoSource.java b/make/src/classes/build/tools/module/GenModuleInfoSource.java --- a/make/src/classes/build/tools/module/GenModuleInfoSource.java +++ b/make/src/classes/build/tools/module/GenModuleInfoSource.java @@ -146,9 +146,10 @@ for (String l : lines) { writer.println(l); if (l.trim().startsWith("module ")) { - writer.format(" // source file: %s%n", sourceFile); + // print URI rather than file path to avoid escape + writer.format(" // source file: %s%n", sourceFile.toUri()); for (Path file: extraFiles) { - writer.format(" // %s%n", file); + writer.format(" // %s%n", file.toUri()); } break; } From paul.sandoz at oracle.com Fri Dec 2 17:44:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 2 Dec 2016 09:44:40 -0800 Subject: Review Request: JDK-8170633 backslashes in gensrc/module-info.java comments need escaping In-Reply-To: References: Message-ID: <86070754-E17A-49A4-8B37-8AEFD88AEE6E@oracle.com> > On 2 Dec 2016, at 09:39, Mandy Chung wrote: > > The build tool generating module-info.java includes the path name of the source files in the comment for diagnosis where backslash character needs escaping. This patch prints URI rather than file path. > +1 Paul. > Mandy > > diff --git a/make/src/classes/build/tools/module/GenModuleInfoSource.java b/make/src/classes/build/tools/module/GenModuleInfoSource.java > --- a/make/src/classes/build/tools/module/GenModuleInfoSource.java > +++ b/make/src/classes/build/tools/module/GenModuleInfoSource.java > @@ -146,9 +146,10 @@ > for (String l : lines) { > writer.println(l); > if (l.trim().startsWith("module ")) { > - writer.format(" // source file: %s%n", sourceFile); > + // print URI rather than file path to avoid escape > + writer.format(" // source file: %s%n", sourceFile.toUri()); > for (Path file: extraFiles) { > - writer.format(" // %s%n", file); > + writer.format(" // %s%n", file.toUri()); > } > break; > } > From Alan.Bateman at oracle.com Fri Dec 2 18:26:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 2 Dec 2016 18:26:33 +0000 Subject: Review Request: JDK-8170633 backslashes in gensrc/module-info.java comments need escaping In-Reply-To: References: Message-ID: On 02/12/2016 17:39, Mandy Chung wrote: > The build tool generating module-info.java includes the path name of the source files in the comment for diagnosis where backslash character needs escaping. This patch prints URI rather than file path. > > Putting the URI in the comment looks fine. -Alan From bradford.wetmore at oracle.com Fri Dec 2 19:09:49 2016 From: bradford.wetmore at oracle.com (Bradford Wetmore) Date: Fri, 2 Dec 2016 11:09:49 -0800 Subject: Review Request: JDK-8170633 backslashes in, gensrc/module-info.java comments need escaping In-Reply-To: References: Message-ID: <50571abe-551a-9bd9-902a-8c3bbdc06c64@oracle.com> > The build tool generating module-info.java includes the path name of > the source files in the comment for diagnosis where backslash > character needs escaping. This patch prints URI rather than file > path. As submitter and having tested the build patch, looks good to me. Brad From ivan.gerasimov at oracle.com Sun Dec 4 12:07:17 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 4 Dec 2016 15:07:17 +0300 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char Message-ID: Hello! There are several places in JDK where the same character is appended to a StringBuilder object multiple times (usually padding). With each append there are a few routine checks performed. They could have been done only once, if we had a method for appending multiple copies at a time. A simple benchmark shows that such method may save us a few machine cycles (see the results below). In the benchmark, three approaches were compared: 0) Using the new appendN(char, int) method to append several chars at once, 1) Calling append(char) in a loop, 2) Appending a prepared-in-advance string On my machine, the new method demonstrates better or comparable performance for all sizes up to 20. In the webrev, there are two changesets included: - the new default Appendable.appendN(char, int) method, its overrides in StringBuilder/Buffer and a basic test, - several applications of the new method across JDK. Would you please help review? Comments, suggestions are welcome. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170348 WEBREV: http://cr.openjdk.java.net/~igerasim/8170348/00/webrev/ Benchmark: http://cr.openjdk.java.net/~igerasim/8170348/00/MyBenchmark.java Benchmark (size) Mode Cnt Score Error Units MyBenchmark.test_0_New 0 thrpt 70 331922128.215 ? 16399254.452 ops/s MyBenchmark.test_0_New 1 thrpt 70 209207932.893 ? 14955800.231 ops/s MyBenchmark.test_0_New 5 thrpt 70 72926671.621 ? 4841791.555 ops/s MyBenchmark.test_0_New 10 thrpt 70 67779575.053 ? 3234366.239 ops/s MyBenchmark.test_0_New 20 thrpt 70 59731629.661 ? 2769497.288 ops/s MyBenchmark.test_1_Old 0 thrpt 70 333467628.860 ? 15981678.430 ops/s MyBenchmark.test_1_Old 1 thrpt 70 156126381.967 ? 9619653.294 ops/s MyBenchmark.test_1_Old 5 thrpt 70 46550204.382 ? 2009987.637 ops/s MyBenchmark.test_1_Old 10 thrpt 70 23309297.849 ? 1268874.282 ops/s MyBenchmark.test_1_Old 20 thrpt 70 13143637.821 ? 662265.103 ops/s MyBenchmark.test_2_Solid 0 thrpt 70 138548108.540 ? 6408775.462 ops/s MyBenchmark.test_2_Solid 1 thrpt 70 63890936.132 ? 3918274.970 ops/s MyBenchmark.test_2_Solid 5 thrpt 70 65838879.075 ? 2701493.698 ops/s MyBenchmark.test_2_Solid 10 thrpt 70 65387238.993 ? 3131562.548 ops/s MyBenchmark.test_2_Solid 20 thrpt 70 57528150.828 ? 3171453.716 ops/s With kind regards, Ivan From claes.redestad at oracle.com Sun Dec 4 13:48:52 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 4 Dec 2016 05:48:52 -0800 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: References: Message-ID: <58441EC4.4090104@oracle.com> Hi Ivan, as this adds a new public API I guess it's too late for 9 at this point, but here's a few comments anyhow: - you could use Arrays.fill(byte[], int, int, byte) for LATIN-1 case in AbstractStringBuilder. Might not make it much faster (unless there are intrinsics at play, but perhaps a bit less verbose. - for a convenience API like this, I think it's slightly awkward that a negative n throws IAE since users have to think carefully about whether they need to guard the call to appendN with a range check or not. I'd find this utility more useful if it was more forgiving and allowed simplifying the caller further. Benchmark comments: - since you're reusing a StringBuilder you're effectively removing the impact of resizing the underlying buffer, which is typically a significant part of appending, so while this zooms in on the cost of actually appending to a prepared builder, it might overstate the effect. Creating new StringBuilders (of varying sizes) in a setup method outside the @Benchmark method might be more in line with typical use, in addition to what you have now (which is zooming in on the cost of appending without allocation overhead). setLength(0) could also be moved to an invocation level @Setup method) - seeing that appending a String, which uses System.arraycopy, can be slower for small strings is a bit surprising as I'd assume it'd be completely intrinsified. Is the compiled code making a JNI transition or are things not being inlined properly? - please use -tu us -bm avgt or annotate benchmarks to output scores with a reasonable number of digits. Thanks! /Claes On 12/04/2016 04:07 AM, Ivan Gerasimov wrote: > Hello! > > There are several places in JDK where the same character is appended > to a StringBuilder object multiple times (usually padding). > With each append there are a few routine checks performed. > They could have been done only once, if we had a method for appending > multiple copies at a time. > A simple benchmark shows that such method may save us a few machine > cycles (see the results below). > > In the benchmark, three approaches were compared: > 0) Using the new appendN(char, int) method to append several chars at > once, > 1) Calling append(char) in a loop, > 2) Appending a prepared-in-advance string > > On my machine, the new method demonstrates better or comparable > performance for all sizes up to 20. > > In the webrev, there are two changesets included: > - the new default Appendable.appendN(char, int) method, its overrides > in StringBuilder/Buffer and a basic test, > - several applications of the new method across JDK. > > Would you please help review? > Comments, suggestions are welcome. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170348 > WEBREV: http://cr.openjdk.java.net/~igerasim/8170348/00/webrev/ > Benchmark: > http://cr.openjdk.java.net/~igerasim/8170348/00/MyBenchmark.java > > > Benchmark (size) Mode Cnt Score Error Units > MyBenchmark.test_0_New 0 thrpt 70 331922128.215 ? > 16399254.452 ops/s > MyBenchmark.test_0_New 1 thrpt 70 209207932.893 ? > 14955800.231 ops/s > MyBenchmark.test_0_New 5 thrpt 70 72926671.621 ? > 4841791.555 ops/s > MyBenchmark.test_0_New 10 thrpt 70 67779575.053 ? > 3234366.239 ops/s > MyBenchmark.test_0_New 20 thrpt 70 59731629.661 ? > 2769497.288 ops/s > MyBenchmark.test_1_Old 0 thrpt 70 333467628.860 ? > 15981678.430 ops/s > MyBenchmark.test_1_Old 1 thrpt 70 156126381.967 ? > 9619653.294 ops/s > MyBenchmark.test_1_Old 5 thrpt 70 46550204.382 ? > 2009987.637 ops/s > MyBenchmark.test_1_Old 10 thrpt 70 23309297.849 ? > 1268874.282 ops/s > MyBenchmark.test_1_Old 20 thrpt 70 13143637.821 ? > 662265.103 ops/s > MyBenchmark.test_2_Solid 0 thrpt 70 138548108.540 ? > 6408775.462 ops/s > MyBenchmark.test_2_Solid 1 thrpt 70 63890936.132 ? > 3918274.970 ops/s > MyBenchmark.test_2_Solid 5 thrpt 70 65838879.075 ? > 2701493.698 ops/s > MyBenchmark.test_2_Solid 10 thrpt 70 65387238.993 ? > 3131562.548 ops/s > MyBenchmark.test_2_Solid 20 thrpt 70 57528150.828 ? > 3171453.716 ops/s > > > With kind regards, > Ivan > From ivan.gerasimov at oracle.com Sun Dec 4 16:42:39 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 4 Dec 2016 19:42:39 +0300 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <58441EC4.4090104@oracle.com> References: <58441EC4.4090104@oracle.com> Message-ID: <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> Thank you Claes for looking into it! On 04.12.2016 16:48, Claes Redestad wrote: > Hi Ivan, > > as this adds a new public API I guess it's too late for 9 at this > point, but here's a few > comments anyhow: > Yes, of course. If people find it useful, I would expect it to go to jdk 10. > - you could use Arrays.fill(byte[], int, int, byte) for LATIN-1 case > in AbstractStringBuilder. > Might not make it much faster (unless there are intrinsics at play, > but perhaps a bit less > verbose. > The do-while loop saves us one comparison, comparing to the loop in Arrays.fill(). I'd prefer to keep the explicit loop, as it's only three lines of code long. > - for a convenience API like this, I think it's slightly awkward that > a negative n throws IAE > since users have to think carefully about whether they need to guard > the call to appendN > with a range check or not. I'd find this utility more useful if it was > more forgiving and > allowed simplifying the caller further. > Yes, I understand your point. There are different approaches to handling arguments. E.g. for indices it might be allowed to have from > to (treat it as from == to), and from < 0. Or, like in Perl, negative index might be treated as offset from the end of a list or array. However, in Java, the tradition seems to have formed to have strong argument checks, not allowing much interpretation. For example, similarly looking Collections.nCopies(int n, T) also throws IAE for negative n. > Benchmark comments: > > - since you're reusing a StringBuilder you're effectively removing the > impact of resizing > the underlying buffer, which is typically a significant part of > appending, so while this > zooms in on the cost of actually appending to a prepared builder, it > might overstate the > effect. > It was intentional, to be honest. If appending several chars causes reallocation, then appending chars in a loop can only be slower, comparing to appendN() or append(String). I didn't want to find the sharp constant of the speedup factor, but just wanted to be sure that the increase in performance is observable. > Creating new StringBuilders (of varying sizes) in a setup method > outside the > @Benchmark method might be more in line with typical use, in addition > to what you have > now (which is zooming in on the cost of appending without allocation > overhead). > setLength(0) could also be moved to an invocation level @Setup method) > > - seeing that appending a String, which uses System.arraycopy, can be > slower for small > strings is a bit surprising as I'd assume it'd be completely > intrinsified. Is the compiled code > making a JNI transition or are things not being inlined properly? > I'm not sure exactly why appending short String is slower then filling. Might it be because the former means both reading from and writing to the memory, and the later only means writing? Anyways, I only wanted to make sure that replacing the code in BigInteger and FDBigInteger won't make things slower. > - please use -tu us -bm avgt or annotate benchmarks to output scores > with a reasonable > number of digits. > Sure. Here you go: Benchmark (size) Mode Cnt Score Error Units MyBenchmark.test_0_New 0 avgt 4 0.003 ? 0.004 us/op MyBenchmark.test_0_New 1 avgt 4 0.005 ? 0.008 us/op MyBenchmark.test_0_New 5 avgt 4 0.014 ? 0.015 us/op MyBenchmark.test_0_New 10 avgt 4 0.016 ? 0.019 us/op MyBenchmark.test_0_New 20 avgt 4 0.018 ? 0.010 us/op MyBenchmark.test_1_Old 0 avgt 4 0.003 ? 0.001 us/op MyBenchmark.test_1_Old 1 avgt 4 0.006 ? 0.004 us/op MyBenchmark.test_1_Old 5 avgt 4 0.023 ? 0.021 us/op MyBenchmark.test_1_Old 10 avgt 4 0.049 ? 0.071 us/op MyBenchmark.test_1_Old 20 avgt 4 0.089 ? 0.110 us/op MyBenchmark.test_2_Solid 0 avgt 4 0.007 ? 0.003 us/op MyBenchmark.test_2_Solid 1 avgt 4 0.018 ? 0.024 us/op MyBenchmark.test_2_Solid 5 avgt 4 0.016 ? 0.011 us/op MyBenchmark.test_2_Solid 10 avgt 4 0.017 ? 0.016 us/op MyBenchmark.test_2_Solid 20 avgt 4 0.016 ? 0.007 us/op With kind regards, Ivan > Thanks! > > /Claes > > On 12/04/2016 04:07 AM, Ivan Gerasimov wrote: >> Hello! >> >> There are several places in JDK where the same character is appended >> to a StringBuilder object multiple times (usually padding). >> With each append there are a few routine checks performed. >> They could have been done only once, if we had a method for appending >> multiple copies at a time. >> A simple benchmark shows that such method may save us a few machine >> cycles (see the results below). >> >> In the benchmark, three approaches were compared: >> 0) Using the new appendN(char, int) method to append several chars at >> once, >> 1) Calling append(char) in a loop, >> 2) Appending a prepared-in-advance string >> >> On my machine, the new method demonstrates better or comparable >> performance for all sizes up to 20. >> >> In the webrev, there are two changesets included: >> - the new default Appendable.appendN(char, int) method, its overrides >> in StringBuilder/Buffer and a basic test, >> - several applications of the new method across JDK. >> >> Would you please help review? >> Comments, suggestions are welcome. >> >> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170348 >> WEBREV: http://cr.openjdk.java.net/~igerasim/8170348/00/webrev/ >> Benchmark: >> http://cr.openjdk.java.net/~igerasim/8170348/00/MyBenchmark.java >> >> >> Benchmark (size) Mode Cnt Score Error Units >> MyBenchmark.test_0_New 0 thrpt 70 331922128.215 ? >> 16399254.452 ops/s >> MyBenchmark.test_0_New 1 thrpt 70 209207932.893 ? >> 14955800.231 ops/s >> MyBenchmark.test_0_New 5 thrpt 70 72926671.621 ? >> 4841791.555 ops/s >> MyBenchmark.test_0_New 10 thrpt 70 67779575.053 ? >> 3234366.239 ops/s >> MyBenchmark.test_0_New 20 thrpt 70 59731629.661 ? >> 2769497.288 ops/s >> MyBenchmark.test_1_Old 0 thrpt 70 333467628.860 ? >> 15981678.430 ops/s >> MyBenchmark.test_1_Old 1 thrpt 70 156126381.967 ? >> 9619653.294 ops/s >> MyBenchmark.test_1_Old 5 thrpt 70 46550204.382 ? >> 2009987.637 ops/s >> MyBenchmark.test_1_Old 10 thrpt 70 23309297.849 ? >> 1268874.282 ops/s >> MyBenchmark.test_1_Old 20 thrpt 70 13143637.821 ? >> 662265.103 ops/s >> MyBenchmark.test_2_Solid 0 thrpt 70 138548108.540 ? >> 6408775.462 ops/s >> MyBenchmark.test_2_Solid 1 thrpt 70 63890936.132 ? >> 3918274.970 ops/s >> MyBenchmark.test_2_Solid 5 thrpt 70 65838879.075 ? >> 2701493.698 ops/s >> MyBenchmark.test_2_Solid 10 thrpt 70 65387238.993 ? >> 3131562.548 ops/s >> MyBenchmark.test_2_Solid 20 thrpt 70 57528150.828 ? >> 3171453.716 ops/s >> >> >> With kind regards, >> Ivan >> > > From swpalmer at gmail.com Sun Dec 4 21:21:30 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Sun, 4 Dec 2016 16:21:30 -0500 Subject: Reducing Garbage Generated by URLClassLoader Message-ID: Excuse me if this is the wrong list for this discussion. Please direct me to the right place if this isn?t it. When doing an analysis of garbage generation in our application we discovered a significant number of redundant strings generated by the class loader. In my case there are hundreds of jars on the classpath - everything in the application is a plugin. I figured on average 10kB of useless garbage char[]s were generated per findResource call for plugin resources. This is caused mostly by the ZipFile implementation. What is the purpose of java.util.zip.ZipCoder?s byte[] getBytes(String s) method? It seems to simply be a custom implementation of string.getBytes(CharSet cs) and as such needs to first make a copy of the char[] to work on. This combined with the need to operate on byte[] path names internally in the ZipFile implementation means that URLClassLoader generates a lot of unnecessary garbage in a findResource call - proportional to the number of jars on the classpath. Since JarFile forces the ZipFile to be open with UTF-8 always, if there was some API exposed that took a byte[] for the resource name, all of that extra string copying and encoding could be hoisted out of the loop in sun.misc.URLClassPath. Would this be worth it creating an internal class for something like a ?ClasspathJarFile? to and tweaking ZipFile so the byte[] based method is protected instead of private? I also noticed that sun.net.www.ParseUtil.encodePath(String, boolean) usually had nothing useful to do but still made three copies of the string passed in anyway (two char arrays to work on, and the String returned). Cheers, Scott From claes.redestad at oracle.com Sun Dec 4 21:58:42 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Sun, 4 Dec 2016 13:58:42 -0800 Subject: Reducing Garbage Generated by URLClassLoader In-Reply-To: References: Message-ID: <58449192.7000807@oracle.com> Hi Scott, On 12/04/2016 01:21 PM, Scott Palmer wrote: > Excuse me if this is the wrong list for this discussion. Please direct me to the right place if this isn?t it. I think this is a good place based on the aspects you're addressing. > > When doing an analysis of garbage generation in our application we discovered a significant number of redundant strings generated by the class loader. In my case there are hundreds of jars on the classpath - everything in the application is a plugin. I figured on average 10kB of useless garbage char[]s were generated per findResource call for plugin resources. > > This is caused mostly by the ZipFile implementation. What is the purpose of java.util.zip.ZipCoder?s byte[] getBytes(String s) method? It seems to simply be a custom implementation of string.getBytes(CharSet cs) and as such needs to first make a copy of the char[] to work on. This combined with the need to operate on byte[] path names internally in the ZipFile implementation means that URLClassLoader generates a lot of unnecessary garbage in a findResource call - proportional to the number of jars on the classpath. > > Since JarFile forces the ZipFile to be open with UTF-8 always, if there was some API exposed that took a byte[] for the resource name, all of that extra string copying and encoding could be hoisted out of the loop in sun.misc.URLClassPath. Would this be worth it creating an internal class for something like a ?ClasspathJarFile? to and tweaking ZipFile so the byte[] based method is protected instead of private? I can't answer for ZipCoder, but there's been some recent attempts to address some of this, the latest of which was ultimately abandoned since the added complexity was deemed too high: http://mail.openjdk.java.net/pipermail/core-libs-dev/2015-June/034397.html Is there some way for you to test that patch on your application on an OpenJDK build? If it gives you more than 1-2% it might be reason to re-open. Exposing methods that take byte[]s as input is probably not a good idea, however, since it can lead to various unwanted side-effects[1] > I also noticed that sun.net.www.ParseUtil.encodePath(String, boolean) usually had nothing useful to do but still made three copies of the string passed in anyway (two char arrays to work on, and the String returned). I've seen this in some startup profiles before, and it did look like a low-hanging fruit at that time too, but I recall having issues with regressing on strings that actually needs to be encoded. Could be rather straightforward to resolve if someone has time to attempt a solution that avoids allocation when there's nothing to encode and can avoid a throughput regression when encoding *does* happen I'd be happy to review it. Thanks! /Claes [1] https://en.wikipedia.org/wiki/Time_of_check_to_time_of_use > > > > Cheers, > > Scott > From kubota.yuji at gmail.com Mon Dec 5 05:46:57 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Mon, 5 Dec 2016 14:46:57 +0900 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: References: <565EF499.6040709@oracle.com> <854411e1-660d-3d28-e948-a6df074edf93@oracle.com> Message-ID: Hi Aleksej, We await this backport for migrating our system into JDK 8. If you want some help to progress it, please let me know :) Thanks, Yuji 2016-08-04 9:35 GMT+09:00 KUBOTA Yuji : > Hi Aleksej, > > Thank you very much! > If you need some help about the patch, please mention me :) > > Thanks, > Yuji > > 2016-08-03 19:56 GMT+09:00 Aleks Efimov : >> Hi Yuji, >> >> I've created JDK8 backport [1] for this issue and will work on it in the >> upcoming months. >> >> Best Regards, >> >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8162941 >> >> >> >> On 02/08/16 08:33, KUBOTA Yuji wrote: >>> >>> Hi all, >>> >>> Could you let me know when this fix will be backport to JDK 8? >>> We need this backport to migrate our system from JDK 7 to JDK 8. >>> >>> Thanks, >>> Yuji >>> >>> 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji : >>>> >>>> Hi Miroslav, >>>> >>>> Thank you for your sponsor! : >>>> https://bugs.openjdk.java.net/browse/JDK-8146086 >>>> >>>> Can I ask the schedule when does this fix backport to JDK8 ? >>>> >>>> Thanks, >>>> Yuji >>>> >>>> 2015-12-02 22:39 GMT+09:00 Miroslav Kos : >>>>> >>>>> Hi Yuji, >>>>> thanks for the patch - it fixes the issue and looks ok to me. I'll >>>>> integrate >>>>> it to standalone JAX-WS repo and it will be integrated into openjdk >>>>> during >>>>> next syncup. >>>>> >>>>> Thanks >>>>> Miran >>>>> >>>>> >>>>> >>>>> >>>>> On 01/12/15 11:11, KUBOTA Yuji wrote: >>>>>> >>>>>> Hi Miroslav and all, >>>>>> >>>>>> Could you please review the below issue and patch? >>>>>> >>>>>> I got the advice by Alan at net-dev. So I want to ask you. >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html >>>>>> >>>>>> ---- >>>>>> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK >>>>>> community. This's second times from JavaOne14. :) >>>>>> >>>>>> We find an unexpected exception in JAX-WS, so I write a patch to fix >>>>>> it. >>>>>> We think that this issue may block the migration to JDK9 from JDK7. >>>>>> >>>>>> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the >>>>>> following test code, JDK9 (and JDK8) returns "java.net.BindException: >>>>>> Address already in use.? as the below. But JDK7 does NOT return the >>>>>> exception. >>>>>> >>>>>> - Test code for reproduce >>>>>> --- >>>>>> import javax.jws.*; >>>>>> import javax.xml.ws.*; >>>>>> >>>>>> public class WSTest{ >>>>>> >>>>>> @WebService >>>>>> public static class Method1{ >>>>>> @WebMethod >>>>>> public String getMethod1Value(){ >>>>>> return "from Method1"; >>>>>> } >>>>>> } >>>>>> >>>>>> @WebService >>>>>> public static class Method2{ >>>>>> @WebMethod >>>>>> public String getMethod2Value(){ >>>>>> return "from Method2"; >>>>>> } >>>>>> } >>>>>> >>>>>> public static void main(String[] args) throws Exception{ >>>>>> Endpoint endPoint1 = >>>>>> Endpoint.publish("http://0.0.0.0:8081/method1", >>>>>> new >>>>>> Method1()); >>>>>> Endpoint endPoint2 = >>>>>> Endpoint.publish("http://0.0.0.0:8081/method2", >>>>>> new >>>>>> Method2()); >>>>>> >>>>>> System.out.println("Sleep 3 secs..."); >>>>>> >>>>>> Thread.sleep(3000); >>>>>> >>>>>> endPoint2.stop(); >>>>>> endPoint1.stop(); >>>>>> } >>>>>> >>>>>> } >>>>>> --- >>>>>> >>>>>> - StackTrace >>>>>> --- >>>>>> Exception in thread "main" >>>>>> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime >>>>>> Error: java.net.BindException: Address already in use >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) >>>>>> at javax.xml.ws.Endpoint.publish(Endpoint.java:240) >>>>>> at wstest.WSTest.main(WSTest.java:27) >>>>>> Caused by: java.net.BindException: Address already in use >>>>>> at sun.nio.ch.Net.bind0(Native Method) >>>>>> at sun.nio.ch.Net.bind(Net.java:432) >>>>>> at sun.nio.ch.Net.bind(Net.java:424) >>>>>> at >>>>>> >>>>>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) >>>>>> at >>>>>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) >>>>>> at sun.net.httpserver.ServerImpl.(ServerImpl.java:102) >>>>>> at >>>>>> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50) >>>>>> at >>>>>> >>>>>> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) >>>>>> at >>>>>> com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) >>>>>> ... 5 more >>>>>> ----- >>>>>> >>>>>> To publishes the Endpoint, JAX-WS checks whether the HttpContext has >>>>>> been created by given address, then creates a HttpContext if do not >>>>>> exist. >>>>>> If we sets 0.0.0.0 as given address, JAX-WS checks by >>>>>> ServerSocket#getLocalSocketAddress() (server local address), so >>>>>> returns BindException when 0.0.0.0 has been blinded already. >>>>>> >>>>>> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think >>>>>> about above situation. And JAX_WS-941 does not back port to JDK7. >>>>>> >>>>>> So I write a patch which is based jdk9/dev/jaxws >>>>>> (changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941. >>>>>> >>>>>> Please review this patch :) >>>>>> >>>>>> [1]: https://java.net/jira/browse/JAX_WS-941 >>>>>> >>>>>> - Patch >>>>>> --- >>>>>> diff -r 2d84c6f4cbba >>>>>> >>>>>> >>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>> --- >>>>>> >>>>>> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>> Thu Oct 22 08:47:47 2015 -0700 >>>>>> +++ >>>>>> >>>>>> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>> Tue Oct 27 19:48:35 2015 +0900 >>>>>> @@ -38,6 +38,7 @@ >>>>>> import java.util.concurrent.ExecutorService; >>>>>> import java.util.concurrent.Executors; >>>>>> import java.util.logging.Logger; >>>>>> +import java.util.Optional; >>>>>> >>>>>> /** >>>>>> * Manages all the WebService HTTP servers created by JAXWS runtime. >>>>>> @@ -81,24 +82,38 @@ >>>>>> synchronized(servers) { >>>>>> state = servers.get(inetAddress); >>>>>> if (state == null) { >>>>>> - logger.fine("Creating new HTTP Server at >>>>>> "+inetAddress); >>>>>> - // Creates server with default socket backlog >>>>>> - server = HttpServer.create(inetAddress, 0); >>>>>> - >>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>> - String path = url.toURI().getPath(); >>>>>> - logger.fine("Creating HTTP Context at = "+path); >>>>>> - HttpContext context = server.createContext(path); >>>>>> - server.start(); >>>>>> + final int finalPortNum = port; >>>>>> + Optional stateOpt = >>>>>> + servers.values() >>>>>> + .stream() >>>>>> + .filter(s -> s.getServer() >>>>>> + .getAddress() >>>>>> + .getPort() == >>>>>> finalPortNum) >>>>>> + .findAny(); >>>>>> >>>>>> - // we have to get actual inetAddress from server, >>>>>> which can differ from the original in some cases. >>>>>> - // e.g. A port number of zero will let the system >>>>>> pick up an ephemeral port in a bind operation, >>>>>> - // or IP: 0.0.0.0 - which is used to monitor >>>>>> network traffic from any valid IP address >>>>>> - inetAddress = server.getAddress(); >>>>>> + if (inetAddress.getAddress().isAnyLocalAddress() >>>>>> && >>>>>> + stateOpt.isPresent()) { >>>>>> + state = stateOpt.get(); >>>>>> + } else { >>>>>> + logger.fine("Creating new HTTP Server at >>>>>> "+inetAddress); >>>>>> + // Creates server with default socket backlog >>>>>> + server = HttpServer.create(inetAddress, 0); >>>>>> + >>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>> + String path = url.toURI().getPath(); >>>>>> + logger.fine("Creating HTTP Context at = >>>>>> "+path); >>>>>> + HttpContext context = >>>>>> server.createContext(path); >>>>>> + server.start(); >>>>>> >>>>>> - logger.fine("HTTP server started = "+inetAddress); >>>>>> - state = new ServerState(server, path); >>>>>> - servers.put(inetAddress, state); >>>>>> - return context; >>>>>> + // we have to get actual inetAddress from >>>>>> server, which can differ from the original in some cases. >>>>>> + // e.g. A port number of zero will let the >>>>>> system pick up an ephemeral port in a bind operation, >>>>>> + // or IP: 0.0.0.0 - which is used to monitor >>>>>> network traffic from any valid IP address >>>>>> + inetAddress = server.getAddress(); >>>>>> + >>>>>> + logger.fine("HTTP server started = >>>>>> "+inetAddress); >>>>>> + state = new ServerState(server, path); >>>>>> + servers.put(inetAddress, state); >>>>>> + return context; >>>>>> + } >>>>>> } >>>>>> } >>>>>> server = state.getServer(); >>>>>> --- >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>>> >>>>> >> From xueming.shen at oracle.com Mon Dec 5 05:58:07 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Sun, 04 Dec 2016 21:58:07 -0800 Subject: Reducing Garbage Generated by URLClassLoader In-Reply-To: References: Message-ID: <584501EF.806@oracle.com> On 12/4/16, 1:21 PM, Scott Palmer wrote: > Excuse me if this is the wrong list for this discussion. Please direct me to the right place if this isn?t it. > > When doing an analysis of garbage generation in our application we discovered a significant number of redundant strings generated by the class loader. In my case there are hundreds of jars on the classpath - everything in the application is a plugin. I figured on average 10kB of useless garbage char[]s were generated per findResource call for plugin resources. > > This is caused mostly by the ZipFile implementation. What is the purpose of java.util.zip.ZipCoder?s byte[] getBytes(String s) method? It seems to simply be a custom implementation of string.getBytes(CharSet cs) and as such needs to first make a copy of the char[] to work on. The "entry name" stored in the zip/jar file is not encoded as a UTF16 char sequence but bytes in some "native" encodings, utf8 is one of these encodings the ZipFile supports. The default one for a jar file is utf8. So when you want to lookup a resource from the jar file with a name as a String object, we have to convert/encode this "name" from String into the corresponding byte[] in utf8 and do a hash table lookup to find the resource. Here are some implementation details (1) why do we need a "custom" version in ZipFile. This is because String.getBytes(cs) replaces unmappable/malformed chars with "?" silently, ZipFile API needs to throw an corresponding exception in this scenario, so we have to have a "custom" version to do it. (2) for performance reason we don't want to convert all jar entry names in all open jar file into either String or char[] in advance, they are kept as byte[] in their original form and we don't even have a single byte[] copy for each entry name, all names are kept in their original "cen" table form in byte[] and we only have a "offset" to each entry's offset. We are talking about hundreds of jars and each jar has hundreds if not thousands of entries. Arguably we can do the other way around, always convert those entry names in each open jar file to String, and then we don't have to do the String->byte[] during lookup. It's a design decision. If there is enough evidence suggests otherwise, it can be changed/doable, given we now have all the implementation at Java level in jdk9. That said, given the optimization we have done for String in jdk9, it might be worth considering to have a fast path for those ascii-only entry names (I would assume 99.9%+ of the entry names are ascii-only in real world), then it should take a simple byte[] copy to convert/encode those entry names from String to byte[]. sherman > This combined with the need to operate on byte[] path names internally in the ZipFile implementation means that URLClassLoader generates a lot of unnecessary garbage in a findResource call - proportional to the number of jars on the classpath. > > Since JarFile forces the ZipFile to be open with UTF-8 always, if there was some API exposed that took a byte[] for the resource name, all of that extra string copying and encoding could be hoisted out of the loop in sun.misc.URLClassPath. Would this be worth it creating an internal class for something like a ?ClasspathJarFile? to and tweaking ZipFile so the byte[] based method is protected instead of private? > > I also noticed that sun.net.www.ParseUtil.encodePath(String, boolean) usually had nothing useful to do but still made three copies of the string passed in anyway (two char arrays to work on, and the String returned). > > > > Cheers, > > Scott > From mkanat at google.com Mon Dec 5 06:31:25 2016 From: mkanat at google.com (Max Kanat-Alexander) Date: Mon, 5 Dec 2016 01:31:25 -0500 Subject: Reducing Garbage Generated by URLClassLoader In-Reply-To: <584501EF.806@oracle.com> References: <584501EF.806@oracle.com> Message-ID: Yeah, I have implemented a fast-path byte-only ZipCoder in a customized JDK and it makes a big difference for allocations in long classpaths. The basic code to do just that isn't very complex. I could possibly dig that up and upstream it if there's interest. My recollection is that my solution isn't the cleanest, but it doesn't regress the "needs encoding" path. It also is possible to optimize URLClassLoader itself to do a better job of caching zip entries, which significantly reduces the String allocation load if you're doing a lot of lookups on the classpath. I have also implemented something like this, but it's hard to get right and my changes aren't in a state where they could be easily upstreamed. -Max On Mon, Dec 5, 2016 at 12:58 AM, Xueming Shen wrote: > On 12/4/16, 1:21 PM, Scott Palmer wrote: > >> Excuse me if this is the wrong list for this discussion. Please direct >> me to the right place if this isn?t it. >> >> When doing an analysis of garbage generation in our application we >> discovered a significant number of redundant strings generated by the class >> loader. In my case there are hundreds of jars on the classpath - >> everything in the application is a plugin. I figured on average 10kB of >> useless garbage char[]s were generated per findResource call for plugin >> resources. >> >> This is caused mostly by the ZipFile implementation. What is the purpose >> of java.util.zip.ZipCoder?s byte[] getBytes(String s) method? It seems to >> simply be a custom implementation of string.getBytes(CharSet cs) and as >> such needs to first make a copy of the char[] to work on. >> > > The "entry name" stored in the zip/jar file is not encoded as a UTF16 char > sequence but bytes in > some "native" encodings, utf8 is one of these encodings the ZipFile > supports. The default one for > a jar file is utf8. So when you want to lookup a resource from the jar > file with a name as a String > object, we have to convert/encode this "name" from String into the > corresponding byte[] in utf8 > and do a hash table lookup to find the resource. Here are some > implementation details > > (1) why do we need a "custom" version in ZipFile. This is because > String.getBytes(cs) replaces > unmappable/malformed chars with "?" silently, ZipFile API needs to throw > an corresponding > exception in this scenario, so we have to have a "custom" version to do it. > > (2) for performance reason we don't want to convert all jar entry names in > all open jar file into > either String or char[] in advance, they are kept as byte[] in their > original form and we don't even > have a single byte[] copy for each entry name, all names are kept in their > original "cen" table form > in byte[] and we only have a "offset" to each entry's offset. We are > talking about hundreds of > jars and each jar has hundreds if not thousands of entries. Arguably we > can do the other way > around, always convert those entry names in each open jar file to String, > and then we don't have > to do the String->byte[] during lookup. It's a design decision. If there > is enough evidence > suggests otherwise, it can be changed/doable, given we now have all the > implementation at > Java level in jdk9. > > That said, given the optimization we have done for String in jdk9, it > might be worth considering > to have a fast path for those ascii-only entry names (I would assume > 99.9%+ of the entry names > are ascii-only in real world), then it should take a simple byte[] copy to > convert/encode those > entry names from String to byte[]. > > sherman > > > This combined with the need to operate on byte[] path names internally >> in the ZipFile implementation means that URLClassLoader generates a lot of >> unnecessary garbage in a findResource call - proportional to the number of >> jars on the classpath. >> >> Since JarFile forces the ZipFile to be open with UTF-8 always, if there >> was some API exposed that took a byte[] for the resource name, all of that >> extra string copying and encoding could be hoisted out of the loop in >> sun.misc.URLClassPath. Would this be worth it creating an internal class >> for something like a ?ClasspathJarFile? to and tweaking ZipFile so the >> byte[] based method is protected instead of private? >> >> I also noticed that sun.net.www.ParseUtil.encodePath(String, boolean) >> usually had nothing useful to do but still made three copies of the string >> passed in anyway (two char arrays to work on, and the String returned). >> >> >> >> Cheers, >> >> Scott >> >> > From huaming.li at oracle.com Mon Dec 5 08:12:42 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 5 Dec 2016 16:12:42 +0800 Subject: RFR of JDK-8170669: com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java fails after JDK-8153916 Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170669 webrev: http://cr.openjdk.java.net/~mli/8170669/webrev.00/ Root Cause: 2 tests impact each other. (test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java, UnbindIdempotent.java) Solution: adding othervm should resolve the issue. Thank you -Hamlin p.s. Besides of the test issue talked above, I think there is some defect in RMI API, below is the analysis. Root Cause: when calling LocateRegistry.createRegistry(port), it will check if the ObjectTable contains the same ObjectEndPoint, if it contains, "java.rmi.server.ExportException: internal error: ObjID already in use" is thrown in ObjectTable.java. 2 ObjectEndPoint objects are considered the same if both have the same id and same tranport instance. For 2 calls of LocateRegistry.createRegistry(0), they have the same id(ObjID.REGISTRY_ID) and same endpoint & transport instance, so they are considered the same and exception is thrown. ================= more detailed explanation ================= Although in LocateRegistry.createRegistry(0)->...->TCPTransport->exportObject(target)->TCPTransport.listen()->TCPEndpoint.setDefaultPort(...), it will add new endpoint instance for port 0 with a specific port number(for example, it's 9999) in localEndpoints, but it still keeps endpoint instance for port 0 in localEndpoints, and both endpoints(0, 9999) are mapped to the same epList which includes one item with port number as 9999. the transport member of previous 2 endpoint instances(0, 9999) is indeed built on port 9999, this transport listening on port 9999 is used as part of key(other part is object id) to insert into ObjectTable. so when LocateRegistry.createRegistry(0) is called second time, LocateRegistry.createRegistry(0)->...->TCPEndpoint.getLocalEndpoint(0, ...) will get the previous transport instance(listening on 9999), so finally, in LocateRegistry.createRegistry(0)->...->ObjectTable.putTarget(target), in line 183 of ObjectTable.java, objTable.containsKey(oe) will return true, then exception is thrown. ================= conclusion ================= I think this is a RMI product issue, because below code runs successfully, Registry registry1 = LocateRegistry.createRegistry(60003); Registry registry2 = LocateRegistry.createRegistry(60004); but below code will throw exception, Registry registry1 = LocateRegistry.createRegistry(0); Registry registry2 = LocateRegistry.createRegistry(0); From amy.lu at oracle.com Mon Dec 5 08:23:40 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 5 Dec 2016 16:23:40 +0800 Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64 Message-ID: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> java/io/pathNames/GeneralWin32.java When tests run concurrently (-conc:N), it?s possible that this test will walk into and does some testing on other test?s working dir, other than it?s own. Please review the patch to avoid this unexpected behavior by restricting the "checkNames" to test's own working directory. bug: https://bugs.openjdk.java.net/browse/JDK-8156595 webrev: http://cr.openjdk.java.net/~amlu/8156595/webrev.00 Thanks, Amy From aph at redhat.com Mon Dec 5 10:10:20 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Dec 2016 10:10:20 +0000 Subject: potential error in fdlibm asin In-Reply-To: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> References: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> Message-ID: <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> On 02/12/16 14:24, Lindenmaier, Goetz wrote: > > I found one copy of this code in the internet where the "else" is removed, > but it's not completely the same: > https://github.com/jerryscript-project/jerryscript/blob/master/jerry-libm/asin.c > > Does anybody have the knowledge to tell me what's wrong? > Does anybody know how to contribute a fix to netlib fdlibm? I think the only way to proceed with this is to find an input argument which is affected by this very odd code. If there is one. does it give a correct or an incorrect result? If not, we don't care and it can be tidied up later. Andrew. From martijnverburg at gmail.com Mon Dec 5 10:11:45 2016 From: martijnverburg at gmail.com (Martijn Verburg) Date: Mon, 5 Dec 2016 10:11:45 +0000 Subject: On what issues could I help clean up for JDK 9 In-Reply-To: References: <0B0F98E4-B3F7-48E4-B294-76BA66ACD0AB@reini.net> Message-ID: Thanks Claes! That's helpful, we'll pick a few of these over on adoption-discuss and come back here to start a discussion on the relevant issue(s) before we start. Cheers, Martijn On 2 December 2016 at 13:12, Claes Redestad wrote: > Hi, > > I'd suggest start looking at requests for code cleanup, performance > optimizations or similar that doesn't > alter any public semantics (such as adding public APIs or subtly changing > the behavior of existing > ones). > > A few simple JBS searches lists at least some things that look tempting: > > "Cleanup": > https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22Clea > nup%22%20%26%26%20status%20in%20(Open)%20and%20assignee%20is%20EMPTY > > "Optimize": > https://bugs.openjdk.java.net/issues/?jql=text%20~%20%22Clea > nup%22%20%26%26%20status%20in%20(Open)%20and%20assignee%20is%20EMPTY > > Some, mostly hotspot engineers, use the "starter" label to mark issues > thought to be good candidates for someone new to the project (this doesn't > necessarily > mean "easy"): > https://bugs.openjdk.java.net/issues/?jql=labels%20in%20(%22 > starter%22)%20%26%26%20status%20in%20(Open) > > Hope this helps! > > /Claes > > On 2016-12-01 22:58, Patrick Reinhart wrote: > >> Hi there, >> >> I wanted to ask if there is a simple JBS query to find small clean up >> parts to help with? >> >> Seems to me a good starting point for some ?hacking-on-the-OpenJDK-sessio >> ns? >> >> >> -Patrick >> > > From volker.simonis at gmail.com Mon Dec 5 10:30:31 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Mon, 5 Dec 2016 11:30:31 +0100 Subject: potential error in fdlibm asin In-Reply-To: <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> References: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> Message-ID: On Mon, Dec 5, 2016 at 11:10 AM, Andrew Haley wrote: > On 02/12/16 14:24, Lindenmaier, Goetz wrote: >> >> I found one copy of this code in the internet where the "else" is removed, >> but it's not completely the same: >> https://github.com/jerryscript-project/jerryscript/blob/master/jerry-libm/asin.c >> >> Does anybody have the knowledge to tell me what's wrong? >> Does anybody know how to contribute a fix to netlib fdlibm? > > I think the only way to proceed with this is to find an input argument > which is affected by this very odd code. If there is one. does it > give a correct or an incorrect result? If not, we don't care and it > can be tidied up later. What would be the ultimate reference to to compare a potentially incorrect result against if "the Java math library is defined with respect to fdlibm version 5.3" [1] ? [1] https://docs.oracle.com/javase/8/docs/api/java/lang/StrictMath.html > > Andrew. > From goetz.lindenmaier at sap.com Mon Dec 5 13:29:05 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 5 Dec 2016 13:29:05 +0000 Subject: potential error in fdlibm asin In-Reply-To: <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> References: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> Message-ID: <107d5a4228014ee981dbf44492acbf8b@DEROTE13DE08.global.corp.sap> Hi, does anybody know for which x huge+x>one does _not_hold? Where huge = 1.000e+300, one = 1.00000000000000000000e+00 |x| < 2**-27 I've no idea, but I need that to build a test case. Anyways we think t=0 is fine for |x| < 2**-27 as in that range x = asin(x) wrt. to the preciseness of double. If t = 0, p will evalutate to p=0, q to q=1 and thus x will be returned. Best regards, Goetz. > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Andrew Haley > Sent: Montag, 5. Dezember 2016 11:10 > To: core-libs-dev at openjdk.java.net > Subject: Re: potential error in fdlibm asin > > On 02/12/16 14:24, Lindenmaier, Goetz wrote: > > > > I found one copy of this code in the internet where the "else" is removed, > > but it's not completely the same: > > https://github.com/jerryscript-project/jerryscript/blob/master/jerry- > libm/asin.c > > > > Does anybody have the knowledge to tell me what's wrong? > > Does anybody know how to contribute a fix to netlib fdlibm? > > I think the only way to proceed with this is to find an input argument > which is affected by this very odd code. If there is one. does it > give a correct or an incorrect result? If not, we don't care and it > can be tidied up later. > > Andrew. From aph at redhat.com Mon Dec 5 14:15:27 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Dec 2016 14:15:27 +0000 Subject: potential error in fdlibm asin In-Reply-To: References: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> Message-ID: <25f8d042-fdd0-8fb0-0ef8-abdca0a620fa@redhat.com> On 05/12/16 10:30, Volker Simonis wrote: > On Mon, Dec 5, 2016 at 11:10 AM, Andrew Haley wrote: >> On 02/12/16 14:24, Lindenmaier, Goetz wrote: >>> >>> I found one copy of this code in the internet where the "else" is removed, >>> but it's not completely the same: >>> https://github.com/jerryscript-project/jerryscript/blob/master/jerry-libm/asin.c >>> >>> Does anybody have the knowledge to tell me what's wrong? >>> Does anybody know how to contribute a fix to netlib fdlibm? >> >> I think the only way to proceed with this is to find an input argument >> which is affected by this very odd code. If there is one. does it >> give a correct or an incorrect result? If not, we don't care and it >> can be tidied up later. > > What would be the ultimate reference to to compare a potentially > incorrect result against if "the Java math library is defined with > respect to fdlibm version 5.3" [1] ? > > [1] https://docs.oracle.com/javase/8/docs/api/java/lang/StrictMath.html The ultimate reference is hard to determine, but we need to know a value of asin which is more than a couple of ulp or so away from the correct value. Andrew. From Roger.Riggs at Oracle.com Mon Dec 5 14:31:25 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 5 Dec 2016 09:31:25 -0500 Subject: RFR of JDK-8170669: com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java fails after JDK-8153916 In-Reply-To: References: Message-ID: Hi Hamlin, The changeset looks fine (to use /othervm). Please file a new issue for your finding about createRegistry(0); I agree it is likely a product issue. Thanks, Roger On 12/5/2016 3:12 AM, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8170669 > webrev: http://cr.openjdk.java.net/~mli/8170669/webrev.00/ > > Root Cause: > 2 tests impact each other. > (test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java, > UnbindIdempotent.java) > Solution: > adding othervm should resolve the issue. > > Thank you > -Hamlin > > > p.s. Besides of the test issue talked above, I think there is some > defect in RMI API, below is the analysis. > > Root Cause: > when calling LocateRegistry.createRegistry(port), it will check if the > ObjectTable contains the same ObjectEndPoint, if it contains, > "java.rmi.server.ExportException: internal error: ObjID already in > use" is thrown in ObjectTable.java. 2 ObjectEndPoint objects are > considered the same if both have the same id and same tranport > instance. For 2 calls of LocateRegistry.createRegistry(0), they have > the same id(ObjID.REGISTRY_ID) and same endpoint & transport instance, > so they are considered the same and exception is thrown. > > ================= more detailed explanation ================= > Although in > LocateRegistry.createRegistry(0)->...->TCPTransport->exportObject(target)->TCPTransport.listen()->TCPEndpoint.setDefaultPort(...), > it will add new endpoint instance for port 0 with a specific port > number(for example, it's 9999) in localEndpoints, but it still keeps > endpoint instance for port 0 in localEndpoints, and both endpoints(0, > 9999) are mapped to the same epList which includes one item with port > number as 9999. the transport member of previous 2 endpoint > instances(0, 9999) is indeed built on port 9999, this transport > listening on port 9999 is used as part of key(other part is object id) > to insert into ObjectTable. so when LocateRegistry.createRegistry(0) > is called second time, > LocateRegistry.createRegistry(0)->...->TCPEndpoint.getLocalEndpoint(0, > ...) will get the previous transport instance(listening on 9999), so > finally, in > LocateRegistry.createRegistry(0)->...->ObjectTable.putTarget(target), > in line 183 of ObjectTable.java, objTable.containsKey(oe) will return > true, then exception is thrown. > > ================= conclusion ================= > I think this is a RMI product issue, because below code runs > successfully, > Registry registry1 = LocateRegistry.createRegistry(60003); > Registry registry2 = LocateRegistry.createRegistry(60004); > but below code will throw exception, > Registry registry1 = LocateRegistry.createRegistry(0); > Registry registry2 = LocateRegistry.createRegistry(0); > From sergei.kovalev at oracle.com Mon Dec 5 14:50:17 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 5 Dec 2016 17:50:17 +0300 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation Message-ID: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> Hi Team, Could you please review a small change for regression test? BugID: JDK-8170664 Webrev: http://cr.openjdk.java.net/~skovalev/8170664/webrev.00/ Issue: One test fails in case of usage command line option "--limit-module java.base". Summary: The test has written in assumption that JDK always has java.util.logging module on board. In reality we can limit JDK by java.base only. In this case JDK will have only SimpleConsoleLogger on board and the test failing. The fix adds a check for limited logging ability and introduce a separate branch in the test for SimpleConsoleLogger case. -- With best regards, Sergei From aph at redhat.com Mon Dec 5 14:54:26 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Dec 2016 14:54:26 +0000 Subject: potential error in fdlibm asin In-Reply-To: <107d5a4228014ee981dbf44492acbf8b@DEROTE13DE08.global.corp.sap> References: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> <107d5a4228014ee981dbf44492acbf8b@DEROTE13DE08.global.corp.sap> Message-ID: On 05/12/16 13:29, Lindenmaier, Goetz wrote: > does anybody know for which x > huge+x>one > does _not_hold? Where > huge = 1.000e+300, > one = 1.00000000000000000000e+00 > |x| < 2**-27 There is nothing. That branch is always taken; the only purpose is to try to set the inexact flag if x != 0. Andrew. From goetz.lindenmaier at sap.com Mon Dec 5 15:43:22 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 5 Dec 2016 15:43:22 +0000 Subject: potential error in fdlibm asin In-Reply-To: References: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> <107d5a4228014ee981dbf44492acbf8b@DEROTE13DE08.global.corp.sap> Message-ID: <99944ddd282348df98db2c7edbfbc83e@DEROTE13DE08.global.corp.sap> Ah, you mean it sets some status in the processor? If the if is always executed the code is all fine. I'll remove the unnecessary 'else' and add a comment 'Never reached' behind the if. Thanks for your help! Best regards, Goetz. > -----Original Message----- > From: Andrew Haley [mailto:aph at redhat.com] > Sent: Montag, 5. Dezember 2016 15:54 > To: Lindenmaier, Goetz ; core-libs- > dev at openjdk.java.net > Subject: Re: potential error in fdlibm asin > > On 05/12/16 13:29, Lindenmaier, Goetz wrote: > > does anybody know for which x > > huge+x>one > > does _not_hold? Where > > huge = 1.000e+300, > > one = 1.00000000000000000000e+00 > > |x| < 2**-27 > > There is nothing. That branch is always taken; the only purpose is to try > to set the inexact flag if x != 0. > > Andrew. From aph at redhat.com Mon Dec 5 16:15:36 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 5 Dec 2016 16:15:36 +0000 Subject: potential error in fdlibm asin In-Reply-To: <99944ddd282348df98db2c7edbfbc83e@DEROTE13DE08.global.corp.sap> References: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> <107d5a4228014ee981dbf44492acbf8b@DEROTE13DE08.global.corp.sap> <99944ddd282348df98db2c7edbfbc83e@DEROTE13DE08.global.corp.sap> Message-ID: <6616bf4a-9aa6-9aa2-438e-4db81dd3f062@redhat.com> On 05/12/16 15:43, Lindenmaier, Goetz wrote: > Ah, you mean it sets some status in the processor? Yes. In the (possibly vain) hope of the programmer. > If the if is always executed the code is all fine. > I'll remove the unnecessary 'else' and add a comment 'Never reached' behind the if. I wouldn't change the code. Changing the indentation wouldn't hurt. Andrew. From swpalmer at gmail.com Mon Dec 5 17:27:12 2016 From: swpalmer at gmail.com (Scott Palmer) Date: Mon, 5 Dec 2016 12:27:12 -0500 Subject: Reducing Garbage Generated by URLClassLoader In-Reply-To: References: <584501EF.806@oracle.com> Message-ID: > On Dec 5, 2016, at 1:31 AM, Max Kanat-Alexander wrote: > > Yeah, I have implemented a fast-path byte-only ZipCoder in a customized JDK > and it makes a big difference for allocations in long classpaths. I expected to see an improvement, but haven?t made any attempt at solving the problem yet. I was just gauging how much interest there was in such a change. It is nice to see that some work has already been done. Do you have numbers? Regards, Scott > The basic > code to do just that isn't very complex. I could possibly dig that up and > upstream it if there's interest. My recollection is that my solution isn't > the cleanest, but it doesn't regress the "needs encoding" path. > > It also is possible to optimize URLClassLoader itself to do a better job of > caching zip entries, which significantly reduces the String allocation load > if you're doing a lot of lookups on the classpath. I have also implemented > something like this, but it's hard to get right and my changes aren't in a > state where they could be easily upstreamed. > > -Max From joe.darcy at oracle.com Mon Dec 5 18:17:19 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 5 Dec 2016 10:17:19 -0800 Subject: potential error in fdlibm asin In-Reply-To: References: <311b7911bc534ebbb2c60c6edf250fb0@DEROTE13DE08.global.corp.sap> <839dbd7c-7982-7d12-457f-82ead36d26ee@redhat.com> Message-ID: FYI, if you want to check the value an fdlibm function against another implementation, you could use the Correctly Rounded mathematical library (CRlibm) as a reference: http://lipforge.ens-lyon.fr/www/crlibm/ The relevant function in this case would be asin_rn. As its name implies, CRlibm aims to return the floating-point value closed to the exact one. The java.lang.Math error requirement for asin is 1 ulp; therefore, if not identical the fdlibm asin result and the CRlibm asin_rn result should be adjacent floating-point numbers. HTH, -Joe On 12/5/2016 2:30 AM, Volker Simonis wrote: > On Mon, Dec 5, 2016 at 11:10 AM, Andrew Haley wrote: >> On 02/12/16 14:24, Lindenmaier, Goetz wrote: >>> I found one copy of this code in the internet where the "else" is removed, >>> but it's not completely the same: >>> https://github.com/jerryscript-project/jerryscript/blob/master/jerry-libm/asin.c >>> >>> Does anybody have the knowledge to tell me what's wrong? >>> Does anybody know how to contribute a fix to netlib fdlibm? >> I think the only way to proceed with this is to find an input argument >> which is affected by this very odd code. If there is one. does it >> give a correct or an incorrect result? If not, we don't care and it >> can be tidied up later. > What would be the ultimate reference to to compare a potentially > incorrect result against if "the Java math library is defined with > respect to fdlibm version 5.3" [1] ? > > [1] https://docs.oracle.com/javase/8/docs/api/java/lang/StrictMath.html >> Andrew. >> From fishgarage at cbfiddle.com Sun Dec 4 20:50:15 2016 From: fishgarage at cbfiddle.com (Alan Snyder) Date: Sun, 4 Dec 2016 12:50:15 -0800 Subject: PollingWatchService possible issue Message-ID: <4FECE4B6-90E9-463F-904F-75F5262A61C8@cbfiddle.com> I notice that PollingWatchService never checks the file key when it reads a directory to see if it is reading from the same directory that it started with. I suspect that creates a potential for incorrect behavior if the directory tree is rearranged (between polls) so that the original path accesses a different directory. Specifically, if the original directory remains available via some other path, then someone watching on that path or trying to register using that path will be using a watch service that is reading the wrong directory. From daniel.fuchs at oracle.com Mon Dec 5 18:40:09 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 5 Dec 2016 18:40:09 +0000 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> Message-ID: <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> On 05/12/16 14:50, Sergei Kovalev wrote: > Hi Team, > > Could you please review a small change for regression test? Hi Sergei, Could you try with: if (Layer.boot().findModule("java.logging").isPresent()) { // expect JdkLazyLogger } else { // expect SimpleConsoleLogger } That shouldn't require any usage of jdk.internal APIs. best regards, -- daniel > > BugID: JDK-8170664 > Webrev: http://cr.openjdk.java.net/~skovalev/8170664/webrev.00/ > > Issue: One test fails in case of usage command line option > "--limit-module java.base". > Summary: The test has written in assumption that JDK always has > java.util.logging module on board. In reality we can limit JDK by > java.base only. In this case JDK will have only SimpleConsoleLogger on > board and the test failing. The fix adds a check for limited logging > ability and introduce a separate branch in the test for > SimpleConsoleLogger case. > From Roger.Riggs at Oracle.com Mon Dec 5 18:47:41 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 5 Dec 2016 13:47:41 -0500 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> Message-ID: Hi Sergei, I suspect that the variable "simleConsoleOnly" is misspelled. -> "sim*p*leConsoleOnly" Roger On 12/5/2016 9:50 AM, Sergei Kovalev wrote: > Hi Team, > > Could you please review a small change for regression test? > > BugID: JDK-8170664 > Webrev: http://cr.openjdk.java.net/~skovalev/8170664/webrev.00/ > > Issue: One test fails in case of usage command line option > "--limit-module java.base". > Summary: The test has written in assumption that JDK always has > java.util.logging module on board. In reality we can limit JDK by > java.base only. In this case JDK will have only SimpleConsoleLogger on > board and the test failing. The fix adds a check for limited logging > ability and introduce a separate branch in the test for > SimpleConsoleLogger case. > From paul.sandoz at oracle.com Mon Dec 5 19:17:38 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Dec 2016 11:17:38 -0800 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> References: <58441EC4.4090104@oracle.com> <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> Message-ID: <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> > On 4 Dec 2016, at 08:42, Ivan Gerasimov wrote: > > Thank you Claes for looking into it! > > > On 04.12.2016 16:48, Claes Redestad wrote: >> Hi Ivan, >> >> as this adds a new public API I guess it's too late for 9 at this point, but here's a few >> comments anyhow: >> > Yes, of course. > If people find it useful, I would expect it to go to jdk 10. Add a fix version of 10, then it?s clear on the intent. Once tests are added :-) we can review for that release. Personally i would use Arrays.fill, i gather the pattern is already recognised: https://bugs.openjdk.java.net/browse/JDK-4809552 http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d64a8c7aa9d5 The advantage of using Arrays.fill is we know that the pattern will be recognized (if not it?s a bug, and i suppose it could be made intrinsic to wire up faster). (see -XX:+TraceOptimizeFill). I suspect we should review the filling optimization to see if it can be enhanced with newer SIMD instructions, as i gather the current implementation writes a max of 8 bytes at a time (with an explicit unrolled loop for 32 bytes at a time, containing 4 separate stores). It?s good that you found places in the JDK, that adds justification for such methods, especially for BigInteger and that static array of strings full of ?0? characters. The updates to MethodHandleImpl are not perf sensitive, i question the usage here but it does reduce stuff in the constant pool i suppose. Paul. > >> - you could use Arrays.fill(byte[], int, int, byte) for LATIN-1 case in AbstractStringBuilder. >> Might not make it much faster (unless there are intrinsics at play, but perhaps a bit less >> verbose. >> > The do-while loop saves us one comparison, comparing to the loop in Arrays.fill(). > I'd prefer to keep the explicit loop, as it's only three lines of code long. > >> - for a convenience API like this, I think it's slightly awkward that a negative n throws IAE >> since users have to think carefully about whether they need to guard the call to appendN >> with a range check or not. I'd find this utility more useful if it was more forgiving and >> allowed simplifying the caller further. >> > Yes, I understand your point. There are different approaches to handling arguments. > E.g. for indices it might be allowed to have from > to (treat it as from == to), and from < 0. > Or, like in Perl, negative index might be treated as offset from the end of a list or array. > However, in Java, the tradition seems to have formed to have strong argument checks, not allowing much interpretation. > For example, similarly looking Collections.nCopies(int n, T) also throws IAE for negative n. > >> Benchmark comments: >> >> - since you're reusing a StringBuilder you're effectively removing the impact of resizing >> the underlying buffer, which is typically a significant part of appending, so while this >> zooms in on the cost of actually appending to a prepared builder, it might overstate the >> effect. >> > It was intentional, to be honest. > If appending several chars causes reallocation, then appending chars in a loop can only be slower, comparing to appendN() or append(String). > I didn't want to find the sharp constant of the speedup factor, but just wanted to be sure that the increase in performance is observable. > >> Creating new StringBuilders (of varying sizes) in a setup method outside the >> @Benchmark method might be more in line with typical use, in addition to what you have >> now (which is zooming in on the cost of appending without allocation overhead). >> setLength(0) could also be moved to an invocation level @Setup method) >> >> - seeing that appending a String, which uses System.arraycopy, can be slower for small >> strings is a bit surprising as I'd assume it'd be completely intrinsified. Is the compiled code >> making a JNI transition or are things not being inlined properly? >> > I'm not sure exactly why appending short String is slower then filling. > Might it be because the former means both reading from and writing to the memory, and the later only means writing? > Anyways, I only wanted to make sure that replacing the code in BigInteger and FDBigInteger won't make things slower. > >> - please use -tu us -bm avgt or annotate benchmarks to output scores with a reasonable >> number of digits. >> > Sure. Here you go: > > Benchmark (size) Mode Cnt Score Error Units > MyBenchmark.test_0_New 0 avgt 4 0.003 ? 0.004 us/op > MyBenchmark.test_0_New 1 avgt 4 0.005 ? 0.008 us/op > MyBenchmark.test_0_New 5 avgt 4 0.014 ? 0.015 us/op > MyBenchmark.test_0_New 10 avgt 4 0.016 ? 0.019 us/op > MyBenchmark.test_0_New 20 avgt 4 0.018 ? 0.010 us/op > MyBenchmark.test_1_Old 0 avgt 4 0.003 ? 0.001 us/op > MyBenchmark.test_1_Old 1 avgt 4 0.006 ? 0.004 us/op > MyBenchmark.test_1_Old 5 avgt 4 0.023 ? 0.021 us/op > MyBenchmark.test_1_Old 10 avgt 4 0.049 ? 0.071 us/op > MyBenchmark.test_1_Old 20 avgt 4 0.089 ? 0.110 us/op > MyBenchmark.test_2_Solid 0 avgt 4 0.007 ? 0.003 us/op > MyBenchmark.test_2_Solid 1 avgt 4 0.018 ? 0.024 us/op > MyBenchmark.test_2_Solid 5 avgt 4 0.016 ? 0.011 us/op > MyBenchmark.test_2_Solid 10 avgt 4 0.017 ? 0.016 us/op > MyBenchmark.test_2_Solid 20 avgt 4 0.016 ? 0.007 us/op > > > With kind regards, > Ivan > > >> Thanks! >> >> /Claes >> >> On 12/04/2016 04:07 AM, Ivan Gerasimov wrote: >>> Hello! >>> >>> There are several places in JDK where the same character is appended to a StringBuilder object multiple times (usually padding). >>> With each append there are a few routine checks performed. >>> They could have been done only once, if we had a method for appending multiple copies at a time. >>> A simple benchmark shows that such method may save us a few machine cycles (see the results below). >>> >>> In the benchmark, three approaches were compared: >>> 0) Using the new appendN(char, int) method to append several chars at once, >>> 1) Calling append(char) in a loop, >>> 2) Appending a prepared-in-advance string >>> >>> On my machine, the new method demonstrates better or comparable performance for all sizes up to 20. >>> >>> In the webrev, there are two changesets included: >>> - the new default Appendable.appendN(char, int) method, its overrides in StringBuilder/Buffer and a basic test, >>> - several applications of the new method across JDK. >>> >>> Would you please help review? >>> Comments, suggestions are welcome. >>> >>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170348 >>> WEBREV: http://cr.openjdk.java.net/~igerasim/8170348/00/webrev/ >>> Benchmark: http://cr.openjdk.java.net/~igerasim/8170348/00/MyBenchmark.java >>> >>> >>> Benchmark (size) Mode Cnt Score Error Units >>> MyBenchmark.test_0_New 0 thrpt 70 331922128.215 ? 16399254.452 ops/s >>> MyBenchmark.test_0_New 1 thrpt 70 209207932.893 ? 14955800.231 ops/s >>> MyBenchmark.test_0_New 5 thrpt 70 72926671.621 ? 4841791.555 ops/s >>> MyBenchmark.test_0_New 10 thrpt 70 67779575.053 ? 3234366.239 ops/s >>> MyBenchmark.test_0_New 20 thrpt 70 59731629.661 ? 2769497.288 ops/s >>> MyBenchmark.test_1_Old 0 thrpt 70 333467628.860 ? 15981678.430 ops/s >>> MyBenchmark.test_1_Old 1 thrpt 70 156126381.967 ? 9619653.294 ops/s >>> MyBenchmark.test_1_Old 5 thrpt 70 46550204.382 ? 2009987.637 ops/s >>> MyBenchmark.test_1_Old 10 thrpt 70 23309297.849 ? 1268874.282 ops/s >>> MyBenchmark.test_1_Old 20 thrpt 70 13143637.821 ? 662265.103 ops/s >>> MyBenchmark.test_2_Solid 0 thrpt 70 138548108.540 ? 6408775.462 ops/s >>> MyBenchmark.test_2_Solid 1 thrpt 70 63890936.132 ? 3918274.970 ops/s >>> MyBenchmark.test_2_Solid 5 thrpt 70 65838879.075 ? 2701493.698 ops/s >>> MyBenchmark.test_2_Solid 10 thrpt 70 65387238.993 ? 3131562.548 ops/s >>> MyBenchmark.test_2_Solid 20 thrpt 70 57528150.828 ? 3171453.716 ops/s >>> >>> >>> With kind regards, >>> Ivan >>> >> >> > From paul.sandoz at oracle.com Mon Dec 5 20:12:39 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 5 Dec 2016 12:12:39 -0800 Subject: RFR 8170733: HashMap.HashIterator.remove method does not use cached value for the hash code. Message-ID: Hi, Please review this small fix to the Linked/HashMap iterators. The remove method can use the cached hash code. Paul. diff -r 5c9389804cbc src/java.base/share/classes/java/util/HashMap.java --- a/src/java.base/share/classes/java/util/HashMap.java Mon Dec 05 12:53:53 2016 +0530 +++ b/src/java.base/share/classes/java/util/HashMap.java Mon Dec 05 12:10:46 2016 -0800 @@ -1502,8 +1502,7 @@ if (modCount != expectedModCount) throw new ConcurrentModificationException(); current = null; - K key = p.key; - removeNode(hash(key), key, null, false, false); + removeNode(p.hash, p.key, null, false, false); expectedModCount = modCount; } } diff -r 5c9389804cbc src/java.base/share/classes/java/util/LinkedHashMap.java --- a/src/java.base/share/classes/java/util/LinkedHashMap.java Mon Dec 05 12:53:53 2016 +0530 +++ b/src/java.base/share/classes/java/util/LinkedHashMap.java Mon Dec 05 12:10:46 2016 -0800 @@ -731,8 +731,7 @@ if (modCount != expectedModCount) throw new ConcurrentModificationException(); current = null; - K key = p.key; - removeNode(hash(key), key, null, false, false); + removeNode(p.hash, p.key, null, false, false); expectedModCount = modCount; } } From martinrb at google.com Mon Dec 5 20:14:24 2016 From: martinrb at google.com (Martin Buchholz) Date: Mon, 5 Dec 2016 12:14:24 -0800 Subject: RFR 8170733: HashMap.HashIterator.remove method does not use cached value for the hash code. In-Reply-To: References: Message-ID: Looks good to me! On Mon, Dec 5, 2016 at 12:12 PM, Paul Sandoz wrote: > Hi, > > Please review this small fix to the Linked/HashMap iterators. The remove > method can use the cached hash code. > > Paul. > > diff -r 5c9389804cbc src/java.base/share/classes/java/util/HashMap.java > --- a/src/java.base/share/classes/java/util/HashMap.java Mon Dec > 05 12:53:53 2016 +0530 > +++ b/src/java.base/share/classes/java/util/HashMap.java Mon Dec > 05 12:10:46 2016 -0800 > @@ -1502,8 +1502,7 @@ > if (modCount != expectedModCount) > throw new ConcurrentModificationException(); > current = null; > - K key = p.key; > - removeNode(hash(key), key, null, false, false); > + removeNode(p.hash, p.key, null, false, false); > expectedModCount = modCount; > } > } > diff -r 5c9389804cbc src/java.base/share/classes/ > java/util/LinkedHashMap.java > --- a/src/java.base/share/classes/java/util/LinkedHashMap.java Mon Dec > 05 12:53:53 2016 +0530 > +++ b/src/java.base/share/classes/java/util/LinkedHashMap.java Mon Dec > 05 12:10:46 2016 -0800 > @@ -731,8 +731,7 @@ > if (modCount != expectedModCount) > throw new ConcurrentModificationException(); > current = null; > - K key = p.key; > - removeNode(hash(key), key, null, false, false); > + removeNode(p.hash, p.key, null, false, false); > expectedModCount = modCount; > } > } > From shade at redhat.com Mon Dec 5 20:14:34 2016 From: shade at redhat.com (Aleksey Shipilev) Date: Mon, 5 Dec 2016 21:14:34 +0100 Subject: RFR 8170733: HashMap.HashIterator.remove method does not use cached value for the hash code. In-Reply-To: References: Message-ID: <1aab8bd9-07ea-07bf-bb94-991d768ba1ad@redhat.com> On 12/05/2016 09:12 PM, Paul Sandoz wrote: > diff -r 5c9389804cbc src/java.base/share/classes/java/util/HashMap.java > --- a/src/java.base/share/classes/java/util/HashMap.java Mon Dec 05 12:53:53 2016 +0530 > +++ b/src/java.base/share/classes/java/util/HashMap.java Mon Dec 05 12:10:46 2016 -0800 > @@ -1502,8 +1502,7 @@ > if (modCount != expectedModCount) > throw new ConcurrentModificationException(); > current = null; > - K key = p.key; > - removeNode(hash(key), key, null, false, false); > + removeNode(p.hash, p.key, null, false, false); > expectedModCount = modCount; > } > } > diff -r 5c9389804cbc src/java.base/share/classes/java/util/LinkedHashMap.java > --- a/src/java.base/share/classes/java/util/LinkedHashMap.java Mon Dec 05 12:53:53 2016 +0530 > +++ b/src/java.base/share/classes/java/util/LinkedHashMap.java Mon Dec 05 12:10:46 2016 -0800 > @@ -731,8 +731,7 @@ > if (modCount != expectedModCount) > throw new ConcurrentModificationException(); > current = null; > - K key = p.key; > - removeNode(hash(key), key, null, false, false); > + removeNode(p.hash, p.key, null, false, false); > expectedModCount = modCount; > } > } > D'oh. Looks good. Thanks, -Aleksey From Roger.Riggs at Oracle.com Mon Dec 5 21:44:39 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 5 Dec 2016 16:44:39 -0500 Subject: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net> References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net> <7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com> <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net> Message-ID: Hi Patrick, On 11/30/2016 4:47 PM, Patrick Reinhart wrote: > ... >> A few comments on the webrev: >> >> - 359: The withAutoFlush javadoc should be more explicit about when a new vs the same >> PrintWriter is returned. The ?activates? verb doesn't convey any sense about the instance that is returned. > 359 * Activates {@code printf}, or {@code format} methods to automatically > 360 * flush the output buffer after writing their data. > > Would the following be better: > > Returns the same instance if {@code autoFlush} does not change the > actual setting, otherwise a new instance with changed behavior is returned > my $.02 version Returns the same instance if {@code autoFlush} does not changethe actual setting, otherwise a new instance with*the requested autoFlush *is returned*.* >> - 375: Can this use the new private constructor that will handle psOut. > Here I can not get hold on the encoding at this point or have I missed something here? True, not easily, it is available as a String from OutputStreamWriter.getEncoding() but it would suffer from having to lookup it by name again. > > >> -320, etc. The @since should be 1 or 2 digits to match the version scheme > It seems, that I?m still not in the new version scheme ;-) - should be 9 - I will change that, the same for 343 > >> - no tests for new PrintWriter(OutputStream , Charset) > I will also add that > >> - From the test file name 'FailngConstructors", its not clear that's the right place >> for the positive tests of the withAutoFlush methods. > I will move that out to a new Test as soon we are more clear about the other points ok Thanks, Roger > >> That's all I have time for at the moment, >> >> Regards, Roger >> >> >> On 11/29/2016 4:15 PM, Patrick Reinhart wrote: >>> Does anyone sponsor this fix? >>> >>> http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 >>> >>> -Patrick From patrick at reini.net Mon Dec 5 22:29:40 2016 From: patrick at reini.net (Patrick Reinhart) Date: Mon, 5 Dec 2016 23:29:40 +0100 Subject: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net> <7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com> <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net> Message-ID: > Am 05.12.2016 um 22:44 schrieb Roger Riggs : > > Hi Patrick, > > On 11/30/2016 4:47 PM, Patrick Reinhart wrote: >> ... >>> A few comments on the webrev: >>> >>> - 359: The withAutoFlush javadoc should be more explicit about when a new vs the same >>> PrintWriter is returned. The ?activates? verb doesn't convey any sense about the instance that is returned. >> 359 * Activates {@code printf}, or {@code format} methods to automatically >> 360 * flush the output buffer after writing their data. >> >> Would the following be better: >> >> Returns the same instance if {@code autoFlush} does not change the >> actual setting, otherwise a new instance with changed behavior is returned >> > my $.02 version > Returns the same instance if {@code autoFlush} does not change the > actual setting, otherwise a new instance with the requested autoFlush is returned. Sounds good to me. If there are no other suggestions I will use that one.. >>> - 375: Can this use the new private constructor that will handle psOut. >> Here I can not get hold on the encoding at this point or have I missed something here? > True, not easily, it is available as a String from OutputStreamWriter.getEncoding() but it would suffer from > having to lookup it by name again. Right, even the Charset is actually available within the StreamEncoder implementation but not provided to the outside world. Also the OutputStreamWriter is in wrapped in a BufferedWriter and would be needed to be extracted from there again in the first place. >> >>> -320, etc. The @since should be 1 or 2 digits to match the version scheme >> It seems, that I?m still not in the new version scheme ;-) - should be 9 - I will change that, the same for 343 >> >>> - no tests for new PrintWriter(OutputStream , Charset) >> I will also add that >> >>> - From the test file name 'FailngConstructors", its not clear that's the right place >>> for the positive tests of the withAutoFlush methods. >> I will move that out to a new Test as soon we are more clear about the other points > ok > > Thanks, Roger >> >>> That's all I have time for at the moment, >>> >>> Regards, Roger >>> >>> >>> On 11/29/2016 4:15 PM, Patrick Reinhart wrote: >>>> Does anyone sponsor this fix? >>>> >>>> http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.00 >>>> >>>> -Patrick > From huaming.li at oracle.com Tue Dec 6 00:04:26 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 6 Dec 2016 08:04:26 +0800 Subject: RFR of JDK-8170669: com/sun/jndi/rmi/registry/RegistryContext/UnbindIdempotent.java fails after JDK-8153916 In-Reply-To: References: Message-ID: <90cc8c78-43f7-78e9-c131-0d500a9d18e8@oracle.com> Hi Roger, Thank you for reviewing. File bug: https://bugs.openjdk.java.net/browse/JDK-8170728 -Hamlin On 2016/12/5 22:31, Roger Riggs wrote: > Hi Hamlin, > > The changeset looks fine (to use /othervm). > > Please file a new issue for your finding about createRegistry(0); I > agree it is likely a product issue. > > Thanks, Roger > > > On 12/5/2016 3:12 AM, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8170669 >> webrev: http://cr.openjdk.java.net/~mli/8170669/webrev.00/ >> >> Root Cause: >> 2 tests impact each other. >> (test/com/sun/jndi/rmi/registry/RegistryContext/ContextWithNullProperties.java, >> UnbindIdempotent.java) >> Solution: >> adding othervm should resolve the issue. >> >> Thank you >> -Hamlin >> >> >> p.s. Besides of the test issue talked above, I think there is some >> defect in RMI API, below is the analysis. >> >> Root Cause: >> when calling LocateRegistry.createRegistry(port), it will check if >> the ObjectTable contains the same ObjectEndPoint, if it contains, >> "java.rmi.server.ExportException: internal error: ObjID already in >> use" is thrown in ObjectTable.java. 2 ObjectEndPoint objects are >> considered the same if both have the same id and same tranport >> instance. For 2 calls of LocateRegistry.createRegistry(0), they have >> the same id(ObjID.REGISTRY_ID) and same endpoint & transport >> instance, so they are considered the same and exception is thrown. >> >> ================= more detailed explanation ================= >> Although in >> LocateRegistry.createRegistry(0)->...->TCPTransport->exportObject(target)->TCPTransport.listen()->TCPEndpoint.setDefaultPort(...), >> it will add new endpoint instance for port 0 with a specific port >> number(for example, it's 9999) in localEndpoints, but it still keeps >> endpoint instance for port 0 in localEndpoints, and both endpoints(0, >> 9999) are mapped to the same epList which includes one item with port >> number as 9999. the transport member of previous 2 endpoint >> instances(0, 9999) is indeed built on port 9999, this transport >> listening on port 9999 is used as part of key(other part is object >> id) to insert into ObjectTable. so when >> LocateRegistry.createRegistry(0) is called second time, >> LocateRegistry.createRegistry(0)->...->TCPEndpoint.getLocalEndpoint(0, >> ...) will get the previous transport instance(listening on 9999), so >> finally, in >> LocateRegistry.createRegistry(0)->...->ObjectTable.putTarget(target), >> in line 183 of ObjectTable.java, objTable.containsKey(oe) will return >> true, then exception is thrown. >> >> ================= conclusion ================= >> I think this is a RMI product issue, because below code runs >> successfully, >> Registry registry1 = LocateRegistry.createRegistry(60003); >> Registry registry2 = LocateRegistry.createRegistry(60004); >> but below code will throw exception, >> Registry registry1 = LocateRegistry.createRegistry(0); >> Registry registry2 = LocateRegistry.createRegistry(0); >> > From felix.yang at oracle.com Tue Dec 6 01:28:35 2016 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 6 Dec 2016 09:28:35 +0800 Subject: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly In-Reply-To: References: Message-ID: <92d8acd0-5b76-cf8e-65de-3bc60e311e19@oracle.com> Add core-libs. Thanks, Felix On 2016/12/5 22:14, Felix Yang wrote: > Hi, > > updated webrev. May I have a reviewer to review this > > http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ > > -Felix > On 2016/12/5 15:50, Felix Yang wrote: >> >> >> On 2016/12/5 15:47, Langer, Christoph wrote: >>> Hi Felix, >>> >>> looks ok to me. >>> >>> You probably should remove the reference to the old shell script in >>> comment line 25, though: >>> >>> 25 * Test run from script, AcceptCauseFileDescriptorLeak.sh >> Christoph, Good catch! >> >> Thanks, >> Felix >>> >>> Best regards >>> Christoph >> > From felix.yang at oracle.com Tue Dec 6 02:08:21 2016 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 6 Dec 2016 10:08:21 +0800 Subject: RFR 8081390, javax/management/remote/mandatory/connection/RMIConnector_NPETest.java may leave orphaned processes Message-ID: <32e4ef1a-d023-997e-e88b-fdaab0a42cdb@oracle.com> Hi, please review the small fix to avoid orphaned processes left. Bug: https://bugs.openjdk.java.net/browse/JDK-8081390 Webrev: http://cr.openjdk.java.net/~xiaofeya/8081390/webrev.00/ Thanks, Felix From huaming.li at oracle.com Tue Dec 6 03:26:38 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 6 Dec 2016 11:26:38 +0800 Subject: RFR 8081390, javax/management/remote/mandatory/connection/RMIConnector_NPETest.java may leave orphaned processes In-Reply-To: <32e4ef1a-d023-997e-e88b-fdaab0a42cdb@oracle.com> References: <32e4ef1a-d023-997e-e88b-fdaab0a42cdb@oracle.com> Message-ID: <98f4903f-4107-8c25-417d-4fd12aad8496@oracle.com> Hi Felix, As the issue is timeout at rmid.start(), so it does not resolve the issue to just move rmid.start() to try block. I saw the issue happened last in 2015/6, maybe we could just close it as "Not Reproduced"? Thank you -Hamlin On 2016/12/6 10:08, Felix Yang wrote: > Hi, > > please review the small fix to avoid orphaned processes left. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8081390 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8081390/webrev.00/ > > Thanks, > > Felix > From felix.yang at oracle.com Tue Dec 6 03:38:35 2016 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 6 Dec 2016 11:38:35 +0800 Subject: RFR 8081390, javax/management/remote/mandatory/connection/RMIConnector_NPETest.java may leave orphaned processes In-Reply-To: <98f4903f-4107-8c25-417d-4fd12aad8496@oracle.com> References: <32e4ef1a-d023-997e-e88b-fdaab0a42cdb@oracle.com> <98f4903f-4107-8c25-417d-4fd12aad8496@oracle.com> Message-ID: <5b3e8d96-3693-3571-f1c2-1c52b3e0c1d7@oracle.com> Hi Hamlin, as stated in the bug, the timeout is more-likely a test setup issue that small timeout factor together with "-Xcomp". But in theory, if not put rmid.start() in finally, it indeed possibly leaves orphaned processes. So that is still a minor problem to fix. Thanks, Felix On 2016/12/6 11:26, Hamlin Li wrote: > Hi Felix, > > As the issue is timeout at rmid.start(), so it does not resolve the > issue to just move rmid.start() to try block. > > I saw the issue happened last in 2015/6, maybe we could just close it > as "Not Reproduced"? > > > Thank you > -Hamlin > > On 2016/12/6 10:08, Felix Yang wrote: >> Hi, >> >> please review the small fix to avoid orphaned processes left. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8081390 >> >> Webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8081390/webrev.00/ >> >> Thanks, >> >> Felix >> > From mkanat at google.com Tue Dec 6 07:11:09 2016 From: mkanat at google.com (Max Kanat-Alexander) Date: Tue, 6 Dec 2016 02:11:09 -0500 Subject: Reducing Garbage Generated by URLClassLoader In-Reply-To: References: <584501EF.806@oracle.com> Message-ID: My recollection is that on a binary that does nothing but start up with a long classpath and try to load most of the classes in it, I saw a 20% decrease in allocations as well as a noticeable, if small CPU improvement (but I forget the number for that). On Mon, Dec 5, 2016 at 12:27 PM, Scott Palmer wrote: > > > On Dec 5, 2016, at 1:31 AM, Max Kanat-Alexander > wrote: > > > > Yeah, I have implemented a fast-path byte-only ZipCoder in a customized > JDK > > and it makes a big difference for allocations in long classpaths. > > I expected to see an improvement, but haven?t made any attempt at solving > the problem yet. I was just gauging how much interest there was in such a > change. It is nice to see that some work has already been done. Do you > have numbers? > > Regards, > > Scott > > > > The basic > > code to do just that isn't very complex. I could possibly dig that up and > > upstream it if there's interest. My recollection is that my solution > isn't > > the cleanest, but it doesn't regress the "needs encoding" path. > > > > It also is possible to optimize URLClassLoader itself to do a better job > of > > caching zip entries, which significantly reduces the String allocation > load > > if you're doing a lot of lookups on the classpath. I have also > implemented > > something like this, but it's hard to get right and my changes aren't in > a > > state where they could be easily upstreamed. > > > > -Max > > From huaming.li at oracle.com Tue Dec 6 07:18:14 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 6 Dec 2016 15:18:14 +0800 Subject: RFR of JDK-8170704: java/rmi/activation/Activatable/* tests fails intermittently with "output improperly annotated" Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170704 webrev: http://cr.openjdk.java.net/~mli/8170704/webrev.00/ * Root Cause: The issue can be reproduced by adjust sleeping time to smaller values, so on busy machine it's possible that the sleeping time is not long enough for rmi system to pass myRMI err/out to rmid err/out. * Solution: scale timeout by time factor. Thank you -Hamlin From huaming.li at oracle.com Tue Dec 6 07:32:45 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 6 Dec 2016 15:32:45 +0800 Subject: RFR 8081390, javax/management/remote/mandatory/connection/RMIConnector_NPETest.java may leave orphaned processes In-Reply-To: <5b3e8d96-3693-3571-f1c2-1c52b3e0c1d7@oracle.com> References: <32e4ef1a-d023-997e-e88b-fdaab0a42cdb@oracle.com> <98f4903f-4107-8c25-417d-4fd12aad8496@oracle.com> <5b3e8d96-3693-3571-f1c2-1c52b3e0c1d7@oracle.com> Message-ID: <41e335bb-e74d-7b59-451d-f1ae68777308@oracle.com> I see, looks fine. But I'm not a reviewer. Thank you -Hamlin On 2016/12/6 11:38, Felix Yang wrote: > Hi Hamlin, > > as stated in the bug, the timeout is more-likely a test setup issue > that small timeout factor together with "-Xcomp". > > But in theory, if not put rmid.start() in finally, it indeed > possibly leaves orphaned processes. So that is still a minor problem > to fix. > > Thanks, > Felix > On 2016/12/6 11:26, Hamlin Li wrote: >> Hi Felix, >> >> As the issue is timeout at rmid.start(), so it does not resolve the >> issue to just move rmid.start() to try block. >> >> I saw the issue happened last in 2015/6, maybe we could just close it >> as "Not Reproduced"? >> >> >> Thank you >> -Hamlin >> >> On 2016/12/6 10:08, Felix Yang wrote: >>> Hi, >>> >>> please review the small fix to avoid orphaned processes left. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8081390 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~xiaofeya/8081390/webrev.00/ >>> >>> Thanks, >>> >>> Felix >>> >> > From michael.hixson at gmail.com Tue Dec 6 08:03:54 2016 From: michael.hixson at gmail.com (Michael Hixson) Date: Tue, 6 Dec 2016 00:03:54 -0800 Subject: default methods inherited by EnumSet and EnumMap Message-ID: Hello, I notice that EnumSet and EnumMap don't override any of the default methods that were added to collections in Java 8. Were they specifically considered then avoided during the Java 8 upgrades, or was it simply that no one got around to optimizing them? Are there existing issues/bugs for optimizing them? I couldn't find any. As one example: I suspect that EnumMap.forEach(action) could improve a lot. Right now it looks like iterating over keySet() and calling get(key) is faster than forEach(action) when it comes to EnumMap (unlike every other Map implementation I tested). -Michael From felix.yang at oracle.com Tue Dec 6 09:06:06 2016 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 6 Dec 2016 17:06:06 +0800 Subject: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently Message-ID: <3b5d8771-43f8-4205-cfa1-e6d6850793e9@oracle.com> Hi, please review the following patch. It generally coverts codes from shell to plain java. Bug: https://bugs.openjdk.java.net/browse/JDK-8169115 Webrev: http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/ Thanks, Felix From martijnverburg at gmail.com Tue Dec 6 09:22:08 2016 From: martijnverburg at gmail.com (Martijn Verburg) Date: Tue, 6 Dec 2016 09:22:08 +0000 Subject: JDK-6253001 - Joinrowset bug - question on whether test code has been migrated? Message-ID: Hi all, The Adoption Group is having a go at collaboratively walking through the process of resolving an open bug with the view of writing up the steps for folks new to OpenJDK. We picked https://bugs.openjdk.java.net/browse/JDK-6253001 - a fairly simple, low priority joinrowset bug reported in the sql area. Our intention is to investigate the bug, reproduce it and *if* a fix is required wait until the jdk 10 forests open to submit it there (as it's only a P4). ----- Of course with older bugs there is a hidden history :-). The original test is listed as living in: com.sun.rowset.tests.smoke.joinrowset.joinrowset3.JoinRowSet3.testJoinRowSet22 However we're unable to find that exact test which means that either: 1.) It's an internal Sun/Oracle test 2.) It's been migrated / replaced by one of the tests in *jdk/javax/sql/testing/test/rowset/joinrowset/JoinRowSetTests.java* Does anyone familiar with the tests around the SQL package know the history here? Cheers, Martijn From sergei.kovalev at oracle.com Tue Dec 6 09:36:26 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 6 Dec 2016 12:36:26 +0300 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> Message-ID: Hi Daniel, Please take a look at http://cr.openjdk.java.net/~skovalev/8170664/webrev.01/ This simplify logic a bit. What if JDK uses some custom logging library instead of java.logging? Looks like in this case the test will expect SimpleConsoleLogger but it could be not a case. Isn't it? Does it matter for testing? -- With best regards, Sergei 05.12.16 21:40, Daniel Fuchs wrote: > On 05/12/16 14:50, Sergei Kovalev wrote: >> Hi Team, >> >> Could you please review a small change for regression test? > > Hi Sergei, > > Could you try with: > > if (Layer.boot().findModule("java.logging").isPresent()) { > // expect JdkLazyLogger > } else { > // expect SimpleConsoleLogger > } > > That shouldn't require any usage of jdk.internal APIs. > > best regards, > > -- daniel > >> >> BugID: JDK-8170664 >> Webrev: http://cr.openjdk.java.net/~skovalev/8170664/webrev.00/ >> >> Issue: One test fails in case of usage command line option >> "--limit-module java.base". >> Summary: The test has written in assumption that JDK always has >> java.util.logging module on board. In reality we can limit JDK by >> java.base only. In this case JDK will have only SimpleConsoleLogger on >> board and the test failing. The fix adds a check for limited logging >> ability and introduce a separate branch in the test for >> SimpleConsoleLogger case. >> > From volker.simonis at gmail.com Tue Dec 6 09:59:26 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 6 Dec 2016 10:59:26 +0100 Subject: Fwd: [PATCH]: few memory errors fixes In-Reply-To: References: Message-ID: Hi David, thanks for your contribution. Your fixes look reasonable. I'm forwarding your mail to to core-libs-dev and awt-dev for reviewing. Regards, Volker ---------- Forwarded message ---------- From: David CARLIER Date: Mon, Dec 5, 2016 at 10:10 PM Subject: [PATCH]: few memory errors fixes To: jdk9-dev at openjdk.java.net Hi, this is my first patch sent to the mailing list. One corrects the wrong delete operator used and a potential memory leak. Hope it is useful. Kind regards. -------------- next part -------------- diff --git a/src/java.base/share/native/libjimage/imageDecompressor.cpp b/src/java.base/share/native/libjimage/imageDecompressor.cpp --- a/src/java.base/share/native/libjimage/imageDecompressor.cpp +++ b/src/java.base/share/native/libjimage/imageDecompressor.cpp @@ -181,7 +181,7 @@ } } while (has_header); memcpy(uncompressed, decompressed_resource, (size_t) uncompressed_size); - delete decompressed_resource; + delete [] decompressed_resource; } // Zip decompressor diff --git a/src/java.desktop/unix/native/common/awt/fontpath.c b/src/java.desktop/unix/native/common/awt/fontpath.c --- a/src/java.desktop/unix/native/common/awt/fontpath.c +++ b/src/java.desktop/unix/native/common/awt/fontpath.c @@ -289,6 +289,7 @@ onePath = SAFE_SIZE_ARRAY_ALLOC(malloc, strlen (fDirP->name[index]) + 2, sizeof( char ) ); if (onePath == NULL) { free ( ( void *) appendDirList ); + free ( ( void *) newFontPath ); XFreeFontPath ( origFontPath ); return; } From daniel.fuchs at oracle.com Tue Dec 6 10:04:15 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Dec 2016 10:04:15 +0000 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> Message-ID: <93942bfe-5cbc-84f0-2366-5f7790bb55ee@oracle.com> On 06/12/16 09:36, Sergei Kovalev wrote: > Hi Daniel, > > Please take a look at > http://cr.openjdk.java.net/~skovalev/8170664/webrev.01/ Hi Sergey, This looks good. Please add a comment to explain why we're doing this here: 111 if (simleConsoleOnly) { // happens if the test is called with // --limit-modules java.base > This simplify logic a bit. What if JDK uses some custom logging library > instead of java.logging? Looks like in this case the test will expect > SimpleConsoleLogger but it could be not a case. Isn't it? Does it matter > for testing? The test runs in a controlled environment. The JDK has no 'custom library'. An application might, but there are other tests for that. So in the case we're testing here it's either java.logging present or java.logging absent - and no other alternative. best regards, -- daniel > From goetz.lindenmaier at sap.com Tue Dec 6 10:09:34 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 Dec 2016 10:09:34 +0000 Subject: Fwd: [PATCH]: few memory errors fixes In-Reply-To: References: Message-ID: <9ac7ab7b4b4c46b1881eaa6315efe735@DEROTE13DE08.global.corp.sap> Hi, the fix to imageDecompressor.cpp is already reported in https://bugs.openjdk.java.net/browse/JDK-8170663 I'll send RFR for that today. I'll add you to contributors. Best regards, Goetz. > -----Original Message----- > From: awt-dev [mailto:awt-dev-bounces at openjdk.java.net] On Behalf Of > Volker Simonis > Sent: Dienstag, 6. Dezember 2016 10:59 > To: Java Core Libs ; awt- > dev at openjdk.java.net > Subject: Fwd: [PATCH]: few memory errors fixes > > Hi David, > > thanks for your contribution. Your fixes look reasonable. > I'm forwarding your mail to to core-libs-dev and awt-dev for reviewing. > > Regards, > Volker > > > ---------- Forwarded message ---------- > From: David CARLIER > Date: Mon, Dec 5, 2016 at 10:10 PM > Subject: [PATCH]: few memory errors fixes > To: jdk9-dev at openjdk.java.net > > > Hi, > > this is my first patch sent to the mailing list. One corrects the wrong > delete operator used and a potential memory leak. > > Hope it is useful. > > Kind regards. From daniel.fuchs at oracle.com Tue Dec 6 10:19:55 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Dec 2016 10:19:55 +0000 Subject: RFR of JDK-8170704: java/rmi/activation/Activatable/* tests fails intermittently with "output improperly annotated" In-Reply-To: References: Message-ID: <864e209d-7d37-8396-103c-e4a0d927d026@oracle.com> Looks reasonable to me Hamlin! best regards, -- daniel On 06/12/16 07:18, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8170704 > webrev: http://cr.openjdk.java.net/~mli/8170704/webrev.00/ > > * Root Cause: > The issue can be reproduced by adjust sleeping time to smaller values, > so on busy machine it's possible that the sleeping time is not long > enough for rmi system to pass myRMI err/out to rmid err/out. > * Solution: > scale timeout by time factor. > > Thank you > -Hamlin From chris.hegarty at oracle.com Tue Dec 6 10:46:08 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 6 Dec 2016 10:46:08 +0000 Subject: RFR [9] 8166568 & 8169492 jmod extract and bug fix Message-ID: <7234393A-8139-441E-9709-6AA3E3C409A5@oracle.com> This change adds a basic option to the jmod tool to extract all its contents to the current working directory, 8166568 [1]. Additionally, there is a bug fix for a public mutable static, 8169492 [2]. http://cr.openjdk.java.net/~chegar/8166568_8169492.00/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8166568 [2] https://bugs.openjdk.java.net/browse/JDK-8169492 From daniel.fuchs at oracle.com Tue Dec 6 11:15:23 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Dec 2016 11:15:23 +0000 Subject: RFR [9] 8166568 & 8169492 jmod extract and bug fix In-Reply-To: <7234393A-8139-441E-9709-6AA3E3C409A5@oracle.com> References: <7234393A-8139-441E-9709-6AA3E3C409A5@oracle.com> Message-ID: Hi Chris, On 06/12/16 10:46, Chris Hegarty wrote: > This change adds a basic option to the jmod tool to extract all its contents to > the current working directory, 8166568 [1]. Additionally, there is a bug fix for > a public mutable static, 8169492 [2]. This is not my area of expertise but these changes look straightforward, and they make sense to me. best regards, -- daniel > > http://cr.openjdk.java.net/~chegar/8166568_8169492.00/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8166568 > [2] https://bugs.openjdk.java.net/browse/JDK-8169492 > From dmitry.samersoff at oracle.com Tue Dec 6 11:16:26 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 6 Dec 2016 14:16:26 +0300 Subject: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently In-Reply-To: <3b5d8771-43f8-4205-cfa1-e6d6850793e9@oracle.com> References: <3b5d8771-43f8-4205-cfa1-e6d6850793e9@oracle.com> Message-ID: <8cd1ba28-3dfb-6c69-312d-4a48072efa16@oracle.com> Felix, 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for this test. Could we use different one (e.g. icann.org) 2. This test run JTREG -> Test VM -> Another VM. Could we optimize process usage? It might be better to create a jtreg "same vm" process that 1. launch another process with -Djava.net.preferIPv4Stack=true that do A and PRT lookup in one run. 2. Read results of process above, do PTR lookup with default settings and compare results. -Dmitry On 2016-12-06 12:06, Felix Yang wrote: > Hi, > > please review the following patch. It generally coverts codes from > shell to plain java. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8169115 > > Webrev: > > http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/ > > Thanks, > > Felix > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From chris.hegarty at oracle.com Tue Dec 6 11:27:19 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 6 Dec 2016 11:27:19 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: References: Message-ID: Mandy and I exchanged some mails off line, here is updated proposed wording. > On 21 Nov 2016, at 09:41, Chris Hegarty wrote: > > JDK-8155977 updated ObjectInputStream::resolveClass, and > resolveProxyClass, to work with the platform class loader, but > inadvertently removed the text describing the order in which the > call stack is searched, for the 'loader'. > > The omission, from Java SE 8, is " ... closest such method to the > currently executing frame". Similar text should be reinstated. diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java b/src/java.base/share/classes/java/io/ObjectInputStream.java --- a/src/java.base/share/classes/java/io/ObjectInputStream.java +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java @@ -640,46 +640,45 @@ /** * Load the local class equivalent of the specified stream class * description. Subclasses may implement this method to allow classes to * be fetched from an alternate source. * *

The corresponding method in ObjectOutputStream is * annotateClass. This method will be invoked only once for * each unique class in the stream. This method can be implemented by * subclasses to use an alternate loading mechanism but must return a * Class object. Once returned, if the class is not an array * class, its serialVersionUID is compared to the serialVersionUID of the * serialized class, and if there is a mismatch, the deserialization fails * and an {@link InvalidClassException} is thrown. * *

The default implementation of this method in * ObjectInputStream returns the result of calling * 

      *     Class.forName(desc.getName(), false, loader)
      *
- * where loader is determined as follows: if there is a - * method on the current thread's stack whose declaring class is not a - * - * platform class, then loader is - * the class loader of such class; otherwise, loader - * is the {@linkplain ClassLoader#getPlatformClassLoader() + * where loader is the first class loader on the current + * thread?s stack (starting from the currently executing method) that is + * neither the + * platform class loader nor its ancestor; otherwise, + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() * platform class loader}. If this call results in a * ClassNotFoundException and the name of the passed * ObjectStreamClass instance is the Java language keyword * for a primitive type or void, then the Class object * representing that primitive type or void will be returned * (e.g., an ObjectStreamClass with the name * "int" will be resolved to Integer.TYPE). * Otherwise, the ClassNotFoundException will be thrown to * the caller of this method. * * @param desc an instance of class ObjectStreamClass * @return a Class object corresponding to desc * @throws IOException any of the usual Input/Output exceptions. * @throws ClassNotFoundException if class of a serialized object cannot * be found. */ protected Class resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException { String name = desc.getName(); @@ -704,46 +703,45 @@ * *

This method is called exactly once for each unique proxy class * descriptor in the stream. * *

The corresponding method in ObjectOutputStream is * annotateProxyClass. For a given subclass of * ObjectInputStream that overrides this method, the * annotateProxyClass method in the corresponding subclass of * ObjectOutputStream must write any data or objects read by * this method. * *

The default implementation of this method in * ObjectInputStream returns the result of calling * Proxy.getProxyClass with the list of Class * objects for the interfaces that are named in the interfaces * parameter. The Class object for each interface name * i is the value returned by calling * 

      *     Class.forName(i, false, loader)
      *
- * where loader is determined as follows: if there is a - * method on the current thread's stack whose declaring class is not a - * - * platform class, then loader is - * the class loader of such class; otherwise, loader - * is the {@linkplain ClassLoader#getPlatformClassLoader() + * where loader is the first class loader on the current + * thread?s stack (starting from the currently executing method) that is + * neither the + * platform class loader nor its ancestor; otherwise, + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() * platform class loader}. * Unless any of the resolved interfaces are non-public, this same value * of loader is also the class loader passed to * Proxy.getProxyClass; if non-public interfaces are present, * their class loader is passed instead (if more than one non-public * interface class loader is encountered, an * IllegalAccessError is thrown). * If Proxy.getProxyClass throws an * IllegalArgumentException, resolveProxyClass * will throw a ClassNotFoundException containing the * IllegalArgumentException. * * @param interfaces the list of interface names that were * deserialized in the proxy class descriptor * @return a proxy class for the specified interfaces * @throws IOException any exception thrown by the underlying * InputStream * @throws ClassNotFoundException if the proxy class or any of the * named interfaces could not be found * @see ObjectOutputStream#annotateProxyClass(Class) -Chris. > [1] https://bugs.openjdk.java.net/browse/JDK-8155977 From daniel.fuchs at oracle.com Tue Dec 6 11:35:08 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Dec 2016 11:35:08 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: References: Message-ID: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> Hi Chris, Is that a typo? I see it at two places: otherwise, + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() * platform class loader}. ("loaded" vs "loader") best regards, -- daniel On 06/12/16 11:27, Chris Hegarty wrote: > Mandy and I exchanged some mails off line, here is updated proposed wording. > > >> On 21 Nov 2016, at 09:41, Chris Hegarty wrote: >> >> JDK-8155977 updated ObjectInputStream::resolveClass, and >> resolveProxyClass, to work with the platform class loader, but >> inadvertently removed the text describing the order in which the >> call stack is searched, for the 'loader'. >> >> The omission, from Java SE 8, is " ... closest such method to the >> currently executing frame". Similar text should be reinstated. > > diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java b/src/java.base/share/classes/java/io/ObjectInputStream.java > --- a/src/java.base/share/classes/java/io/ObjectInputStream.java > +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java > @@ -640,46 +640,45 @@ > > /** > * Load the local class equivalent of the specified stream class > * description. Subclasses may implement this method to allow classes to > * be fetched from an alternate source. > * > *

The corresponding method in ObjectOutputStream is > * annotateClass. This method will be invoked only once for > * each unique class in the stream. This method can be implemented by > * subclasses to use an alternate loading mechanism but must return a > * Class object. Once returned, if the class is not an array > * class, its serialVersionUID is compared to the serialVersionUID of the > * serialized class, and if there is a mismatch, the deserialization fails > * and an {@link InvalidClassException} is thrown. > * > *

The default implementation of this method in > * ObjectInputStream returns the result of calling > * 

>       *     Class.forName(desc.getName(), false, loader)
>       *
> - * where loader is determined as follows: if there is a > - * method on the current thread's stack whose declaring class is not a > - * > - * platform class, then loader is > - * the class loader of such class; otherwise, loader > - * is the {@linkplain ClassLoader#getPlatformClassLoader() > + * where loader is the first class loader on the current > + * thread?s stack (starting from the currently executing method) that is > + * neither the > + * platform class loader nor its ancestor; otherwise, > + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() > * platform class loader}. If this call results in a > * ClassNotFoundException and the name of the passed > * ObjectStreamClass instance is the Java language keyword > * for a primitive type or void, then the Class object > * representing that primitive type or void will be returned > * (e.g., an ObjectStreamClass with the name > * "int" will be resolved to Integer.TYPE). > * Otherwise, the ClassNotFoundException will be thrown to > * the caller of this method. > * > * @param desc an instance of class ObjectStreamClass > * @return a Class object corresponding to desc > * @throws IOException any of the usual Input/Output exceptions. > * @throws ClassNotFoundException if class of a serialized object cannot > * be found. > */ > protected Class resolveClass(ObjectStreamClass desc) > throws IOException, ClassNotFoundException > { > String name = desc.getName(); > @@ -704,46 +703,45 @@ > * > *

This method is called exactly once for each unique proxy class > * descriptor in the stream. > * > *

The corresponding method in ObjectOutputStream is > * annotateProxyClass. For a given subclass of > * ObjectInputStream that overrides this method, the > * annotateProxyClass method in the corresponding subclass of > * ObjectOutputStream must write any data or objects read by > * this method. > * > *

The default implementation of this method in > * ObjectInputStream returns the result of calling > * Proxy.getProxyClass with the list of Class > * objects for the interfaces that are named in the interfaces > * parameter. The Class object for each interface name > * i is the value returned by calling > * 

>       *     Class.forName(i, false, loader)
>       *
> - * where loader is determined as follows: if there is a > - * method on the current thread's stack whose declaring class is not a > - * > - * platform class, then loader is > - * the class loader of such class; otherwise, loader > - * is the {@linkplain ClassLoader#getPlatformClassLoader() > + * where loader is the first class loader on the current > + * thread?s stack (starting from the currently executing method) that is > + * neither the > + * platform class loader nor its ancestor; otherwise, > + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() > * platform class loader}. > * Unless any of the resolved interfaces are non-public, this same value > * of loader is also the class loader passed to > * Proxy.getProxyClass; if non-public interfaces are present, > * their class loader is passed instead (if more than one non-public > * interface class loader is encountered, an > * IllegalAccessError is thrown). > * If Proxy.getProxyClass throws an > * IllegalArgumentException, resolveProxyClass > * will throw a ClassNotFoundException containing the > * IllegalArgumentException. > * > * @param interfaces the list of interface names that were > * deserialized in the proxy class descriptor > * @return a proxy class for the specified interfaces > * @throws IOException any exception thrown by the underlying > * InputStream > * @throws ClassNotFoundException if the proxy class or any of the > * named interfaces could not be found > * @see ObjectOutputStream#annotateProxyClass(Class) > > > -Chris. > >> [1] https://bugs.openjdk.java.net/browse/JDK-8155977 > From chris.hegarty at oracle.com Tue Dec 6 11:38:57 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 6 Dec 2016 11:38:57 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> References: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> Message-ID: <2ECEE516-9083-4844-95FE-5DB154F3E46D@oracle.com> > On 6 Dec 2016, at 11:35, Daniel Fuchs wrote: > > Hi Chris, > > Is that a typo? I see it at two places: > > otherwise, > + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() > * platform class loader}. > > ("loaded" vs "loader") It is a typo, thanks. For completeness, here is the updated version: diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java b/src/java.base/share/classes/java/io/ObjectInputStream.java --- a/src/java.base/share/classes/java/io/ObjectInputStream.java +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java @@ -640,46 +640,45 @@ /** * Load the local class equivalent of the specified stream class * description. Subclasses may implement this method to allow classes to * be fetched from an alternate source. * *

The corresponding method in ObjectOutputStream is * annotateClass. This method will be invoked only once for * each unique class in the stream. This method can be implemented by * subclasses to use an alternate loading mechanism but must return a * Class object. Once returned, if the class is not an array * class, its serialVersionUID is compared to the serialVersionUID of the * serialized class, and if there is a mismatch, the deserialization fails * and an {@link InvalidClassException} is thrown. * *

The default implementation of this method in * ObjectInputStream returns the result of calling * 

      *     Class.forName(desc.getName(), false, loader)
      *
- * where loader is determined as follows: if there is a - * method on the current thread's stack whose declaring class is not a - * - * platform class, then loader is - * the class loader of such class; otherwise, loader - * is the {@linkplain ClassLoader#getPlatformClassLoader() + * where loader is the first class loader on the current + * thread's stack (starting from the currently executing method) that is + * neither the + * platform class loader nor its ancestor; otherwise, + * loader is the {@linkplain ClassLoader#getPlatformClassLoader() * platform class loader}. If this call results in a * ClassNotFoundException and the name of the passed * ObjectStreamClass instance is the Java language keyword * for a primitive type or void, then the Class object * representing that primitive type or void will be returned * (e.g., an ObjectStreamClass with the name * "int" will be resolved to Integer.TYPE). * Otherwise, the ClassNotFoundException will be thrown to * the caller of this method. * * @param desc an instance of class ObjectStreamClass * @return a Class object corresponding to desc * @throws IOException any of the usual Input/Output exceptions. * @throws ClassNotFoundException if class of a serialized object cannot * be found. */ protected Class resolveClass(ObjectStreamClass desc) throws IOException, ClassNotFoundException { String name = desc.getName(); @@ -704,46 +703,45 @@ * *

This method is called exactly once for each unique proxy class * descriptor in the stream. * *

The corresponding method in ObjectOutputStream is * annotateProxyClass. For a given subclass of * ObjectInputStream that overrides this method, the * annotateProxyClass method in the corresponding subclass of * ObjectOutputStream must write any data or objects read by * this method. * *

The default implementation of this method in * ObjectInputStream returns the result of calling * Proxy.getProxyClass with the list of Class * objects for the interfaces that are named in the interfaces * parameter. The Class object for each interface name * i is the value returned by calling * 

      *     Class.forName(i, false, loader)
      *
- * where loader is determined as follows: if there is a - * method on the current thread's stack whose declaring class is not a - * - * platform class, then loader is - * the class loader of such class; otherwise, loader - * is the {@linkplain ClassLoader#getPlatformClassLoader() + * where loader is the first class loader on the current + * thread's stack (starting from the currently executing method) that is + * neither the + * platform class loader nor its ancestor; otherwise, + * loader is the {@linkplain ClassLoader#getPlatformClassLoader() * platform class loader}. * Unless any of the resolved interfaces are non-public, this same value * of loader is also the class loader passed to * Proxy.getProxyClass; if non-public interfaces are present, * their class loader is passed instead (if more than one non-public * interface class loader is encountered, an * IllegalAccessError is thrown). * If Proxy.getProxyClass throws an * IllegalArgumentException, resolveProxyClass * will throw a ClassNotFoundException containing the * IllegalArgumentException. * * @param interfaces the list of interface names that were * deserialized in the proxy class descriptor * @return a proxy class for the specified interfaces * @throws IOException any exception thrown by the underlying * InputStream * @throws ClassNotFoundException if the proxy class or any of the * named interfaces could not be found * @see ObjectOutputStream#annotateProxyClass(Class) -Chris. From daniel.fuchs at oracle.com Tue Dec 6 11:53:51 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Dec 2016 11:53:51 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: <2ECEE516-9083-4844-95FE-5DB154F3E46D@oracle.com> References: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> <2ECEE516-9083-4844-95FE-5DB154F3E46D@oracle.com> Message-ID: <9aa195c5-7fa5-38cd-51c6-664622a2cb9b@oracle.com> Hi Chris, I have an additional suggestion: could you update the comment of the private ObjectInputStream::latestUserDefinedLoader() in the same file to align with what the method is actually doing? I looked at what jdk.internal.misc.VM.latestUserDefinedLoader() does, and the comment in ObjectInputStream::latestUserDefinedLoader() doesn't seem to match the implementation. best regards, -- daniel On 06/12/16 11:38, Chris Hegarty wrote: > >> On 6 Dec 2016, at 11:35, Daniel Fuchs wrote: >> >> Hi Chris, >> >> Is that a typo? I see it at two places: >> >> otherwise, >> + * loaded is the {@linkplain ClassLoader#getPlatformClassLoader() >> * platform class loader}. >> >> ("loaded" vs "loader") > > It is a typo, thanks. For completeness, here is the updated version: > > diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java b/src/java.base/share/classes/java/io/ObjectInputStream.java > --- a/src/java.base/share/classes/java/io/ObjectInputStream.java > +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java > @@ -640,46 +640,45 @@ > > /** > * Load the local class equivalent of the specified stream class > * description. Subclasses may implement this method to allow classes to > * be fetched from an alternate source. > * > *

The corresponding method in ObjectOutputStream is > * annotateClass. This method will be invoked only once for > * each unique class in the stream. This method can be implemented by > * subclasses to use an alternate loading mechanism but must return a > * Class object. Once returned, if the class is not an array > * class, its serialVersionUID is compared to the serialVersionUID of the > * serialized class, and if there is a mismatch, the deserialization fails > * and an {@link InvalidClassException} is thrown. > * > *

The default implementation of this method in > * ObjectInputStream returns the result of calling > * 

>       *     Class.forName(desc.getName(), false, loader)
>       *
> - * where loader is determined as follows: if there is a > - * method on the current thread's stack whose declaring class is not a > - * > - * platform class, then loader is > - * the class loader of such class; otherwise, loader > - * is the {@linkplain ClassLoader#getPlatformClassLoader() > + * where loader is the first class loader on the current > + * thread's stack (starting from the currently executing method) that is > + * neither the > + * platform class loader nor its ancestor; otherwise, > + * loader is the {@linkplain ClassLoader#getPlatformClassLoader() > * platform class loader}. If this call results in a > * ClassNotFoundException and the name of the passed > * ObjectStreamClass instance is the Java language keyword > * for a primitive type or void, then the Class object > * representing that primitive type or void will be returned > * (e.g., an ObjectStreamClass with the name > * "int" will be resolved to Integer.TYPE). > * Otherwise, the ClassNotFoundException will be thrown to > * the caller of this method. > * > * @param desc an instance of class ObjectStreamClass > * @return a Class object corresponding to desc > * @throws IOException any of the usual Input/Output exceptions. > * @throws ClassNotFoundException if class of a serialized object cannot > * be found. > */ > protected Class resolveClass(ObjectStreamClass desc) > throws IOException, ClassNotFoundException > { > String name = desc.getName(); > @@ -704,46 +703,45 @@ > * > *

This method is called exactly once for each unique proxy class > * descriptor in the stream. > * > *

The corresponding method in ObjectOutputStream is > * annotateProxyClass. For a given subclass of > * ObjectInputStream that overrides this method, the > * annotateProxyClass method in the corresponding subclass of > * ObjectOutputStream must write any data or objects read by > * this method. > * > *

The default implementation of this method in > * ObjectInputStream returns the result of calling > * Proxy.getProxyClass with the list of Class > * objects for the interfaces that are named in the interfaces > * parameter. The Class object for each interface name > * i is the value returned by calling > * 

>       *     Class.forName(i, false, loader)
>       *
> - * where loader is determined as follows: if there is a > - * method on the current thread's stack whose declaring class is not a > - * > - * platform class, then loader is > - * the class loader of such class; otherwise, loader > - * is the {@linkplain ClassLoader#getPlatformClassLoader() > + * where loader is the first class loader on the current > + * thread's stack (starting from the currently executing method) that is > + * neither the > + * platform class loader nor its ancestor; otherwise, > + * loader is the {@linkplain ClassLoader#getPlatformClassLoader() > * platform class loader}. > * Unless any of the resolved interfaces are non-public, this same value > * of loader is also the class loader passed to > * Proxy.getProxyClass; if non-public interfaces are present, > * their class loader is passed instead (if more than one non-public > * interface class loader is encountered, an > * IllegalAccessError is thrown). > * If Proxy.getProxyClass throws an > * IllegalArgumentException, resolveProxyClass > * will throw a ClassNotFoundException containing the > * IllegalArgumentException. > * > * @param interfaces the list of interface names that were > * deserialized in the proxy class descriptor > * @return a proxy class for the specified interfaces > * @throws IOException any exception thrown by the underlying > * InputStream > * @throws ClassNotFoundException if the proxy class or any of the > * named interfaces could not be found > * @see ObjectOutputStream#annotateProxyClass(Class) > > > -Chris. > From lance.andersen at oracle.com Tue Dec 6 11:56:17 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 6 Dec 2016 06:56:17 -0500 Subject: JDK-6253001 - Joinrowset bug - question on whether test code has been migrated? In-Reply-To: References: Message-ID: <5E2872A6-B5EB-4B04-BB34-07FD843D9089@oracle.com> Hi Martjin, > On Dec 6, 2016, at 4:22 AM, Martijn Verburg wrote: > > Hi all, > > The Adoption Group is having a go at collaboratively walking through the > process of resolving an open bug with the view of writing up the steps for > folks new to OpenJDK. > > We picked https://bugs.openjdk.java.net/browse/JDK-6253001 - a fairly > simple, low priority joinrowset bug reported in the sql area. Our > intention is to investigate the bug, reproduce it and *if* a fix is > required wait until the jdk 10 forests open to submit it there (as it's > only a P4). > > ----- > > Of course with older bugs there is a hidden history :-). The original test > is listed as living in: > > com.sun.rowset.tests.smoke.joinrowset.joinrowset3.JoinRowSet3.testJoinRowSet22 > > However we're unable to find that exact test which means that either: > > 1.) It's an internal Sun/Oracle test The test referenced in the bug is a test in an internal test suite which has since been retired. > 2.) It's been migrated / replaced by one of the tests in > *jdk/javax/sql/testing/test/rowset/joinrowset/JoinRowSetTests.java* That is correct > > Does anyone familiar with the tests around the SQL package know the history > here? Best Lance > > Cheers, > Martijn Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From chris.hegarty at oracle.com Tue Dec 6 12:25:29 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 6 Dec 2016 12:25:29 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: <9aa195c5-7fa5-38cd-51c6-664622a2cb9b@oracle.com> References: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> <2ECEE516-9083-4844-95FE-5DB154F3E46D@oracle.com> <9aa195c5-7fa5-38cd-51c6-664622a2cb9b@oracle.com> Message-ID: <854718B7-7805-4051-BE0B-17B9F07D015A@oracle.com> > On 6 Dec 2016, at 11:53, Daniel Fuchs wrote: > > Hi Chris, > > I have an additional suggestion: could you update the > comment of the private ObjectInputStream::latestUserDefinedLoader() > in the same file to align with what the method is actually > doing? > > I looked at what jdk.internal.misc.VM.latestUserDefinedLoader() > does, and the comment in ObjectInputStream::latestUserDefinedLoader() > doesn't seem to match the implementation. Right, the comment is now outdated and needs a refresh. I did this, along with removing the comment about the dependency from corba which was removed by 8164908 [1] ( which you pointed out off line ). Moved into a webrev, as the changes have grown a little: http://cr.openjdk.java.net/~chegar/8169653.00/ -Chris. [1] https://bugs.openjdk.java.net/browse/JDK-8164908 From daniel.fuchs at oracle.com Tue Dec 6 13:00:54 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Dec 2016 13:00:54 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: <854718B7-7805-4051-BE0B-17B9F07D015A@oracle.com> References: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> <2ECEE516-9083-4844-95FE-5DB154F3E46D@oracle.com> <9aa195c5-7fa5-38cd-51c6-664622a2cb9b@oracle.com> <854718B7-7805-4051-BE0B-17B9F07D015A@oracle.com> Message-ID: <8ab8924c-18eb-d0fc-29ea-56338b910913@oracle.com> Hi Chris, Looks good. I wonder about the two different links for platform class loader now. Should the first one perhaps include "nor its ancestor" in the link text? best regards, -- daniel On 06/12/16 12:25, Chris Hegarty wrote: > >> On 6 Dec 2016, at 11:53, Daniel Fuchs wrote: >> >> Hi Chris, >> >> I have an additional suggestion: could you update the >> comment of the private ObjectInputStream::latestUserDefinedLoader() >> in the same file to align with what the method is actually >> doing? >> >> I looked at what jdk.internal.misc.VM.latestUserDefinedLoader() >> does, and the comment in ObjectInputStream::latestUserDefinedLoader() >> doesn't seem to match the implementation. > > Right, the comment is now outdated and needs a refresh. I did this, along with > removing the comment about the dependency from corba which was removed > by 8164908 [1] ( which you pointed out off line ). > > Moved into a webrev, as the changes have grown a little: > http://cr.openjdk.java.net/~chegar/8169653.00/ > > -Chris. > > [1] https://bugs.openjdk.java.net/browse/JDK-8164908 > From goetz.lindenmaier at sap.com Tue Dec 6 13:12:30 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Tue, 6 Dec 2016 13:12:30 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. Message-ID: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> Hi, This change fixes some minor issues found in our code scans. I hope this correctly addresses corelib and serviceability issues. Please review: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ Best regards, Goetz. Changes in detail: e_asin.c Code scan reports missing {}. The code "if (huge+x>one) {" is only there to set the inexact flag of the processor. It's a way to avoid the C compiler to optimize the code away. It is always true, so the parenthesis of the outer else don't matter. Although this basically just adds the {} I would like to submit this to avoid anybody else spends more the 30sec on understanding these if statements. k_standard.c exc.retval is returned below and thus should always be initialized. imageDecompressor.cpp Wrong destructor is used. Reported also by David CARLIER java.c in line 1865 'name' was used, it should be 'alias'. java_md_solinux.c "//" in path is useless. Further down a free is missing. SDE.c Call to stratumTableIndex can return negative value if defaultStratumId == null. socket_md.c arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in the macros. unpack.cpp n.slice should not get negative argument for end, which is passed from dollar1. But dollar1 can get negative where it is set to the result of lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). From chris.hegarty at oracle.com Tue Dec 6 14:17:02 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 6 Dec 2016 14:17:02 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: <8ab8924c-18eb-d0fc-29ea-56338b910913@oracle.com> References: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> <2ECEE516-9083-4844-95FE-5DB154F3E46D@oracle.com> <9aa195c5-7fa5-38cd-51c6-664622a2cb9b@oracle.com> <854718B7-7805-4051-BE0B-17B9F07D015A@oracle.com> <8ab8924c-18eb-d0fc-29ea-56338b910913@oracle.com> Message-ID: > On 6 Dec 2016, at 13:00, Daniel Fuchs wrote: > > Hi Chris, > > Looks good. I wonder about the two different links for > platform class loader now. > ... You?re right. Since getPlatformClassLoader has a link to the built-in loader verbiage, how about we just drop the direct link? Developers can follow through getPlatformClassLoader. http://cr.openjdk.java.net/~chegar/8169653.01/ -Chris. From daniel.fuchs at oracle.com Tue Dec 6 14:56:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Dec 2016 14:56:13 +0000 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: References: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> <2ECEE516-9083-4844-95FE-5DB154F3E46D@oracle.com> <9aa195c5-7fa5-38cd-51c6-664622a2cb9b@oracle.com> <854718B7-7805-4051-BE0B-17B9F07D015A@oracle.com> <8ab8924c-18eb-d0fc-29ea-56338b910913@oracle.com> Message-ID: On 06/12/16 14:17, Chris Hegarty wrote: > >> On 6 Dec 2016, at 13:00, Daniel Fuchs wrote: >> >> Hi Chris, >> >> Looks good. I wonder about the two different links for >> platform class loader now. >> ... > > You?re right. Since getPlatformClassLoader has a link to the built-in loader > verbiage, how about we just drop the direct link? Developers can follow through > getPlatformClassLoader. > > http://cr.openjdk.java.net/~chegar/8169653.01/ Looks good to me Chris. Thanks! -- daniel > > -Chris. > From Roger.Riggs at Oracle.com Tue Dec 6 15:27:17 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Dec 2016 10:27:17 -0500 Subject: RFR of JDK-8170704: java/rmi/activation/Activatable/* tests fails intermittently with "output improperly annotated" In-Reply-To: <864e209d-7d37-8396-103c-e4a0d927d026@oracle.com> References: <864e209d-7d37-8396-103c-e4a0d927d026@oracle.com> Message-ID: Hi, I'm rather partial to fractional timeoutFactors, especially those < 1.0, useful for debugging and not having to wait. Can the conversion to long be deferred until it is used? (The other TestLibrary has a Util function to scale the timeout, but not the RMI one... arg technical debt!) Roger On 12/6/2016 5:19 AM, Daniel Fuchs wrote: > Looks reasonable to me Hamlin! > > best regards, > > -- daniel > > On 06/12/16 07:18, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8170704 >> webrev: http://cr.openjdk.java.net/~mli/8170704/webrev.00/ >> >> * Root Cause: >> The issue can be reproduced by adjust sleeping time to smaller values, >> so on busy machine it's possible that the sleeping time is not long >> enough for rmi system to pass myRMI err/out to rmid err/out. >> * Solution: >> scale timeout by time factor. >> >> Thank you >> -Hamlin > From Roger.Riggs at Oracle.com Tue Dec 6 15:45:55 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Dec 2016 10:45:55 -0500 Subject: RFR 8081390, javax/management/remote/mandatory/connection/RMIConnector_NPETest.java may leave orphaned processes In-Reply-To: <41e335bb-e74d-7b59-451d-f1ae68777308@oracle.com> References: <32e4ef1a-d023-997e-e88b-fdaab0a42cdb@oracle.com> <98f4903f-4107-8c25-417d-4fd12aad8496@oracle.com> <5b3e8d96-3693-3571-f1c2-1c52b3e0c1d7@oracle.com> <41e335bb-e74d-7b59-451d-f1ae68777308@oracle.com> Message-ID: <1b9931c3-52be-00cc-4fb6-634a8327884b@Oracle.com> Hi, Looks fine, rmid will be destroyed in the finally clause. !! There is no description in the bug and the open comments are unenlightening. Attaching one of the failing logs would be have been useful. Roger On 12/6/2016 2:32 AM, Hamlin Li wrote: > I see, looks fine. But I'm not a reviewer. > > Thank you > -Hamlin > > On 2016/12/6 11:38, Felix Yang wrote: >> Hi Hamlin, >> >> as stated in the bug, the timeout is more-likely a test setup >> issue that small timeout factor together with "-Xcomp". >> >> But in theory, if not put rmid.start() in finally, it indeed >> possibly leaves orphaned processes. So that is still a minor problem >> to fix. >> >> Thanks, >> Felix >> On 2016/12/6 11:26, Hamlin Li wrote: >>> Hi Felix, >>> >>> As the issue is timeout at rmid.start(), so it does not resolve the >>> issue to just move rmid.start() to try block. >>> >>> I saw the issue happened last in 2015/6, maybe we could just close >>> it as "Not Reproduced"? >>> >>> >>> Thank you >>> -Hamlin >>> >>> On 2016/12/6 10:08, Felix Yang wrote: >>>> Hi, >>>> >>>> please review the small fix to avoid orphaned processes left. >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8081390 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~xiaofeya/8081390/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Felix >>>> >>> >> > From felix.yang at oracle.com Tue Dec 6 15:54:45 2016 From: felix.yang at oracle.com (Felix Yang) Date: Tue, 6 Dec 2016 23:54:45 +0800 Subject: RFR 8081390, javax/management/remote/mandatory/connection/RMIConnector_NPETest.java may leave orphaned processes In-Reply-To: <1b9931c3-52be-00cc-4fb6-634a8327884b@Oracle.com> References: <32e4ef1a-d023-997e-e88b-fdaab0a42cdb@oracle.com> <98f4903f-4107-8c25-417d-4fd12aad8496@oracle.com> <5b3e8d96-3693-3571-f1c2-1c52b3e0c1d7@oracle.com> <41e335bb-e74d-7b59-451d-f1ae68777308@oracle.com> <1b9931c3-52be-00cc-4fb6-634a8327884b@Oracle.com> Message-ID: <475ba836-a7c8-90fe-7e9d-c13c93a1a991@oracle.com> Hi Roger, thanks for the comments. I added more information to the comments. -Felix On 2016/12/6 23:45, Roger Riggs wrote: > Hi, > > Looks fine, rmid will be destroyed in the finally clause. > > !! There is no description in the bug and the open comments are > unenlightening. > Attaching one of the failing logs would be have been useful. > > Roger > > On 12/6/2016 2:32 AM, Hamlin Li wrote: >> I see, looks fine. But I'm not a reviewer. >> >> Thank you >> -Hamlin >> >> On 2016/12/6 11:38, Felix Yang wrote: >>> Hi Hamlin, >>> >>> as stated in the bug, the timeout is more-likely a test setup >>> issue that small timeout factor together with "-Xcomp". >>> >>> But in theory, if not put rmid.start() in finally, it indeed >>> possibly leaves orphaned processes. So that is still a minor problem >>> to fix. >>> >>> Thanks, >>> Felix >>> On 2016/12/6 11:26, Hamlin Li wrote: >>>> Hi Felix, >>>> >>>> As the issue is timeout at rmid.start(), so it does not resolve the >>>> issue to just move rmid.start() to try block. >>>> >>>> I saw the issue happened last in 2015/6, maybe we could just close >>>> it as "Not Reproduced"? >>>> >>>> >>>> Thank you >>>> -Hamlin >>>> >>>> On 2016/12/6 10:08, Felix Yang wrote: >>>>> Hi, >>>>> >>>>> please review the small fix to avoid orphaned processes left. >>>>> >>>>> Bug: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8081390 >>>>> >>>>> Webrev: >>>>> >>>>> http://cr.openjdk.java.net/~xiaofeya/8081390/webrev.00/ >>>>> >>>>> Thanks, >>>>> >>>>> Felix >>>>> >>>> >>> >> > From dmitry.samersoff at oracle.com Tue Dec 6 15:59:26 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Tue, 6 Dec 2016 18:59:26 +0300 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> Message-ID: Goetz, For serviceability code, please see comments below: * src/java.base/share/native/libjli/java.c No comments * src/java.base/unix/native/libjli/java_md_solinux.c Is this line correct? 519 jvmpath = JLI_StringDup(jvmpath); * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c It might be better to return immediately if cnt < 0, regardless of value of sti. * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c It might be better to write arg.l_linger = (on) ? (unsigned short)value.i : 0; and leave one copy of setsockopt() call -Dmitry On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > Hi, > > > > This change fixes some minor issues found in our code scans. > > I hope this correctly addresses corelib and serviceability issues. > > > > Please review: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ > > > > Best regards, > > Goetz. > > > > Changes in detail: > > > > e_asin.c > > Code scan reports missing {}. > > > The code "if (huge+x>one) {" is only there to set the inexact flag of > the processor. > It's a way to avoid the C compiler to optimize the code away. It is > always true, > so the parenthesis of the outer else don't matter. > > Although this basically just adds the {} I would like to submit this to > > avoid anybody else spends more the 30sec on understanding these > > if statements. > > > k_standard.c > > exc.retval is returned below and thus should always be initialized. > > > imageDecompressor.cpp > > Wrong destructor is used. Reported also by David CARLIER > > > java.c > > in line 1865 'name' was used, it should be 'alias'. > > > java_md_solinux.c > > "//" in path is useless. Further down a free is missing. > > > SDE.c > > Call to stratumTableIndex can return negative value if defaultStratumId > == null. > > > socket_md.c > > arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > the macros. > > > unpack.cpp > > n.slice should not get negative argument for end, which is passed from > dollar1. > But dollar1 can get negative where it is set to the result of > lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From mandy.chung at oracle.com Tue Dec 6 16:44:37 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 6 Dec 2016 08:44:37 -0800 Subject: RFR 8169653: Restore ObjectInputStream::resolveClass call stack default search order In-Reply-To: References: <9697c4d3-c502-8348-183b-e8aa37326648@oracle.com> <2ECEE516-9083-4844-95FE-5DB154F3E46D@oracle.com> <9aa195c5-7fa5-38cd-51c6-664622a2cb9b@oracle.com> <854718B7-7805-4051-BE0B-17B9F07D015A@oracle.com> <8ab8924c-18eb-d0fc-29ea-56338b910913@oracle.com> Message-ID: <475015AB-D144-4BDE-9D0F-EF59BF49D0D7@oracle.com> > On Dec 6, 2016, at 6:17 AM, Chris Hegarty wrote: > > http://cr.openjdk.java.net/~chegar/8169653.01/ Looks good. Mandy From jason_mehrens at hotmail.com Tue Dec 6 17:09:19 2016 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 6 Dec 2016 17:09:19 +0000 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: References: Message-ID: Ivan, Will java.util.StringJoiner be modified too? I assume a nCopies char sequence object doesn't pan out performance wise? Thanks, Jason ________________________________________ From: core-libs-dev on behalf of Ivan Gerasimov Sent: Sunday, December 4, 2016 6:07 AM To: core-libs-dev at openjdk.java.net Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char Hello! There are several places in JDK where the same character is appended to a StringBuilder object multiple times (usually padding). With each append there are a few routine checks performed. They could have been done only once, if we had a method for appending multiple copies at a time. A simple benchmark shows that such method may save us a few machine cycles (see the results below). In the benchmark, three approaches were compared: 0) Using the new appendN(char, int) method to append several chars at once, 1) Calling append(char) in a loop, 2) Appending a prepared-in-advance string On my machine, the new method demonstrates better or comparable performance for all sizes up to 20. In the webrev, there are two changesets included: - the new default Appendable.appendN(char, int) method, its overrides in StringBuilder/Buffer and a basic test, - several applications of the new method across JDK. Would you please help review? Comments, suggestions are welcome. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170348 WEBREV: http://cr.openjdk.java.net/~igerasim/8170348/00/webrev/ Benchmark: http://cr.openjdk.java.net/~igerasim/8170348/00/MyBenchmark.java Benchmark (size) Mode Cnt Score Error Units MyBenchmark.test_0_New 0 thrpt 70 331922128.215 ? 16399254.452 ops/s MyBenchmark.test_0_New 1 thrpt 70 209207932.893 ? 14955800.231 ops/s MyBenchmark.test_0_New 5 thrpt 70 72926671.621 ? 4841791.555 ops/s MyBenchmark.test_0_New 10 thrpt 70 67779575.053 ? 3234366.239 ops/s MyBenchmark.test_0_New 20 thrpt 70 59731629.661 ? 2769497.288 ops/s MyBenchmark.test_1_Old 0 thrpt 70 333467628.860 ? 15981678.430 ops/s MyBenchmark.test_1_Old 1 thrpt 70 156126381.967 ? 9619653.294 ops/s MyBenchmark.test_1_Old 5 thrpt 70 46550204.382 ? 2009987.637 ops/s MyBenchmark.test_1_Old 10 thrpt 70 23309297.849 ? 1268874.282 ops/s MyBenchmark.test_1_Old 20 thrpt 70 13143637.821 ? 662265.103 ops/s MyBenchmark.test_2_Solid 0 thrpt 70 138548108.540 ? 6408775.462 ops/s MyBenchmark.test_2_Solid 1 thrpt 70 63890936.132 ? 3918274.970 ops/s MyBenchmark.test_2_Solid 5 thrpt 70 65838879.075 ? 2701493.698 ops/s MyBenchmark.test_2_Solid 10 thrpt 70 65387238.993 ? 3131562.548 ops/s MyBenchmark.test_2_Solid 20 thrpt 70 57528150.828 ? 3171453.716 ops/s With kind regards, Ivan From mandy.chung at oracle.com Tue Dec 6 17:30:27 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 6 Dec 2016 09:30:27 -0800 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> Message-ID: > On Dec 6, 2016, at 1:36 AM, Sergei Kovalev wrote: > > Hi Daniel, > > Please take a look at http://cr.openjdk.java.net/~skovalev/8170664/webrev.01/ 109 boolean simleConsoleOnly = !Layer.boot().findModule("java.logging").isPresent(); typo: s/simle/simple 107 Class sploggerType = splogger.getClass(); : 123 Class sloggerType = slogger.getClass(); 124 System.out.println("slogger: " + sloggerType); 125 if (sloggerType.equals(sploggerType)) { This check is redundant. Is this the intended check? Assuming the above check is not needed, you can further simplify something like this: String expectedType = Layer.boot().findModule("java.logging").isPresent() ? "SimpleConsoleLogger" : "JdkLazyLogger?; Mandy From daniel.fuchs at oracle.com Tue Dec 6 17:49:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 6 Dec 2016 17:49:13 +0000 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> Message-ID: On 06/12/16 17:30, Mandy Chung wrote: > >> On Dec 6, 2016, at 1:36 AM, Sergei Kovalev wrote: >> >> Hi Daniel, >> >> Please take a look at http://cr.openjdk.java.net/~skovalev/8170664/webrev.01/ > > 109 boolean simleConsoleOnly = !Layer.boot().findModule("java.logging").isPresent(); > > typo: s/simle/simple > > 107 Class sploggerType = splogger.getClass(); > : > 123 Class sloggerType = slogger.getClass(); > 124 System.out.println("slogger: " + sloggerType); > 125 if (sloggerType.equals(sploggerType)) { > > This check is redundant. Is this the intended check? > > Assuming the above check is not needed, you can further simplify something like this: > > String expectedType = Layer.boot().findModule("java.logging").isPresent() > ? "SimpleConsoleLogger" : "JdkLazyLogger?; Hi Mandy, No it's not redundant. Sorry for using bad variable names which differ only by 1 letter. splogger => System.Logger returned for a platform class (loaded by platform class loader) slogger => System.Logger returned for a regular class (not loaded by platform logger or its ancestor). if java.logging is not present and no provider is found then both will be a SimpleConsoleLogger, otherwise the former will be a lazy logger, and the latter a logger returned by java.logging implementation of the DefaultLoggerFinder... Before 8163162 they would have been of the same class - so the test just checks that 8163162 is doing what we expect. best regards, -- daniel > > Mandy > From martinrb at google.com Tue Dec 6 17:53:25 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 Dec 2016 09:53:25 -0800 Subject: default methods inherited by EnumSet and EnumMap In-Reply-To: References: Message-ID: Almost every core library collection class can benefit from overriding those default methods for performance. But it hasn't been done consistently - I noticed this myself recently in other collection classes; we have an effort under way to fix that for jdk9 (notably ArrayDeque). But EnumMap/EnumSet have probably fallen into the orphaned bucket. On Tue, Dec 6, 2016 at 12:03 AM, Michael Hixson wrote: > Hello, > > I notice that EnumSet and EnumMap don't override any of the default > methods that were added to collections in Java 8. Were they > specifically considered then avoided during the Java 8 upgrades, or > was it simply that no one got around to optimizing them? Are there > existing issues/bugs for optimizing them? I couldn't find any. > > As one example: I suspect that EnumMap.forEach(action) could improve > a lot. Right now it looks like iterating over keySet() and calling > get(key) is faster than forEach(action) when it comes to EnumMap > (unlike every other Map implementation I tested). > > -Michael > From paul.sandoz at oracle.com Tue Dec 6 20:00:29 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Dec 2016 12:00:29 -0800 Subject: default methods inherited by EnumSet and EnumMap In-Reply-To: References: Message-ID: <9124E36C-D4BB-4A24-93B7-F1E9AC194556@oracle.com> I logged this issue for EnumSet/EnumMap: https://bugs.openjdk.java.net/browse/JDK-8170826 Paul. > On 6 Dec 2016, at 09:53, Martin Buchholz wrote: > > Almost every core library collection class can benefit from overriding > those default methods for performance. > But it hasn't been done consistently - I noticed this myself recently in > other collection classes; we have an effort under way to fix that for jdk9 > (notably ArrayDeque). But EnumMap/EnumSet have probably fallen into the > orphaned bucket. > > On Tue, Dec 6, 2016 at 12:03 AM, Michael Hixson > wrote: > >> Hello, >> >> I notice that EnumSet and EnumMap don't override any of the default >> methods that were added to collections in Java 8. Were they >> specifically considered then avoided during the Java 8 upgrades, or >> was it simply that no one got around to optimizing them? Are there >> existing issues/bugs for optimizing them? I couldn't find any. >> >> As one example: I suspect that EnumMap.forEach(action) could improve >> a lot. Right now it looks like iterating over keySet() and calling >> get(key) is faster than forEach(action) when it comes to EnumMap >> (unlike every other Map implementation I tested). >> >> -Michael >> From stuart.marks at oracle.com Tue Dec 6 21:28:54 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 6 Dec 2016 13:28:54 -0800 Subject: RFR(s): 8166446 SingletonIterator.forEachRemaining doesn't advance before calling action Message-ID: Hi all, Please review this small fix to adjust the behavior of SingletonIterator.forEachRemaining in the case where its action throws an exception: http://cr.openjdk.java.net/~smarks/reviews/8166446/webrev.0/ Strictly speaking, this behavior is undefined (see the spec adjustment JDK-8168745 [1] [2] that Paul Sandoz pushed recently). However, we felt it was reasonable to make this case behave consistently with the default implementation of Iterator.forEachRemaining(), which advances before calling the action. Also, please ignore the extra changeset comment lines in the webrev. There's only one changeset here: rev 16204 : 8166446: SingletonIterator.forEachRemaining doesn't advance before calling action Something funny is up with webrev.... Thanks, s'marks [1] https://bugs.openjdk.java.net/browse/JDK-8168745 [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a563aaa85446 From martinrb at google.com Tue Dec 6 21:48:42 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 Dec 2016 13:48:42 -0800 Subject: RFR(s): 8166446 SingletonIterator.forEachRemaining doesn't advance before calling action In-Reply-To: References: Message-ID: Looks good. I've called similar methods assertIteratorExhausted instead of checkAtEnd. You could add it.forEachRemaining(e -> throw new AssertionError()); to that method. On Tue, Dec 6, 2016 at 1:28 PM, Stuart Marks wrote: > Hi all, > > Please review this small fix to adjust the behavior of > SingletonIterator.forEachRemaining in the case where its action throws an > exception: > > http://cr.openjdk.java.net/~smarks/reviews/8166446/webrev.0/ > > Strictly speaking, this behavior is undefined (see the spec adjustment > JDK-8168745 [1] [2] that Paul Sandoz pushed recently). However, we felt it > was reasonable to make this case behave consistently with the default > implementation of Iterator.forEachRemaining(), which advances before > calling the action. > > Also, please ignore the extra changeset comment lines in the webrev. > There's only one changeset here: > > rev 16204 : 8166446: SingletonIterator.forEachRemaining doesn't > advance before calling action > > Something funny is up with webrev.... > > Thanks, > > s'marks > > > [1] https://bugs.openjdk.java.net/browse/JDK-8168745 > > [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a563aaa85446 > From mandy.chung at oracle.com Tue Dec 6 22:03:49 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 6 Dec 2016 14:03:49 -0800 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> Message-ID: > On Dec 6, 2016, at 9:49 AM, Daniel Fuchs wrote: > > On 06/12/16 17:30, Mandy Chung wrote: >> >>> On Dec 6, 2016, at 1:36 AM, Sergei Kovalev wrote: >>> >>> Hi Daniel, >>> >>> Please take a look at http://cr.openjdk.java.net/~skovalev/8170664/webrev.01/ >> >> 109 boolean simleConsoleOnly = !Layer.boot().findModule("java.logging").isPresent(); >> >> typo: s/simle/simple >> >> 107 Class sploggerType = splogger.getClass(); >> : >> 123 Class sloggerType = slogger.getClass(); >> 124 System.out.println("slogger: " + sloggerType); >> 125 if (sloggerType.equals(sploggerType)) { >> >> This check is redundant. Is this the intended check? >> >> Assuming the above check is not needed, you can further simplify something like this: >> >> String expectedType = Layer.boot().findModule("java.logging").isPresent() >> ? "SimpleConsoleLogger" : "JdkLazyLogger?; > > Hi Mandy, > > No it's not redundant. Sorry for using bad variable names > which differ only by 1 letter. Ah I missed that one character difference. Perhaps removing letter ?s? would make it easier to distinguish. There are a couple raw type Class. It might be good to change them to Class. otherwise looks fine. Mandy From Roger.Riggs at Oracle.com Tue Dec 6 22:04:50 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Dec 2016 17:04:50 -0500 Subject: RFR 9: 8170291 : Unpredictable results of j.i.ObjectInputFilter::createFilter Message-ID: Please review a few additional clarifications to the ObjectInputFilter specification for generating a filter from a pattern and use in ObjectInputStream plus related test updates. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-createfilter-8170287/ Thanks, Roger From xueming.shen at oracle.com Tue Dec 6 22:14:07 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 06 Dec 2016 14:14:07 -0800 Subject: RFR 9: JDK-8170828: test/java/util/zip/ZipFile/TestZipFile needs @modules to work with Method.setAccessible() Message-ID: <5847382F.8080903@oracle.com> Hi, Please help review the change for #8170828 issue: https://bugs.openjdk.java.net/browse/JDK-8170828 webrev: http://cr.openjdk.java.net/~sherman/8170828 The offending test case started to fail because the new @modules: xxx:open tag is missing for it to access java.base private method. Thanks, Sherman From martinrb at google.com Tue Dec 6 22:16:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 6 Dec 2016 14:16:57 -0800 Subject: RFR 9: JDK-8170828: test/java/util/zip/ZipFile/TestZipFile needs @modules to work with Method.setAccessible() In-Reply-To: <5847382F.8080903@oracle.com> References: <5847382F.8080903@oracle.com> Message-ID: Looks good to me! On Tue, Dec 6, 2016 at 2:14 PM, Xueming Shen wrote: > Hi, > > Please help review the change for #8170828 > > issue: https://bugs.openjdk.java.net/browse/JDK-8170828 > webrev: http://cr.openjdk.java.net/~sherman/8170828 > > The offending test case started to fail because the new @modules: xxx:open > tag > is missing for it to access java.base private method. > > Thanks, > Sherman > > From Roger.Riggs at Oracle.com Tue Dec 6 22:17:11 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 6 Dec 2016 17:17:11 -0500 Subject: RFR 9: JDK-8170828: test/java/util/zip/ZipFile/TestZipFile needs @modules to work with Method.setAccessible() In-Reply-To: <5847382F.8080903@oracle.com> References: <5847382F.8080903@oracle.com> Message-ID: <5a7fe5f9-a6fa-0346-3fd3-316a4b8acc04@Oracle.com> Hi Sherman, Looks fine. The issue should have a label noreg-self. Roger On 12/6/2016 5:14 PM, Xueming Shen wrote: > Hi, > > Please help review the change for #8170828 > > issue: https://bugs.openjdk.java.net/browse/JDK-8170828 > webrev: http://cr.openjdk.java.net/~sherman/8170828 > > The offending test case started to fail because the new @modules: > xxx:open tag > is missing for it to access java.base private method. > > Thanks, > Sherman > From paul.sandoz at oracle.com Tue Dec 6 23:59:10 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 6 Dec 2016 15:59:10 -0800 Subject: RFR(s): 8166446 SingletonIterator.forEachRemaining doesn't advance before calling action In-Reply-To: References: Message-ID: <74831614-FFBE-4CB4-B063-F3BCADBB8F72@oracle.com> > On 6 Dec 2016, at 13:28, Stuart Marks wrote: > > Hi all, > > Please review this small fix to adjust the behavior of SingletonIterator.forEachRemaining in the case where its action throws an exception: > > http://cr.openjdk.java.net/~smarks/reviews/8166446/webrev.0/ > +1 Paul. From naoto.sato at oracle.com Wed Dec 7 00:02:35 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 6 Dec 2016 16:02:35 -0800 Subject: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190 Message-ID: <239843b3-e78f-0dc6-0432-577d2f205950@oracle.com> Hello, Please review the proposed fix to the following issues: https://bugs.openjdk.java.net/browse/JDK-8170465 https://bugs.openjdk.java.net/browse/JDK-8170466 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.00/ These two JNI calls (NewStringUTF() and JNU_CallMethodByName()) in src/java.base/share/native/libjava/jni_util.c can throw an exception. Those possible exceptions need to be properly checked. Naoto From xueming.shen at oracle.com Wed Dec 7 00:14:15 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Tue, 06 Dec 2016 16:14:15 -0800 Subject: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos Message-ID: <58475457.6090503@oracle.com> Hi, Please help review.commit the proposed change for JDK8170831 issue: https://bugs.openjdk.java.net/browse/JDK-8170831 webrev: http://cr.openjdk.java.net/~sherman/8170831/ (1) As explained in the issue description, the new implementation now does not have the cache mechanism as the old C implementation does (the C implementation still is still in repo, take a look at "jdk/src/java.base/share/native/libzip/zip_util.c#Zip_GetEntry2(...)". the corresponding cache is stored in zip->cache, "zip_util.h#trypedef struct jzfile/cache". (2) instead of having this cache in class ZipFile.Source, the cached pair is now at ZipFile level for simplicity. (3) I now simply compare the identity of the entry "name", to avoid the unnecessary string comparing operation, with the assumption that it's rare that someone will replace the entry name filed of the returned ZipEntry with a new String object with the same value and come back for the InputStream. (4) given currently there is no easy way to generate a zip/jar file with same entry name in test case (out ZipInputStream does not such use scenario, with an exception), I'm not adding new test case as the regression test, but I do have verified the change with the jar files that have entries with same name but different bytes. opinion? Thanks, Xueming From mandy.chung at oracle.com Wed Dec 7 00:16:24 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 6 Dec 2016 16:16:24 -0800 Subject: RFR 9: JDK-8170828: test/java/util/zip/ZipFile/TestZipFile needs @modules to work with Method.setAccessible() In-Reply-To: <5847382F.8080903@oracle.com> References: <5847382F.8080903@oracle.com> Message-ID: <8014C80A-BD91-4954-847D-63532C828B22@oracle.com> > On Dec 6, 2016, at 2:14 PM, Xueming Shen wrote: > > Hi, > > Please help review the change for #8170828 > > issue: https://bugs.openjdk.java.net/browse/JDK-8170828 > webrev: http://cr.openjdk.java.net/~sherman/8170828 > +1 > The offending test case started to fail because the new @modules: xxx:open tag is missing for it to access java.base private method. Thanks for fixing it. It?s a manual test that explained why it?s missed. Mandy From david.holmes at oracle.com Wed Dec 7 00:53:33 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Dec 2016 10:53:33 +1000 Subject: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190 In-Reply-To: <239843b3-e78f-0dc6-0432-577d2f205950@oracle.com> References: <239843b3-e78f-0dc6-0432-577d2f205950@oracle.com> Message-ID: Hi Naoto, On 7/12/2016 10:02 AM, Naoto Sato wrote: > Hello, > > Please review the proposed fix to the following issues: > > https://bugs.openjdk.java.net/browse/JDK-8170465 > https://bugs.openjdk.java.net/browse/JDK-8170466 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.00/ > > These two JNI calls (NewStringUTF() and JNU_CallMethodByName()) in > src/java.base/share/native/libjava/jni_util.c can throw an exception. > Those possible exceptions need to be properly checked. JNU_CHECK_EXCEPTION will do a return from the method in which it is placed, so you need to be careful to ensure you do all needed cleanup before that eg: 203 JNU_CHECK_EXCEPTION(env); 204 free(str1); needs to be reversed else we won't free str1. Similarly: 210 JNU_CHECK_EXCEPTION(env); 211 (*env)->DeleteLocalRef(env, s2); needs to be reversed so we don't leak the local ref. (It is safe to call DeleteLocalRef with an exception pending.) Thanks, David > Naoto From naoto.sato at oracle.com Wed Dec 7 01:04:42 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 6 Dec 2016 17:04:42 -0800 Subject: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190 In-Reply-To: References: <239843b3-e78f-0dc6-0432-577d2f205950@oracle.com> Message-ID: Thanks, David. The fix is modified accordingly: http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.01/ Naoto On 12/6/16 4:53 PM, David Holmes wrote: > Hi Naoto, > > On 7/12/2016 10:02 AM, Naoto Sato wrote: >> Hello, >> >> Please review the proposed fix to the following issues: >> >> https://bugs.openjdk.java.net/browse/JDK-8170465 >> https://bugs.openjdk.java.net/browse/JDK-8170466 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.00/ >> >> These two JNI calls (NewStringUTF() and JNU_CallMethodByName()) in >> src/java.base/share/native/libjava/jni_util.c can throw an exception. >> Those possible exceptions need to be properly checked. > > JNU_CHECK_EXCEPTION will do a return from the method in which it is > placed, so you need to be careful to ensure you do all needed cleanup > before that eg: > > 203 JNU_CHECK_EXCEPTION(env); > 204 free(str1); > > needs to be reversed else we won't free str1. Similarly: > > 210 JNU_CHECK_EXCEPTION(env); > 211 (*env)->DeleteLocalRef(env, s2); > > needs to be reversed so we don't leak the local ref. (It is safe to call > DeleteLocalRef with an exception pending.) > > Thanks, > David > >> Naoto From stuart.marks at oracle.com Wed Dec 7 01:20:26 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Tue, 6 Dec 2016 17:20:26 -0800 Subject: RFR(s): 8166446 SingletonIterator.forEachRemaining doesn't advance before calling action In-Reply-To: References: Message-ID: <29e80785-f1cd-56ba-eb70-90fc79d3fc53@oracle.com> Thanks. Good ideas. I've renamed that method and adjusted it a bit. s'marks On 12/6/16 1:48 PM, Martin Buchholz wrote: > Looks good. > > I've called similar methods assertIteratorExhausted instead of checkAtEnd. > You could add > > it.forEachRemaining(e -> throw new AssertionError()); > to that method. > > > > On Tue, Dec 6, 2016 at 1:28 PM, Stuart Marks > wrote: > > Hi all, > > Please review this small fix to adjust the behavior of > SingletonIterator.forEachRemaining in the case where its action throws an > exception: > > http://cr.openjdk.java.net/~smarks/reviews/8166446/webrev.0/ > > > Strictly speaking, this behavior is undefined (see the spec adjustment > JDK-8168745 [1] [2] that Paul Sandoz pushed recently). However, we felt it > was reasonable to make this case behave consistently with the default > implementation of Iterator.forEachRemaining(), which advances before > calling the action. > > Also, please ignore the extra changeset comment lines in the webrev. > There's only one changeset here: > > rev 16204 : 8166446: SingletonIterator.forEachRemaining doesn't > advance before calling action > > Something funny is up with webrev.... > > Thanks, > > s'marks > > > [1] https://bugs.openjdk.java.net/browse/JDK-8168745 > > > [2] http://hg.openjdk.java.net/jdk9/dev/jdk/rev/a563aaa85446 > > > From huaming.li at oracle.com Wed Dec 7 01:57:36 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 7 Dec 2016 09:57:36 +0800 Subject: RFR of JDK-8170704: java/rmi/activation/Activatable/* tests fails intermittently with "output improperly annotated" In-Reply-To: References: <864e209d-7d37-8396-103c-e4a0d927d026@oracle.com> Message-ID: <3221188b-4d1d-6849-d7b4-658f8e2c42fc@oracle.com> Hi Roger, Daniel, Thank you for reviewing, just modified as Roger suggested to defer the conversion until it is used, and pushed the code. -Hamlin On 2016/12/6 23:27, Roger Riggs wrote: > Hi, > > I'm rather partial to fractional timeoutFactors, especially those < > 1.0, useful for debugging and not having to wait. > Can the conversion to long be deferred until it is used? > > (The other TestLibrary has a Util function to scale the timeout, but > not the RMI one... arg technical debt!) > > Roger > > > On 12/6/2016 5:19 AM, Daniel Fuchs wrote: >> Looks reasonable to me Hamlin! >> >> best regards, >> >> -- daniel >> >> On 06/12/16 07:18, Hamlin Li wrote: >>> Would you please review the below patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8170704 >>> webrev: http://cr.openjdk.java.net/~mli/8170704/webrev.00/ >>> >>> * Root Cause: >>> The issue can be reproduced by adjust sleeping time to smaller values, >>> so on busy machine it's possible that the sleeping time is not long >>> enough for rmi system to pass myRMI err/out to rmid err/out. >>> * Solution: >>> scale timeout by time factor. >>> >>> Thank you >>> -Hamlin >> > From david.holmes at oracle.com Wed Dec 7 02:14:44 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Dec 2016 12:14:44 +1000 Subject: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190 In-Reply-To: References: <239843b3-e78f-0dc6-0432-577d2f205950@oracle.com> Message-ID: <77288838-abfa-30d7-45f4-1efaba15528a@oracle.com> On 7/12/2016 11:04 AM, Naoto Sato wrote: > Thanks, David. The fix is modified accordingly: > > http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.01/ Thanks for fixing that. The null checks after the exception checks are now redundant as you can only get a null return from those methods if an exception becomes pending. But leaving them in as a precaution is okay I guess. Thanks, David > Naoto > > On 12/6/16 4:53 PM, David Holmes wrote: >> Hi Naoto, >> >> On 7/12/2016 10:02 AM, Naoto Sato wrote: >>> Hello, >>> >>> Please review the proposed fix to the following issues: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8170465 >>> https://bugs.openjdk.java.net/browse/JDK-8170466 >>> >>> The proposed fix is located at: >>> >>> http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.00/ >>> >>> These two JNI calls (NewStringUTF() and JNU_CallMethodByName()) in >>> src/java.base/share/native/libjava/jni_util.c can throw an exception. >>> Those possible exceptions need to be properly checked. >> >> JNU_CHECK_EXCEPTION will do a return from the method in which it is >> placed, so you need to be careful to ensure you do all needed cleanup >> before that eg: >> >> 203 JNU_CHECK_EXCEPTION(env); >> 204 free(str1); >> >> needs to be reversed else we won't free str1. Similarly: >> >> 210 JNU_CHECK_EXCEPTION(env); >> 211 (*env)->DeleteLocalRef(env, s2); >> >> needs to be reversed so we don't leak the local ref. (It is safe to call >> DeleteLocalRef with an exception pending.) >> >> Thanks, >> David >> >>> Naoto From frank.yuan at oracle.com Wed Dec 7 03:15:24 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 7 Dec 2016 11:15:24 +0800 Subject: RFR JDK-8169948 [JAXP] Update ServiceProviderTest for newDefaultInstance() methods in JAXP factories Message-ID: <01f701d25038$287347c0$7959d740$@oracle.com> Hi all Would you like to review http://cr.openjdk.java.net/~fyuan/8169948/webrev.00/? Bug: https://bugs.openjdk.java.net/browse/JDK-8169948 This test update is because of JDK-8169778 Add new public methods to get new instances of the JAXP factories builtin system-default implementations. DefaultFactoryWrapperTest.java tests a provider that return a custom factory instance wrapping the built-in system-default implementation. Thanks Frank From huaming.li at oracle.com Wed Dec 7 06:46:23 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 7 Dec 2016 14:46:23 +0800 Subject: RFR of JDK-: failed test case is not checked in java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8170839 webrev: http://cr.openjdk.java.net/~mli/8170839/webrev.00/ Thank you -Hamlin ------------------------------------------------------------------------ diff -r 10b191e1793b test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java --- a/test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java Tue Dec 06 17:53:22 2016 -0800 +++ b/test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java Tue Dec 06 22:44:29 2016 -0800 @@ -1,5 +1,5 @@ /* - * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -140,7 +140,7 @@ System.err.println("invoking method on activatable object..."); try { obj1.ping(); - + throw new RuntimeException("ActivateFailedException is expected"); } catch (ActivateFailedException e) { /* From huaming.li at oracle.com Wed Dec 7 06:47:23 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 7 Dec 2016 14:47:23 +0800 Subject: RFR of JDK-8170839: failed test case is not checked in java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java In-Reply-To: References: Message-ID: correct the subject On 2016/12/7 14:46, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8170839 > > webrev: http://cr.openjdk.java.net/~mli/8170839/webrev.00/ > > > Thank you > -Hamlin > > ------------------------------------------------------------------------ > > diff -r 10b191e1793b > test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java > --- > a/test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java > Tue Dec 06 17:53:22 2016 -0800 > +++ > b/test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java > Tue Dec 06 22:44:29 2016 -0800 > @@ -1,5 +1,5 @@ > /* > - * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All rights > reserved. > + * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All rights > reserved. > * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. > * > * This code is free software; you can redistribute it and/or modify it > @@ -140,7 +140,7 @@ > System.err.println("invoking method on activatable > object..."); > try { > obj1.ping(); > - > + throw new RuntimeException("ActivateFailedException > is expected"); > } catch (ActivateFailedException e) { > > /* > From christoph.langer at sap.com Wed Dec 7 07:49:33 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 7 Dec 2016 07:49:33 +0000 Subject: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190 In-Reply-To: <77288838-abfa-30d7-45f4-1efaba15528a@oracle.com> References: <239843b3-e78f-0dc6-0432-577d2f205950@oracle.com> <77288838-abfa-30d7-45f4-1efaba15528a@oracle.com> Message-ID: <20d2a445ae254bd1b81228165dbb1dcf@DEWDFE13DE03.global.corp.sap> Hi Naoto, the new webrev looks ok to me, too. Thanks for fixing. And I agree to the point that the NULL check can be removed...if you like. Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of David Holmes > Sent: Mittwoch, 7. Dezember 2016 03:15 > To: Naoto Sato ; core-libs-dev dev at openjdk.java.net> > Subject: Re: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190 > > On 7/12/2016 11:04 AM, Naoto Sato wrote: > > Thanks, David. The fix is modified accordingly: > > > > http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.01/ > > Thanks for fixing that. > > The null checks after the exception checks are now redundant as you can > only get a null return from those methods if an exception becomes > pending. But leaving them in as a precaution is okay I guess. > > Thanks, > David > > > Naoto > > > > On 12/6/16 4:53 PM, David Holmes wrote: > >> Hi Naoto, > >> > >> On 7/12/2016 10:02 AM, Naoto Sato wrote: > >>> Hello, > >>> > >>> Please review the proposed fix to the following issues: > >>> > >>> https://bugs.openjdk.java.net/browse/JDK-8170465 > >>> https://bugs.openjdk.java.net/browse/JDK-8170466 > >>> > >>> The proposed fix is located at: > >>> > >>> http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.00/ > >>> > >>> These two JNI calls (NewStringUTF() and JNU_CallMethodByName()) in > >>> src/java.base/share/native/libjava/jni_util.c can throw an exception. > >>> Those possible exceptions need to be properly checked. > >> > >> JNU_CHECK_EXCEPTION will do a return from the method in which it is > >> placed, so you need to be careful to ensure you do all needed cleanup > >> before that eg: > >> > >> 203 JNU_CHECK_EXCEPTION(env); > >> 204 free(str1); > >> > >> needs to be reversed else we won't free str1. Similarly: > >> > >> 210 JNU_CHECK_EXCEPTION(env); > >> 211 (*env)->DeleteLocalRef(env, s2); > >> > >> needs to be reversed so we don't leak the local ref. (It is safe to call > >> DeleteLocalRef with an exception pending.) > >> > >> Thanks, > >> David > >> > >>> Naoto From goetz.lindenmaier at sap.com Wed Dec 7 08:37:35 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Dec 2016 08:37:35 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> Message-ID: <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Hi Dmitry, thanks for looking at my change! Updated webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > * src/java.base/unix/native/libjli/java_md_solinux.c > Is this line correct? > 519 jvmpath = JLI_StringDup(jvmpath); It seems pointless. Should I remove it? (The whole file is a horror.) > * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > It might be better to return immediately if cnt < 0, > regardless of value of sti. I'm not sure what you mean. I tried to fix it, but please double-check the new webrev. > * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > It might be better to write > arg.l_linger = (on) ? (unsigned short)value.i : 0; > and leave one copy of setsockopt() call Yes, looks better. Best regards, Goetz > > -Dmitry > > > On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > > Hi, > > > > > > > > This change fixes some minor issues found in our code scans. > > > > I hope this correctly addresses corelib and serviceability issues. > > > > > > > > Please review: > > > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ > > > > > > > > Best regards, > > > > Goetz. > > > > > > > > Changes in detail: > > > > > > > > e_asin.c > > > > Code scan reports missing {}. > > > > > > The code "if (huge+x>one) {" is only there to set the inexact flag of > > the processor. > > It's a way to avoid the C compiler to optimize the code away. It is > > always true, > > so the parenthesis of the outer else don't matter. > > > > Although this basically just adds the {} I would like to submit this to > > > > avoid anybody else spends more the 30sec on understanding these > > > > if statements. > > > > > > k_standard.c > > > > exc.retval is returned below and thus should always be initialized. > > > > > > imageDecompressor.cpp > > > > Wrong destructor is used. Reported also by David CARLIER > > > > > > java.c > > > > in line 1865 'name' was used, it should be 'alias'. > > > > > > java_md_solinux.c > > > > "//" in path is useless. Further down a free is missing. > > > > > > SDE.c > > > > Call to stratumTableIndex can return negative value if defaultStratumId > > == null. > > > > > > socket_md.c > > > > arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > > the macros. > > > > > > unpack.cpp > > > > n.slice should not get negative argument for end, which is passed from > > dollar1. > > But dollar1 can get negative where it is set to the result of > > lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > > > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From felix.yang at oracle.com Wed Dec 7 09:27:00 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 7 Dec 2016 17:27:00 +0800 Subject: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently In-Reply-To: <8cd1ba28-3dfb-6c69-312d-4a48072efa16@oracle.com> References: <3b5d8771-43f8-4205-cfa1-e6d6850793e9@oracle.com> <8cd1ba28-3dfb-6c69-312d-4a48072efa16@oracle.com> Message-ID: Hi Dmitry, thanks for the comments. My opinions inlined... Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.01/ -Felix On 2016/12/6 19:16, Dmitry Samersoff wrote: > Felix, > > 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for > this test. Could we use different one (e.g. icann.org) Probably not. I'm not sure about the test design history, but "icann.org" may require the test environment(inside Oracle) to set up proxy to access internet, otherwise the test may be just skipped silently. "javaweb.sfbay.sun.com" is accessible both inside and outside Oracle network. -Felix > > 2. This test run JTREG -> Test VM -> Another VM. Could we optimize > process usage? > > It might be better to create a jtreg "same vm" process that > > 1. launch another process with -Djava.net.preferIPv4Stack=true > that do A and PRT lookup in one run. > > 2. Read results of process above, do PTR lookup with default > settings and compare results. > > -Dmitry > > > On 2016-12-06 12:06, Felix Yang wrote: >> Hi, >> >> please review the following patch. It generally coverts codes from >> shell to plain java. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8169115 >> >> Webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/ >> >> Thanks, >> >> Felix >> > From david.holmes at oracle.com Wed Dec 7 09:31:50 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 7 Dec 2016 19:31:50 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: On 7/12/2016 6:37 PM, Lindenmaier, Goetz wrote: > Hi Dmitry, > > thanks for looking at my change! > Updated webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > >> * src/java.base/unix/native/libjli/java_md_solinux.c >> Is this line correct? >> 519 jvmpath = JLI_StringDup(jvmpath); > > It seems pointless. Should I remove it? (The whole file is a horror.) Seems to me it is making a copy of the incoming char[] so that it can be modified in this function without affecting the original char[] in the caller. David ----- >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >> It might be better to return immediately if cnt < 0, >> regardless of value of sti. > > I'm not sure what you mean. I tried to fix it, but please > double-check the new webrev. > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >> It might be better to write >> arg.l_linger = (on) ? (unsigned short)value.i : 0; >> and leave one copy of setsockopt() call > > Yes, looks better. > > Best regards, > Goetz > > >> >> -Dmitry >> >> >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> >>> >>> This change fixes some minor issues found in our code scans. >>> >>> I hope this correctly addresses corelib and serviceability issues. >>> >>> >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ >>> >>> >>> >>> Best regards, >>> >>> Goetz. >>> >>> >>> >>> Changes in detail: >>> >>> >>> >>> e_asin.c >>> >>> Code scan reports missing {}. >>> >>> >>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>> the processor. >>> It's a way to avoid the C compiler to optimize the code away. It is >>> always true, >>> so the parenthesis of the outer else don't matter. >>> >>> Although this basically just adds the {} I would like to submit this to >>> >>> avoid anybody else spends more the 30sec on understanding these >>> >>> if statements. >>> >>> >>> k_standard.c >>> >>> exc.retval is returned below and thus should always be initialized. >>> >>> >>> imageDecompressor.cpp >>> >>> Wrong destructor is used. Reported also by David CARLIER >>> >>> >>> java.c >>> >>> in line 1865 'name' was used, it should be 'alias'. >>> >>> >>> java_md_solinux.c >>> >>> "//" in path is useless. Further down a free is missing. >>> >>> >>> SDE.c >>> >>> Call to stratumTableIndex can return negative value if defaultStratumId >>> == null. >>> >>> >>> socket_md.c >>> >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>> the macros. >>> >>> >>> unpack.cpp >>> >>> n.slice should not get negative argument for end, which is passed from >>> dollar1. >>> But dollar1 can get negative where it is set to the result of >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Wed Dec 7 11:46:36 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 7 Dec 2016 11:46:36 +0000 Subject: RFR 9: 8170291 : Unpredictable results of j.i.ObjectInputFilter::createFilter In-Reply-To: References: Message-ID: Hi Roger, What about adding a bit of leeway in the reason for which IAE can be thrown. Here is the text from your webrev: 359 * @throws IllegalArgumentException If any of the following is true: 360 *
    361 *
  • if a limit is missing the name or the name is not one of 362 * "maxdepth", "maxrefs", "maxbytes", or "maxarray" 363 *
  • if the value of the limit can not be parsed by 364 * {@link Long#parseLong Long.parseLong} or is negative 365 *
  • if the pattern contains "/" and the module name is missing 366 * or the remaining pattern is empty 367 *
  • if the package is missing for ".*" and ".**" 368 *
could it be amended to something like: @throws IllegalArgumentException if the pattern string is illegal or malformed and cannot be parsed. In particular, an IllegalArgumentException will be thrown if any of the following is true: ... best regards, -- daniel On 06/12/16 22:04, Roger Riggs wrote: > Please review a few additional clarifications to the ObjectInputFilter > specification for generating > a filter from a pattern and use in ObjectInputStream plus related test > updates. > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-createfilter-8170287/ > > Thanks, Roger > From goetz.lindenmaier at sap.com Wed Dec 7 11:54:31 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Dec 2016 11:54:31 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: <0a542d83bca24747a6361215e522304b@DEROTE13DE08.global.corp.sap> Ah, you're right, the 'lastslash' assignment! Thanks, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Wednesday, December 07, 2016 10:32 AM > To: Lindenmaier, Goetz ; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 7/12/2016 6:37 PM, Lindenmaier, Goetz wrote: > > Hi Dmitry, > > > > thanks for looking at my change! > > Updated webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > > > >> * src/java.base/unix/native/libjli/java_md_solinux.c > >> Is this line correct? > >> 519 jvmpath = JLI_StringDup(jvmpath); > > > > It seems pointless. Should I remove it? (The whole file is a horror.) > > Seems to me it is making a copy of the incoming char[] so that it can be > modified in this function without affecting the original char[] in the > caller. > > David > ----- > > > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >> It might be better to return immediately if cnt < 0, > >> regardless of value of sti. > > > > I'm not sure what you mean. I tried to fix it, but please > > double-check the new webrev. > > > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >> It might be better to write > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >> and leave one copy of setsockopt() call > > > > Yes, looks better. > > > > Best regards, > > Goetz > > > > > >> > >> -Dmitry > >> > >> > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> > >>> > >>> This change fixes some minor issues found in our code scans. > >>> > >>> I hope this correctly addresses corelib and serviceability issues. > >>> > >>> > >>> > >>> Please review: > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.01/ > >>> > >>> > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> > >>> > >>> > >>> Changes in detail: > >>> > >>> > >>> > >>> e_asin.c > >>> > >>> Code scan reports missing {}. > >>> > >>> > >>> The code "if (huge+x>one) {" is only there to set the inexact flag of > >>> the processor. > >>> It's a way to avoid the C compiler to optimize the code away. It is > >>> always true, > >>> so the parenthesis of the outer else don't matter. > >>> > >>> Although this basically just adds the {} I would like to submit this to > >>> > >>> avoid anybody else spends more the 30sec on understanding these > >>> > >>> if statements. > >>> > >>> > >>> k_standard.c > >>> > >>> exc.retval is returned below and thus should always be initialized. > >>> > >>> > >>> imageDecompressor.cpp > >>> > >>> Wrong destructor is used. Reported also by David CARLIER > >>> > >>> > >>> java.c > >>> > >>> in line 1865 'name' was used, it should be 'alias'. > >>> > >>> > >>> java_md_solinux.c > >>> > >>> "//" in path is useless. Further down a free is missing. > >>> > >>> > >>> SDE.c > >>> > >>> Call to stratumTableIndex can return negative value if defaultStratumId > >>> == null. > >>> > >>> > >>> socket_md.c > >>> > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > >>> the macros. > >>> > >>> > >>> unpack.cpp > >>> > >>> n.slice should not get negative argument for end, which is passed from > >>> dollar1. > >>> But dollar1 can get negative where it is set to the result of > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>> > >> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Wed Dec 7 12:26:02 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 7 Dec 2016 12:26:02 +0000 Subject: RFR JDK-8169948 [JAXP] Update ServiceProviderTest for newDefaultInstance() methods in JAXP factories In-Reply-To: <01f701d25038$287347c0$7959d740$@oracle.com> References: <01f701d25038$287347c0$7959d740$@oracle.com> Message-ID: Hi Frank, Looks good to me! best regards, -- daniel On 07/12/16 03:15, Frank Yuan wrote: > Hi all > > > > Would you like to review > http://cr.openjdk.java.net/~fyuan/8169948/webrev.00/? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169948 > > > > This test update is because of JDK-8169778 Add new public methods to get > new instances of the JAXP factories builtin system-default > implementations. DefaultFactoryWrapperTest.java tests a provider that > return a custom factory instance wrapping the built-in system-default > implementation. > > > > > > Thanks > > Frank > From sergei.kovalev at oracle.com Wed Dec 7 12:26:45 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 7 Dec 2016 15:26:45 +0300 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> Message-ID: Hi Mandy, Daniel, Thank you for reviewing this. I've made a try to improve naming of variables. Also replaced row Class declaration. Please take a look. http://cr.openjdk.java.net/~skovalev/8170664/webrev.02/ -- With best regards, Sergei 07.12.16 01:03, Mandy Chung wrote: >> On Dec 6, 2016, at 9:49 AM, Daniel Fuchs wrote: >> >> On 06/12/16 17:30, Mandy Chung wrote: >>>> On Dec 6, 2016, at 1:36 AM, Sergei Kovalev wrote: >>>> >>>> Hi Daniel, >>>> >>>> Please take a look at http://cr.openjdk.java.net/~skovalev/8170664/webrev.01/ >>> 109 boolean simleConsoleOnly = !Layer.boot().findModule("java.logging").isPresent(); >>> >>> typo: s/simle/simple >>> >>> 107 Class sploggerType = splogger.getClass(); >>> : >>> 123 Class sloggerType = slogger.getClass(); >>> 124 System.out.println("slogger: " + sloggerType); >>> 125 if (sloggerType.equals(sploggerType)) { >>> >>> This check is redundant. Is this the intended check? >>> >>> Assuming the above check is not needed, you can further simplify something like this: >>> >>> String expectedType = Layer.boot().findModule("java.logging").isPresent() >>> ? "SimpleConsoleLogger" : "JdkLazyLogger?; >> Hi Mandy, >> >> No it's not redundant. Sorry for using bad variable names >> which differ only by 1 letter. > Ah I missed that one character difference. Perhaps removing letter ?s? would make it easier to distinguish. > > There are a couple raw type Class. It might be good to change them to Class. > > otherwise looks fine. > Mandy > From dmitry.samersoff at oracle.com Wed Dec 7 13:19:04 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 7 Dec 2016 16:19:04 +0300 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <0a542d83bca24747a6361215e522304b@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <0a542d83bca24747a6361215e522304b@DEROTE13DE08.global.corp.sap> Message-ID: Goetz, On 2016-12-07 14:54, Lindenmaier, Goetz wrote: > Ah, you're right, the 'lastslash' assignment! In this case we have to keep strdup. Could we at least change it to something like new_jvmpath = JLI_StringDup(jvmpath); and use new_jvmpath below. And yes, the whole file is a horror. -Dmitry > > Thanks, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Wednesday, December 07, 2016 10:32 AM >> To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 7/12/2016 6:37 PM, Lindenmaier, Goetz wrote: >>> Hi Dmitry, >>> >>> thanks for looking at my change! >>> Updated webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>> >>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>> Is this line correct? >>>> 519 jvmpath = JLI_StringDup(jvmpath); >>> >>> It seems pointless. Should I remove it? (The whole file is a horror.) >> >> Seems to me it is making a copy of the incoming char[] so that it can be >> modified in this function without affecting the original char[] in the >> caller. >> >> David >> ----- >> >> >>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>> It might be better to return immediately if cnt < 0, >>>> regardless of value of sti. >>> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >>> >>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>> It might be better to write >>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>> and leave one copy of setsockopt() call >>> >>> Yes, looks better. >>> >>> Best regards, >>> Goetz >>> >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> This change fixes some minor issues found in our code scans. >>>>> >>>>> I hope this correctly addresses corelib and serviceability issues. >>>>> >>>>> >>>>> >>>>> Please review: >>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.01/ >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> Changes in detail: >>>>> >>>>> >>>>> >>>>> e_asin.c >>>>> >>>>> Code scan reports missing {}. >>>>> >>>>> >>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>>>> the processor. >>>>> It's a way to avoid the C compiler to optimize the code away. It is >>>>> always true, >>>>> so the parenthesis of the outer else don't matter. >>>>> >>>>> Although this basically just adds the {} I would like to submit this to >>>>> >>>>> avoid anybody else spends more the 30sec on understanding these >>>>> >>>>> if statements. >>>>> >>>>> >>>>> k_standard.c >>>>> >>>>> exc.retval is returned below and thus should always be initialized. >>>>> >>>>> >>>>> imageDecompressor.cpp >>>>> >>>>> Wrong destructor is used. Reported also by David CARLIER >>>>> >>>>> >>>>> java.c >>>>> >>>>> in line 1865 'name' was used, it should be 'alias'. >>>>> >>>>> >>>>> java_md_solinux.c >>>>> >>>>> "//" in path is useless. Further down a free is missing. >>>>> >>>>> >>>>> SDE.c >>>>> >>>>> Call to stratumTableIndex can return negative value if defaultStratumId >>>>> == null. >>>>> >>>>> >>>>> socket_md.c >>>>> >>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>>>> the macros. >>>>> >>>>> >>>>> unpack.cpp >>>>> >>>>> n.slice should not get negative argument for end, which is passed from >>>>> dollar1. >>>>> But dollar1 can get negative where it is set to the result of >>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From daniel.fuchs at oracle.com Wed Dec 7 13:24:01 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 7 Dec 2016 13:24:01 +0000 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> Message-ID: Looks good to me Sergei! Thanks for making this change. best regards, -- daniel On 07/12/16 12:26, Sergei Kovalev wrote: > Hi Mandy, Daniel, > > Thank you for reviewing this. > > I've made a try to improve naming of variables. Also replaced row Class > declaration. Please take a look. > > http://cr.openjdk.java.net/~skovalev/8170664/webrev.02/ > From dmitry.samersoff at oracle.com Wed Dec 7 13:43:19 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 7 Dec 2016 16:43:19 +0300 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: Goetz, SDE.c: You might combine if at ll. 260 and 263 to one but it's just matter of test. if (sti == baseStratumIndex || sti < 0) { return; /* Java stratum - return unchanged */ } > I'm not sure what you mean. I tried to fix it, but please > double-check the new webrev. if cnt is <= 0 loop at l.267 for (; cnt-- > 0; ++fromEntry) { is never run and we effectively do *entryCountPtr = 0; at l.283 So if we you suspect that cnt may become negative or 0: (your v.01 changes) 260 if (sti < 0 && cnt > 0) { 261 return; 262 } it's better to check it early. But I'm not sure we have to care about negative/zero cnt here. -Dmitry On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > Hi Dmitry, > > thanks for looking at my change! > Updated webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > >> * src/java.base/unix/native/libjli/java_md_solinux.c >> Is this line correct? >> 519 jvmpath = JLI_StringDup(jvmpath); > > It seems pointless. Should I remove it? (The whole file is a horror.) > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >> It might be better to return immediately if cnt < 0, >> regardless of value of sti. > > I'm not sure what you mean. I tried to fix it, but please > double-check the new webrev. > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >> It might be better to write >> arg.l_linger = (on) ? (unsigned short)value.i : 0; >> and leave one copy of setsockopt() call > > Yes, looks better. > > Best regards, > Goetz > > >> >> -Dmitry >> >> >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> >>> >>> This change fixes some minor issues found in our code scans. >>> >>> I hope this correctly addresses corelib and serviceability issues. >>> >>> >>> >>> Please review: >>> >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.01/ >>> >>> >>> >>> Best regards, >>> >>> Goetz. >>> >>> >>> >>> Changes in detail: >>> >>> >>> >>> e_asin.c >>> >>> Code scan reports missing {}. >>> >>> >>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>> the processor. >>> It's a way to avoid the C compiler to optimize the code away. It is >>> always true, >>> so the parenthesis of the outer else don't matter. >>> >>> Although this basically just adds the {} I would like to submit this to >>> >>> avoid anybody else spends more the 30sec on understanding these >>> >>> if statements. >>> >>> >>> k_standard.c >>> >>> exc.retval is returned below and thus should always be initialized. >>> >>> >>> imageDecompressor.cpp >>> >>> Wrong destructor is used. Reported also by David CARLIER >>> >>> >>> java.c >>> >>> in line 1865 'name' was used, it should be 'alias'. >>> >>> >>> java_md_solinux.c >>> >>> "//" in path is useless. Further down a free is missing. >>> >>> >>> SDE.c >>> >>> Call to stratumTableIndex can return negative value if defaultStratumId >>> == null. >>> >>> >>> socket_md.c >>> >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>> the macros. >>> >>> >>> unpack.cpp >>> >>> n.slice should not get negative argument for end, which is passed from >>> dollar1. >>> But dollar1 can get negative where it is set to the result of >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>> >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From felix.yang at oracle.com Wed Dec 7 14:29:47 2016 From: felix.yang at oracle.com (Felix Yang) Date: Wed, 7 Dec 2016 22:29:47 +0800 Subject: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly In-Reply-To: <92d8acd0-5b76-cf8e-65de-3bc60e311e19@oracle.com> References: <92d8acd0-5b76-cf8e-65de-3bc60e311e19@oracle.com> Message-ID: :-) -Felix > On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: > > Add core-libs. > > Thanks, > Felix > On 2016/12/5 22:14, Felix Yang wrote: >> Hi, >> >> updated webrev. May I have a reviewer to review this >> >> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ >> >> -Felix >> On 2016/12/5 15:50, Felix Yang wrote: >>> >>> >>> On 2016/12/5 15:47, Langer, Christoph wrote: >>>> Hi Felix, >>>> >>>> looks ok to me. >>>> >>>> You probably should remove the reference to the old shell script in comment line 25, though: >>>> >>>> 25 * Test run from script, AcceptCauseFileDescriptorLeak.sh >>> Christoph, Good catch! >>> >>> Thanks, >>> Felix >>>> >>>> Best regards >>>> Christoph >>> >> > From chris.hegarty at oracle.com Wed Dec 7 14:37:00 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Dec 2016 14:37:00 +0000 Subject: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly In-Reply-To: References: <92d8acd0-5b76-cf8e-65de-3bc60e311e19@oracle.com> Message-ID: <648E0938-2137-4972-8A81-18551116ECE4@oracle.com> > On 7 Dec 2016, at 14:29, Felix Yang wrote: >>> ... >>> updated webrev. May I have a reviewer to review this >>> >>> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ I think this is ok Felix. -Chris. From daniel.fuchs at oracle.com Wed Dec 7 14:48:10 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 7 Dec 2016 14:48:10 +0000 Subject: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly In-Reply-To: References: <92d8acd0-5b76-cf8e-65de-3bc60e311e19@oracle.com> Message-ID: <35550c6b-6381-6d58-b0b2-a31f47bf96cb@oracle.com> Hi Felix, Looks good in general, but is 74 return; intended, or is that a test bug? best regards, -- daniel On 07/12/16 14:29, Felix Yang wrote: > :-) > > -Felix >> On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: >> >> Add core-libs. >> >> Thanks, >> Felix >> On 2016/12/5 22:14, Felix Yang wrote: >>> Hi, >>> >>> updated webrev. May I have a reviewer to review this >>> >>> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ >>> >>> -Felix >>> On 2016/12/5 15:50, Felix Yang wrote: >>>> >>>> >>>> On 2016/12/5 15:47, Langer, Christoph wrote: >>>>> Hi Felix, >>>>> >>>>> looks ok to me. >>>>> >>>>> You probably should remove the reference to the old shell script in comment line 25, though: >>>>> >>>>> 25 * Test run from script, AcceptCauseFileDescriptorLeak.sh >>>> Christoph, Good catch! >>>> >>>> Thanks, >>>> Felix >>>>> >>>>> Best regards >>>>> Christoph >>>> >>> >> > From chris.hegarty at oracle.com Wed Dec 7 14:50:21 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 7 Dec 2016 14:50:21 +0000 Subject: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly In-Reply-To: <35550c6b-6381-6d58-b0b2-a31f47bf96cb@oracle.com> References: <92d8acd0-5b76-cf8e-65de-3bc60e311e19@oracle.com> <35550c6b-6381-6d58-b0b2-a31f47bf96cb@oracle.com> Message-ID: > On 7 Dec 2016, at 14:48, Daniel Fuchs wrote: > > Hi Felix, > > Looks good in general, but is > 74 return; > intended, or is that a test bug? It is intended, as that is the code path that will be executed when the test invokes itself. -Chris. > best regards, > > -- daniel > > On 07/12/16 14:29, Felix Yang wrote: >> :-) >> >> -Felix >>> On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: >>> >>> Add core-libs. >>> >>> Thanks, >>> Felix >>> On 2016/12/5 22:14, Felix Yang wrote: >>>> Hi, >>>> >>>> updated webrev. May I have a reviewer to review this >>>> >>>> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ >>>> >>>> -Felix >>>> On 2016/12/5 15:50, Felix Yang wrote: >>>>> >>>>> >>>>> On 2016/12/5 15:47, Langer, Christoph wrote: >>>>>> Hi Felix, >>>>>> >>>>>> looks ok to me. >>>>>> >>>>>> You probably should remove the reference to the old shell script in comment line 25, though: >>>>>> >>>>>> 25 * Test run from script, AcceptCauseFileDescriptorLeak.sh >>>>> Christoph, Good catch! >>>>> >>>>> Thanks, >>>>> Felix >>>>>> >>>>>> Best regards >>>>>> Christoph >>>>> >>>> >>> >> > From daniel.fuchs at oracle.com Wed Dec 7 15:01:54 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 7 Dec 2016 15:01:54 +0000 Subject: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly In-Reply-To: References: <92d8acd0-5b76-cf8e-65de-3bc60e311e19@oracle.com> <35550c6b-6381-6d58-b0b2-a31f47bf96cb@oracle.com> Message-ID: <4107e7af-42ab-6f73-2f34-cf3159dd5c41@oracle.com> On 07/12/16 14:50, Chris Hegarty wrote: > It is intended, as that is the code path that will be executed when the test > invokes itself. Oh - right - I see it now. So looks good to me too :-) -- daniel > > -Chris. > > >> best regards, >> >> -- daniel >> >> On 07/12/16 14:29, Felix Yang wrote: >>> :-) >>> >>> -Felix >>>> On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: >>>> >>>> Add core-libs. >>>> >>>> Thanks, >>>> Felix >>>> On 2016/12/5 22:14, Felix Yang wrote: >>>>> Hi, >>>>> >>>>> updated webrev. May I have a reviewer to review this >>>>> >>>>> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ >>>>> >>>>> -Felix >>>>> On 2016/12/5 15:50, Felix Yang wrote: >>>>>> >>>>>> >>>>>> On 2016/12/5 15:47, Langer, Christoph wrote: >>>>>>> Hi Felix, >>>>>>> >>>>>>> looks ok to me. >>>>>>> >>>>>>> You probably should remove the reference to the old shell script in comment line 25, though: >>>>>>> >>>>>>> 25 * Test run from script, AcceptCauseFileDescriptorLeak.sh >>>>>> Christoph, Good catch! >>>>>> >>>>>> Thanks, >>>>>> Felix >>>>>>> >>>>>>> Best regards >>>>>>> Christoph >>>>>> >>>>> >>>> >>> >> > From goetz.lindenmaier at sap.com Wed Dec 7 15:26:59 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 7 Dec 2016 15:26:59 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: Hi Dmitry, yes, new_jvmpath is consistent with the other variables. I also merged the ifs in SDE.c. new webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ Best regards, Goetz. > -----Original Message----- > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > Sent: Wednesday, December 07, 2016 2:43 PM > To: Lindenmaier, Goetz ; Java Core Libs > ; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > Goetz, > > SDE.c: > > You might combine if at ll. 260 and 263 to one but it's just matter of test. > > if (sti == baseStratumIndex || sti < 0) { > return; /* Java stratum - return unchanged */ > } > > > I'm not sure what you mean. I tried to fix it, but please > > double-check the new webrev. > > if cnt is <= 0 loop at l.267 > > for (; cnt-- > 0; ++fromEntry) { > > is never run and we effectively do > > *entryCountPtr = 0; > > at l.283 > > So if we you suspect that cnt may become negative or 0: > (your v.01 changes) > > 260 if (sti < 0 && cnt > 0) { > 261 return; > 262 } > > it's better to check it early. > > But I'm not sure we have to care about negative/zero cnt here. > > -Dmitry > > On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > > Hi Dmitry, > > > > thanks for looking at my change! > > Updated webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > > > >> * src/java.base/unix/native/libjli/java_md_solinux.c > >> Is this line correct? > >> 519 jvmpath = JLI_StringDup(jvmpath); > > > > It seems pointless. Should I remove it? (The whole file is a horror.) > > > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >> It might be better to return immediately if cnt < 0, > >> regardless of value of sti. > > > > I'm not sure what you mean. I tried to fix it, but please > > double-check the new webrev. > > > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >> It might be better to write > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >> and leave one copy of setsockopt() call > > > > Yes, looks better. > > > > Best regards, > > Goetz > > > > > >> > >> -Dmitry > >> > >> > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> > >>> > >>> This change fixes some minor issues found in our code scans. > >>> > >>> I hope this correctly addresses corelib and serviceability issues. > >>> > >>> > >>> > >>> Please review: > >>> > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.01/ > >>> > >>> > >>> > >>> Best regards, > >>> > >>> Goetz. > >>> > >>> > >>> > >>> Changes in detail: > >>> > >>> > >>> > >>> e_asin.c > >>> > >>> Code scan reports missing {}. > >>> > >>> > >>> The code "if (huge+x>one) {" is only there to set the inexact flag of > >>> the processor. > >>> It's a way to avoid the C compiler to optimize the code away. It is > >>> always true, > >>> so the parenthesis of the outer else don't matter. > >>> > >>> Although this basically just adds the {} I would like to submit this to > >>> > >>> avoid anybody else spends more the 30sec on understanding these > >>> > >>> if statements. > >>> > >>> > >>> k_standard.c > >>> > >>> exc.retval is returned below and thus should always be initialized. > >>> > >>> > >>> imageDecompressor.cpp > >>> > >>> Wrong destructor is used. Reported also by David CARLIER > >>> > >>> > >>> java.c > >>> > >>> in line 1865 'name' was used, it should be 'alias'. > >>> > >>> > >>> java_md_solinux.c > >>> > >>> "//" in path is useless. Further down a free is missing. > >>> > >>> > >>> SDE.c > >>> > >>> Call to stratumTableIndex can return negative value if defaultStratumId > >>> == null. > >>> > >>> > >>> socket_md.c > >>> > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > >>> the macros. > >>> > >>> > >>> unpack.cpp > >>> > >>> n.slice should not get negative argument for end, which is passed from > >>> dollar1. > >>> But dollar1 can get negative where it is set to the result of > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>> > >> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. > > > -- > Dmitry Samersoff > Oracle Java development team, Saint Petersburg, Russia > * I would love to change the world, but they won't give me the sources. From dmitry.samersoff at oracle.com Wed Dec 7 16:10:06 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Wed, 7 Dec 2016 19:10:06 +0300 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: Goetz, This version of serviceability changes looks good to me. -Dmitry On 2016-12-07 18:26, Lindenmaier, Goetz wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c. > > new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > > Best regards, > Goetz. > >> -----Original Message----- >> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >> Sent: Wednesday, December 07, 2016 2:43 PM >> To: Lindenmaier, Goetz ; Java Core Libs >> ; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> Goetz, >> >> SDE.c: >> >> You might combine if at ll. 260 and 263 to one but it's just matter of test. >> >> if (sti == baseStratumIndex || sti < 0) { >> return; /* Java stratum - return unchanged */ >> } >> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >> >> if cnt is <= 0 loop at l.267 >> >> for (; cnt-- > 0; ++fromEntry) { >> >> is never run and we effectively do >> >> *entryCountPtr = 0; >> >> at l.283 >> >> So if we you suspect that cnt may become negative or 0: >> (your v.01 changes) >> >> 260 if (sti < 0 && cnt > 0) { >> 261 return; >> 262 } >> >> it's better to check it early. >> >> But I'm not sure we have to care about negative/zero cnt here. >> >> -Dmitry >> >> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>> Hi Dmitry, >>> >>> thanks for looking at my change! >>> Updated webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>> >>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>> Is this line correct? >>>> 519 jvmpath = JLI_StringDup(jvmpath); >>> >>> It seems pointless. Should I remove it? (The whole file is a horror.) >>> >>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>> It might be better to return immediately if cnt < 0, >>>> regardless of value of sti. >>> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >>> >>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>> It might be better to write >>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>> and leave one copy of setsockopt() call >>> >>> Yes, looks better. >>> >>> Best regards, >>> Goetz >>> >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> This change fixes some minor issues found in our code scans. >>>>> >>>>> I hope this correctly addresses corelib and serviceability issues. >>>>> >>>>> >>>>> >>>>> Please review: >>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.01/ >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> Changes in detail: >>>>> >>>>> >>>>> >>>>> e_asin.c >>>>> >>>>> Code scan reports missing {}. >>>>> >>>>> >>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>>>> the processor. >>>>> It's a way to avoid the C compiler to optimize the code away. It is >>>>> always true, >>>>> so the parenthesis of the outer else don't matter. >>>>> >>>>> Although this basically just adds the {} I would like to submit this to >>>>> >>>>> avoid anybody else spends more the 30sec on understanding these >>>>> >>>>> if statements. >>>>> >>>>> >>>>> k_standard.c >>>>> >>>>> exc.retval is returned below and thus should always be initialized. >>>>> >>>>> >>>>> imageDecompressor.cpp >>>>> >>>>> Wrong destructor is used. Reported also by David CARLIER >>>>> >>>>> >>>>> java.c >>>>> >>>>> in line 1865 'name' was used, it should be 'alias'. >>>>> >>>>> >>>>> java_md_solinux.c >>>>> >>>>> "//" in path is useless. Further down a free is missing. >>>>> >>>>> >>>>> SDE.c >>>>> >>>>> Call to stratumTableIndex can return negative value if defaultStratumId >>>>> == null. >>>>> >>>>> >>>>> socket_md.c >>>>> >>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>>>> the macros. >>>>> >>>>> >>>>> unpack.cpp >>>>> >>>>> n.slice should not get negative argument for end, which is passed from >>>>> dollar1. >>>>> But dollar1 can get negative where it is set to the result of >>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From naoto.sato at oracle.com Wed Dec 7 16:17:37 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 7 Dec 2016 08:17:37 -0800 Subject: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190 In-Reply-To: <20d2a445ae254bd1b81228165dbb1dcf@DEWDFE13DE03.global.corp.sap> References: <239843b3-e78f-0dc6-0432-577d2f205950@oracle.com> <77288838-abfa-30d7-45f4-1efaba15528a@oracle.com> <20d2a445ae254bd1b81228165dbb1dcf@DEWDFE13DE03.global.corp.sap> Message-ID: <0b5e68f7-ed39-4f4f-cfdf-3ca2c70e432a@oracle.com> Thanks for the review, Christoph. I too agree that the null check can be removed, but decided to keep it as a precaution as David mentioned. Naoto On 12/6/16 11:49 PM, Langer, Christoph wrote: > Hi Naoto, > > the new webrev looks ok to me, too. Thanks for fixing. > > And I agree to the point that the NULL check can be removed...if you like. > > Best regards > Christoph > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of David Holmes >> Sent: Mittwoch, 7. Dezember 2016 03:15 >> To: Naoto Sato ; core-libs-dev > dev at openjdk.java.net> >> Subject: Re: [9] RFR: 8170465, 8170466: JNI exception pending in jni_util.c:190 >> >> On 7/12/2016 11:04 AM, Naoto Sato wrote: >>> Thanks, David. The fix is modified accordingly: >>> >>> http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.01/ >> >> Thanks for fixing that. >> >> The null checks after the exception checks are now redundant as you can >> only get a null return from those methods if an exception becomes >> pending. But leaving them in as a precaution is okay I guess. >> >> Thanks, >> David >> >>> Naoto >>> >>> On 12/6/16 4:53 PM, David Holmes wrote: >>>> Hi Naoto, >>>> >>>> On 7/12/2016 10:02 AM, Naoto Sato wrote: >>>>> Hello, >>>>> >>>>> Please review the proposed fix to the following issues: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8170465 >>>>> https://bugs.openjdk.java.net/browse/JDK-8170466 >>>>> >>>>> The proposed fix is located at: >>>>> >>>>> http://cr.openjdk.java.net/~naoto/8170465.8170466/webrev.00/ >>>>> >>>>> These two JNI calls (NewStringUTF() and JNU_CallMethodByName()) in >>>>> src/java.base/share/native/libjava/jni_util.c can throw an exception. >>>>> Those possible exceptions need to be properly checked. >>>> >>>> JNU_CHECK_EXCEPTION will do a return from the method in which it is >>>> placed, so you need to be careful to ensure you do all needed cleanup >>>> before that eg: >>>> >>>> 203 JNU_CHECK_EXCEPTION(env); >>>> 204 free(str1); >>>> >>>> needs to be reversed else we won't free str1. Similarly: >>>> >>>> 210 JNU_CHECK_EXCEPTION(env); >>>> 211 (*env)->DeleteLocalRef(env, s2); >>>> >>>> needs to be reversed so we don't leak the local ref. (It is safe to call >>>> DeleteLocalRef with an exception pending.) >>>> >>>> Thanks, >>>> David >>>> >>>>> Naoto From mandy.chung at oracle.com Wed Dec 7 16:26:03 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Dec 2016 08:26:03 -0800 Subject: RFR(s): 8170664: SystemLoggerInPlatformLoader.java failing in case of module limitation In-Reply-To: References: <38bb2fac-38a3-addb-4ca8-89a7dcfe85ae@oracle.com> <479e1dcb-2983-a1c3-7935-ef24233ed994@oracle.com> Message-ID: > On Dec 7, 2016, at 4:26 AM, Sergei Kovalev wrote: > > Hi Mandy, Daniel, > > Thank you for reviewing this. > > I've made a try to improve naming of variables. Also replaced row Class declaration. Please take a look. > > http://cr.openjdk.java.net/~skovalev/8170664/webrev.02/ +1 Mandy From vincent.x.ryan at oracle.com Wed Dec 7 16:32:07 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Wed, 7 Dec 2016 16:32:07 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data Message-ID: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing a very simple replacement in a new and supported class: java.util.HexDump. Thanks. Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ From martinrb at google.com Wed Dec 7 17:09:21 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 7 Dec 2016 09:09:21 -0800 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: This changes fdlibm, which has historically been untouched. Don't commit without Joe Darcy's approval. On Wed, Dec 7, 2016 at 7:26 AM, Lindenmaier, Goetz < goetz.lindenmaier at sap.com> wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c. > > new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > > Best regards, > Goetz. > > > -----Original Message----- > > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > > Sent: Wednesday, December 07, 2016 2:43 PM > > To: Lindenmaier, Goetz ; Java Core Libs > > ; serviceability-dev (serviceability- > > dev at openjdk.java.net) > > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > > coding. > > > > Goetz, > > > > SDE.c: > > > > You might combine if at ll. 260 and 263 to one but it's just matter of > test. > > > > if (sti == baseStratumIndex || sti < 0) { > > return; /* Java stratum - return unchanged */ > > } > > > > > I'm not sure what you mean. I tried to fix it, but please > > > double-check the new webrev. > > > > if cnt is <= 0 loop at l.267 > > > > for (; cnt-- > 0; ++fromEntry) { > > > > is never run and we effectively do > > > > *entryCountPtr = 0; > > > > at l.283 > > > > So if we you suspect that cnt may become negative or 0: > > (your v.01 changes) > > > > 260 if (sti < 0 && cnt > 0) { > > 261 return; > > 262 } > > > > it's better to check it early. > > > > But I'm not sure we have to care about negative/zero cnt here. > > > > -Dmitry > > > > On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > > > Hi Dmitry, > > > > > > thanks for looking at my change! > > > Updated webrev: > > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > > > > > >> * src/java.base/unix/native/libjli/java_md_solinux.c > > >> Is this line correct? > > >> 519 jvmpath = JLI_StringDup(jvmpath); > > > > > > It seems pointless. Should I remove it? (The whole file is a horror.) > > > > > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > > >> It might be better to return immediately if cnt < 0, > > >> regardless of value of sti. > > > > > > I'm not sure what you mean. I tried to fix it, but please > > > double-check the new webrev. > > > > > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > > >> It might be better to write > > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; > > >> and leave one copy of setsockopt() call > > > > > > Yes, looks better. > > > > > > Best regards, > > > Goetz > > > > > > > > >> > > >> -Dmitry > > >> > > >> > > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > > >>> Hi, > > >>> > > >>> > > >>> > > >>> This change fixes some minor issues found in our code scans. > > >>> > > >>> I hope this correctly addresses corelib and serviceability issues. > > >>> > > >>> > > >>> > > >>> Please review: > > >>> > > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > > corlib_s11y/webrev.01/ > > >>> > > >>> > > >>> > > >>> Best regards, > > >>> > > >>> Goetz. > > >>> > > >>> > > >>> > > >>> Changes in detail: > > >>> > > >>> > > >>> > > >>> e_asin.c > > >>> > > >>> Code scan reports missing {}. > > >>> > > >>> > > >>> The code "if (huge+x>one) {" is only there to set the inexact flag of > > >>> the processor. > > >>> It's a way to avoid the C compiler to optimize the code away. It is > > >>> always true, > > >>> so the parenthesis of the outer else don't matter. > > >>> > > >>> Although this basically just adds the {} I would like to submit this > to > > >>> > > >>> avoid anybody else spends more the 30sec on understanding these > > >>> > > >>> if statements. > > >>> > > >>> > > >>> k_standard.c > > >>> > > >>> exc.retval is returned below and thus should always be initialized. > > >>> > > >>> > > >>> imageDecompressor.cpp > > >>> > > >>> Wrong destructor is used. Reported also by David CARLIER > > >>> > > >>> > > >>> java.c > > >>> > > >>> in line 1865 'name' was used, it should be 'alias'. > > >>> > > >>> > > >>> java_md_solinux.c > > >>> > > >>> "//" in path is useless. Further down a free is missing. > > >>> > > >>> > > >>> SDE.c > > >>> > > >>> Call to stratumTableIndex can return negative value if > defaultStratumId > > >>> == null. > > >>> > > >>> > > >>> socket_md.c > > >>> > > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is > hidden in > > >>> the macros. > > >>> > > >>> > > >>> unpack.cpp > > >>> > > >>> n.slice should not get negative argument for end, which is passed > from > > >>> dollar1. > > >>> But dollar1 can get negative where it is set to the result of > > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > > >>> > > >> > > >> > > >> -- > > >> Dmitry Samersoff > > >> Oracle Java development team, Saint Petersburg, Russia > > >> * I would love to change the world, but they won't give me the > sources. > > > > > > -- > > Dmitry Samersoff > > Oracle Java development team, Saint Petersburg, Russia > > * I would love to change the world, but they won't give me the sources. > From lance.andersen at oracle.com Wed Dec 7 17:35:28 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 7 Dec 2016 12:35:28 -0500 Subject: RFR JDK-8169948 [JAXP] Update ServiceProviderTest for newDefaultInstance() methods in JAXP factories In-Reply-To: <01f701d25038$287347c0$7959d740$@oracle.com> References: <01f701d25038$287347c0$7959d740$@oracle.com> Message-ID: <5F651C1E-D7A0-4D61-ACCE-C8B0EF64637E@oracle.com> Hi Frank, Looks fine Best Lance > On Dec 6, 2016, at 10:15 PM, Frank Yuan wrote: > > Hi all > > > > Would you like to review http://cr.openjdk.java.net/~fyuan/8169948/webrev.00/? > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169948 > > > > This test update is because of JDK-8169778 Add new public methods to get new instances of the JAXP factories builtin system-default > implementations. DefaultFactoryWrapperTest.java tests a provider that return a custom factory instance wrapping the built-in > system-default implementation. > > > > > > Thanks > > Frank > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From Roger.Riggs at Oracle.com Wed Dec 7 18:01:05 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Dec 2016 13:01:05 -0500 Subject: RFR of JDK-8170839: failed test case is not checked in java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java In-Reply-To: References: Message-ID: <2c8e6cd7-9896-c98e-4572-647f575b613b@Oracle.com> Hi Hamlin, Looks fine. Roger On 12/7/2016 1:47 AM, Hamlin Li wrote: > correct the subject > > > On 2016/12/7 14:46, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8170839 >> >> webrev: http://cr.openjdk.java.net/~mli/8170839/webrev.00/ >> >> >> Thank you >> -Hamlin >> >> ------------------------------------------------------------------------ >> >> diff -r 10b191e1793b >> test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java >> --- >> a/test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java >> Tue Dec 06 17:53:22 2016 -0800 >> +++ >> b/test/java/rmi/activation/ActivateFailedException/activateFails/ActivateFails.java >> Tue Dec 06 22:44:29 2016 -0800 >> @@ -1,5 +1,5 @@ >> /* >> - * Copyright (c) 1998, 2014, Oracle and/or its affiliates. All >> rights reserved. >> + * Copyright (c) 1998, 2016, Oracle and/or its affiliates. All >> rights reserved. >> * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. >> * >> * This code is free software; you can redistribute it and/or modify it >> @@ -140,7 +140,7 @@ >> System.err.println("invoking method on activatable >> object..."); >> try { >> obj1.ping(); >> - >> + throw new RuntimeException("ActivateFailedException >> is expected"); >> } catch (ActivateFailedException e) { >> >> /* >> > From paul.sandoz at oracle.com Wed Dec 7 18:19:32 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Dec 2016 10:19:32 -0800 Subject: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos In-Reply-To: <58475457.6090503@oracle.com> References: <58475457.6090503@oracle.com> Message-ID: <88A2349C-C007-458E-AA5F-817A9F1B8BD3@oracle.com> Hi, 334 if (lastEntryName != null && lastEntryName == entry.name) { Can you just do: if (Objects.equals(lastEntryName, entry.name)) { // [*] ? the assumptions being entry.name is never null, which i believe is valid, and one can check the string contents if refs are not equal. Paul. [*] public static boolean equals(Object a, Object b) { return (a == b) || (a != null && a.equals(b)); } > On 6 Dec 2016, at 16:14, Xueming Shen wrote: > > Hi, > > Please help review.commit the proposed change for JDK8170831 > > issue: https://bugs.openjdk.java.net/browse/JDK-8170831 > webrev: http://cr.openjdk.java.net/~sherman/8170831/ > > (1) As explained in the issue description, the new implementation now does not have the cache > mechanism as the old C implementation does (the C implementation still is still in repo, take a > look at "jdk/src/java.base/share/native/libzip/zip_util.c#Zip_GetEntry2(...)". > the corresponding cache is stored in zip->cache, "zip_util.h#trypedef struct jzfile/cache". > > (2) instead of having this cache in class ZipFile.Source, the cached pair is now at ZipFile > level for simplicity. > > (3) I now simply compare the identity of the entry "name", to avoid the unnecessary string > comparing operation, with the assumption that it's rare that someone will replace the entry > name filed of the returned ZipEntry with a new String object with the same value and come > back for the InputStream. > > (4) given currently there is no easy way to generate a zip/jar file with same entry name > in test case (out ZipInputStream does not such use scenario, with an exception), I'm not adding > new test case as the regression test, but I do have verified the change with the jar files that have > entries with same name but different bytes. > > opinion? > > Thanks, > Xueming > > From Roger.Riggs at Oracle.com Wed Dec 7 19:25:45 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Dec 2016 14:25:45 -0500 Subject: RFR 9: 8170291 : Unpredictable results of j.i.ObjectInputFilter::createFilter In-Reply-To: References: Message-ID: Hi Daniel, Webrev updated in place: http://cr.openjdk.java.net/~rriggs/webrev-createfilter-8170287/ Thanks for the suggestion, expanding on the text is a better intro to the more detail spec that follows. I also received a request to give a better description of the depth and references values in ObjectInputStream. The changes are in the webrev and below: diff --git a/src/java.base/share/classes/java/io/ObjectInputFilter.java b/src/java.base/share/classes/java/io/ObjectInputFilter.java --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java @@ -356,7 +356,9 @@ public interface ObjectInputFilter { * @param pattern the pattern string to parse; not null * @return a filter to check a class being deserialized; * {@code null} if no patterns - * @throws IllegalArgumentException If any of the following is true: + * @throws IllegalArgumentException if the pattern string is illegal or + * malformed and cannot be parsed. + * In particular, if any of the following is true: *
    *
  • if a limit is missing the name or the name is not one of * "maxdepth", "maxrefs", "maxbytes", or "maxarray" diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java b/src/java.base/share/classes/java/io/ObjectInputStream.java --- a/src/java.base/share/classes/java/io/ObjectInputStream.java +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java @@ -1168,6 +1168,13 @@ public class ObjectInputStream * for each class and reference in the stream. * The filter can check any or all of the class, the array length, the number * of references, the depth of the graph, and the size of the input stream. + * The depth is the number of nested {@linkplain #readObject readObject} + * calls starting with the reading of the root of the graph being deserialized + * and the current object being deserialized. + * The number of references is the cumulative number of objects and references + * to objects already read from the stream including the current object being read. + * The filter is invoked only when reading objects from the stream and for + * not primitives. Thanks, Roger On 12/7/2016 6:46 AM, Daniel Fuchs wrote: > Hi Roger, > > What about adding a bit of leeway in the reason for which > IAE can be thrown. Here is the text from your webrev: > > 359 * @throws IllegalArgumentException If any of the > following is true: > 360 *
      > 361 *
    • if a limit is missing the name or the name is > not one of > 362 * "maxdepth", "maxrefs", "maxbytes", or "maxarray" > 363 *
    • if the value of the limit can not be parsed by > 364 * {@link Long#parseLong Long.parseLong} or is > negative > 365 *
    • if the pattern contains "/" and the module name > is missing > 366 * or the remaining pattern is empty > 367 *
    • if the package is missing for ".*" and ".**" > 368 *
    > > could it be amended to something like: > > @throws IllegalArgumentException if the pattern string is illegal or > malformed and cannot be parsed. > In particular, an IllegalArgumentException will be thrown > if any of the following is true: ... > > best regards, > > -- daniel > > > On 06/12/16 22:04, Roger Riggs wrote: >> Please review a few additional clarifications to the ObjectInputFilter >> specification for generating >> a filter from a pattern and use in ObjectInputStream plus related test >> updates. >> >> Webrev: >> http://cr.openjdk.java.net/~rriggs/webrev-createfilter-8170287/ >> >> Thanks, Roger >> > From xueming.shen at oracle.com Wed Dec 7 19:29:09 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Wed, 07 Dec 2016 11:29:09 -0800 Subject: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos In-Reply-To: <88A2349C-C007-458E-AA5F-817A9F1B8BD3@oracle.com> References: <58475457.6090503@oracle.com> <88A2349C-C007-458E-AA5F-817A9F1B8BD3@oracle.com> Message-ID: <58486305.8010009@oracle.com> Hi Paul, Thanks for the suggestion. Webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8170831 Sherman On 12/7/16, 10:19 AM, Paul Sandoz wrote: > Hi, > > 334 if (lastEntryName != null&& lastEntryName == entry.name) { > > Can you just do: > > if (Objects.equals(lastEntryName, entry.name)) { // [*] > > ? the assumptions being entry.name is never null, which i believe is valid, and one can check the string contents if refs are not equal. > > Paul. > > [*] > public static boolean equals(Object a, Object b) { > return (a == b) || (a != null&& a.equals(b)); > } > >> On 6 Dec 2016, at 16:14, Xueming Shen wrote: >> >> Hi, >> >> Please help review.commit the proposed change for JDK8170831 >> >> issue: https://bugs.openjdk.java.net/browse/JDK-8170831 >> webrev: http://cr.openjdk.java.net/~sherman/8170831/ >> >> (1) As explained in the issue description, the new implementation now does not have the cache >> mechanism as the old C implementation does (the C implementation still is still in repo, take a >> look at "jdk/src/java.base/share/native/libzip/zip_util.c#Zip_GetEntry2(...)". >> the corresponding cache is stored in zip->cache, "zip_util.h#trypedef struct jzfile/cache". >> >> (2) instead of having this cache in class ZipFile.Source, the cached pair is now at ZipFile >> level for simplicity. >> >> (3) I now simply compare the identity of the entry "name", to avoid the unnecessary string >> comparing operation, with the assumption that it's rare that someone will replace the entry >> name filed of the returned ZipEntry with a new String object with the same value and come >> back for the InputStream. >> >> (4) given currently there is no easy way to generate a zip/jar file with same entry name >> in test case (out ZipInputStream does not such use scenario, with an exception), I'm not adding >> new test case as the regression test, but I do have verified the change with the jar files that have >> entries with same name but different bytes. >> >> opinion? >> >> Thanks, >> Xueming >> >> From paul.sandoz at oracle.com Wed Dec 7 19:38:20 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 7 Dec 2016 11:38:20 -0800 Subject: RFR 9: JDK 8170831: ZipFile implementation no longer caches the last accessed entry/pos In-Reply-To: <58486305.8010009@oracle.com> References: <58475457.6090503@oracle.com> <88A2349C-C007-458E-AA5F-817A9F1B8BD3@oracle.com> <58486305.8010009@oracle.com> Message-ID: <10F70A27-931C-44CD-9C2F-8AF2B80F0EB7@oracle.com> > On 7 Dec 2016, at 11:29, Xueming Shen wrote: > > Hi Paul, > > Thanks for the suggestion. Webrev has been updated accordingly. > > http://cr.openjdk.java.net/~sherman/8170831 > +1 > Sherman > From daniel.fuchs at oracle.com Wed Dec 7 20:04:38 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 7 Dec 2016 20:04:38 +0000 Subject: RFR 9: 8170291 : Unpredictable results of j.i.ObjectInputFilter::createFilter In-Reply-To: References: Message-ID: Looks good Roger! best regards, -- daniel On 07/12/16 19:25, Roger Riggs wrote: > Hi Daniel, > > Webrev updated in place: > http://cr.openjdk.java.net/~rriggs/webrev-createfilter-8170287/ > > Thanks for the suggestion, expanding on the text is a better intro to > the more detail spec that follows. > > I also received a request to give a better description of the depth and > references values > in ObjectInputStream. > > The changes are in the webrev and below: > > diff --git a/src/java.base/share/classes/java/io/ObjectInputFilter.java > b/src/java.base/share/classes/java/io/ObjectInputFilter.java > --- a/src/java.base/share/classes/java/io/ObjectInputFilter.java > +++ b/src/java.base/share/classes/java/io/ObjectInputFilter.java > @@ -356,7 +356,9 @@ public interface ObjectInputFilter { > * @param pattern the pattern string to parse; not null > * @return a filter to check a class being deserialized; > * {@code null} if no patterns > - * @throws IllegalArgumentException If any of the following is > true: > + * @throws IllegalArgumentException if the pattern string is > illegal or > + * malformed and cannot be parsed. > + * In particular, if any of the following is true: > *
      > *
    • if a limit is missing the name or the name is not one of > * "maxdepth", "maxrefs", "maxbytes", or "maxarray" > diff --git a/src/java.base/share/classes/java/io/ObjectInputStream.java > b/src/java.base/share/classes/java/io/ObjectInputStream.java > --- a/src/java.base/share/classes/java/io/ObjectInputStream.java > +++ b/src/java.base/share/classes/java/io/ObjectInputStream.java > @@ -1168,6 +1168,13 @@ public class ObjectInputStream > * for each class and reference in the stream. > * The filter can check any or all of the class, the array length, > the number > * of references, the depth of the graph, and the size of the input > stream. > + * The depth is the number of nested {@linkplain #readObject > readObject} > + * calls starting with the reading of the root of the graph being > deserialized > + * and the current object being deserialized. > + * The number of references is the cumulative number of objects and > references > + * to objects already read from the stream including the current > object being read. > + * The filter is invoked only when reading objects from the stream > and for > + * not primitives. > > > Thanks, Roger > > > On 12/7/2016 6:46 AM, Daniel Fuchs wrote: >> Hi Roger, >> >> What about adding a bit of leeway in the reason for which >> IAE can be thrown. Here is the text from your webrev: >> >> 359 * @throws IllegalArgumentException If any of the >> following is true: >> 360 *
        >> 361 *
      • if a limit is missing the name or the name is >> not one of >> 362 * "maxdepth", "maxrefs", "maxbytes", or "maxarray" >> 363 *
      • if the value of the limit can not be parsed by >> 364 * {@link Long#parseLong Long.parseLong} or is >> negative >> 365 *
      • if the pattern contains "/" and the module name >> is missing >> 366 * or the remaining pattern is empty >> 367 *
      • if the package is missing for ".*" and ".**" >> 368 *
      >> >> could it be amended to something like: >> >> @throws IllegalArgumentException if the pattern string is illegal or >> malformed and cannot be parsed. >> In particular, an IllegalArgumentException will be thrown >> if any of the following is true: ... >> >> best regards, >> >> -- daniel >> >> >> On 06/12/16 22:04, Roger Riggs wrote: >>> Please review a few additional clarifications to the ObjectInputFilter >>> specification for generating >>> a filter from a pattern and use in ObjectInputStream plus related test >>> updates. >>> >>> Webrev: >>> http://cr.openjdk.java.net/~rriggs/webrev-createfilter-8170287/ >>> >>> Thanks, Roger >>> >> > From huizhe.wang at oracle.com Wed Dec 7 20:34:19 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 07 Dec 2016 12:34:19 -0800 Subject: RFR JDK-8169948 [JAXP] Update ServiceProviderTest for newDefaultInstance() methods in JAXP factories In-Reply-To: <5F651C1E-D7A0-4D61-ACCE-C8B0EF64637E@oracle.com> References: <01f701d25038$287347c0$7959d740$@oracle.com> <5F651C1E-D7A0-4D61-ACCE-C8B0EF64637E@oracle.com> Message-ID: <5848724B.80203@oracle.com> Hi Frank, Looks good to me too. Thanks for adding tests. Best, Joe On 12/7/16, 9:35 AM, Lance Andersen wrote: > Hi Frank, > > Looks fine > > Best > Lance >> On Dec 6, 2016, at 10:15 PM, Frank Yuan > > wrote: >> >> Hi all >> >> >> >> Would you like to review >> http://cr.openjdk.java.net/~fyuan/8169948/webrev.00/? >> >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8169948 >> >> >> >> This test update is because of JDK-8169778 Add new public methods to >> get new instances of the JAXP factories builtin system-default >> implementations. DefaultFactoryWrapperTest.java tests a provider that >> return a custom factory instance wrapping the built-in >> system-default implementation. >> >> >> >> >> >> Thanks >> >> Frank >> > > > > Lance > Andersen| Principal Member of Technical Staff | +1.781.442.2037 > Oracle Java Engineering > 1 Network Drive > Burlington, MA 01803 > Lance.Andersen at oracle.com > > > From joe.darcy at oracle.com Wed Dec 7 20:36:55 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 07 Dec 2016 12:36:55 -0800 Subject: JDK 9 RFR of JDK-8170875: Problem list LocaleTest.java until JDK-8170840 is fixed Message-ID: <584872E7.5070304@oracle.com> Hello, After the fix for JDK-8071929, the test java/util/Locale/LocaleTest.java has been failing across platforms. Until JDK-8170840 is fixed, the test should be problem listed. Patch below. Thanks, -Joe --- a/test/ProblemList.txt Wed Dec 07 11:53:26 2016 -0800 +++ b/test/ProblemList.txt Wed Dec 07 12:35:32 2016 -0800 @@ -291,6 +291,8 @@ java/util/BitSet/BitSetStreamTest.java 8079538 generic-all +java/util/Locale/LocaleTest.java 8170840 generic-all + ############################################################################ # jdk_instrument From Roger.Riggs at Oracle.com Wed Dec 7 20:42:47 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Dec 2016 15:42:47 -0500 Subject: JDK 9 RFR of JDK-8170875: Problem list LocaleTest.java until JDK-8170840 is fixed In-Reply-To: <584872E7.5070304@oracle.com> References: <584872E7.5070304@oracle.com> Message-ID: Looks fine Joe. On 12/7/2016 3:36 PM, Joseph D. Darcy wrote: > Hello, > > After the fix for JDK-8071929, the test > > java/util/Locale/LocaleTest.java > > has been failing across platforms. Until JDK-8170840 is fixed, the > test should be problem listed. > > Patch below. > > Thanks, > > -Joe > > --- a/test/ProblemList.txt Wed Dec 07 11:53:26 2016 -0800 > +++ b/test/ProblemList.txt Wed Dec 07 12:35:32 2016 -0800 > @@ -291,6 +291,8 @@ > > java/util/BitSet/BitSetStreamTest.java 8079538 generic-all > > +java/util/Locale/LocaleTest.java 8170840 generic-all > + > ############################################################################ > > > # jdk_instrument > From naoto.sato at oracle.com Wed Dec 7 20:42:00 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 7 Dec 2016 12:42:00 -0800 Subject: JDK 9 RFR of JDK-8170875: Problem list LocaleTest.java until JDK-8170840 is fixed In-Reply-To: <584872E7.5070304@oracle.com> References: <584872E7.5070304@oracle.com> Message-ID: <09637687-6fd4-03be-815b-e9e8c115a0dc@oracle.com> +1 Naoto On 12/7/16 12:36 PM, Joseph D. Darcy wrote: > Hello, > > After the fix for JDK-8071929, the test > > java/util/Locale/LocaleTest.java > > has been failing across platforms. Until JDK-8170840 is fixed, the test > should be problem listed. > > Patch below. > > Thanks, > > -Joe > > --- a/test/ProblemList.txt Wed Dec 07 11:53:26 2016 -0800 > +++ b/test/ProblemList.txt Wed Dec 07 12:35:32 2016 -0800 > @@ -291,6 +291,8 @@ > > java/util/BitSet/BitSetStreamTest.java 8079538 generic-all > > +java/util/Locale/LocaleTest.java 8170840 generic-all > + > ############################################################################ > > > # jdk_instrument > From Roger.Riggs at Oracle.com Wed Dec 7 21:20:26 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Dec 2016 16:20:26 -0500 Subject: RFR 9: 8153882 rmid emits warning about security policy with obsolete URL Message-ID: Please review a change to an warning message from rmid when the security policy is incorrectly configured. There is no reliable link to the rmid documentation that will remain accurate across JDK versions. The direct link is removed and expect the user to find the rmid documentation from the doc bundle or via a web search. (this corrects the US english version, other locale will require translation) Webrev: http://cr.openjdk.java.net/~rriggs/webrev-rmid-url-8153882/ Issue: https://bugs.openjdk.java.net/browse/JDK-8153882 Thanks, Roger From brent.christian at oracle.com Wed Dec 7 21:56:58 2016 From: brent.christian at oracle.com (Brent Christian) Date: Wed, 07 Dec 2016 13:56:58 -0800 Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint Message-ID: <584885AA.9060202@oracle.com> Hi, Please review my fix for 8169389. Bug: https://bugs.openjdk.java.net/browse/JDK-8169389 Webrev: http://cr.openjdk.java.net/~bchristi/8169389/webrev.03/ The addition of classloader names (JDK-6749237) updated the format of StackTraceElement.toString(). A field was added to store the "[[class-loader-name]/[module-name[@module-version]]]" portion of the returned String. Instead of storing a String, we can cut down on footprint by using a bitfield to indicate which fields to include in the toString() output. Looking at the heap usage of a simple test case indicates ~25% reduction in space used by Throwable's StackTraceElement[]. (Of course this could vary quite a bit, depending on the specifics of the call stack.) The additional byte field does not increase the instance size of a StackTraceElement; it is within space already lost for alignment (per linux_x64 w/ CompressedOops). While working on this, it was noticed that with the new toString() format, there are circumstances in which two StackTraceElements can be equals(), but return different values from toString(). I thought it was worth updating the JavaDoc to call out this unusual possibility. Likewise, there can be information reflected in the StackTraceElement getter methods that is not reflected in the toString() value. I updated the test code to check for this. Thanks, -Brent From Roger.Riggs at Oracle.com Wed Dec 7 22:28:04 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 7 Dec 2016 17:28:04 -0500 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> References: <58441EC4.4090104@oracle.com> <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> Message-ID: <9cf64c84-f010-608f-33d1-3bce2e6e4381@Oracle.com> Hi Ivan, A few comments... Appendable.appendN default method: I'd expect many time n is small so allocating a new StringBuilder every time seems not optimal. A simple loop with append(c) would have fewer (memory) side effects. And in particular for n=0, it could avoid doing anything. AbstractStringBuilder: I agree with Claes' comment suggesting that IAE for negative lengths is a pain and defining it to append 0 would be natural in many use cases. MethodHandleImpl.toString(): You could beneficially replace StringBuffer with StringBuilder while you are there. (and maybe pre-size the builder). $.02, Roger On 12/5/2016 2:17 PM, Paul Sandoz wrote: >> On 4 Dec 2016, at 08:42, Ivan Gerasimov wrote: >> >> Thank you Claes for looking into it! >> >> >> On 04.12.2016 16:48, Claes Redestad wrote: >>> Hi Ivan, >>> >>> as this adds a new public API I guess it's too late for 9 at this point, but here's a few >>> comments anyhow: >>> >> Yes, of course. >> If people find it useful, I would expect it to go to jdk 10. > Add a fix version of 10, then it?s clear on the intent. Once tests are added :-) we can review for that release. > > Personally i would use Arrays.fill, i gather the pattern is already recognised: > > https://bugs.openjdk.java.net/browse/JDK-4809552 > http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d64a8c7aa9d5 > > The advantage of using Arrays.fill is we know that the pattern will be recognized (if not it?s a bug, and i suppose it could be made intrinsic to wire up faster). (see -XX:+TraceOptimizeFill). I suspect we should review the filling optimization to see if it can be enhanced with newer SIMD instructions, as i gather the current implementation writes a max of 8 bytes at a time (with an explicit unrolled loop for 32 bytes at a time, containing 4 separate stores). > > > It?s good that you found places in the JDK, that adds justification for such methods, especially for BigInteger and that static array of strings full of ?0? characters. > > The updates to MethodHandleImpl are not perf sensitive, i question the usage here but it does reduce stuff in the constant pool i suppose. > > Paul. > > >>> - you could use Arrays.fill(byte[], int, int, byte) for LATIN-1 case in AbstractStringBuilder. >>> Might not make it much faster (unless there are intrinsics at play, but perhaps a bit less >>> verbose. >>> >> The do-while loop saves us one comparison, comparing to the loop in Arrays.fill(). >> I'd prefer to keep the explicit loop, as it's only three lines of code long. >> >>> - for a convenience API like this, I think it's slightly awkward that a negative n throws IAE >>> since users have to think carefully about whether they need to guard the call to appendN >>> with a range check or not. I'd find this utility more useful if it was more forgiving and >>> allowed simplifying the caller further. >>> >> Yes, I understand your point. There are different approaches to handling arguments. >> E.g. for indices it might be allowed to have from > to (treat it as from == to), and from < 0. >> Or, like in Perl, negative index might be treated as offset from the end of a list or array. >> However, in Java, the tradition seems to have formed to have strong argument checks, not allowing much interpretation. >> For example, similarly looking Collections.nCopies(int n, T) also throws IAE for negative n. >> >>> Benchmark comments: >>> >>> - since you're reusing a StringBuilder you're effectively removing the impact of resizing >>> the underlying buffer, which is typically a significant part of appending, so while this >>> zooms in on the cost of actually appending to a prepared builder, it might overstate the >>> effect. >>> >> It was intentional, to be honest. >> If appending several chars causes reallocation, then appending chars in a loop can only be slower, comparing to appendN() or append(String). >> I didn't want to find the sharp constant of the speedup factor, but just wanted to be sure that the increase in performance is observable. >> >>> Creating new StringBuilders (of varying sizes) in a setup method outside the >>> @Benchmark method might be more in line with typical use, in addition to what you have >>> now (which is zooming in on the cost of appending without allocation overhead). >>> setLength(0) could also be moved to an invocation level @Setup method) >>> >>> - seeing that appending a String, which uses System.arraycopy, can be slower for small >>> strings is a bit surprising as I'd assume it'd be completely intrinsified. Is the compiled code >>> making a JNI transition or are things not being inlined properly? >>> >> I'm not sure exactly why appending short String is slower then filling. >> Might it be because the former means both reading from and writing to the memory, and the later only means writing? >> Anyways, I only wanted to make sure that replacing the code in BigInteger and FDBigInteger won't make things slower. >> >>> - please use -tu us -bm avgt or annotate benchmarks to output scores with a reasonable >>> number of digits. >>> >> Sure. Here you go: >> >> Benchmark (size) Mode Cnt Score Error Units >> MyBenchmark.test_0_New 0 avgt 4 0.003 ? 0.004 us/op >> MyBenchmark.test_0_New 1 avgt 4 0.005 ? 0.008 us/op >> MyBenchmark.test_0_New 5 avgt 4 0.014 ? 0.015 us/op >> MyBenchmark.test_0_New 10 avgt 4 0.016 ? 0.019 us/op >> MyBenchmark.test_0_New 20 avgt 4 0.018 ? 0.010 us/op >> MyBenchmark.test_1_Old 0 avgt 4 0.003 ? 0.001 us/op >> MyBenchmark.test_1_Old 1 avgt 4 0.006 ? 0.004 us/op >> MyBenchmark.test_1_Old 5 avgt 4 0.023 ? 0.021 us/op >> MyBenchmark.test_1_Old 10 avgt 4 0.049 ? 0.071 us/op >> MyBenchmark.test_1_Old 20 avgt 4 0.089 ? 0.110 us/op >> MyBenchmark.test_2_Solid 0 avgt 4 0.007 ? 0.003 us/op >> MyBenchmark.test_2_Solid 1 avgt 4 0.018 ? 0.024 us/op >> MyBenchmark.test_2_Solid 5 avgt 4 0.016 ? 0.011 us/op >> MyBenchmark.test_2_Solid 10 avgt 4 0.017 ? 0.016 us/op >> MyBenchmark.test_2_Solid 20 avgt 4 0.016 ? 0.007 us/op >> >> >> With kind regards, >> Ivan >> >> >>> Thanks! >>> >>> /Claes >>> >>> On 12/04/2016 04:07 AM, Ivan Gerasimov wrote: >>>> Hello! >>>> >>>> There are several places in JDK where the same character is appended to a StringBuilder object multiple times (usually padding). >>>> With each append there are a few routine checks performed. >>>> They could have been done only once, if we had a method for appending multiple copies at a time. >>>> A simple benchmark shows that such method may save us a few machine cycles (see the results below). >>>> >>>> In the benchmark, three approaches were compared: >>>> 0) Using the new appendN(char, int) method to append several chars at once, >>>> 1) Calling append(char) in a loop, >>>> 2) Appending a prepared-in-advance string >>>> >>>> On my machine, the new method demonstrates better or comparable performance for all sizes up to 20. >>>> >>>> In the webrev, there are two changesets included: >>>> - the new default Appendable.appendN(char, int) method, its overrides in StringBuilder/Buffer and a basic test, >>>> - several applications of the new method across JDK. >>>> >>>> Would you please help review? >>>> Comments, suggestions are welcome. >>>> >>>> BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170348 >>>> WEBREV: http://cr.openjdk.java.net/~igerasim/8170348/00/webrev/ >>>> Benchmark: http://cr.openjdk.java.net/~igerasim/8170348/00/MyBenchmark.java >>>> >>>> >>>> Benchmark (size) Mode Cnt Score Error Units >>>> MyBenchmark.test_0_New 0 thrpt 70 331922128.215 ? 16399254.452 ops/s >>>> MyBenchmark.test_0_New 1 thrpt 70 209207932.893 ? 14955800.231 ops/s >>>> MyBenchmark.test_0_New 5 thrpt 70 72926671.621 ? 4841791.555 ops/s >>>> MyBenchmark.test_0_New 10 thrpt 70 67779575.053 ? 3234366.239 ops/s >>>> MyBenchmark.test_0_New 20 thrpt 70 59731629.661 ? 2769497.288 ops/s >>>> MyBenchmark.test_1_Old 0 thrpt 70 333467628.860 ? 15981678.430 ops/s >>>> MyBenchmark.test_1_Old 1 thrpt 70 156126381.967 ? 9619653.294 ops/s >>>> MyBenchmark.test_1_Old 5 thrpt 70 46550204.382 ? 2009987.637 ops/s >>>> MyBenchmark.test_1_Old 10 thrpt 70 23309297.849 ? 1268874.282 ops/s >>>> MyBenchmark.test_1_Old 20 thrpt 70 13143637.821 ? 662265.103 ops/s >>>> MyBenchmark.test_2_Solid 0 thrpt 70 138548108.540 ? 6408775.462 ops/s >>>> MyBenchmark.test_2_Solid 1 thrpt 70 63890936.132 ? 3918274.970 ops/s >>>> MyBenchmark.test_2_Solid 5 thrpt 70 65838879.075 ? 2701493.698 ops/s >>>> MyBenchmark.test_2_Solid 10 thrpt 70 65387238.993 ? 3131562.548 ops/s >>>> MyBenchmark.test_2_Solid 20 thrpt 70 57528150.828 ? 3171453.716 ops/s >>>> >>>> >>>> With kind regards, >>>> Ivan >>>> >>> From mandy.chung at oracle.com Thu Dec 8 00:05:09 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Dec 2016 16:05:09 -0800 Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint In-Reply-To: <584885AA.9060202@oracle.com> References: <584885AA.9060202@oracle.com> Message-ID: <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com> > On Dec 7, 2016, at 1:56 PM, Brent Christian wrote: > > Hi, > > Please review my fix for 8169389. > > Bug: > https://bugs.openjdk.java.net/browse/JDK-8169389 > Webrev: > http://cr.openjdk.java.net/~bchristi/8169389/webrev.03/ > : Thanks for making this good change. Claes would be happy with the footprint saving. I suggest to add two utility methods rather than the has method: boolean dropClassLoaderName() boolean dropModuleVersion() 430 if (m != null && m.isNamed() && 431 (isHashedInJavaBase(m) || !m.getDescriptor().version().isPresent())) { 432 bits |= JDK_NON_UPGRADEABLE_MODULE; 433 } I think this should simply be: if (isHashedInJavaBase(m)) {..} Can you retain the javadoc of toLoaderModuleClassName, revised if appropriate, in the computeFormat method? line 322-325: what about: The toString method may return two different values on two StackTraceElement instances that are equal for example when one created via the constructor and one obtained from Throwable or StackFrame where an implementation may choose to omit some element in the returned string. Is @apiNote in equals necessary? Maybe the one added in toString is adequate? Mandy From joe.darcy at oracle.com Thu Dec 8 00:55:13 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Wed, 07 Dec 2016 16:55:13 -0800 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: <53196beb-30c8-eee7-bb4f-59a8bda4dd1f@oracle.com> References: <617953b0-2398-c931-931e-3370e96f2b07@oracle.com> <53196beb-30c8-eee7-bb4f-59a8bda4dd1f@oracle.com> Message-ID: <5848AF71.2080102@oracle.com> Hello, I think work like this merits some additional test development to make sure the new, faster implementation doesn't introduce any regressions in correctness. From a quick look in the java/lang/Class test directory, I didn't see any existing tests probing the correctness of isAnonymous; although there are some uses of that method. Thanks, -Joe On 12/1/2016 9:34 AM, Claes Redestad wrote: > Hi, > > sadly, avoiding getSimpleBinaryName is where most of the gain comes > from, avoiding > getSimpleName only improves marginally on the baseline: > > Benchmark Mode Cnt Score Error Units > Clazz.isAnonymousClass_Anon avgt 10 192.522 ? 33.214 ns/op > Clazz.isAnonymousClass_Regular avgt 10 115.770 ? 19.953 ns/op > > Wrapping the checkPermission call inside getEnclosingMethod so that > Reflection.getCallerClass() doesn't happening improves things a bit, > but still > not close: > > Clazz.isAnonymousClass_Anon avgt 10 187.074 ? 38.128 ns/op > Clazz.isAnonymousClass_Regular avgt 10 96.196 ? 15.709 ns/op > > /Claes > > On 2016-12-01 17:57, Mandy Chung wrote: >> Hi Claes, >> >> What is the performance difference if this method calls >> getSimpleBinaryName? Your patch exposes the implementation details >> and sensitive to the change there, if any. >> >> Mandy >> >>> On Dec 1, 2016, at 5:38 AM, Claes Redestad >>> wrote: >>> >>> Hi, >>> >>> due to recent interest to optimize Class.isAnonymousClass[1] I took >>> a look at the implementation and found that we can further improve >>> performance of this method, especially when asking non-anonymous >>> classes[2]. >>> >>> As such calls are a common occurrence during startup and bootstrap >>> of lambdas this actually appears rather worthwhile: >>> >>> Webrev: http://cr.openjdk.java.net/~redestad/8170595/webrev.01/ >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170595 >>> >>> Thanks! >>> >>> /Claes >>> >>> [1] >>> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045116.html >>> [2] >>> Benchmark Mode Cnt Score Error Units >>> Clazz.isAnonymousClass_Anon avgt 50 200.900 ? 15.503 ns/op >>> Clazz.isAnonymousClass_Regular avgt 50 136.896 ? 9.605 ns/op >>> >>> Clazz.isAnonymousClass_Anon avgt 50 186.564 ? 12.219 ns/op >>> Clazz.isAnonymousClass_Regular avgt 50 33.878 ? 1.524 ns/op >>> >>> See bug for benchmark source > From felix.yang at oracle.com Thu Dec 8 03:06:22 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 8 Dec 2016 11:06:22 +0800 Subject: RFR 8170890, Problem list tools/javadoc/CheckResourceKeys.java and tools/javadoc/ReleaseOption.java until fix for JDK-8170772 Message-ID: <2cf14f38-29c0-a663-f444-f28742a647f6@oracle.com> Hi, please review the patch to problem-list two tier1 tests from Linux platform. Bug: https://bugs.openjdk.java.net/browse/JDK-8170890 Thanks, Felix diff -r 586c93260d3b test/ProblemList.txt --- a/test/ProblemList.txt Mon Dec 05 15:08:24 2016 -0800 +++ b/test/ProblemList.txt Wed Dec 07 18:47:22 2016 -0800 @@ -31,6 +31,8 @@ jdk/javadoc/tool/enum/enumType/Main.java 8152313 generic-all convert to doclet test framework jdk/javadoc/tool/varArgs/Main.java 8152313 generic-all convert to doclet test framework jdk/javadoc/doclet/testIOException/TestIOException.java 8164597 windows-all +tools/javadoc/CheckResourceKeys.java 8170772 linux-all +tools/javadoc/ReleaseOption.java 8170772 linux-all ########################################################################### # From huaming.li at oracle.com Thu Dec 8 03:07:26 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 8 Dec 2016 11:07:26 +0800 Subject: RFR of JDK-7195382: TEST_BUG: java/rmi/activation/CommandEnvironment/SetChildEnv.java can fail Message-ID: <134bca0b-06b6-0fbb-2570-09bb1f14dcff@oracle.com> Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-7195382 webrev: http://cr.openjdk.java.net/~mli/7195382/webrev.00/ what's changed? * Use createRMIDOnEphemeralPort to avoid "port in use" exception. * Because createRMIDOnEphemeralPort will choose different ports for rmid for multiple runs, it will fail subsequent ActivationGroup except of first run, so have to run 4 test cases in different JVM by putting them in rather in separate "@run main/othervm". * Put rmid.cleanup() in finally block to avoid orphan process bug. * delete dead code. Thank you -Hamlin From mandy.chung at oracle.com Thu Dec 8 03:30:14 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Wed, 7 Dec 2016 19:30:14 -0800 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: <3ebaac19-48dd-9292-f5f5-8e6d822e9d38@oracle.com> References: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> <58409545.4070803@oracle.com> <3ebaac19-48dd-9292-f5f5-8e6d822e9d38@oracle.com> Message-ID: > On Dec 2, 2016, at 6:29 AM, Claes Redestad wrote: > > : > http://cr.openjdk.java.net/~redestad/8170595/webrev.03/ > > This brings significant improvements to some variants: Good to see the significant improvements. I think what isLocalOrAnonymousClass needs probably is something like this: private boolean hasEnclosingMethodInfo() { Object[] enclosingInfo = getEnclosingMethod0(); if (enclosingInfo != null) { EnclosingMethodInfo.validate(enclosingInfo); } return enclosingInfo != null; } Then EnclosingMethodInfo doesn?t seem the need to change. The overall change would be simpler. As Joe suggests, this worths adding test cases for these methods, if not present. Mandy From david.holmes at oracle.com Thu Dec 8 07:22:12 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Dec 2016 17:22:12 +1000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> Message-ID: On 8/12/2016 2:32 AM, Vincent Ryan wrote: > A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. > Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing > a very simple replacement in a new and supported class: java.util.HexDump. > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 > Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ googling for "hexdump java" reveals quite a few hits - including javax.xml.bind.DatatypeConverter. Does this sun.* class really meet the acceptance criteria for inclusion in java.util? That bar is intentionally set very high. Just wondering ... David From david.holmes at oracle.com Thu Dec 8 08:13:31 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 8 Dec 2016 18:13:31 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> Hi Goetz, On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c. > > new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ src/java.base/share/native/libjli/java.c As far as I can see the existing code is working perfectly fine. Given a jvm.cfg with: -server KNOWN -client IGNORE -myvm KNOWN -oldvm ALIASED_TO -server The usage text is: -server to select the "server" VM -myvm to select the "myvm" VM -oldvm is a synonym for the "server" VM [deprecated] The default VM is server, because you are running on a server-class machine. which is exactly what I would expect. Why do you think there is a bug? --- src/java.base/unix/native/libjli/java_md_solinux.c Again I'm not sure what the bug is here. On AIX the output string is expanded with: "%s/lib/%s/jli:" so it needs to account for the extra "/lib//jli:" characters - and that is exactly what the existing code does: + JLI_StrLen("/lib//jli:") The jvmpath -> jvm_newpath change wasn't really necessary - a comment on the strdup would have sufficed IMO. Thanks, David ----- > Best regards, > Goetz. > >> -----Original Message----- >> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >> Sent: Wednesday, December 07, 2016 2:43 PM >> To: Lindenmaier, Goetz ; Java Core Libs >> ; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> Goetz, >> >> SDE.c: >> >> You might combine if at ll. 260 and 263 to one but it's just matter of test. >> >> if (sti == baseStratumIndex || sti < 0) { >> return; /* Java stratum - return unchanged */ >> } >> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >> >> if cnt is <= 0 loop at l.267 >> >> for (; cnt-- > 0; ++fromEntry) { >> >> is never run and we effectively do >> >> *entryCountPtr = 0; >> >> at l.283 >> >> So if we you suspect that cnt may become negative or 0: >> (your v.01 changes) >> >> 260 if (sti < 0 && cnt > 0) { >> 261 return; >> 262 } >> >> it's better to check it early. >> >> But I'm not sure we have to care about negative/zero cnt here. >> >> -Dmitry >> >> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>> Hi Dmitry, >>> >>> thanks for looking at my change! >>> Updated webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>> >>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>> Is this line correct? >>>> 519 jvmpath = JLI_StringDup(jvmpath); >>> >>> It seems pointless. Should I remove it? (The whole file is a horror.) >>> >>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>> It might be better to return immediately if cnt < 0, >>>> regardless of value of sti. >>> >>> I'm not sure what you mean. I tried to fix it, but please >>> double-check the new webrev. >>> >>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>> It might be better to write >>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>> and leave one copy of setsockopt() call >>> >>> Yes, looks better. >>> >>> Best regards, >>> Goetz >>> >>> >>>> >>>> -Dmitry >>>> >>>> >>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> >>>>> >>>>> This change fixes some minor issues found in our code scans. >>>>> >>>>> I hope this correctly addresses corelib and serviceability issues. >>>>> >>>>> >>>>> >>>>> Please review: >>>>> >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.01/ >>>>> >>>>> >>>>> >>>>> Best regards, >>>>> >>>>> Goetz. >>>>> >>>>> >>>>> >>>>> Changes in detail: >>>>> >>>>> >>>>> >>>>> e_asin.c >>>>> >>>>> Code scan reports missing {}. >>>>> >>>>> >>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>>>> the processor. >>>>> It's a way to avoid the C compiler to optimize the code away. It is >>>>> always true, >>>>> so the parenthesis of the outer else don't matter. >>>>> >>>>> Although this basically just adds the {} I would like to submit this to >>>>> >>>>> avoid anybody else spends more the 30sec on understanding these >>>>> >>>>> if statements. >>>>> >>>>> >>>>> k_standard.c >>>>> >>>>> exc.retval is returned below and thus should always be initialized. >>>>> >>>>> >>>>> imageDecompressor.cpp >>>>> >>>>> Wrong destructor is used. Reported also by David CARLIER >>>>> >>>>> >>>>> java.c >>>>> >>>>> in line 1865 'name' was used, it should be 'alias'. >>>>> >>>>> >>>>> java_md_solinux.c >>>>> >>>>> "//" in path is useless. Further down a free is missing. >>>>> >>>>> >>>>> SDE.c >>>>> >>>>> Call to stratumTableIndex can return negative value if defaultStratumId >>>>> == null. >>>>> >>>>> >>>>> socket_md.c >>>>> >>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>>>> the macros. >>>>> >>>>> >>>>> unpack.cpp >>>>> >>>>> n.slice should not get negative argument for end, which is passed from >>>>> dollar1. >>>>> But dollar1 can get negative where it is set to the result of >>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>> >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. >> >> >> -- >> Dmitry Samersoff >> Oracle Java development team, Saint Petersburg, Russia >> * I would love to change the world, but they won't give me the sources. From peter.levart at gmail.com Thu Dec 8 08:28:03 2016 From: peter.levart at gmail.com (Peter Levart) Date: Thu, 8 Dec 2016 09:28:03 +0100 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <9cf64c84-f010-608f-33d1-3bce2e6e4381@Oracle.com> References: <58441EC4.4090104@oracle.com> <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> <9cf64c84-f010-608f-33d1-3bce2e6e4381@Oracle.com> Message-ID: <48ae7274-6b8a-63ea-2ca8-779c1da118ae@gmail.com> On 12/07/2016 11:28 PM, Roger Riggs wrote: > AbstractStringBuilder: > I agree with Claes' comment suggesting that IAE for negative > lengths is a pain > and defining it to append 0 would be natural in many use cases. OTOH, inserting a simple Math.max(n, 0) instead of n where n could get negative would achieve the same without complicating the expression too much. Java standard APIs have a tradition of being explicit rather than having implicit hidden logic which surely shortens many usecases, but makes them harder to read and understand for casual readers not intimately familiar with such API. The logic to treat negative lengths as 0 is implicit and not universally correct. Regards, Peter From masayoshi.okutsu at oracle.com Thu Dec 8 08:55:36 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Thu, 8 Dec 2016 17:55:36 +0900 Subject: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era Message-ID: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> Hi, Please review the fix for JDK-8054214. It was necessary to override Era::getDisplayName to get era names from the specified property. This one fixes getAbbreviation() as well. Issue: https://bugs.openjdk.java.net/browse/JDK-8054214 Webrev: http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/ Thanks, Masayoshi From Ulf.Zibis at CoSoCo.de Thu Dec 8 09:01:29 2016 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 8 Dec 2016 10:01:29 +0100 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <48ae7274-6b8a-63ea-2ca8-779c1da118ae@gmail.com> References: <58441EC4.4090104@oracle.com> <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> <9cf64c84-f010-608f-33d1-3bce2e6e4381@Oracle.com> <48ae7274-6b8a-63ea-2ca8-779c1da118ae@gmail.com> Message-ID: <0bce88cd-8d1d-645e-f971-512ec3e133f6@CoSoCo.de> Am 08.12.2016 um 09:28 schrieb Peter Levart: > > On 12/07/2016 11:28 PM, Roger Riggs wrote: >> AbstractStringBuilder: >> I agree with Claes' comment suggesting that IAE for negative lengths is a pain >> and defining it to append 0 would be natural in many use cases. > > OTOH, inserting a simple Math.max(n, 0) instead of n where n could get negative would achieve the > same without complicating the expression too much. Java standard APIs have a tradition of being > explicit rather than having implicit hidden logic which surely shortens many usecases, but makes > them harder to read and understand for casual readers not intimately familiar with such API. The > logic to treat negative lengths as 0 is implicit and not universally correct. +1 If we would treat negative values as 0, we loose a chance, where programmers could become aware about possible errors in the logic of their program. -Ulf From claes.redestad at oracle.com Thu Dec 8 09:27:01 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 8 Dec 2016 10:27:01 +0100 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <0bce88cd-8d1d-645e-f971-512ec3e133f6@CoSoCo.de> References: <58441EC4.4090104@oracle.com> <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> <9cf64c84-f010-608f-33d1-3bce2e6e4381@Oracle.com> <48ae7274-6b8a-63ea-2ca8-779c1da118ae@gmail.com> <0bce88cd-8d1d-645e-f971-512ec3e133f6@CoSoCo.de> Message-ID: <2bd60475-c2fc-49ca-6ad5-26be5d5d33ca@oracle.com> On 2016-12-08 10:01, Ulf Zibis wrote: > Am 08.12.2016 um 09:28 schrieb Peter Levart: >> >> On 12/07/2016 11:28 PM, Roger Riggs wrote: >>> AbstractStringBuilder: >>> I agree with Claes' comment suggesting that IAE for negative >>> lengths is a pain >>> and defining it to append 0 would be natural in many use cases. >> >> OTOH, inserting a simple Math.max(n, 0) instead of n where n could >> get negative would achieve the same without complicating the >> expression too much. Java standard APIs have a tradition of being >> explicit rather than having implicit hidden logic which surely >> shortens many usecases, but makes them harder to read and understand >> for casual readers not intimately familiar with such API. The logic >> to treat negative lengths as 0 is implicit and not universally correct. > +1 > If we would treat negative values as 0, we loose a chance, where > programmers could become aware about possible errors in the logic of > their program. Right, the two of you have convinced me that some exceptional explicitness is the better choice in this (and likely most) cases. Thanks! /Claes > > -Ulf From volker.simonis at gmail.com Thu Dec 8 09:34:04 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Thu, 8 Dec 2016 10:34:04 +0100 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> Message-ID: Hi Vincent, the bug is closed and can't be looked at outside Oracle. Can you please make it visible for everybody. Also, this is a change of the public API so it requires a CCC request/approval. Finally, this seems to be clearly a feature and not a bug so it requires an FC extension request [1] Thanks, Volker [1] http://openjdk.java.net/projects/jdk9/fc-extension-process On Wed, Dec 7, 2016 at 5:32 PM, Vincent Ryan wrote: > A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. > Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing > a very simple replacement in a new and supported class: java.util.HexDump. > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 > Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ > From vincent.x.ryan at oracle.com Thu Dec 8 10:32:35 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 8 Dec 2016 10:32:35 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> Message-ID: > On 8 Dec 2016, at 09:34, Volker Simonis wrote: > > Hi Vincent, > > the bug is closed and can't be looked at outside Oracle. > Can you please make it visible for everybody. Sorry. I?ve just corrected that. > > Also, this is a change of the public API so it requires a CCC request/approval. I?ve a CCC prepared which I will submit if there is consensus on the proposed API. > > Finally, this seems to be clearly a feature and not a bug so it > requires an FC extension request [1] Right. I?ve begun that too. > > Thanks, > Volker > > [1] http://openjdk.java.net/projects/jdk9/fc-extension-process > > On Wed, Dec 7, 2016 at 5:32 PM, Vincent Ryan wrote: >> A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. >> Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing >> a very simple replacement in a new and supported class: java.util.HexDump. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ >> From felix.yang at oracle.com Thu Dec 8 10:35:25 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 8 Dec 2016 18:35:25 +0800 Subject: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently In-Reply-To: <8cd1ba28-3dfb-6c69-312d-4a48072efa16@oracle.com> References: <3b5d8771-43f8-4205-cfa1-e6d6850793e9@oracle.com> <8cd1ba28-3dfb-6c69-312d-4a48072efa16@oracle.com> Message-ID: <72f17901-9c5f-ac4b-18ad-b60398347848@oracle.com> Hi Dmitry, I tested your suggested "icann.org" and it indeed works well. Please review the updated webrev: http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.02/ Thanks, Felix On 2016/12/6 19:16, Dmitry Samersoff wrote: > Felix, > > 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for > this test. Could we use different one (e.g. icann.org) > > 2. This test run JTREG -> Test VM -> Another VM. Could we optimize > process usage? > > It might be better to create a jtreg "same vm" process that > > 1. launch another process with -Djava.net.preferIPv4Stack=true > that do A and PRT lookup in one run. > > 2. Read results of process above, do PTR lookup with default > settings and compare results. > > -Dmitry > > > On 2016-12-06 12:06, Felix Yang wrote: >> Hi, >> >> please review the following patch. It generally coverts codes from >> shell to plain java. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8169115 >> >> Webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/ >> >> Thanks, >> >> Felix >> > From dmitry.samersoff at oracle.com Thu Dec 8 10:37:25 2016 From: dmitry.samersoff at oracle.com (Dmitry Samersoff) Date: Thu, 8 Dec 2016 13:37:25 +0300 Subject: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently In-Reply-To: <72f17901-9c5f-ac4b-18ad-b60398347848@oracle.com> References: <3b5d8771-43f8-4205-cfa1-e6d6850793e9@oracle.com> <8cd1ba28-3dfb-6c69-312d-4a48072efa16@oracle.com> <72f17901-9c5f-ac4b-18ad-b60398347848@oracle.com> Message-ID: Felix, Changes looks good to me. Thank you for doing it. -Dmitry On 2016-12-08 13:35, Felix Yang wrote: > Hi Dmitry, > > I tested your suggested "icann.org" and it indeed works well. Please > review the updated webrev: > > http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.02/ > > Thanks, > Felix > On 2016/12/6 19:16, Dmitry Samersoff wrote: >> Felix, >> >> 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for >> this test. Could we use different one (e.g. icann.org) >> >> 2. This test run JTREG -> Test VM -> Another VM. Could we optimize >> process usage? >> >> It might be better to create a jtreg "same vm" process that >> >> 1. launch another process with -Djava.net.preferIPv4Stack=true >> that do A and PRT lookup in one run. >> >> 2. Read results of process above, do PTR lookup with default >> settings and compare results. >> >> -Dmitry >> >> >> On 2016-12-06 12:06, Felix Yang wrote: >>> Hi, >>> >>> please review the following patch. It generally coverts codes from >>> shell to plain java. >>> >>> Bug: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8169115 >>> >>> Webrev: >>> >>> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/ >>> >>> Thanks, >>> >>> Felix >>> >> > -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources. From Ulf.Zibis at CoSoCo.de Thu Dec 8 10:41:51 2016 From: Ulf.Zibis at CoSoCo.de (Ulf Zibis) Date: Thu, 8 Dec 2016 11:41:51 +0100 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> Message-ID: <36c5f2dd-29e6-fcc0-4102-79407bd8b350@CoSoCo.de> Hi, I would prefer a "normal" class instead a convolut of static methods. Via a normal constructor, we could pass some custom parameters e.g. capital/uppercase letters for "abcdef", prefix a header line, width of the index counter, bytes per line, i.e. have all the parameters, you have hardcoded, variable. Additionally I would like to see a method with variable start and end: String dump(byte[] bytes, int start, int length) -Ulf Am 07.12.2016 um 17:32 schrieb Vincent Ryan: > A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. > Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing > a very simple replacement in a new and supported class: java.util.HexDump. > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 > Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ > > From claes.redestad at oracle.com Thu Dec 8 11:06:33 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 8 Dec 2016 12:06:33 +0100 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: References: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> <58409545.4070803@oracle.com> <3ebaac19-48dd-9292-f5f5-8e6d822e9d38@oracle.com> Message-ID: <410cc13d-d550-81ac-9aab-f3cacc51399e@oracle.com> On 2016-12-08 04:30, Mandy Chung wrote: >> On Dec 2, 2016, at 6:29 AM, Claes Redestad wrote: >> >> : >> http://cr.openjdk.java.net/~redestad/8170595/webrev.03/ >> >> This brings significant improvements to some variants: > Good to see the significant improvements. > > I think what isLocalOrAnonymousClass needs probably is something like this: > > private boolean hasEnclosingMethodInfo() { > Object[] enclosingInfo = getEnclosingMethod0(); > if (enclosingInfo != null) { > EnclosingMethodInfo.validate(enclosingInfo); > } > return enclosingInfo != null; > } > > Then EnclosingMethodInfo doesn?t seem the need to change. The overall change would be simpler. Adding hasEnclosingMethodInfo has some descriptive value, but we'd still need to change EnclosingMethodInfo a bit to separate the validation from the constructor. > > As Joe suggests, this worths adding test cases for these methods, if not present. I was also concerned about the lack of explicit tests for this under jdk/test, but found what seemed like comprehensive tests in langtools, EnclosingMethodTest.java in particular. However, it seems adding a straightforward, minimal test inspired by other tests under java/lang/Class wouldn't hurt to ensure completeness and some more local coverage, so I made an attempt at this: http://cr.openjdk.java.net/~redestad/8170595/webrev.04/ Thanks! /Claes > > Mandy > From vincent.x.ryan at oracle.com Thu Dec 8 11:23:38 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 8 Dec 2016 11:23:38 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <36c5f2dd-29e6-fcc0-4102-79407bd8b350@CoSoCo.de> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <36c5f2dd-29e6-fcc0-4102-79407bd8b350@CoSoCo.de> Message-ID: <0B473D44-0918-4178-ADF7-B98067DFD744@oracle.com> > On 8 Dec 2016, at 10:41, Ulf Zibis wrote: > > Hi, > > I would prefer a "normal" class instead a convolut of static methods. Via a normal constructor, we could pass some custom parameters e.g. capital/uppercase letters for "abcdef", prefix a header line, width of the index counter, bytes per line, i.e. have all the parameters, you have hardcoded, variable. The dumpToStream method is designed to cater for all forms of customisation. You can see in the implementation that the dump method simply calls dumpToStream with a custom collector. I think that approach is more flexible than a constructor taking a fixed set of parameters. > > Additionally I would like to see a method with variable start and end: > > String dump(byte[] bytes, int start, int length) > That makes sense, I will add that. And matching one for dumpToStream ? > > -Ulf > > Am 07.12.2016 um 17:32 schrieb Vincent Ryan: >> A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. >> Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing >> a very simple replacement in a new and supported class: java.util.HexDump. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ >> >> > From jbluettduncan at gmail.com Thu Dec 8 11:52:47 2016 From: jbluettduncan at gmail.com (Jonathan Bluett-Duncan) Date: Thu, 8 Dec 2016 11:52:47 +0000 Subject: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era In-Reply-To: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> Message-ID: Hi Masayoshi, I'm not a reviewer, but there's something in JapaneseEra.java.cdiff.html which isn't terribly clear to me, so I wonder if you could clarify it for me. In the method `getDisplayName(TextStyle style, Locale locale)`, it's not clear to me why the call to `Objects.requireNonNull(locale, "locale");` is within the if-statement rather than on the first line. Is this because `Era.super::getDisplayName` already has a null check of its own? Kind regards, Jonathan On 8 December 2016 at 08:55, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for JDK-8054214. It was necessary to override > Era::getDisplayName to get era names from the specified property. This one > fixes getAbbreviation() as well. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8054214 > > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/ > > Thanks, > Masayoshi > > From vincent.x.ryan at oracle.com Thu Dec 8 12:10:33 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 8 Dec 2016 12:10:33 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> Message-ID: <20462051-E28F-45CA-BC7C-94D1FE34AC5A@oracle.com> > On 8 Dec 2016, at 07:22, David Holmes wrote: > > On 8/12/2016 2:32 AM, Vincent Ryan wrote: >> A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. >> Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing >> a very simple replacement in a new and supported class: java.util.HexDump. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ > > googling for "hexdump java" reveals quite a few hits - including javax.xml.bind.DatatypeConverter. DatatypeConverter is no longer directly accessible in JDK 9 as it is in the java.xml.bind module. So an ??add-modules? flag would be required. > > Does this sun.* class really meet the acceptance criteria for inclusion in java.util? That bar is intentionally set very high. We considered other locations for these methods (including java.lang.String !) but settled on java.util.HexString as a good balance between visibility and controversy. > > Just wondering ... > > David > From vincent.x.ryan at oracle.com Thu Dec 8 12:15:12 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Thu, 8 Dec 2016 12:15:12 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <20462051-E28F-45CA-BC7C-94D1FE34AC5A@oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <20462051-E28F-45CA-BC7C-94D1FE34AC5A@oracle.com> Message-ID: <8F7887FA-C52C-494E-8239-22824FE73A37@oracle.com> > On 8 Dec 2016, at 12:10, Vincent Ryan wrote: > > >> On 8 Dec 2016, at 07:22, David Holmes wrote: >> >> On 8/12/2016 2:32 AM, Vincent Ryan wrote: >>> A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. >>> Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing >>> a very simple replacement in a new and supported class: java.util.HexDump. >>> >>> Thanks. >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >>> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ >> >> googling for "hexdump java" reveals quite a few hits - including javax.xml.bind.DatatypeConverter. > > DatatypeConverter is no longer directly accessible in JDK 9 as it is in the java.xml.bind module. > So an ??add-modules? flag would be required. > > >> >> Does this sun.* class really meet the acceptance criteria for inclusion in java.util? That bar is intentionally set very high. > > We considered other locations for these methods (including java.lang.String !) but settled on java.util.HexString s/HexString/HexDump > as a good balance between visibility and controversy. > > >> >> Just wondering ... >> >> David >> > From christoph.langer at sap.com Thu Dec 8 12:21:23 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 8 Dec 2016 12:21:23 +0000 Subject: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently In-Reply-To: <72f17901-9c5f-ac4b-18ad-b60398347848@oracle.com> References: <3b5d8771-43f8-4205-cfa1-e6d6850793e9@oracle.com> <8cd1ba28-3dfb-6c69-312d-4a48072efa16@oracle.com> <72f17901-9c5f-ac4b-18ad-b60398347848@oracle.com> Message-ID: <82274a59caf547d5a12066021c3d2cd8@DEWDFE13DE03.global.corp.sap> Hi Felix, looks good also for me. Small typo: 85 throw new RuntimeException("Mistmatch between default" Mistmatch -> Mismatch :) Best regards Christoph > -----Original Message----- > From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Felix > Yang > Sent: Donnerstag, 8. Dezember 2016 11:35 > To: Dmitry Samersoff ; core-libs- > dev at openjdk.java.net; net-dev at openjdk.java.net; CHRIS.HEGARTY > > Subject: Re: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed > intermittently > > Hi Dmitry, > > I tested your suggested "icann.org" and it indeed works well. Please > review the updated webrev: > > http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.02/ > > Thanks, > Felix > On 2016/12/6 19:16, Dmitry Samersoff wrote: > > Felix, > > > > 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for > > this test. Could we use different one (e.g. icann.org) > > > > 2. This test run JTREG -> Test VM -> Another VM. Could we optimize > > process usage? > > > > It might be better to create a jtreg "same vm" process that > > > > 1. launch another process with -Djava.net.preferIPv4Stack=true > > that do A and PRT lookup in one run. > > > > 2. Read results of process above, do PTR lookup with default > > settings and compare results. > > > > -Dmitry > > > > > > On 2016-12-06 12:06, Felix Yang wrote: > >> Hi, > >> > >> please review the following patch. It generally coverts codes from > >> shell to plain java. > >> > >> Bug: > >> > >> https://bugs.openjdk.java.net/browse/JDK-8169115 > >> > >> Webrev: > >> > >> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/ > >> > >> Thanks, > >> > >> Felix > >> > > From goetz.lindenmaier at sap.com Thu Dec 8 14:21:23 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Dec 2016 14:21:23 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> Message-ID: Hi David, thanks for looking at the change. New webrev: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > src/java.base/share/native/libjli/java.c > As far as I can see the existing code is working perfectly fine. Ah, thanks for the explanation, now I got it! Removed. > Again I'm not sure what the bug is here. On AIX the output string is > expanded with: > "%s/lib/%s/jli:" I first edited this against jdk9/hs, where the arch is gone since 8066474, http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc but the // was not adapted. Then I moved the change to jdk9/dev because I thought I have to push it there. And yes, in that coding // would be correct. So I have to wait until hs is promoted ... > The jvmpath -> jvm_newpath change wasn't really necessary - a comment on > the strdup would have sufficed IMO. Dmitry asked me to add it. But I think it's ok. Can I consider this reviewed now? I.e. could I push it once 8066474 is promoted and Joe Darcy agreed? Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 8. Dezember 2016 09:14 > To: Lindenmaier, Goetz ; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > Hi Goetz, > > On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > > Hi Dmitry, > > > > yes, new_jvmpath is consistent with the other variables. > > I also merged the ifs in SDE.c. > > > > new webrev: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > > src/java.base/share/native/libjli/java.c > > As far as I can see the existing code is working perfectly fine. Given a > jvm.cfg with: > > -server KNOWN > -client IGNORE > -myvm KNOWN > -oldvm ALIASED_TO -server > > The usage text is: > > -server to select the "server" VM > -myvm to select the "myvm" VM > -oldvm is a synonym for the "server" VM [deprecated] > The default VM is server, > because you are running on a server-class machine. > > which is exactly what I would expect. Why do you think there is a bug? > > --- > > src/java.base/unix/native/libjli/java_md_solinux.c > > Again I'm not sure what the bug is here. On AIX the output string is > expanded with: > > "%s/lib/%s/jli:" > > so it needs to account for the extra "/lib//jli:" characters - and that > is exactly what the existing code does: > > + JLI_StrLen("/lib//jli:") > > The jvmpath -> jvm_newpath change wasn't really necessary - a comment on > the strdup would have sufficed IMO. > > Thanks, > David > ----- > > > > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >> Sent: Wednesday, December 07, 2016 2:43 PM > >> To: Lindenmaier, Goetz ; Java Core Libs > >> ; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> Goetz, > >> > >> SDE.c: > >> > >> You might combine if at ll. 260 and 263 to one but it's just matter of test. > >> > >> if (sti == baseStratumIndex || sti < 0) { > >> return; /* Java stratum - return unchanged */ > >> } > >> > >>> I'm not sure what you mean. I tried to fix it, but please > >>> double-check the new webrev. > >> > >> if cnt is <= 0 loop at l.267 > >> > >> for (; cnt-- > 0; ++fromEntry) { > >> > >> is never run and we effectively do > >> > >> *entryCountPtr = 0; > >> > >> at l.283 > >> > >> So if we you suspect that cnt may become negative or 0: > >> (your v.01 changes) > >> > >> 260 if (sti < 0 && cnt > 0) { > >> 261 return; > >> 262 } > >> > >> it's better to check it early. > >> > >> But I'm not sure we have to care about negative/zero cnt here. > >> > >> -Dmitry > >> > >> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>> Hi Dmitry, > >>> > >>> thanks for looking at my change! > >>> Updated webrev: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 > >>> > >>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>> Is this line correct? > >>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>> > >>> It seems pointless. Should I remove it? (The whole file is a horror.) > >>> > >>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>> It might be better to return immediately if cnt < 0, > >>>> regardless of value of sti. > >>> > >>> I'm not sure what you mean. I tried to fix it, but please > >>> double-check the new webrev. > >>> > >>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>> It might be better to write > >>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>> and leave one copy of setsockopt() call > >>> > >>> Yes, looks better. > >>> > >>> Best regards, > >>> Goetz > >>> > >>> > >>>> > >>>> -Dmitry > >>>> > >>>> > >>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> > >>>>> > >>>>> This change fixes some minor issues found in our code scans. > >>>>> > >>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>> > >>>>> > >>>>> > >>>>> Please review: > >>>>> > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.01/ > >>>>> > >>>>> > >>>>> > >>>>> Best regards, > >>>>> > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>> Changes in detail: > >>>>> > >>>>> > >>>>> > >>>>> e_asin.c > >>>>> > >>>>> Code scan reports missing {}. > >>>>> > >>>>> > >>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of > >>>>> the processor. > >>>>> It's a way to avoid the C compiler to optimize the code away. It is > >>>>> always true, > >>>>> so the parenthesis of the outer else don't matter. > >>>>> > >>>>> Although this basically just adds the {} I would like to submit this to > >>>>> > >>>>> avoid anybody else spends more the 30sec on understanding these > >>>>> > >>>>> if statements. > >>>>> > >>>>> > >>>>> k_standard.c > >>>>> > >>>>> exc.retval is returned below and thus should always be initialized. > >>>>> > >>>>> > >>>>> imageDecompressor.cpp > >>>>> > >>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>> > >>>>> > >>>>> java.c > >>>>> > >>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>> > >>>>> > >>>>> java_md_solinux.c > >>>>> > >>>>> "//" in path is useless. Further down a free is missing. > >>>>> > >>>>> > >>>>> SDE.c > >>>>> > >>>>> Call to stratumTableIndex can return negative value if defaultStratumId > >>>>> == null. > >>>>> > >>>>> > >>>>> socket_md.c > >>>>> > >>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in > >>>>> the macros. > >>>>> > >>>>> > >>>>> unpack.cpp > >>>>> > >>>>> n.slice should not get negative argument for end, which is passed from > >>>>> dollar1. > >>>>> But dollar1 can get negative where it is set to the result of > >>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>> > >>>> > >>>> > >>>> -- > >>>> Dmitry Samersoff > >>>> Oracle Java development team, Saint Petersburg, Russia > >>>> * I would love to change the world, but they won't give me the sources. > >> > >> > >> -- > >> Dmitry Samersoff > >> Oracle Java development team, Saint Petersburg, Russia > >> * I would love to change the world, but they won't give me the sources. From goetz.lindenmaier at sap.com Thu Dec 8 14:32:35 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 8 Dec 2016 14:32:35 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> Message-ID: <054e0fbbbff042349dc2bc555fdd5be5@DEROTE13DE08.global.corp.sap> Hi Joe, could you please have a look at my change to e_asin.c: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/src/java.base/share/native/libfdlibm/e_asin.c.udiff.html The change conserves the situation, I just added {} and comments. I would appreciate to clean this up as it's hard to understand and our code scan does not like it the way it is. We had talked about this in my thread where I learned to read this code :) http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045165.html Best regards, Goetz. > -----Original Message----- > From: Martin Buchholz [mailto:martinrb at google.com] > Sent: Mittwoch, 7. Dezember 2016 18:09 > To: Lindenmaier, Goetz ; Joe Darcy > > Cc: Dmitry Samersoff ; Java Core Libs libs-dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > This changes fdlibm, which has historically been untouched. Don't commit > without Joe Darcy's approval. > > On Wed, Dec 7, 2016 at 7:26 AM, Lindenmaier, Goetz > > wrote: > > > Hi Dmitry, > > yes, new_jvmpath is consistent with the other variables. > I also merged the ifs in SDE.c. > > new webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.03/ corlib_s11y/webrev.03/> > > Best regards, > Goetz. > > > -----Original Message----- > > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com > ] > > Sent: Wednesday, December 07, 2016 2:43 PM > > To: Lindenmaier, Goetz >; Java Core Libs > > dev at openjdk.java.net> >; serviceability-dev (serviceability- > > dev at openjdk.java.net ) > dev at openjdk.java.net> > > > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > > coding. > > > > > Goetz, > > > > SDE.c: > > > > You might combine if at ll. 260 and 263 to one but it's just matter of > test. > > > > if (sti == baseStratumIndex || sti < 0) { > > return; /* Java stratum - return unchanged */ > > } > > > > > I'm not sure what you mean. I tried to fix it, but please > > > double-check the new webrev. > > > > if cnt is <= 0 loop at l.267 > > > > for (; cnt-- > 0; ++fromEntry) { > > > > is never run and we effectively do > > > > *entryCountPtr = 0; > > > > at l.283 > > > > So if we you suspect that cnt may become negative or 0: > > (your v.01 changes) > > > > 260 if (sti < 0 && cnt > 0) { > > 261 return; > > 262 } > > > > it's better to check it early. > > > > But I'm not sure we have to care about negative/zero cnt here. > > > > -Dmitry > > > > On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > > > Hi Dmitry, > > > > > > thanks for looking at my change! > > > Updated webrev: > > > http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.02 corlib_s11y/webrev.02> > > > > > >> * src/java.base/unix/native/libjli/java_md_solinux.c > > >> Is this line correct? > > >> 519 jvmpath = JLI_StringDup(jvmpath); > > > > > > It seems pointless. Should I remove it? (The whole file is a horror.) > > > > > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > > >> It might be better to return immediately if cnt < 0, > > >> regardless of value of sti. > > > > > > I'm not sure what you mean. I tried to fix it, but please > > > double-check the new webrev. > > > > > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > > >> It might be better to write > > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; > > >> and leave one copy of setsockopt() call > > > > > > Yes, looks better. > > > > > > Best regards, > > > Goetz > > > > > > > > >> > > >> -Dmitry > > >> > > >> > > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > > >>> Hi, > > >>> > > >>> > > >>> > > >>> This change fixes some minor issues found in our code scans. > > >>> > > >>> I hope this correctly addresses corelib and serviceability issues. > > >>> > > >>> > > >>> > > >>> Please review: > > >>> > > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > > > corlib_s11y/webrev.01/ > > >>> > > >>> > > >>> > > >>> Best regards, > > >>> > > >>> Goetz. > > >>> > > >>> > > >>> > > >>> Changes in detail: > > >>> > > >>> > > >>> > > >>> e_asin.c > > >>> > > >>> Code scan reports missing {}. > > >>> > > >>> > > >>> The code "if (huge+x>one) {" is only there to set the inexact flag > of > > >>> the processor. > > >>> It's a way to avoid the C compiler to optimize the code away. It is > > >>> always true, > > >>> so the parenthesis of the outer else don't matter. > > >>> > > >>> Although this basically just adds the {} I would like to submit this > to > > >>> > > >>> avoid anybody else spends more the 30sec on understanding > these > > >>> > > >>> if statements. > > >>> > > >>> > > >>> k_standard.c > > >>> > > >>> exc.retval is returned below and thus should always be initialized. > > >>> > > >>> > > >>> imageDecompressor.cpp > > >>> > > >>> Wrong destructor is used. Reported also by David CARLIER > > >>> > > >>> > > >>> java.c > > >>> > > >>> in line 1865 'name' was used, it should be 'alias'. > > >>> > > >>> > > >>> java_md_solinux.c > > >>> > > >>> "//" in path is useless. Further down a free is missing. > > >>> > > >>> > > >>> SDE.c > > >>> > > >>> Call to stratumTableIndex can return negative value if > defaultStratumId > > >>> == null. > > >>> > > >>> > > >>> socket_md.c > > >>> > > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden > in > > >>> the macros. > > >>> > > >>> > > >>> unpack.cpp > > >>> > > >>> n.slice should not get negative argument for end, which is passed > from > > >>> dollar1. > > >>> But dollar1 can get negative where it is set to the result of > > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > > >>> > > >> > > >> > > >> -- > > >> Dmitry Samersoff > > >> Oracle Java development team, Saint Petersburg, Russia > > >> * I would love to change the world, but they won't give me the > sources. > > > > > > -- > > Dmitry Samersoff > > Oracle Java development team, Saint Petersburg, Russia > > * I would love to change the world, but they won't give me the > sources. > > From felix.yang at oracle.com Thu Dec 8 15:35:09 2016 From: felix.yang at oracle.com (Felix Yang) Date: Thu, 8 Dec 2016 23:35:09 +0800 Subject: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently In-Reply-To: <82274a59caf547d5a12066021c3d2cd8@DEWDFE13DE03.global.corp.sap> References: <3b5d8771-43f8-4205-cfa1-e6d6850793e9@oracle.com> <8cd1ba28-3dfb-6c69-312d-4a48072efa16@oracle.com> <72f17901-9c5f-ac4b-18ad-b60398347848@oracle.com> <82274a59caf547d5a12066021c3d2cd8@DEWDFE13DE03.global.corp.sap> Message-ID: <57bee4f4-866e-3661-e80a-644e2d69b49e@oracle.com> Langer and Dmitry, thanks for the review. Pushed with typo fixed -Felix On 2016/12/8 20:21, Langer, Christoph wrote: > Hi Felix, > > looks good also for me. > > Small typo: > 85 throw new RuntimeException("Mistmatch between default" > > Mistmatch -> Mismatch :) > > Best regards > Christoph > >> -----Original Message----- >> From: net-dev [mailto:net-dev-bounces at openjdk.java.net] On Behalf Of Felix >> Yang >> Sent: Donnerstag, 8. Dezember 2016 11:35 >> To: Dmitry Samersoff ; core-libs- >> dev at openjdk.java.net; net-dev at openjdk.java.net; CHRIS.HEGARTY >> >> Subject: Re: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed >> intermittently >> >> Hi Dmitry, >> >> I tested your suggested "icann.org" and it indeed works well. Please >> review the updated webrev: >> >> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.02/ >> >> Thanks, >> Felix >> On 2016/12/6 19:16, Dmitry Samersoff wrote: >>> Felix, >>> >>> 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for >>> this test. Could we use different one (e.g. icann.org) >>> >>> 2. This test run JTREG -> Test VM -> Another VM. Could we optimize >>> process usage? >>> >>> It might be better to create a jtreg "same vm" process that >>> >>> 1. launch another process with -Djava.net.preferIPv4Stack=true >>> that do A and PRT lookup in one run. >>> >>> 2. Read results of process above, do PTR lookup with default >>> settings and compare results. >>> >>> -Dmitry >>> >>> >>> On 2016-12-06 12:06, Felix Yang wrote: >>>> Hi, >>>> >>>> please review the following patch. It generally coverts codes from >>>> shell to plain java. >>>> >>>> Bug: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8169115 >>>> >>>> Webrev: >>>> >>>> http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.00/ >>>> >>>> Thanks, >>>> >>>> Felix >>>> From paul.sandoz at oracle.com Thu Dec 8 16:44:12 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Dec 2016 08:44:12 -0800 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <2bd60475-c2fc-49ca-6ad5-26be5d5d33ca@oracle.com> References: <58441EC4.4090104@oracle.com> <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> <9cf64c84-f010-608f-33d1-3bce2e6e4381@Oracle.com> <48ae7274-6b8a-63ea-2ca8-779c1da118ae@gmail.com> <0bce88cd-8d1d-645e-f971-512ec3e133f6@CoSoCo.de> <2bd60475-c2fc-49ca-6ad5-26be5d5d33ca@oracle.com> Message-ID: > On 8 Dec 2016, at 01:27, Claes Redestad wrote: > > > > On 2016-12-08 10:01, Ulf Zibis wrote: >> Am 08.12.2016 um 09:28 schrieb Peter Levart: >>> >>> On 12/07/2016 11:28 PM, Roger Riggs wrote: >>>> AbstractStringBuilder: >>>> I agree with Claes' comment suggesting that IAE for negative lengths is a pain >>>> and defining it to append 0 would be natural in many use cases. >>> >>> OTOH, inserting a simple Math.max(n, 0) instead of n where n could get negative would achieve the same without complicating the expression too much. Java standard APIs have a tradition of being explicit rather than having implicit hidden logic which surely shortens many usecases, but makes them harder to read and understand for casual readers not intimately familiar with such API. The logic to treat negative lengths as 0 is implicit and not universally correct. >> +1 >> If we would treat negative values as 0, we loose a chance, where programmers could become aware about possible errors in the logic of their program. > > Right, the two of you have convinced me that some exceptional explicitness is the better choice in this (and likely most) cases. > +1 i think this is the correct approach. Paul. From mandy.chung at oracle.com Thu Dec 8 17:17:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Dec 2016 09:17:42 -0800 Subject: RFR: 8170595: Optimize Class.isAnonymousClass In-Reply-To: <410cc13d-d550-81ac-9aab-f3cacc51399e@oracle.com> References: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> <58409545.4070803@oracle.com> <3ebaac19-48dd-9292-f5f5-8e6d822e9d38@oracle.com> <410cc13d-d550-81ac-9aab-f3cacc51399e@oracle.com> Message-ID: <81AB0537-4F8C-4474-94C1-690266404252@oracle.com> > On Dec 8, 2016, at 3:06 AM, Claes Redestad wrote: > > http://cr.openjdk.java.net/~redestad/8170595/webrev.04/ Looks good. Can you update the synoposis of this issue to include isLocalClass and isMemberClass? Mandy From claes.redestad at oracle.com Thu Dec 8 17:33:47 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Thu, 8 Dec 2016 18:33:47 +0100 Subject: RFR: 8170595: Optimize Class.isAnonymousClass, isLocalClass, and isMemberClass In-Reply-To: <81AB0537-4F8C-4474-94C1-690266404252@oracle.com> References: <2076a0b69fa3ca03a433db158a712929@email.freenet.de> <58409545.4070803@oracle.com> <3ebaac19-48dd-9292-f5f5-8e6d822e9d38@oracle.com> <410cc13d-d550-81ac-9aab-f3cacc51399e@oracle.com> <81AB0537-4F8C-4474-94C1-690266404252@oracle.com> Message-ID: <6908f16d-ea3f-acc3-6c78-29bc4db85274@oracle.com> On 2016-12-08 18:17, Mandy Chung wrote: >> On Dec 8, 2016, at 3:06 AM, Claes Redestad wrote: >> >> http://cr.openjdk.java.net/~redestad/8170595/webrev.04/ > Looks good. Thanks! > Can you update the synoposis of this issue to include isLocalClass and isMemberClass? Done. /Claes > > Mandy From nathanmittler at google.com Thu Dec 8 18:03:22 2016 From: nathanmittler at google.com (Nathan Mittler) Date: Thu, 8 Dec 2016 10:03:22 -0800 Subject: Alternatives for Unsafe field access Message-ID: Hi everyone, Apologies in advance if this isn't the correct forum for this question. My team is working on an experimental runtime for Google's protocol buffers which is currently relying on sun.misc.Unsafe to perform various tasks efficiently. I'm aware that the plan is to eventually remove Unsafe altogether, and I want to make sure that we still have a way to move forward with future versions of Java. The code is up on a github branch ( https://github.com/google/protobuf/tree/java_experimental). For an example of the sorts of things our runtime needs to do, you can look at the serialization code ( https://github.com/google/protobuf/blob/java_experimental/java/core/src/main/java/com/google/protobuf/AbstractProto3Schema.java#L49 ). The idea is that the runtime dynamically determines information about message fields (e.g. field types, offsets) and stores it into a single buffer. Our main need is fast read/write access to the private fields of our generated message classes. Java reflection would be too slow and would require data representation as a list of objects, rather than a continuous buffer (much less compact and cache-friendly). Security restrictions would be a concern as well. At first glance at Java 9, I don't see any facilities that would help here. This would seem to be a fairly common use case a low-level serialization framework, such as protobuf. Are there any thoughts on how such a use case could be supported post-Unsafe? Thanks, Nathan From naoto.sato at oracle.com Thu Dec 8 18:20:03 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Thu, 8 Dec 2016 10:20:03 -0800 Subject: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era In-Reply-To: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> Message-ID: Okutsu-san, In JapaneseEra::getDisplayName, Should there be Objects.requireNonNull() check for "style"? The current impl seems to return abbreviated era if null is passed as "style". Naoto On 12/8/16 12:55 AM, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for JDK-8054214. It was necessary to override > Era::getDisplayName to get era names from the specified property. This > one fixes getAbbreviation() as well. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8054214 > > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/ > > Thanks, > Masayoshi > From Alan.Bateman at oracle.com Thu Dec 8 19:44:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 8 Dec 2016 19:44:22 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> Message-ID: <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> On 07/12/2016 16:32, Vincent Ryan wrote: > A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. > Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing > a very simple replacement in a new and supported class: java.util.HexDump. > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 > Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ I'm happy to see a proposal for an API in Java SE for this, it's always sad to bump into code that is using a utility method exposed in java.xml.bind or the JDK internal hex dumper. I've skimmed the API. The class name and package look okay. I assume you can make HexDump final (I realize the ctor is private). The toHexString/fromHexString methods are really useful but I think the javadoc needs to be fleshed out a bit. For example, fromHexString doesn't make it clear whether the A-F need to be in a specific case, the IAE description doesn't make it clear that it is thrown when there is invalid input. The description of toHexString can be clearer on the length of the returned string, the reader might wonder if there is a "0x" prepended for example. I like dump(byte[]) but I could imagine calls to "customize" the returned string in many ways. After reading dumpToStream then I wonder if it might be better to drop dump and let users do their own layout. If you keep it then the javadoc needs work - the reader will have many questions. What is "non-printable", what is the character in the output that splits the lines, how is the last line handled when the input is not a multiple of 16 bytes. Given dumpToStream then I wonder if might be better to drop this method. dumpToStream(byte[]) is interesting too but again needs a lot more javadoc. I assume the spliterator will be replaced eventually as the size is known so you can do a good implementation. It would be useful to put in some @see references from methods like Integer.toHexString. I don't have comments on the implementation/test at this time. -Alan. From Roger.Riggs at Oracle.com Thu Dec 8 19:51:07 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 8 Dec 2016 14:51:07 -0500 Subject: Alternatives for Unsafe field access In-Reply-To: References: Message-ID: Hi Nathan, Have you looked at VarHandles? [1] It is possible to use MethodsHandles.Lookup to get a VarHandle to an unreflected field. Roger [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHandles.Lookup.html On 12/8/2016 1:03 PM, Nathan Mittler wrote: > Hi everyone, > > Apologies in advance if this isn't the correct forum for this question. My > team is working on an experimental runtime for Google's protocol buffers > which is currently relying on sun.misc.Unsafe to perform various tasks > efficiently. I'm aware that the plan is to eventually remove Unsafe > altogether, and I want to make sure that we still have a way to move > forward with future versions of Java. > > The code is up on a github branch ( > https://github.com/google/protobuf/tree/java_experimental). > > For an example of the sorts of things our runtime needs to do, you can look > at the serialization code ( > https://github.com/google/protobuf/blob/java_experimental/java/core/src/main/java/com/google/protobuf/AbstractProto3Schema.java#L49 > ). > > The idea is that the runtime dynamically determines information about > message fields (e.g. field types, offsets) and stores it into a single > buffer. Our main need is fast read/write access to the private fields of > our generated message classes. Java reflection would be too slow and would > require data representation as a list of objects, rather than a continuous > buffer (much less compact and cache-friendly). Security restrictions would > be a concern as well. At first glance at Java 9, I don't see any facilities > that would help here. > > This would seem to be a fairly common use case a low-level serialization > framework, such as protobuf. Are there any thoughts on how such a use case > could be supported post-Unsafe? > > Thanks, > Nathan From paul.sandoz at oracle.com Thu Dec 8 20:08:08 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 8 Dec 2016 12:08:08 -0800 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> Message-ID: Hi, It may take a few iterations to get the API settled. There are other byte sources we may want to consider such as InputStream and ByteBuffer. Comments below. Paul. > On 7 Dec 2016, at 08:32, Vincent Ryan wrote: > > A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. > Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing > a very simple replacement in a new and supported class: java.util.HexDump. > > Thanks. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 > Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ > 55 if (bytes == null) { 56 throw new NullPointerException(); 57 } Objects.requireNonNull 78 * @throws IllegalArgumentException if {@code hexString} has an odd number 79 * of digits 80 * @throws NullPointerException if {@code hexString} is {@code null} 81 */ 82 public static byte[] fromHexString(String hexString) { This should accept a CharSequence, plus also have bounded range equivalent. Also throws IAE if the hexString contains non-convertible characters. 106 /** 107 * Generates a stream of hexadecimal strings, in 16-byte chunks, 108 * from the contents of a binary buffer. 109 * 110 * @param bytes a binary buffer 111 * @return a stream of hexadecimal strings 112 * @throws NullPointerException if {@code bytes} is {@code null} 113 */ 114 public static Stream dumpToStream(byte[] bytes) { 115 if (bytes == null) { 116 throw new NullPointerException(); 117 } 118 return StreamSupport.stream( 119 Spliterators.spliteratorUnknownSize( 120 new HexDumpIterator(bytes), 121 Spliterator.ORDERED | Spliterator.NONNULL), 122 false); 123 } I suspect there is no need for a HexDumpIterator and you can do: return IntStream.range(0, roundUp(bytes.length, 16)).mapToObject(?); and in the map function take care of the trailing bytes based on the byte[] length. That?s potentially simple enough there might be no need for a stream method. Where it gets more complicated is if the source is of unknown size such as InputStream, where the stream returning method probably has more value. Ideally what we want to return is Stream<[Long, String]>, then it?s really easy for others for format, but alas the current form would be ugly and inefficient. So i suspect the dump method has some legs but it?s real value may be for a fully streaming solution. 140 public static String dump(byte[] bytes) { 141 if (bytes == null) { 142 throw new NullPointerException(); 143 } 144 145 int[] count = { -16 }; 146 return dumpToStream(bytes).collect(Collector.of( 147 StringBuilder::new, 148 (stringBuilder, hexString) -> 149 stringBuilder 150 .append(String.format("%08x %s%n", 151 (count[0] += CHUNK_LENGTH), 152 explode(hexString))), 153 StringBuilder::append, 154 StringBuilder::toString)); 155 } The encoding of the count and exploding could also append directly into the main string builder, reducing memory churn. And i think you can also start from IntStream.range(0, roundUp(bytes.length, 16)) avoiding the count state. 192 if (b < ' ' || b > '~') { 193 sb.append(".?); Use ?.? 194 } else { 195 sb.append(new String(new byte[]{ b })); Cast the byte to a char instead. 196 } From nathanmittler at google.com Thu Dec 8 20:49:04 2016 From: nathanmittler at google.com (Nathan Mittler) Date: Thu, 8 Dec 2016 12:49:04 -0800 Subject: Alternatives for Unsafe field access In-Reply-To: References: Message-ID: Hi Roger, If I read that correctly, lookups still have to go through access checks which would seem to imply that they can't be used for private field access. Or am I misunderstanding? On Thu, Dec 8, 2016 at 11:51 AM, Roger Riggs wrote: > Hi Nathan, > > Have you looked at VarHandles? [1] > It is possible to use MethodsHandles.Lookup to get a VarHandle to an > unreflected field. > > Roger > > [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke > /MethodHandles.Lookup.html > > > > On 12/8/2016 1:03 PM, Nathan Mittler wrote: > >> Hi everyone, >> >> Apologies in advance if this isn't the correct forum for this question. My >> team is working on an experimental runtime for Google's protocol buffers >> which is currently relying on sun.misc.Unsafe to perform various tasks >> efficiently. I'm aware that the plan is to eventually remove Unsafe >> altogether, and I want to make sure that we still have a way to move >> forward with future versions of Java. >> >> The code is up on a github branch ( >> https://github.com/google/protobuf/tree/java_experimental). >> >> For an example of the sorts of things our runtime needs to do, you can >> look >> at the serialization code ( >> https://github.com/google/protobuf/blob/java_experimental/ >> java/core/src/main/java/com/google/protobuf/AbstractProto3Schema.java#L49 >> ). >> >> The idea is that the runtime dynamically determines information about >> message fields (e.g. field types, offsets) and stores it into a single >> buffer. Our main need is fast read/write access to the private fields of >> our generated message classes. Java reflection would be too slow and would >> require data representation as a list of objects, rather than a continuous >> buffer (much less compact and cache-friendly). Security restrictions would >> be a concern as well. At first glance at Java 9, I don't see any >> facilities >> that would help here. >> >> This would seem to be a fairly common use case a low-level serialization >> framework, such as protobuf. Are there any thoughts on how such a use case >> could be supported post-Unsafe? >> >> Thanks, >> Nathan >> > > From david.holmes at oracle.com Thu Dec 8 20:59:07 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Dec 2016 06:59:07 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> Message-ID: <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > Hi David, > > thanks for looking at the change. New webrev: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >> src/java.base/share/native/libjli/java.c >> As far as I can see the existing code is working perfectly fine. > Ah, thanks for the explanation, now I got it! Removed. > >> Again I'm not sure what the bug is here. On AIX the output string is >> expanded with: >> "%s/lib/%s/jli:" > I first edited this against jdk9/hs, where the arch is gone since 8066474, > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > but the // was not adapted. Then I moved the change to jdk9/dev because > I thought I have to push it there. And yes, in that coding // would be correct. > So I have to wait until hs is promoted ... So just based on the current file, the change proposed - to remove one / - is not correct until the arch directory is removed. David ----- >> The jvmpath -> jvm_newpath change wasn't really necessary - a comment on >> the strdup would have sufficed IMO. > Dmitry asked me to add it. But I think it's ok. > > Can I consider this reviewed now? I.e. could I push it once 8066474 is > promoted and Joe Darcy agreed? > > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 8. Dezember 2016 09:14 >> To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> Hi Goetz, >> >> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>> Hi Dmitry, >>> >>> yes, new_jvmpath is consistent with the other variables. >>> I also merged the ifs in SDE.c. >>> >>> new webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ >> >> src/java.base/share/native/libjli/java.c >> >> As far as I can see the existing code is working perfectly fine. Given a >> jvm.cfg with: >> >> -server KNOWN >> -client IGNORE >> -myvm KNOWN >> -oldvm ALIASED_TO -server >> >> The usage text is: >> >> -server to select the "server" VM >> -myvm to select the "myvm" VM >> -oldvm is a synonym for the "server" VM [deprecated] >> The default VM is server, >> because you are running on a server-class machine. >> >> which is exactly what I would expect. Why do you think there is a bug? >> >> --- >> >> src/java.base/unix/native/libjli/java_md_solinux.c >> >> Again I'm not sure what the bug is here. On AIX the output string is >> expanded with: >> >> "%s/lib/%s/jli:" >> >> so it needs to account for the extra "/lib//jli:" characters - and that >> is exactly what the existing code does: >> >> + JLI_StrLen("/lib//jli:") >> >> The jvmpath -> jvm_newpath change wasn't really necessary - a comment on >> the strdup would have sufficed IMO. >> >> Thanks, >> David >> ----- >> >> >> >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>> To: Lindenmaier, Goetz ; Java Core Libs >>>> ; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> Goetz, >>>> >>>> SDE.c: >>>> >>>> You might combine if at ll. 260 and 263 to one but it's just matter of test. >>>> >>>> if (sti == baseStratumIndex || sti < 0) { >>>> return; /* Java stratum - return unchanged */ >>>> } >>>> >>>>> I'm not sure what you mean. I tried to fix it, but please >>>>> double-check the new webrev. >>>> >>>> if cnt is <= 0 loop at l.267 >>>> >>>> for (; cnt-- > 0; ++fromEntry) { >>>> >>>> is never run and we effectively do >>>> >>>> *entryCountPtr = 0; >>>> >>>> at l.283 >>>> >>>> So if we you suspect that cnt may become negative or 0: >>>> (your v.01 changes) >>>> >>>> 260 if (sti < 0 && cnt > 0) { >>>> 261 return; >>>> 262 } >>>> >>>> it's better to check it early. >>>> >>>> But I'm not sure we have to care about negative/zero cnt here. >>>> >>>> -Dmitry >>>> >>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>> Hi Dmitry, >>>>> >>>>> thanks for looking at my change! >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>>>> >>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>> Is this line correct? >>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>> >>>>> It seems pointless. Should I remove it? (The whole file is a horror.) >>>>> >>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>> It might be better to return immediately if cnt < 0, >>>>>> regardless of value of sti. >>>>> >>>>> I'm not sure what you mean. I tried to fix it, but please >>>>> double-check the new webrev. >>>>> >>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>> It might be better to write >>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>> and leave one copy of setsockopt() call >>>>> >>>>> Yes, looks better. >>>>> >>>>> Best regards, >>>>> Goetz >>>>> >>>>> >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> >>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> >>>>>>> >>>>>>> This change fixes some minor issues found in our code scans. >>>>>>> >>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Please review: >>>>>>> >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>> corlib_s11y/webrev.01/ >>>>>>> >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>> Changes in detail: >>>>>>> >>>>>>> >>>>>>> >>>>>>> e_asin.c >>>>>>> >>>>>>> Code scan reports missing {}. >>>>>>> >>>>>>> >>>>>>> The code "if (huge+x>one) {" is only there to set the inexact flag of >>>>>>> the processor. >>>>>>> It's a way to avoid the C compiler to optimize the code away. It is >>>>>>> always true, >>>>>>> so the parenthesis of the outer else don't matter. >>>>>>> >>>>>>> Although this basically just adds the {} I would like to submit this to >>>>>>> >>>>>>> avoid anybody else spends more the 30sec on understanding these >>>>>>> >>>>>>> if statements. >>>>>>> >>>>>>> >>>>>>> k_standard.c >>>>>>> >>>>>>> exc.retval is returned below and thus should always be initialized. >>>>>>> >>>>>>> >>>>>>> imageDecompressor.cpp >>>>>>> >>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>> >>>>>>> >>>>>>> java.c >>>>>>> >>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>> >>>>>>> >>>>>>> java_md_solinux.c >>>>>>> >>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>> >>>>>>> >>>>>>> SDE.c >>>>>>> >>>>>>> Call to stratumTableIndex can return negative value if defaultStratumId >>>>>>> == null. >>>>>>> >>>>>>> >>>>>>> socket_md.c >>>>>>> >>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden in >>>>>>> the macros. >>>>>>> >>>>>>> >>>>>>> unpack.cpp >>>>>>> >>>>>>> n.slice should not get negative argument for end, which is passed from >>>>>>> dollar1. >>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the sources. >>>> >>>> >>>> -- >>>> Dmitry Samersoff >>>> Oracle Java development team, Saint Petersburg, Russia >>>> * I would love to change the world, but they won't give me the sources. From john.r.rose at oracle.com Thu Dec 8 21:07:40 2016 From: john.r.rose at oracle.com (John Rose) Date: Thu, 8 Dec 2016 13:07:40 -0800 Subject: Alternatives for Unsafe field access In-Reply-To: References: Message-ID: <8B7F08E7-5A17-4242-8E89-692859EB62FC@oracle.com> They support private fields. Like MethodHandles the access check is performed at creation time not invocation time. Any class can arrange to make VHs and MHs on its own privates. There will also be super user access for frameworks. ? John > On Dec 8, 2016, at 12:49 PM, Nathan Mittler wrote: > > Hi Roger, > If I read that correctly, lookups still have to go through access checks > which would seem to imply that they can't be used for private field access. > Or am I misunderstanding? > >> On Thu, Dec 8, 2016 at 11:51 AM, Roger Riggs wrote: >> >> Hi Nathan, >> >> Have you looked at VarHandles? [1] >> It is possible to use MethodsHandles.Lookup to get a VarHandle to an >> unreflected field. >> >> Roger >> >> [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke >> /MethodHandles.Lookup.html >> >> >> >>> On 12/8/2016 1:03 PM, Nathan Mittler wrote: >>> >>> Hi everyone, >>> >>> Apologies in advance if this isn't the correct forum for this question. My >>> team is working on an experimental runtime for Google's protocol buffers >>> which is currently relying on sun.misc.Unsafe to perform various tasks >>> efficiently. I'm aware that the plan is to eventually remove Unsafe >>> altogether, and I want to make sure that we still have a way to move >>> forward with future versions of Java. >>> >>> The code is up on a github branch ( >>> https://github.com/google/protobuf/tree/java_experimental). >>> >>> For an example of the sorts of things our runtime needs to do, you can >>> look >>> at the serialization code ( >>> https://github.com/google/protobuf/blob/java_experimental/ >>> java/core/src/main/java/com/google/protobuf/AbstractProto3Schema.java#L49 >>> ). >>> >>> The idea is that the runtime dynamically determines information about >>> message fields (e.g. field types, offsets) and stores it into a single >>> buffer. Our main need is fast read/write access to the private fields of >>> our generated message classes. Java reflection would be too slow and would >>> require data representation as a list of objects, rather than a continuous >>> buffer (much less compact and cache-friendly). Security restrictions would >>> be a concern as well. At first glance at Java 9, I don't see any >>> facilities >>> that would help here. >>> >>> This would seem to be a fairly common use case a low-level serialization >>> framework, such as protobuf. Are there any thoughts on how such a use case >>> could be supported post-Unsafe? >>> >>> Thanks, >>> Nathan >>> >> >> From uschindler at apache.org Thu Dec 8 21:10:32 2016 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 08 Dec 2016 21:10:32 +0000 Subject: Alternatives for Unsafe field access In-Reply-To: References: Message-ID: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> Hi, You can first do standard reflection, then use setAccessible and finally use the Lookup object to convert the now-accessible Field instance to a MethodHandle or VarHandle. You just have to know that way, existing since Java 7. Uwe Am 8. Dezember 2016 21:49:04 MEZ schrieb Nathan Mittler : >Hi Roger, >If I read that correctly, lookups still have to go through access >checks >which would seem to imply that they can't be used for private field >access. >Or am I misunderstanding? > >On Thu, Dec 8, 2016 at 11:51 AM, Roger Riggs >wrote: > >> Hi Nathan, >> >> Have you looked at VarHandles? [1] >> It is possible to use MethodsHandles.Lookup to get a VarHandle to an >> unreflected field. >> >> Roger >> >> [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke >> /MethodHandles.Lookup.html >> >> >> >> On 12/8/2016 1:03 PM, Nathan Mittler wrote: >> >>> Hi everyone, >>> >>> Apologies in advance if this isn't the correct forum for this >question. My >>> team is working on an experimental runtime for Google's protocol >buffers >>> which is currently relying on sun.misc.Unsafe to perform various >tasks >>> efficiently. I'm aware that the plan is to eventually remove Unsafe >>> altogether, and I want to make sure that we still have a way to move >>> forward with future versions of Java. >>> >>> The code is up on a github branch ( >>> https://github.com/google/protobuf/tree/java_experimental). >>> >>> For an example of the sorts of things our runtime needs to do, you >can >>> look >>> at the serialization code ( >>> https://github.com/google/protobuf/blob/java_experimental/ >>> >java/core/src/main/java/com/google/protobuf/AbstractProto3Schema.java#L49 >>> ). >>> >>> The idea is that the runtime dynamically determines information >about >>> message fields (e.g. field types, offsets) and stores it into a >single >>> buffer. Our main need is fast read/write access to the private >fields of >>> our generated message classes. Java reflection would be too slow and >would >>> require data representation as a list of objects, rather than a >continuous >>> buffer (much less compact and cache-friendly). Security restrictions >would >>> be a concern as well. At first glance at Java 9, I don't see any >>> facilities >>> that would help here. >>> >>> This would seem to be a fairly common use case a low-level >serialization >>> framework, such as protobuf. Are there any thoughts on how such a >use case >>> could be supported post-Unsafe? >>> >>> Thanks, >>> Nathan >>> >> >> -- Uwe Schindler Achterdiek 19, 28357 Bremen https://www.thetaphi.de From uschindler at apache.org Thu Dec 8 21:13:35 2016 From: uschindler at apache.org (Uwe Schindler) Date: Thu, 08 Dec 2016 21:13:35 +0000 Subject: Alternatives for Unsafe field access In-Reply-To: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> References: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> Message-ID: <8F074A07-7AE7-41F8-A5DA-F75D8BF198D4@apache.org> Hi, Of course, private field access is allowed to your own class if you use a private lookup object. The setAccessible hack is only needed when reflection would also be needed for frameworks or other "superusers". Uwe Am 8. Dezember 2016 22:10:32 MEZ schrieb Uwe Schindler : >Hi, > >You can first do standard reflection, then use setAccessible and >finally use the Lookup object to convert the now-accessible Field >instance to a MethodHandle or VarHandle. You just have to know that >way, existing since Java 7. > >Uwe > >Am 8. Dezember 2016 21:49:04 MEZ schrieb Nathan Mittler >: >>Hi Roger, >>If I read that correctly, lookups still have to go through access >>checks >>which would seem to imply that they can't be used for private field >>access. >>Or am I misunderstanding? >> >>On Thu, Dec 8, 2016 at 11:51 AM, Roger Riggs >>wrote: >> >>> Hi Nathan, >>> >>> Have you looked at VarHandles? [1] >>> It is possible to use MethodsHandles.Lookup to get a VarHandle to an >>> unreflected field. >>> >>> Roger >>> >>> [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke >>> /MethodHandles.Lookup.html >>> >>> >>> >>> On 12/8/2016 1:03 PM, Nathan Mittler wrote: >>> >>>> Hi everyone, >>>> >>>> Apologies in advance if this isn't the correct forum for this >>question. My >>>> team is working on an experimental runtime for Google's protocol >>buffers >>>> which is currently relying on sun.misc.Unsafe to perform various >>tasks >>>> efficiently. I'm aware that the plan is to eventually remove Unsafe >>>> altogether, and I want to make sure that we still have a way to >move >>>> forward with future versions of Java. >>>> >>>> The code is up on a github branch ( >>>> https://github.com/google/protobuf/tree/java_experimental). >>>> >>>> For an example of the sorts of things our runtime needs to do, you >>can >>>> look >>>> at the serialization code ( >>>> https://github.com/google/protobuf/blob/java_experimental/ >>>> >>java/core/src/main/java/com/google/protobuf/AbstractProto3Schema.java#L49 >>>> ). >>>> >>>> The idea is that the runtime dynamically determines information >>about >>>> message fields (e.g. field types, offsets) and stores it into a >>single >>>> buffer. Our main need is fast read/write access to the private >>fields of >>>> our generated message classes. Java reflection would be too slow >and >>would >>>> require data representation as a list of objects, rather than a >>continuous >>>> buffer (much less compact and cache-friendly). Security >restrictions >>would >>>> be a concern as well. At first glance at Java 9, I don't see any >>>> facilities >>>> that would help here. >>>> >>>> This would seem to be a fairly common use case a low-level >>serialization >>>> framework, such as protobuf. Are there any thoughts on how such a >>use case >>>> could be supported post-Unsafe? >>>> >>>> Thanks, >>>> Nathan >>>> >>> >>> > >-- >Uwe Schindler >Achterdiek 19, 28357 Bremen >https://www.thetaphi.de From daniel.daugherty at oracle.com Thu Dec 8 21:31:11 2016 From: daniel.daugherty at oracle.com (Daniel D. Daugherty) Date: Thu, 8 Dec 2016 14:31:11 -0700 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> Message-ID: On 12/8/16 1:59 PM, David Holmes wrote: > On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >> Hi David, >> >> thanks for looking at the change. New webrev: >> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >> >>> src/java.base/share/native/libjli/java.c >>> As far as I can see the existing code is working perfectly fine. >> Ah, thanks for the explanation, now I got it! Removed. >> >>> Again I'm not sure what the bug is here. On AIX the output string is >>> expanded with: >>> "%s/lib/%s/jli:" >> I first edited this against jdk9/hs, where the arch is gone since >> 8066474, >> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >> but the // was not adapted. Then I moved the change to jdk9/dev because >> I thought I have to push it there. And yes, in that coding // would >> be correct. >> So I have to wait until hs is promoted ... > > So just based on the current file, the change proposed - to remove one > / - is not correct until the arch directory is removed. That change is already in JDK9-hs: Changeset: c14f9a7b4cab Author: erikj Date: 2016-12-05 17:55 +0100 URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab 8066474: Remove the lib/ directory from Linux and Solaris images Reviewed-by: tbell, ihse along with changesets in the jdk and hotspot repos along with a few closed repos. Dan > > David > ----- > >>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>> comment on >>> the strdup would have sufficed IMO. >> Dmitry asked me to add it. But I think it's ok. >> >> Can I consider this reviewed now? I.e. could I push it once 8066474 is >> promoted and Joe Darcy agreed? >> >> Best regards, >> Goetz. >> >> >>> -----Original Message----- >>> From: David Holmes [mailto:david.holmes at oracle.com] >>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>> To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >>> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- >>> dev at openjdk.java.net) >>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>> servicabilty >>> coding. >>> >>> Hi Goetz, >>> >>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>> Hi Dmitry, >>>> >>>> yes, new_jvmpath is consistent with the other variables. >>>> I also merged the ifs in SDE.c. >>>> >>>> new webrev: >>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ >>> >>> src/java.base/share/native/libjli/java.c >>> >>> As far as I can see the existing code is working perfectly fine. >>> Given a >>> jvm.cfg with: >>> >>> -server KNOWN >>> -client IGNORE >>> -myvm KNOWN >>> -oldvm ALIASED_TO -server >>> >>> The usage text is: >>> >>> -server to select the "server" VM >>> -myvm to select the "myvm" VM >>> -oldvm is a synonym for the "server" VM [deprecated] >>> The default VM is server, >>> because you are running on a server-class machine. >>> >>> which is exactly what I would expect. Why do you think there is a bug? >>> >>> --- >>> >>> src/java.base/unix/native/libjli/java_md_solinux.c >>> >>> Again I'm not sure what the bug is here. On AIX the output string is >>> expanded with: >>> >>> "%s/lib/%s/jli:" >>> >>> so it needs to account for the extra "/lib//jli:" characters - and that >>> is exactly what the existing code does: >>> >>> + JLI_StrLen("/lib//jli:") >>> >>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>> comment on >>> the strdup would have sufficed IMO. >>> >>> Thanks, >>> David >>> ----- >>> >>> >>> >>> >>>> Best regards, >>>> Goetz. >>>> >>>>> -----Original Message----- >>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>> To: Lindenmaier, Goetz ; Java Core Libs >>>>> ; serviceability-dev (serviceability- >>>>> dev at openjdk.java.net) >>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>> servicabilty >>>>> coding. >>>>> >>>>> Goetz, >>>>> >>>>> SDE.c: >>>>> >>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>> matter of test. >>>>> >>>>> if (sti == baseStratumIndex || sti < 0) { >>>>> return; /* Java stratum - return unchanged */ >>>>> } >>>>> >>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>> double-check the new webrev. >>>>> >>>>> if cnt is <= 0 loop at l.267 >>>>> >>>>> for (; cnt-- > 0; ++fromEntry) { >>>>> >>>>> is never run and we effectively do >>>>> >>>>> *entryCountPtr = 0; >>>>> >>>>> at l.283 >>>>> >>>>> So if we you suspect that cnt may become negative or 0: >>>>> (your v.01 changes) >>>>> >>>>> 260 if (sti < 0 && cnt > 0) { >>>>> 261 return; >>>>> 262 } >>>>> >>>>> it's better to check it early. >>>>> >>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>> >>>>> -Dmitry >>>>> >>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>> Hi Dmitry, >>>>>> >>>>>> thanks for looking at my change! >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>>>>> >>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>> Is this line correct? >>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>> >>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>> horror.) >>>>>> >>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>> It might be better to return immediately if cnt < 0, >>>>>>> regardless of value of sti. >>>>>> >>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>> double-check the new webrev. >>>>>> >>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>> It might be better to write >>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>> and leave one copy of setsockopt() call >>>>>> >>>>>> Yes, looks better. >>>>>> >>>>>> Best regards, >>>>>> Goetz >>>>>> >>>>>> >>>>>>> >>>>>>> -Dmitry >>>>>>> >>>>>>> >>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>> Hi, >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>> >>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Please review: >>>>>>>> >>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>> corlib_s11y/webrev.01/ >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Goetz. >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Changes in detail: >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> e_asin.c >>>>>>>> >>>>>>>> Code scan reports missing {}. >>>>>>>> >>>>>>>> >>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>> flag of >>>>>>>> the processor. >>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>> It is >>>>>>>> always true, >>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>> >>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>> this to >>>>>>>> >>>>>>>> avoid anybody else spends more the 30sec on understanding these >>>>>>>> >>>>>>>> if statements. >>>>>>>> >>>>>>>> >>>>>>>> k_standard.c >>>>>>>> >>>>>>>> exc.retval is returned below and thus should always be >>>>>>>> initialized. >>>>>>>> >>>>>>>> >>>>>>>> imageDecompressor.cpp >>>>>>>> >>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>> >>>>>>>> >>>>>>>> java.c >>>>>>>> >>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>> >>>>>>>> >>>>>>>> java_md_solinux.c >>>>>>>> >>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>> >>>>>>>> >>>>>>>> SDE.c >>>>>>>> >>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>> defaultStratumId >>>>>>>> == null. >>>>>>>> >>>>>>>> >>>>>>>> socket_md.c >>>>>>>> >>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>> hidden in >>>>>>>> the macros. >>>>>>>> >>>>>>>> >>>>>>>> unpack.cpp >>>>>>>> >>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>> passed from >>>>>>>> dollar1. >>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Dmitry Samersoff >>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>> * I would love to change the world, but they won't give me the >>>>>>> sources. >>>>> >>>>> >>>>> -- >>>>> Dmitry Samersoff >>>>> Oracle Java development team, Saint Petersburg, Russia >>>>> * I would love to change the world, but they won't give me the >>>>> sources. From david.holmes at oracle.com Thu Dec 8 22:03:00 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 9 Dec 2016 08:03:00 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> Message-ID: On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > On 12/8/16 1:59 PM, David Holmes wrote: >> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> thanks for looking at the change. New webrev: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >>> >>>> src/java.base/share/native/libjli/java.c >>>> As far as I can see the existing code is working perfectly fine. >>> Ah, thanks for the explanation, now I got it! Removed. >>> >>>> Again I'm not sure what the bug is here. On AIX the output string is >>>> expanded with: >>>> "%s/lib/%s/jli:" >>> I first edited this against jdk9/hs, where the arch is gone since >>> 8066474, >>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>> but the // was not adapted. Then I moved the change to jdk9/dev because >>> I thought I have to push it there. And yes, in that coding // would >>> be correct. >>> So I have to wait until hs is promoted ... >> >> So just based on the current file, the change proposed - to remove one >> / - is not correct until the arch directory is removed. > > That change is already in JDK9-hs: > > Changeset: c14f9a7b4cab > Author: erikj > Date: 2016-12-05 17:55 +0100 > URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > > 8066474: Remove the lib/ directory from Linux and Solaris images > Reviewed-by: tbell, ihse > > along with changesets in the jdk and hotspot repos along with a few > closed repos. Thanks Dan. So we need to see a webrev based on latest hs code - where removing the extra / would be correct. David ----- > Dan > > > >> >> David >> ----- >> >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>> comment on >>>> the strdup would have sufficed IMO. >>> Dmitry asked me to add it. But I think it's ok. >>> >>> Can I consider this reviewed now? I.e. could I push it once 8066474 is >>> promoted and Joe Darcy agreed? >>> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>> To: Lindenmaier, Goetz ; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>> servicabilty >>>> coding. >>>> >>>> Hi Goetz, >>>> >>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>> Hi Dmitry, >>>>> >>>>> yes, new_jvmpath is consistent with the other variables. >>>>> I also merged the ifs in SDE.c. >>>>> >>>>> new webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ >>>> >>>> src/java.base/share/native/libjli/java.c >>>> >>>> As far as I can see the existing code is working perfectly fine. >>>> Given a >>>> jvm.cfg with: >>>> >>>> -server KNOWN >>>> -client IGNORE >>>> -myvm KNOWN >>>> -oldvm ALIASED_TO -server >>>> >>>> The usage text is: >>>> >>>> -server to select the "server" VM >>>> -myvm to select the "myvm" VM >>>> -oldvm is a synonym for the "server" VM [deprecated] >>>> The default VM is server, >>>> because you are running on a server-class machine. >>>> >>>> which is exactly what I would expect. Why do you think there is a bug? >>>> >>>> --- >>>> >>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>> >>>> Again I'm not sure what the bug is here. On AIX the output string is >>>> expanded with: >>>> >>>> "%s/lib/%s/jli:" >>>> >>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>> is exactly what the existing code does: >>>> >>>> + JLI_StrLen("/lib//jli:") >>>> >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>> comment on >>>> the strdup would have sufficed IMO. >>>> >>>> Thanks, >>>> David >>>> ----- >>>> >>>> >>>> >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>> To: Lindenmaier, Goetz ; Java Core Libs >>>>>> ; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>> servicabilty >>>>>> coding. >>>>>> >>>>>> Goetz, >>>>>> >>>>>> SDE.c: >>>>>> >>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>> matter of test. >>>>>> >>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>> return; /* Java stratum - return unchanged */ >>>>>> } >>>>>> >>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>> double-check the new webrev. >>>>>> >>>>>> if cnt is <= 0 loop at l.267 >>>>>> >>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>> >>>>>> is never run and we effectively do >>>>>> >>>>>> *entryCountPtr = 0; >>>>>> >>>>>> at l.283 >>>>>> >>>>>> So if we you suspect that cnt may become negative or 0: >>>>>> (your v.01 changes) >>>>>> >>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>> 261 return; >>>>>> 262 } >>>>>> >>>>>> it's better to check it early. >>>>>> >>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>> >>>>>> -Dmitry >>>>>> >>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> thanks for looking at my change! >>>>>>> Updated webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.02 >>>>>>> >>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>> Is this line correct? >>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>> >>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>> horror.) >>>>>>> >>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>> regardless of value of sti. >>>>>>> >>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>> double-check the new webrev. >>>>>>> >>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>> It might be better to write >>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>> and leave one copy of setsockopt() call >>>>>>> >>>>>>> Yes, looks better. >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> >>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>>> >>>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Please review: >>>>>>>>> >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>> corlib_s11y/webrev.01/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Changes in detail: >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> e_asin.c >>>>>>>>> >>>>>>>>> Code scan reports missing {}. >>>>>>>>> >>>>>>>>> >>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>> flag of >>>>>>>>> the processor. >>>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>>> It is >>>>>>>>> always true, >>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>> >>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>> this to >>>>>>>>> >>>>>>>>> avoid anybody else spends more the 30sec on understanding these >>>>>>>>> >>>>>>>>> if statements. >>>>>>>>> >>>>>>>>> >>>>>>>>> k_standard.c >>>>>>>>> >>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>> initialized. >>>>>>>>> >>>>>>>>> >>>>>>>>> imageDecompressor.cpp >>>>>>>>> >>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>> >>>>>>>>> >>>>>>>>> java.c >>>>>>>>> >>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>> >>>>>>>>> >>>>>>>>> java_md_solinux.c >>>>>>>>> >>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>> >>>>>>>>> >>>>>>>>> SDE.c >>>>>>>>> >>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>> defaultStratumId >>>>>>>>> == null. >>>>>>>>> >>>>>>>>> >>>>>>>>> socket_md.c >>>>>>>>> >>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>> hidden in >>>>>>>>> the macros. >>>>>>>>> >>>>>>>>> >>>>>>>>> unpack.cpp >>>>>>>>> >>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>> passed from >>>>>>>>> dollar1. >>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Samersoff >>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>> sources. >>>>>> >>>>>> >>>>>> -- >>>>>> Dmitry Samersoff >>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>> * I would love to change the world, but they won't give me the >>>>>> sources. > From nathanmittler at google.com Thu Dec 8 22:16:36 2016 From: nathanmittler at google.com (Nathan Mittler) Date: Thu, 8 Dec 2016 14:16:36 -0800 Subject: Alternatives for Unsafe field access In-Reply-To: <8F074A07-7AE7-41F8-A5DA-F75D8BF198D4@apache.org> References: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> <8F074A07-7AE7-41F8-A5DA-F75D8BF198D4@apache.org> Message-ID: Thanks, everyone! Just to be clear: we'll have to support older versions of generated code so relying on the generated message to export VarHandles wouldn't really be an option. And, we will have to access private fields of another (generated) class from within our runtime. I'm a bit concerned with a few potential penalties incurred when using VarHandles vs a single contiguous buffer: 1) Allocation cost: Allocating a single contiguous buffer would be relatively cheap compared to allocating an array of VarHandles. This sort of thing could significantly impact the startup time for applications that use many message types. 2) Storage size: There would likely be a lot more storage required per message type, since we would have to maintain other metadata in a buffer, while also maintaining an array of VarHandles instances. This could blow up quickly for apps using lots of messages. 3) Runtime performance: I suspect that there will be a performance penalty incurred when iterating over an array of VarHandles vs a single continuous buffer due to cache behavior. Also, do I need to be concerned of setAccessible throwing on certain platforms? I've never seen it fail ... perhaps it won't be an issue? Thanks, Nathan On Thu, Dec 8, 2016 at 1:13 PM, Uwe Schindler wrote: > Hi, > > Of course, private field access is allowed to your own class if you use a > private lookup object. The setAccessible hack is only needed when > reflection would also be needed for frameworks or other "superusers". > > Uwe > > Am 8. Dezember 2016 22:10:32 MEZ schrieb Uwe Schindler < > uschindler at apache.org>: > >Hi, > > > >You can first do standard reflection, then use setAccessible and > >finally use the Lookup object to convert the now-accessible Field > >instance to a MethodHandle or VarHandle. You just have to know that > >way, existing since Java 7. > > > >Uwe > > > >Am 8. Dezember 2016 21:49:04 MEZ schrieb Nathan Mittler > >: > >>Hi Roger, > >>If I read that correctly, lookups still have to go through access > >>checks > >>which would seem to imply that they can't be used for private field > >>access. > >>Or am I misunderstanding? > >> > >>On Thu, Dec 8, 2016 at 11:51 AM, Roger Riggs > >>wrote: > >> > >>> Hi Nathan, > >>> > >>> Have you looked at VarHandles? [1] > >>> It is possible to use MethodsHandles.Lookup to get a VarHandle to an > >>> unreflected field. > >>> > >>> Roger > >>> > >>> [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke > >>> /MethodHandles.Lookup.html > >>> > >>> > >>> > >>> On 12/8/2016 1:03 PM, Nathan Mittler wrote: > >>> > >>>> Hi everyone, > >>>> > >>>> Apologies in advance if this isn't the correct forum for this > >>question. My > >>>> team is working on an experimental runtime for Google's protocol > >>buffers > >>>> which is currently relying on sun.misc.Unsafe to perform various > >>tasks > >>>> efficiently. I'm aware that the plan is to eventually remove Unsafe > >>>> altogether, and I want to make sure that we still have a way to > >move > >>>> forward with future versions of Java. > >>>> > >>>> The code is up on a github branch ( > >>>> https://github.com/google/protobuf/tree/java_experimental). > >>>> > >>>> For an example of the sorts of things our runtime needs to do, you > >>can > >>>> look > >>>> at the serialization code ( > >>>> https://github.com/google/protobuf/blob/java_experimental/ > >>>> > >>java/core/src/main/java/com/google/protobuf/ > AbstractProto3Schema.java#L49 > >>>> ). > >>>> > >>>> The idea is that the runtime dynamically determines information > >>about > >>>> message fields (e.g. field types, offsets) and stores it into a > >>single > >>>> buffer. Our main need is fast read/write access to the private > >>fields of > >>>> our generated message classes. Java reflection would be too slow > >and > >>would > >>>> require data representation as a list of objects, rather than a > >>continuous > >>>> buffer (much less compact and cache-friendly). Security > >restrictions > >>would > >>>> be a concern as well. At first glance at Java 9, I don't see any > >>>> facilities > >>>> that would help here. > >>>> > >>>> This would seem to be a fairly common use case a low-level > >>serialization > >>>> framework, such as protobuf. Are there any thoughts on how such a > >>use case > >>>> could be supported post-Unsafe? > >>>> > >>>> Thanks, > >>>> Nathan > >>>> > >>> > >>> > > > >-- > >Uwe Schindler > >Achterdiek 19, 28357 Bremen > >https://www.thetaphi.de > From stuart.marks at oracle.com Thu Dec 8 22:48:50 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Dec 2016 14:48:50 -0800 Subject: RFR(s): JDK-8170943 Collectors.partitioningBy should specify that false and true entries are always present Message-ID: <50efd2dd-bfaa-5c2e-74c7-88592a560c60@oracle.com> Hi all, Please review this small spec change to the Collectors.partitioningBy() methods, appended below. This collector returns Map. The change requires the implementation always to populate the returned map with entries for both false and true keys. The implementation already does this; the entries are initially populated with values obtained by calling the supplier of the downstream collector. The reason for this spec change that it's useful for applications to be able to rely on this. The spec is currently silent about what entries will be present in the map. If one or the other (or both!) of the entries can be absent, callers would have to defend against this possibility. For example, Map> map = stream.collect(partitioningBy(pred)); processResults(map.getOrDefault(false, List.of()), map.getOrDefault(true, List.of())); With the guarantee, it's safe instead to write: Map> map = stream.collect(partitioningBy(pred)); processResults(map.get(false), map.get(true)); In fact, this code works today, it's just that it's not specified to work. It should be. Thanks, s'marks diff -r 7583c87dfe7c src/java.base/share/classes/java/util/stream/Collectors.java --- a/src/java.base/share/classes/java/util/stream/Collectors.java Thu Dec 08 21:21:39 2016 +0000 +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Thu Dec 08 14:39:31 2016 -0800 @@ -1268,6 +1268,8 @@ * to a {@code Predicate}, and organizes them into a * {@code Map>}. * + * The returned {@code Map} always contains mappings for both + * {@code false} and {@code true} keys. * There are no guarantees on the type, mutability, * serializability, or thread-safety of the {@code Map} or {@code List} * returned. @@ -1290,7 +1292,10 @@ * {@code Map} whose values are the result of the downstream * reduction. * - *

      There are no guarantees on the type, mutability, + *

      + * The returned {@code Map} always contains mappings for both + * {@code false} and {@code true} keys. + * There are no guarantees on the type, mutability, * serializability, or thread-safety of the {@code Map} returned. * * @param the type of the input elements From stuart.marks at oracle.com Thu Dec 8 23:32:09 2016 From: stuart.marks at oracle.com (Stuart Marks) Date: Thu, 8 Dec 2016 15:32:09 -0800 Subject: RFR 9: 8153882 rmid emits warning about security policy with obsolete URL In-Reply-To: References: Message-ID: <7fefc973-f128-fcca-8966-62e33de1d407@oracle.com> Hi Roger, Change looks good. Thanks. s'marks On 12/7/16 1:20 PM, Roger Riggs wrote: > Please review a change to an warning message from rmid when the security policy > is incorrectly configured. > There is no reliable link to the rmid documentation that will remain accurate > across JDK versions. > The direct link is removed and expect the user to find the rmid documentation > from the doc bundle or > via a web search. > > (this corrects the US english version, other locale will require translation) > > Webrev: > http://cr.openjdk.java.net/~rriggs/webrev-rmid-url-8153882/ > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8153882 > > Thanks, Roger > > From felix.yang at oracle.com Thu Dec 8 23:58:46 2016 From: felix.yang at oracle.com (Felix Yang) Date: Fri, 9 Dec 2016 07:58:46 +0800 Subject: Ping - Re: RFR 8170890, Problem list tools/javadoc/CheckResourceKeys.java and tools/javadoc/ReleaseOption.java until fix for JDK-8170772 In-Reply-To: <2cf14f38-29c0-a663-f444-f28742a647f6@oracle.com> References: <2cf14f38-29c0-a663-f444-f28742a647f6@oracle.com> Message-ID: Hi all, any comment on this problem-list request? Thanks, Felix On 2016/12/8 11:06, Felix Yang wrote: > Hi, > > please review the patch to problem-list two tier1 tests from Linux > platform. > > Bug: > > https://bugs.openjdk.java.net/browse/JDK-8170890 > > Thanks, > > Felix > > > diff -r 586c93260d3b test/ProblemList.txt > --- a/test/ProblemList.txt Mon Dec 05 15:08:24 2016 -0800 > +++ b/test/ProblemList.txt Wed Dec 07 18:47:22 2016 -0800 > @@ -31,6 +31,8 @@ > jdk/javadoc/tool/enum/enumType/Main.java 8152313 generic-all > convert to doclet test framework > jdk/javadoc/tool/varArgs/Main.java 8152313 generic-all convert to > doclet test framework > jdk/javadoc/doclet/testIOException/TestIOException.java 8164597 > windows-all > +tools/javadoc/CheckResourceKeys.java 8170772 linux-all > +tools/javadoc/ReleaseOption.java 8170772 linux-all > > ########################################################################### > > # > From xueming.shen at oracle.com Fri Dec 9 00:13:10 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Thu, 08 Dec 2016 16:13:10 -0800 Subject: RFR JDK-8170952: jar's usage message output need some cleanup Message-ID: <5849F716.8050701@oracle.com> Hi, Please help some trival usage msg clean of the jar command issue: https://bugs.openjdk.java.net/browse/JDK-8170952 webrev: http://cr.openjdk.java.net/~sherman/8170952/ 321 static void printUsageSummary(PrintWriter out) { 322 out.format("%s%n", Main.getMsg("main.usage.summary")); 323 out.format("%s%n", Main.getMsg("main.usage.summary.try")); 324 } with the original msgs in jar.properties as 177 main.usage.summary=\ 178 jar: You must specify one of -ctxui options. 179 main.usage.summary.try=\ 180 Try `jar --help' for more information. So basic in most use cases, regardless the cause of the parsing err, we always have the following two lines at the bottom of the jar brief usage msgs. jar: You must specify one of -ctxui options. Try `jar --help' for more information. After talked with Chris, I suggested to simply remove the first line "jar: You mut specify ...", IF there is already a error msg (for the real trigger) and the "try jar --help...", for example jar --list --create foo.jar now outputs ------------------------------------ You may not specify more than one '-cuxti' options Try `jar --help' for more information. ------------------------------------ There is use scenario that there is no direct err msg, the general brief usage is print out. For example, if you type "jar" without anything, then output is Usage: jar [OPTION...] [ [--release VERSION] [-C dir] files] ... Try `jar --help' for more information. which I think is more appropriate. I'm copy/pasting the "Usage: ..." from the first line of main.help.preopt. Hope it should be OK for the l10n team. Thanks, Sherman From mandy.chung at oracle.com Fri Dec 9 00:27:49 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Thu, 8 Dec 2016 16:27:49 -0800 Subject: Ping - Re: RFR 8170890, Problem list tools/javadoc/CheckResourceKeys.java and tools/javadoc/ReleaseOption.java until fix for JDK-8170772 In-Reply-To: References: <2cf14f38-29c0-a663-f444-f28742a647f6@oracle.com> Message-ID: I suggest to hold off not to problem list these test failures. CheckResourceKeys.java is a test bug that Jon is working on a test fix. We wanted to observe if ReleaseOption.java will still fail or not. It seems that there is some issue with ResourceBundle caching going on here. Mandy > On Dec 8, 2016, at 3:58 PM, Felix Yang wrote: > > Hi all, > > any comment on this problem-list request? > > Thanks, > Felix > On 2016/12/8 11:06, Felix Yang wrote: >> Hi, >> >> please review the patch to problem-list two tier1 tests from Linux platform. >> >> Bug: >> >> https://bugs.openjdk.java.net/browse/JDK-8170890 >> >> Thanks, >> >> Felix >> >> >> diff -r 586c93260d3b test/ProblemList.txt >> --- a/test/ProblemList.txt Mon Dec 05 15:08:24 2016 -0800 >> +++ b/test/ProblemList.txt Wed Dec 07 18:47:22 2016 -0800 >> @@ -31,6 +31,8 @@ >> jdk/javadoc/tool/enum/enumType/Main.java 8152313 generic-all convert to doclet test framework >> jdk/javadoc/tool/varArgs/Main.java 8152313 generic-all convert to doclet test framework >> jdk/javadoc/doclet/testIOException/TestIOException.java 8164597 windows-all >> +tools/javadoc/CheckResourceKeys.java 8170772 linux-all >> +tools/javadoc/ReleaseOption.java 8170772 linux-all >> >> ########################################################################### >> # >> > From sha.jiang at oracle.com Fri Dec 9 03:07:28 2016 From: sha.jiang at oracle.com (John Jiang) Date: Fri, 9 Dec 2016 11:07:28 +0800 Subject: RFR JDK-8170961: ProblemList tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java due to JDK-8169971 Message-ID: <73b3ce9a-4a77-7d57-2862-c1fa742117bc@oracle.com> Hi, This test has failed for several times on Windows x64 platform, it should be included by ProblemList. Please review the below patch. diff -r e307a1fcbcca test/ProblemList.txt --- a/test/ProblemList.txt Fri Dec 09 02:26:48 2016 +0000 +++ b/test/ProblemList.txt Fri Dec 09 03:00:02 2016 +0000 @@ -265,6 +265,8 @@ tools/jimage/JImageListTest.java 8169713 generic-all tools/jimage/JImageVerifyTest.java 8169713 generic-all +tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java 8169971 windows-x64 + ############################################################################ # jdk_jdi Best regards, John Jiang From huaming.li at oracle.com Fri Dec 9 03:07:39 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 9 Dec 2016 11:07:39 +0800 Subject: RFR of JDK-7195382: TEST_BUG: java/rmi/activation/CommandEnvironment/SetChildEnv.java can fail In-Reply-To: <134bca0b-06b6-0fbb-2570-09bb1f14dcff@oracle.com> References: <134bca0b-06b6-0fbb-2570-09bb1f14dcff@oracle.com> Message-ID: <3f6087ae-bbac-0631-5cae-99f7acf18d90@oracle.com> Is some one available to review the patch? Thank you -Hamlin On 2016/12/8 11:07, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-7195382 > webrev: http://cr.openjdk.java.net/~mli/7195382/webrev.00/ > > what's changed? > * Use createRMIDOnEphemeralPort to avoid "port in use" exception. > * Because createRMIDOnEphemeralPort will choose different ports for > rmid for multiple runs, it will fail subsequent ActivationGroup except > of first run, so have to run 4 test cases in different JVM by putting > them in rather in separate "@run main/othervm". > * Put rmid.cleanup() in finally block to avoid orphan process bug. > * delete dead code. > > Thank you > -Hamlin From amy.lu at oracle.com Fri Dec 9 03:19:06 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 9 Dec 2016 11:19:06 +0800 Subject: JDK 9 RFR of JDK-8023898: Consolidate Map tests Collisions and InPlaceOpsCollisions into general Map-based test Message-ID: Please review this test refactoring to map test Collisions and InPlaceOpsCollisions. These tests have (almost) same code for creating test data, and the test data can be reused cross tests. With converting to testng, test data creating is now done and provided by MapWithCollisionsProviders.java, and each test now uses explicit data provider, which makes test more clear. Other changes include: * Removed the redundant test Collections.testContainsKey and unnecessary map size check in the beginning of each test. * Replaced 'check' with testng assertion method. * Renaming and reformatting to make it more clear. bug:https://bugs.openjdk.java.net/browse/JDK-8023898 webrev:http://cr.openjdk.java.net/~amlu/8023898/webrev.01/ Thanks, Amy From forax at univ-mlv.fr Fri Dec 9 07:21:58 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Fri, 9 Dec 2016 08:21:58 +0100 (CET) Subject: Alternatives for Unsafe field access In-Reply-To: References: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> <8F074A07-7AE7-41F8-A5DA-F75D8BF198D4@apache.org> Message-ID: <1660545266.1761380.1481268118969.JavaMail.zimbra@u-pem.fr> ----- Mail original ----- > De: "Nathan Mittler" > ?: "Uwe Schindler" > Cc: "Daniel Weis" , core-libs-dev at openjdk.java.net, "Louis Ryan" > Envoy?: Jeudi 8 D?cembre 2016 23:16:36 > Objet: Re: Alternatives for Unsafe field access > Thanks, everyone! > > Just to be clear: we'll have to support older versions of generated code so > relying on the generated message to export VarHandles wouldn't really be an > option. And, we will have to access private fields of another (generated) > class from within our runtime. > > I'm a bit concerned with a few potential penalties incurred when using > VarHandles vs a single contiguous buffer: > > 1) Allocation cost: Allocating a single contiguous buffer would be > relatively cheap compared to allocating an array of VarHandles. This sort > of thing could significantly impact the startup time for applications that > use many message types. yes, you have to test > > 2) Storage size: There would likely be a lot more storage required per > message type, since we would have to maintain other metadata in a buffer, > while also maintaining an array of VarHandles instances. This could blow up > quickly for apps using lots of messages. for apps that using a lot of message types > > 3) Runtime performance: I suspect that there will be a performance penalty > incurred when iterating over an array of VarHandles vs a single continuous > buffer due to cache behavior. yes, if you iterate over the array of VarHandle but you can gather all varhandles as a single blob, for each VarHandle, you can convert it to a MethodHandle and fold them together after having partially applied the index into the array and the private field, if you fold them from the last index to the first one, the JIT will do only one bound check i believe. This is basically equivalent to generating you own bytecode for each message type. So instead of having an array of VarHandle, you will have one method handle that will do the serialisation. > > Also, do I need to be concerned of setAccessible throwing on certain > platforms? I've never seen it fail ... perhaps it won't be an issue? setAccessible will work if the module or the package is declared open. > > Thanks, > Nathan regards, R?mi > > > On Thu, Dec 8, 2016 at 1:13 PM, Uwe Schindler wrote: > >> Hi, >> >> Of course, private field access is allowed to your own class if you use a >> private lookup object. The setAccessible hack is only needed when >> reflection would also be needed for frameworks or other "superusers". >> >> Uwe >> >> Am 8. Dezember 2016 22:10:32 MEZ schrieb Uwe Schindler < >> uschindler at apache.org>: >> >Hi, >> > >> >You can first do standard reflection, then use setAccessible and >> >finally use the Lookup object to convert the now-accessible Field >> >instance to a MethodHandle or VarHandle. You just have to know that >> >way, existing since Java 7. >> > >> >Uwe >> > >> >Am 8. Dezember 2016 21:49:04 MEZ schrieb Nathan Mittler >> >: >> >>Hi Roger, >> >>If I read that correctly, lookups still have to go through access >> >>checks >> >>which would seem to imply that they can't be used for private field >> >>access. >> >>Or am I misunderstanding? >> >> >> >>On Thu, Dec 8, 2016 at 11:51 AM, Roger Riggs >> >>wrote: >> >> >> >>> Hi Nathan, >> >>> >> >>> Have you looked at VarHandles? [1] >> >>> It is possible to use MethodsHandles.Lookup to get a VarHandle to an >> >>> unreflected field. >> >>> >> >>> Roger >> >>> >> >>> [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke >> >>> /MethodHandles.Lookup.html >> >>> >> >>> >> >>> >> >>> On 12/8/2016 1:03 PM, Nathan Mittler wrote: >> >>> >> >>>> Hi everyone, >> >>>> >> >>>> Apologies in advance if this isn't the correct forum for this >> >>question. My >> >>>> team is working on an experimental runtime for Google's protocol >> >>buffers >> >>>> which is currently relying on sun.misc.Unsafe to perform various >> >>tasks >> >>>> efficiently. I'm aware that the plan is to eventually remove Unsafe >> >>>> altogether, and I want to make sure that we still have a way to >> >move >> >>>> forward with future versions of Java. >> >>>> >> >>>> The code is up on a github branch ( >> >>>> https://github.com/google/protobuf/tree/java_experimental). >> >>>> >> >>>> For an example of the sorts of things our runtime needs to do, you >> >>can >> >>>> look >> >>>> at the serialization code ( >> >>>> https://github.com/google/protobuf/blob/java_experimental/ >> >>>> >> >>java/core/src/main/java/com/google/protobuf/ >> AbstractProto3Schema.java#L49 >> >>>> ). >> >>>> >> >>>> The idea is that the runtime dynamically determines information >> >>about >> >>>> message fields (e.g. field types, offsets) and stores it into a >> >>single >> >>>> buffer. Our main need is fast read/write access to the private >> >>fields of >> >>>> our generated message classes. Java reflection would be too slow >> >and >> >>would >> >>>> require data representation as a list of objects, rather than a >> >>continuous >> >>>> buffer (much less compact and cache-friendly). Security >> >restrictions >> >>would >> >>>> be a concern as well. At first glance at Java 9, I don't see any >> >>>> facilities >> >>>> that would help here. >> >>>> >> >>>> This would seem to be a fairly common use case a low-level >> >>serialization >> >>>> framework, such as protobuf. Are there any thoughts on how such a >> >>use case >> >>>> could be supported post-Unsafe? >> >>>> >> >>>> Thanks, >> >>>> Nathan >> >>>> >> >>> >> >>> >> > >> >-- >> >Uwe Schindler >> >Achterdiek 19, 28357 Bremen >> >https://www.thetaphi.de From goetz.lindenmaier at sap.com Fri Dec 9 07:25:19 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 9 Dec 2016 07:25:19 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> Message-ID: <902a79e77ff240ed9c0d77dd00dd3482@DEROTE13DE08.global.corp.sap> Hi, I'll post a new webrev once the hs code has been propagated to dev. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 8. Dezember 2016 23:03 > To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > ; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > > On 12/8/16 1:59 PM, David Holmes wrote: > >> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> thanks for looking at the change. New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >>> > >>>> src/java.base/share/native/libjli/java.c > >>>> As far as I can see the existing code is working perfectly fine. > >>> Ah, thanks for the explanation, now I got it! Removed. > >>> > >>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>> expanded with: > >>>> "%s/lib/%s/jli:" > >>> I first edited this against jdk9/hs, where the arch is gone since > >>> 8066474, > >>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>> but the // was not adapted. Then I moved the change to jdk9/dev because > >>> I thought I have to push it there. And yes, in that coding // would > >>> be correct. > >>> So I have to wait until hs is promoted ... > >> > >> So just based on the current file, the change proposed - to remove one > >> / - is not correct until the arch directory is removed. > > > > That change is already in JDK9-hs: > > > > Changeset: c14f9a7b4cab > > Author: erikj > > Date: 2016-12-05 17:55 +0100 > > URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > > > > 8066474: Remove the lib/ directory from Linux and Solaris images > > Reviewed-by: tbell, ihse > > > > along with changesets in the jdk and hotspot repos along with a few > > closed repos. > > Thanks Dan. So we need to see a webrev based on latest hs code - where > removing the extra / would be correct. > > David > ----- > > > Dan > > > > > > > >> > >> David > >> ----- > >> > >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>> comment on > >>>> the strdup would have sufficed IMO. > >>> Dmitry asked me to add it. But I think it's ok. > >>> > >>> Can I consider this reviewed now? I.e. could I push it once 8066474 is > >>> promoted and Joe Darcy agreed? > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>> To: Lindenmaier, Goetz ; 'Dmitry > Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>> servicabilty > >>>> coding. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>> Hi Dmitry, > >>>>> > >>>>> yes, new_jvmpath is consistent with the other variables. > >>>>> I also merged the ifs in SDE.c. > >>>>> > >>>>> new webrev: > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > >>>> > >>>> src/java.base/share/native/libjli/java.c > >>>> > >>>> As far as I can see the existing code is working perfectly fine. > >>>> Given a > >>>> jvm.cfg with: > >>>> > >>>> -server KNOWN > >>>> -client IGNORE > >>>> -myvm KNOWN > >>>> -oldvm ALIASED_TO -server > >>>> > >>>> The usage text is: > >>>> > >>>> -server to select the "server" VM > >>>> -myvm to select the "myvm" VM > >>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>> The default VM is server, > >>>> because you are running on a server-class machine. > >>>> > >>>> which is exactly what I would expect. Why do you think there is a bug? > >>>> > >>>> --- > >>>> > >>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>> > >>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>> expanded with: > >>>> > >>>> "%s/lib/%s/jli:" > >>>> > >>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>> is exactly what the existing code does: > >>>> > >>>> + JLI_StrLen("/lib//jli:") > >>>> > >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>> comment on > >>>> the strdup would have sufficed IMO. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>> > >>>> > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>> To: Lindenmaier, Goetz ; Java Core Libs > >>>>>> ; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>> servicabilty > >>>>>> coding. > >>>>>> > >>>>>> Goetz, > >>>>>> > >>>>>> SDE.c: > >>>>>> > >>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>> matter of test. > >>>>>> > >>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>> return; /* Java stratum - return unchanged */ > >>>>>> } > >>>>>> > >>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>> double-check the new webrev. > >>>>>> > >>>>>> if cnt is <= 0 loop at l.267 > >>>>>> > >>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>> > >>>>>> is never run and we effectively do > >>>>>> > >>>>>> *entryCountPtr = 0; > >>>>>> > >>>>>> at l.283 > >>>>>> > >>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>> (your v.01 changes) > >>>>>> > >>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>> 261 return; > >>>>>> 262 } > >>>>>> > >>>>>> it's better to check it early. > >>>>>> > >>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>> > >>>>>> -Dmitry > >>>>>> > >>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>> Hi Dmitry, > >>>>>>> > >>>>>>> thanks for looking at my change! > >>>>>>> Updated webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.02 > >>>>>>> > >>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>> Is this line correct? > >>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>> > >>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>> horror.) > >>>>>>> > >>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>> regardless of value of sti. > >>>>>>> > >>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>> double-check the new webrev. > >>>>>>> > >>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>> It might be better to write > >>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>> and leave one copy of setsockopt() call > >>>>>>> > >>>>>>> Yes, looks better. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> -Dmitry > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> This change fixes some minor issues found in our code scans. > >>>>>>>>> > >>>>>>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Please review: > >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>> corlib_s11y/webrev.01/ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Changes in detail: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> e_asin.c > >>>>>>>>> > >>>>>>>>> Code scan reports missing {}. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>> flag of > >>>>>>>>> the processor. > >>>>>>>>> It's a way to avoid the C compiler to optimize the code away. > >>>>>>>>> It is > >>>>>>>>> always true, > >>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>> > >>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>> this to > >>>>>>>>> > >>>>>>>>> avoid anybody else spends more the 30sec on understanding these > >>>>>>>>> > >>>>>>>>> if statements. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> k_standard.c > >>>>>>>>> > >>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>> initialized. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> imageDecompressor.cpp > >>>>>>>>> > >>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> java.c > >>>>>>>>> > >>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> java_md_solinux.c > >>>>>>>>> > >>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> SDE.c > >>>>>>>>> > >>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>> defaultStratumId > >>>>>>>>> == null. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> socket_md.c > >>>>>>>>> > >>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>> hidden in > >>>>>>>>> the macros. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> unpack.cpp > >>>>>>>>> > >>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>> passed from > >>>>>>>>> dollar1. > >>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Dmitry Samersoff > >>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>> sources. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Dmitry Samersoff > >>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>> * I would love to change the world, but they won't give me the > >>>>>> sources. > > From blackdrag at gmx.org Fri Dec 9 07:55:26 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 9 Dec 2016 08:55:26 +0100 Subject: Alternatives for Unsafe field access In-Reply-To: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> References: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> Message-ID: <584A636E.6050107@gmx.org> On 08.12.2016 22:10, Uwe Schindler wrote: > Hi, > > You can first do standard reflection, then use setAccessible Maybe we have luck here and it does not apply, but if the field comes from a class of a module and is private, my current level knowledge of jigsaw says, that setAccessible will fail with an exception. It does not matter at all if the class with the field is exported or not. That is because just before the JavaOne #AwkwardStrongEncapsulation made it into jigsaw. Only way around this is to use the Lookup object that has the correct rights from the beginning. How to get it... well... there will be only solutions for certain types of classes. bye Jochen From blackdrag at gmx.org Fri Dec 9 07:57:19 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 9 Dec 2016 08:57:19 +0100 Subject: Alternatives for Unsafe field access In-Reply-To: <584A636E.6050107@gmx.org> References: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> <584A636E.6050107@gmx.org> Message-ID: <584A63DF.8010704@gmx.org> On 09.12.2016 08:55, Jochen Theodorou wrote: > On 08.12.2016 22:10, Uwe Schindler wrote: >> Hi, >> >> You can first do standard reflection, then use setAccessible > > Maybe we have luck here and it does not apply, but if the field comes > from a class of a module and is private, my current level knowledge of > jigsaw says, that setAccessible will fail with an exception. It does not > matter at all if the class with the field is exported or not. That is > because just before the JavaOne #AwkwardStrongEncapsulation made it into > jigsaw. Only way around this is to use the Lookup object that has the > correct rights from the beginning. How to get it... well... there will > be only solutions for certain types of classes. oh, forgot... it works if the module is made open from the command line or declared as such as a work around bye Jcohen From chris.hegarty at oracle.com Fri Dec 9 11:40:01 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 9 Dec 2016 11:40:01 +0000 Subject: RFR JDK-8170952: jar's usage message output need some cleanup In-Reply-To: <5849F716.8050701@oracle.com> References: <5849F716.8050701@oracle.com> Message-ID: <7ae3ac14-0b62-34a8-bfbe-8b9d50a9f1ad@oracle.com> On 09/12/16 00:13, Xueming Shen wrote: > Hi, > > Please help some trival usage msg clean of the jar command > > issue: https://bugs.openjdk.java.net/browse/JDK-8170952 > webrev: http://cr.openjdk.java.net/~sherman/8170952/ Thank you Sherman, the code changes look good to me. -Chris. From andrej.golovnin at gmail.com Fri Dec 9 11:49:25 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Fri, 9 Dec 2016 12:49:25 +0100 Subject: RFR JDK-8170952: jar's usage message output need some cleanup In-Reply-To: <7ae3ac14-0b62-34a8-bfbe-8b9d50a9f1ad@oracle.com> References: <5849F716.8050701@oracle.com> <7ae3ac14-0b62-34a8-bfbe-8b9d50a9f1ad@oracle.com> Message-ID: Hi, src/jdk.jartool/share/classes/sun/tools/jar/Main.java 682 if (info != null) { 683 info.print(out); 684 return true; 685 } The indentation in the line 684 is wrong: it uses 3 spaces instead of 4. Best regards, Andrej Golovnin From Alan.Bateman at oracle.com Fri Dec 9 11:59:26 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Dec 2016 11:59:26 +0000 Subject: Alternatives for Unsafe field access In-Reply-To: <584A636E.6050107@gmx.org> References: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> <584A636E.6050107@gmx.org> Message-ID: <533d2bb6-eec8-b1d7-7e67-1d23993f9093@oracle.com> On 09/12/2016 07:55, Jochen Theodorou wrote: > > Maybe we have luck here and it does not apply, but if the field comes > from a class of a module and is private, my current level knowledge of > jigsaw says, that setAccessible will fail with an exception. It does > not matter at all if the class with the field is exported or not. That > is because just before the JavaOne #AwkwardStrongEncapsulation made it > into jigsaw. Only way around this is to use the Lookup object that has > the correct rights from the beginning. How to get it... well... there > will be only solutions for certain types of classes. > MethodHandles.privateLookupIn [1] was recently added to get a Lookup with private access, it may be useful here. To Jochen's comments then setAccessible has been restricted for some time to prevent it being used to break into non-exported packages. These restriction were dialed up further as part of the JSR 376 issue that Jochen cites. It essentially means that code cannot break into non-public types in exported packages or non-public elements of public types in exported packages. The new privateLookupIn specifies the same check so that it can only be used to get private access when the target class is in a package that is open to the caller (lookup). None of this has any impact when doing "deep reflection" on types on the class path, or as Jochen's modules that are declared "open" or have the interesting types in open packages. For the short term anyway then the restrictions will surface with code that is looking to get a non-public elements of types in the JDK modules because the JDK modules do not open any packages (except for jdk.unsupported which opens sun.misc and sun.reflect to keep code using critical internal APIs working). -Alan [1] http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHandles.html#privateLookupIn-java.lang.Class-java.lang.invoke.MethodHandles.Lookup- From blackdrag at gmx.org Fri Dec 9 12:38:08 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 9 Dec 2016 13:38:08 +0100 Subject: Alternatives for Unsafe field access In-Reply-To: <533d2bb6-eec8-b1d7-7e67-1d23993f9093@oracle.com> References: <177B2032-6E2A-431A-8377-003B4559C6C7@apache.org> <584A636E.6050107@gmx.org> <533d2bb6-eec8-b1d7-7e67-1d23993f9093@oracle.com> Message-ID: <0b94bfb3-5e29-47ac-fea0-34e6e63ab6d8@gmx.org> On 09.12.2016 12:59, Alan Bateman wrote: > On 09/12/2016 07:55, Jochen Theodorou wrote: > >> >> Maybe we have luck here and it does not apply, but if the field comes >> from a class of a module and is private, my current level knowledge of >> jigsaw says, that setAccessible will fail with an exception. It does >> not matter at all if the class with the field is exported or not. That >> is because just before the JavaOne #AwkwardStrongEncapsulation made it >> into jigsaw. Only way around this is to use the Lookup object that has >> the correct rights from the beginning. How to get it... well... there >> will be only solutions for certain types of classes. >> > MethodHandles.privateLookupIn [1] was recently added to get a Lookup > with private access, it may be useful here. I think the documentation needs some improvement to make it clear what lookup modes are set when. And by that I mean really using the mode names in the description. Just from a short lookup for example I have no idea when the MODULE mode is set for a Lookup and when not. [...] > [1] > http://download.java.net/java/jdk9/docs/api/java/lang/invoke/MethodHandles.html#privateLookupIn-java.lang.Class-java.lang.invoke.MethodHandles.Lookup- bye Jochen From Alan.Bateman at oracle.com Fri Dec 9 12:45:08 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Dec 2016 12:45:08 +0000 Subject: Ping - Re: RFR 8170890, Problem list tools/javadoc/CheckResourceKeys.java and tools/javadoc/ReleaseOption.java until fix for JDK-8170772 In-Reply-To: References: <2cf14f38-29c0-a663-f444-f28742a647f6@oracle.com> Message-ID: <820686a1-7e3c-8de9-6c42-d4d50f6f55f7@oracle.com> On 09/12/2016 00:27, Mandy Chung wrote: > I suggest to hold off not to problem list these test failures. > > CheckResourceKeys.java is a test bug that Jon is working on a test fix. We wanted to observe if ReleaseOption.java will still fail or not. > > It seems that there is some issue with ResourceBundle caching going on here. > > I agree with Mandy, this is exposing an issue with the caching mechanism in ResourceBundle that can be fixed quickly. -Alan From peter.levart at gmail.com Fri Dec 9 13:43:43 2016 From: peter.levart at gmail.com (Peter Levart) Date: Fri, 9 Dec 2016 14:43:43 +0100 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: References: Message-ID: <2902b940-cacf-eb90-d384-de714c0c6d7e@gmail.com> Hi Ivan, On 12/04/2016 01:07 PM, Ivan Gerasimov wrote: > Hello! > > There are several places in JDK where the same character is appended > to a StringBuilder object multiple times (usually padding). > With each append there are a few routine checks performed. > They could have been done only once, if we had a method for appending > multiple copies at a time. > A simple benchmark shows that such method may save us a few machine > cycles (see the results below). > > In the benchmark, three approaches were compared: > 0) Using the new appendN(char, int) method to append several chars at > once, > 1) Calling append(char) in a loop, > 2) Appending a prepared-in-advance string > > On my machine, the new method demonstrates better or comparable > performance for all sizes up to 20. > > In the webrev, there are two changesets included: > - the new default Appendable.appendN(char, int) method, its overrides > in StringBuilder/Buffer and a basic test, > - several applications of the new method across JDK. > > Would you please help review? > Comments, suggestions are welcome. > > BUGURL: https://bugs.openjdk.java.net/browse/JDK-8170348 > WEBREV: http://cr.openjdk.java.net/~igerasim/8170348/00/webrev/ > Benchmark: > http://cr.openjdk.java.net/~igerasim/8170348/00/MyBenchmark.java > > > Benchmark (size) Mode Cnt Score Error Units > MyBenchmark.test_0_New 0 thrpt 70 331922128.215 ? > 16399254.452 ops/s > MyBenchmark.test_0_New 1 thrpt 70 209207932.893 ? > 14955800.231 ops/s > MyBenchmark.test_0_New 5 thrpt 70 72926671.621 ? > 4841791.555 ops/s > MyBenchmark.test_0_New 10 thrpt 70 67779575.053 ? > 3234366.239 ops/s > MyBenchmark.test_0_New 20 thrpt 70 59731629.661 ? > 2769497.288 ops/s > MyBenchmark.test_1_Old 0 thrpt 70 333467628.860 ? > 15981678.430 ops/s > MyBenchmark.test_1_Old 1 thrpt 70 156126381.967 ? > 9619653.294 ops/s > MyBenchmark.test_1_Old 5 thrpt 70 46550204.382 ? > 2009987.637 ops/s > MyBenchmark.test_1_Old 10 thrpt 70 23309297.849 ? > 1268874.282 ops/s > MyBenchmark.test_1_Old 20 thrpt 70 13143637.821 ? > 662265.103 ops/s > MyBenchmark.test_2_Solid 0 thrpt 70 138548108.540 ? > 6408775.462 ops/s > MyBenchmark.test_2_Solid 1 thrpt 70 63890936.132 ? > 3918274.970 ops/s > MyBenchmark.test_2_Solid 5 thrpt 70 65838879.075 ? > 2701493.698 ops/s > MyBenchmark.test_2_Solid 10 thrpt 70 65387238.993 ? > 3131562.548 ops/s > MyBenchmark.test_2_Solid 20 thrpt 70 57528150.828 ? > 3171453.716 ops/s > > > With kind regards, > Ivan > An alternative to a new virtual method on Appendable (or maybe a complement to it) could be a special internal CharSequence implementation (CharRepetitions) with a static factory method on CharSequence like the following: http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_Appendable.appendN.alt/webrev.01/ Together with special-case optimization in AbstractStringBuilder.append(CharSequence) it can perform equally well when JITed. I took your benchmark and modified it a bit: http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_Appendable.appendN.alt/AppendNTest.java ...I moved sb.setLength(0) into a special @Setup method so that it doesn't cause the remaining tested code to be over-optimized. You can try just this change in your benchmark and you'll notice a difference. Comparing StringBuilder.appendN(c, n) with StringBuilder.append(CharSequence.repetitions(c, n)) shows they perform on par. Unsurprisingly since CharRepetitions objects is just as a wrapper used to transport parameters (c, n) to the appendN() method and EA makes sure its allocation on the heap is eliminated. Benchmark (size) Mode Cnt Score Error Units AppendNTest.test_0_New 0 avgt 60 15.676 ? 0.098 ns/op AppendNTest.test_0_New 1 avgt 60 19.293 ? 0.024 ns/op AppendNTest.test_0_New 5 avgt 60 22.042 ? 0.156 ns/op AppendNTest.test_0_New 10 avgt 60 22.455 ? 0.453 ns/op AppendNTest.test_0_New 20 avgt 60 23.539 ? 0.280 ns/op AppendNTest.test_1_Old 0 avgt 60 15.818 ? 0.124 ns/op AppendNTest.test_1_Old 1 avgt 60 19.628 ? 0.173 ns/op AppendNTest.test_1_Old 5 avgt 60 27.870 ? 0.521 ns/op AppendNTest.test_1_Old 10 avgt 60 38.956 ? 0.545 ns/op AppendNTest.test_1_Old 20 avgt 60 61.895 ? 1.758 ns/op AppendNTest.test_2_Solid 0 avgt 60 21.610 ? 0.117 ns/op AppendNTest.test_2_Solid 1 avgt 60 25.055 ? 0.208 ns/op AppendNTest.test_2_Solid 5 avgt 60 24.094 ? 0.133 ns/op AppendNTest.test_2_Solid 10 avgt 60 24.178 ? 0.081 ns/op AppendNTest.test_2_Solid 20 avgt 60 24.708 ? 0.101 ns/op AppendNTest.test_3_Repeat 0 avgt 60 15.580 ? 0.031 ns/op AppendNTest.test_3_Repeat 1 avgt 60 19.314 ? 0.094 ns/op AppendNTest.test_3_Repeat 5 avgt 60 21.520 ? 0.063 ns/op AppendNTest.test_3_Repeat 10 avgt 60 22.242 ? 0.027 ns/op AppendNTest.test_3_Repeat 20 avgt 60 23.125 ? 0.074 ns/op CharSequence.repetitions() is also a nice factory for String(s) with repeated characters: CharSequence.repetitions(c, n).toString() Regards, Peter From daniel.fuchs at oracle.com Fri Dec 9 14:09:25 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 9 Dec 2016 14:09:25 +0000 Subject: RFR 8170984: java.util.logging might force the initialization of ResourceBundle class too early. Message-ID: <12b69cec-43ed-51d4-a77a-96b33fd8bacf@oracle.com> Hi, Please find below a fix for: issue: https://bugs.openjdk.java.net/browse/JDK-8170984 8170984: java.util.logging might force the initialization of ResourceBundle class too early. webrev: http://cr.openjdk.java.net/~dfuchs/webrev_8170984/webrev.00/ The issue here is that j.u.l.Level and j.u.l.Logging statically initialize a variable used to provide internal access to ResourceBundle at class loading. This has the unfortunately side effect to force the initialization of the ResourceBundle class, which might happen too early. The fix is simple: instead of doing: static final JavaUtilResourceBundleAccess RB_ACCESS = SharedSecrets.getJavaUtilResourceBundleAccess(); do: private static final class RbAccess { static final JavaUtilResourceBundleAccess RB_ACCESS = SharedSecrets.getJavaUtilResourceBundleAccess(); } which will delay the call to SharedSecrets.getJavaUtilResourceBundleAccess() until RB_ACCESS is actually needed. best regards, -- daniel From Alan.Bateman at oracle.com Fri Dec 9 15:05:43 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Fri, 9 Dec 2016 15:05:43 +0000 Subject: RFR 8170984: java.util.logging might force the initialization of ResourceBundle class too early. In-Reply-To: <12b69cec-43ed-51d4-a77a-96b33fd8bacf@oracle.com> References: <12b69cec-43ed-51d4-a77a-96b33fd8bacf@oracle.com> Message-ID: <96d7d14e-2569-c785-f17c-3a6d1a67a452@oracle.com> On 09/12/2016 14:09, Daniel Fuchs wrote: > Hi, > > Please find below a fix for: > > issue: > https://bugs.openjdk.java.net/browse/JDK-8170984 > 8170984: java.util.logging might force the initialization > of ResourceBundle class too early. > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8170984/webrev.00/ > > The issue here is that j.u.l.Level and j.u.l.Logging > statically initialize a variable used to provide > internal access to ResourceBundle at class loading. This looks okay to me, I think the real issue underlying this bug is a custom system class loader that is doing logging in its initialization. Anyone doing a custom system class loader needs to keep their initialization to an absolute minimum to avoid recursive initialization issues. -Alan From daniel.fuchs at oracle.com Fri Dec 9 15:11:17 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 9 Dec 2016 15:11:17 +0000 Subject: RFR 8170984: java.util.logging might force the initialization of ResourceBundle class too early. In-Reply-To: <96d7d14e-2569-c785-f17c-3a6d1a67a452@oracle.com> References: <12b69cec-43ed-51d4-a77a-96b33fd8bacf@oracle.com> <96d7d14e-2569-c785-f17c-3a6d1a67a452@oracle.com> Message-ID: <43fbb0fd-8f9b-a722-0c13-e01285739cdb@oracle.com> On 09/12/16 15:05, Alan Bateman wrote: > On 09/12/2016 14:09, Daniel Fuchs wrote: > >> Hi, >> >> Please find below a fix for: >> >> issue: >> https://bugs.openjdk.java.net/browse/JDK-8170984 >> 8170984: java.util.logging might force the initialization >> of ResourceBundle class too early. >> >> webrev: >> http://cr.openjdk.java.net/~dfuchs/webrev_8170984/webrev.00/ >> >> The issue here is that j.u.l.Level and j.u.l.Logging >> statically initialize a variable used to provide >> internal access to ResourceBundle at class loading. > This looks okay to me, I think the real issue underlying this bug is a > custom system class loader that is doing logging in its initialization. > Anyone doing a custom system class loader needs to keep their > initialization to an absolute minimum to avoid recursive initialization > issues. Thanks Alan! -- daniel > > -Alan From Roger.Riggs at Oracle.com Fri Dec 9 15:36:58 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 9 Dec 2016 10:36:58 -0500 Subject: RFR of JDK-7195382: TEST_BUG: java/rmi/activation/CommandEnvironment/SetChildEnv.java can fail In-Reply-To: <3f6087ae-bbac-0631-5cae-99f7acf18d90@oracle.com> References: <134bca0b-06b6-0fbb-2570-09bb1f14dcff@oracle.com> <3f6087ae-bbac-0631-5cae-99f7acf18d90@oracle.com> Message-ID: <9984a5f7-0002-2005-4ce2-15b7c5b34736@Oracle.com> Hi Hamlin, The patch looks fine but I would wrap the long @run lines. Looking "-Djava.compiler=NONE" made me wonder why that was important to the test. Roger On 12/8/2016 10:07 PM, Hamlin Li wrote: > Is some one available to review the patch? > > Thank you > -Hamlin > > On 2016/12/8 11:07, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-7195382 >> webrev: http://cr.openjdk.java.net/~mli/7195382/webrev.00/ >> >> what's changed? >> * Use createRMIDOnEphemeralPort to avoid "port in use" exception. >> * Because createRMIDOnEphemeralPort will choose different ports for >> rmid for multiple runs, it will fail subsequent ActivationGroup >> except of first run, so have to run 4 test cases in different JVM by >> putting them in rather in separate "@run main/othervm". >> * Put rmid.cleanup() in finally block to avoid orphan process bug. >> * delete dead code. >> >> Thank you >> -Hamlin > From mandy.chung at oracle.com Fri Dec 9 16:03:53 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Dec 2016 08:03:53 -0800 Subject: RFR 8170984: java.util.logging might force the initialization of ResourceBundle class too early. In-Reply-To: <12b69cec-43ed-51d4-a77a-96b33fd8bacf@oracle.com> References: <12b69cec-43ed-51d4-a77a-96b33fd8bacf@oracle.com> Message-ID: <9E83AD2B-E0F2-4208-A9F7-A9811DC5561B@oracle.com> > On Dec 9, 2016, at 6:09 AM, Daniel Fuchs wrote: > > Hi, > > Please find below a fix for: > > issue: > https://bugs.openjdk.java.net/browse/JDK-8170984 > 8170984: java.util.logging might force the initialization > of ResourceBundle class too early. > > webrev: > http://cr.openjdk.java.net/~dfuchs/webrev_8170984/webrev.00/ Looks fine. Mandy From xueming.shen at oracle.com Fri Dec 9 16:22:51 2016 From: xueming.shen at oracle.com (Xueming Shen) Date: Fri, 9 Dec 2016 08:22:51 -0800 Subject: RFR JDK-8170952: jar's usage message output need some cleanup In-Reply-To: References: <5849F716.8050701@oracle.com> <7ae3ac14-0b62-34a8-bfbe-8b9d50a9f1ad@oracle.com> Message-ID: <0cfd0d93-ac76-699d-0483-d4c619271c17@oracle.com> thanks! webrev has been updated accordingly. http://cr.openjdk.java.net/~sherman/8170952/ On 12/9/16 3:49 AM, Andrej Golovnin wrote: > Hi, > > src/jdk.jartool/share/classes/sun/tools/jar/Main.java > > 682 if (info != null) { > 683 info.print(out); > 684 return true; > 685 } > > The indentation in the line 684 is wrong: it uses 3 spaces instead of 4. > > Best regards, > Andrej Golovnin From paul.sandoz at oracle.com Fri Dec 9 16:49:05 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 9 Dec 2016 08:49:05 -0800 Subject: RFR JDK-8170961: ProblemList tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java due to JDK-8169971 In-Reply-To: <73b3ce9a-4a77-7d57-2862-c1fa742117bc@oracle.com> References: <73b3ce9a-4a77-7d57-2862-c1fa742117bc@oracle.com> Message-ID: <7FEA8371-DB70-434A-944A-D4501B819081@oracle.com> +1 I have not found the cause as to why this test is failing on windows. The test cleans up by deleting directory contents created for jar construction, but for some reason files in the directory become inaccessible so the directory itself cannot be deleted. Paul. > On 8 Dec 2016, at 19:07, John Jiang wrote: > > Hi, > This test has failed for several times on Windows x64 platform, it should be included by ProblemList. > Please review the below patch. > > diff -r e307a1fcbcca test/ProblemList.txt > --- a/test/ProblemList.txt Fri Dec 09 02:26:48 2016 +0000 > +++ b/test/ProblemList.txt Fri Dec 09 03:00:02 2016 +0000 > @@ -265,6 +265,8 @@ > tools/jimage/JImageListTest.java 8169713 generic-all > tools/jimage/JImageVerifyTest.java 8169713 generic-all > > +tools/jlink/multireleasejar/JLinkMultiReleaseJarTest.java 8169971 windows-x64 > + > ############################################################################ > > # jdk_jdi > > Best regards, > John Jiang > From mandy.chung at oracle.com Fri Dec 9 16:49:57 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Dec 2016 08:49:57 -0800 Subject: Review Request JDK-8170772: ResourceBundle improper caching causes tools/javadoc tests intermittently Message-ID: Naoto, Can you review this ResourceBundle caching fix? The caller module may be different than the specified module to ResourceBundle.getBundle(String, Module) method and it should also part of the cache key. http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ The new test shows the issue there and the first loading of the resource bundle of a specific module (success or fail) will be put in the cache and used by subsequent calls. Thanks Mandy From paul.sandoz at oracle.com Fri Dec 9 16:51:17 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 9 Dec 2016 08:51:17 -0800 Subject: RFR(s): JDK-8170943 Collectors.partitioningBy should specify that false and true entries are always present In-Reply-To: <50efd2dd-bfaa-5c2e-74c7-88592a560c60@oracle.com> References: <50efd2dd-bfaa-5c2e-74c7-88592a560c60@oracle.com> Message-ID: <6789BE01-674D-43CF-9BDB-1DC4F6564E24@oracle.com> +1 I was tempted to saying something more about an associated value if it was not operated on (accumulated and combined), but that?s probably api note territory. Paul. > On 8 Dec 2016, at 14:48, Stuart Marks wrote: > > Hi all, > > Please review this small spec change to the Collectors.partitioningBy() methods, appended below. This collector returns Map. The change requires the implementation always to populate the returned map with entries for both false and true keys. > > The implementation already does this; the entries are initially populated with values obtained by calling the supplier of the downstream collector. > > The reason for this spec change that it's useful for applications to be able to rely on this. The spec is currently silent about what entries will be present in the map. If one or the other (or both!) of the entries can be absent, callers would have to defend against this possibility. For example, > > Map> map = stream.collect(partitioningBy(pred)); > processResults(map.getOrDefault(false, List.of()), > map.getOrDefault(true, List.of())); > > With the guarantee, it's safe instead to write: > > Map> map = stream.collect(partitioningBy(pred)); > processResults(map.get(false), map.get(true)); > > In fact, this code works today, it's just that it's not specified to work. It should be. > > Thanks, > > s'marks > > > > diff -r 7583c87dfe7c src/java.base/share/classes/java/util/stream/Collectors.java > --- a/src/java.base/share/classes/java/util/stream/Collectors.java Thu Dec 08 21:21:39 2016 +0000 > +++ b/src/java.base/share/classes/java/util/stream/Collectors.java Thu Dec 08 14:39:31 2016 -0800 > @@ -1268,6 +1268,8 @@ > * to a {@code Predicate}, and organizes them into a > * {@code Map>}. > * > + * The returned {@code Map} always contains mappings for both > + * {@code false} and {@code true} keys. > * There are no guarantees on the type, mutability, > * serializability, or thread-safety of the {@code Map} or {@code List} > * returned. > @@ -1290,7 +1292,10 @@ > * {@code Map} whose values are the result of the downstream > * reduction. > * > - *

      There are no guarantees on the type, mutability, > + *

      > + * The returned {@code Map} always contains mappings for both > + * {@code false} and {@code true} keys. > + * There are no guarantees on the type, mutability, > * serializability, or thread-safety of the {@code Map} returned. > * > * @param the type of the input elements From paul.sandoz at oracle.com Fri Dec 9 17:01:49 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 9 Dec 2016 09:01:49 -0800 Subject: JDK 9 RFR of JDK-8023898: Consolidate Map tests Collisions and InPlaceOpsCollisions into general Map-based test In-Reply-To: References: Message-ID: <1A3C9513-C23C-4457-9D55-FB785614A5E8@oracle.com> Hi Amy, A nice refactoring and clean up. For some test cases in Collisions you don?t need to obtain the array of keys, you just need to know the key length, which can be obtained from map.size(). Paul. > On 8 Dec 2016, at 19:19, Amy Lu wrote: > > Please review this test refactoring to map test Collisions and InPlaceOpsCollisions. > > These tests have (almost) same code for creating test data, and the test data can be reused cross tests. With converting to testng, test data creating is now done and provided by MapWithCollisionsProviders.java, and each test now uses explicit data provider, which makes test more clear. > > Other changes include: > * Removed the redundant test Collections.testContainsKey and unnecessary map size check in the beginning of each test. > * Replaced 'check' with testng assertion method. > * Renaming and reformatting to make it more clear. > > bug:https://bugs.openjdk.java.net/browse/JDK-8023898 > webrev:http://cr.openjdk.java.net/~amlu/8023898/webrev.01/ > > Thanks, > Amy From daniel.fuchs at oracle.com Fri Dec 9 18:05:50 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 9 Dec 2016 18:05:50 +0000 Subject: Review Request JDK-8170772: ResourceBundle improper caching causes tools/javadoc tests intermittently In-Reply-To: References: Message-ID: Hi Mandy, It will be good to have Naoto's opinion on this. But what you propose makes sense to me. best regards, -- daniel On 09/12/16 16:49, Mandy Chung wrote: > Naoto, > > Can you review this ResourceBundle caching fix? The caller module > may be different than the specified module to > ResourceBundle.getBundle(String, Module) method and it should also > part of the cache key. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ > > The new test shows the issue there and the first loading of the > resource bundle of a specific module (success or fail) will be > put in the cache and used by subsequent calls. > > Thanks > Mandy > From naoto.sato at oracle.com Fri Dec 9 18:25:51 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 9 Dec 2016 10:25:51 -0800 Subject: Review Request JDK-8170772: ResourceBundle improper caching causes tools/javadoc tests intermittently In-Reply-To: References: Message-ID: <941a03e9-a8df-de21-ef46-4102ed3fad49@oracle.com> Hi Mandy, The fix looks fine to me. Naoto On 12/9/16 10:05 AM, Daniel Fuchs wrote: > Hi Mandy, > > It will be good to have Naoto's opinion on this. > But what you propose makes sense to me. > > best regards, > > -- daniel > > On 09/12/16 16:49, Mandy Chung wrote: >> Naoto, >> >> Can you review this ResourceBundle caching fix? The caller module >> may be different than the specified module to >> ResourceBundle.getBundle(String, Module) method and it should also >> part of the cache key. >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ >> >> The new test shows the issue there and the first loading of the >> resource bundle of a specific module (success or fail) will be >> put in the cache and used by subsequent calls. >> >> Thanks >> Mandy >> > From joe.darcy at oracle.com Fri Dec 9 22:28:37 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Fri, 09 Dec 2016 14:28:37 -0800 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <054e0fbbbff042349dc2bc555fdd5be5@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <054e0fbbbff042349dc2bc555fdd5be5@DEROTE13DE08.global.corp.sap> Message-ID: <584B3015.2070008@oracle.com> Hi Goetz, Please leave fdlibm asin alone as part of this change. The fdlibm library has some anachronistic coding idioms and certainly at least in this one case misleading code, but I'd prefer to leave the code as-is until it is ported to Java. Thanks, -Joe On 12/8/2016 6:32 AM, Lindenmaier, Goetz wrote: > Hi Joe, > > could you please have a look at my change to e_asin.c: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/src/java.base/share/native/libfdlibm/e_asin.c.udiff.html > > The change conserves the situation, I just added {} and comments. > I would appreciate to clean this up as it's hard to understand and our > code scan does not like it the way it is. > > We had talked about this in my thread where I learned to read this code :) > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-December/045165.html > > Best regards, > Goetz. > > >> -----Original Message----- >> From: Martin Buchholz [mailto:martinrb at google.com] >> Sent: Mittwoch, 7. Dezember 2016 18:09 >> To: Lindenmaier, Goetz ; Joe Darcy >> >> Cc: Dmitry Samersoff ; Java Core Libs > libs-dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> This changes fdlibm, which has historically been untouched. Don't commit >> without Joe Darcy's approval. >> >> On Wed, Dec 7, 2016 at 7:26 AM, Lindenmaier, Goetz >> > wrote: >> >> >> Hi Dmitry, >> >> yes, new_jvmpath is consistent with the other variables. >> I also merged the ifs in SDE.c. >> >> new webrev: >> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.03/ > corlib_s11y/webrev.03/> >> >> Best regards, >> Goetz. >> >> > -----Original Message----- >> > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com >> ] >> > Sent: Wednesday, December 07, 2016 2:43 PM >> > To: Lindenmaier, Goetz > >; Java Core Libs >> > > dev at openjdk.java.net> >; serviceability-dev (serviceability- >> > dev at openjdk.java.net ) >> > dev at openjdk.java.net> > >> > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >> servicabilty >> > coding. >> > >> >> > Goetz, >> > >> > SDE.c: >> > >> > You might combine if at ll. 260 and 263 to one but it's just matter of >> test. >> > >> > if (sti == baseStratumIndex || sti < 0) { >> > return; /* Java stratum - return unchanged */ >> > } >> > >> > > I'm not sure what you mean. I tried to fix it, but please >> > > double-check the new webrev. >> > >> > if cnt is <= 0 loop at l.267 >> > >> > for (; cnt-- > 0; ++fromEntry) { >> > >> > is never run and we effectively do >> > >> > *entryCountPtr = 0; >> > >> > at l.283 >> > >> > So if we you suspect that cnt may become negative or 0: >> > (your v.01 changes) >> > >> > 260 if (sti < 0 && cnt > 0) { >> > 261 return; >> > 262 } >> > >> > it's better to check it early. >> > >> > But I'm not sure we have to care about negative/zero cnt here. >> > >> > -Dmitry >> > >> > On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >> > > Hi Dmitry, >> > > >> > > thanks for looking at my change! >> > > Updated webrev: >> > > http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.02 > corlib_s11y/webrev.02> >> > > >> > >> * src/java.base/unix/native/libjli/java_md_solinux.c >> > >> Is this line correct? >> > >> 519 jvmpath = JLI_StringDup(jvmpath); >> > > >> > > It seems pointless. Should I remove it? (The whole file is a horror.) >> > > >> > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >> > >> It might be better to return immediately if cnt < 0, >> > >> regardless of value of sti. >> > > >> > > I'm not sure what you mean. I tried to fix it, but please >> > > double-check the new webrev. >> > > >> > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >> > >> It might be better to write >> > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; >> > >> and leave one copy of setsockopt() call >> > > >> > > Yes, looks better. >> > > >> > > Best regards, >> > > Goetz >> > > >> > > >> > >> >> > >> -Dmitry >> > >> >> > >> >> > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >> > >>> Hi, >> > >>> >> > >>> >> > >>> >> > >>> This change fixes some minor issues found in our code scans. >> > >>> >> > >>> I hope this correctly addresses corelib and serviceability issues. >> > >>> >> > >>> >> > >>> >> > >>> Please review: >> > >>> >> > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> >> > corlib_s11y/webrev.01/ >> > >>> >> > >>> >> > >>> >> > >>> Best regards, >> > >>> >> > >>> Goetz. >> > >>> >> > >>> >> > >>> >> > >>> Changes in detail: >> > >>> >> > >>> >> > >>> >> > >>> e_asin.c >> > >>> >> > >>> Code scan reports missing {}. >> > >>> >> > >>> >> > >>> The code "if (huge+x>one) {" is only there to set the inexact flag >> of >> > >>> the processor. >> > >>> It's a way to avoid the C compiler to optimize the code away. It is >> > >>> always true, >> > >>> so the parenthesis of the outer else don't matter. >> > >>> >> > >>> Although this basically just adds the {} I would like to submit this >> to >> > >>> >> > >>> avoid anybody else spends more the 30sec on understanding >> these >> > >>> >> > >>> if statements. >> > >>> >> > >>> >> > >>> k_standard.c >> > >>> >> > >>> exc.retval is returned below and thus should always be initialized. >> > >>> >> > >>> >> > >>> imageDecompressor.cpp >> > >>> >> > >>> Wrong destructor is used. Reported also by David CARLIER >> > >>> >> > >>> >> > >>> java.c >> > >>> >> > >>> in line 1865 'name' was used, it should be 'alias'. >> > >>> >> > >>> >> > >>> java_md_solinux.c >> > >>> >> > >>> "//" in path is useless. Further down a free is missing. >> > >>> >> > >>> >> > >>> SDE.c >> > >>> >> > >>> Call to stratumTableIndex can return negative value if >> defaultStratumId >> > >>> == null. >> > >>> >> > >>> >> > >>> socket_md.c >> > >>> >> > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden >> in >> > >>> the macros. >> > >>> >> > >>> >> > >>> unpack.cpp >> > >>> >> > >>> n.slice should not get negative argument for end, which is passed >> from >> > >>> dollar1. >> > >>> But dollar1 can get negative where it is set to the result of >> > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >> > >>> >> > >> >> > >> >> > >> -- >> > >> Dmitry Samersoff >> > >> Oracle Java development team, Saint Petersburg, Russia >> > >> * I would love to change the world, but they won't give me the >> sources. >> > >> > >> > -- >> > Dmitry Samersoff >> > Oracle Java development team, Saint Petersburg, Russia >> > * I would love to change the world, but they won't give me the >> sources. >> >> From uschindler at apache.org Fri Dec 9 22:32:53 2016 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 9 Dec 2016 23:32:53 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch Message-ID: <013d01d2526c$321bbd30$96533790$@apache.org> Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: (1) Unmapping of direct buffers no longer works, although this API was marked as critical because there is no replacement up to now, so code can unmap memory mapped files, which is one of the most important things Apache Lucene needs to use to access huge random access files while reading the index. Without memory mapping, the slowdown for Lucene users will be huge This is caused by the recent Jigsaw changes, published in build 148. Unfortunately we did not test the Jigsaw builds, so we would have noticed that earlier. Basically the following peace of code fails now (with or without doPrivileged and with/without security manager): final Class directBufferClass = Class.forName("java.nio.DirectByteBuffer"); final Method m = directBufferClass.getMethod("cleaner"); m.setAccessible(true); MethodHandle directBufferCleanerMethod = lookup.unreflect(m); Class cleanerClass = directBufferCleanerMethod.type().returnType(); // build method handle for unmapping, full code is here: https://goo.gl/TfQWl6 >From my understanding previous lengthy discussions on OpenJDKs mailing lists (and a discussion on last FOSDEM), we agreed, that this unmapping code will still be supported with Java 9 (it was already adapted to work with Java 8 and Java 9 in Lucene, see the full code at https://goo.gl/TfQWl6) and Java 10 might have a new "official" unmapping API. On FOSDEM we already had some discussions how to implement this (with Andrew Haley and Mark Reinholds). We would have a strong interest to start some proposal about this (JEP or similar, but how to proceed). The idea was to allow unmapping in some special Hotspot state and trigger a safepoint, keywords in the discussion were "volatile only on safepoints". So how to proceed with this. I know we can fix the issue with "--add-opens java.base/java.nio=ALL-UNNAMED", but for a product with huge impact like Elasticsearch or Solr, this is not a good way to go, especially as it will not work out of box anymore. From reading the module documentation, I had the feeling that there were some plans to support those "critical APIs" in the module definition (e.g., add exclusion from the checks for java.nio.DirectByteBuffer). An alternative is of course access to the (public) interface in the internal class sun.nio.ch.DirectBuffer, but we avoided this in our code, because it is also likely to break (I have not yet tried, if you have it declared as critical API). I just refer to the following issues that explicitely added APIs to allow unmapping (jdk.internal.Cleaner implements Runnable,...): https://bugs.openjdk.java.net/browse/JDK-8148117 https://bugs.openjdk.java.net/browse/JDK-8132928 http://cr.openjdk.java.net/~chegar/8148117/src/java.base/share/classes/jdk/internal/ref/Cleaner.java.udiff.html (2) A second thing we noticed is that Groovy no longer works and dies with strange error messages. This does not affect Lucene's program code, but breaks our build system (Ant-based but with some scripts inside). Also Elasticsearch's usage of Gradle is affected. We see this: groovy.lang.MissingMethodException: No signature of method: static java.lang.Integer.valueOf() is applicable for argument types: (java.lang.String) values: [54] Possible solutions: plus(java.lang.String) at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1500) at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1486) at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:53) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) at embedded_script_in_C__Users_Uwe_Schindler_Projects_lucene_trunk_lusolr1_lucene_common_build_dot_xml$_run_closure1.doCall(embedded_script_in_C__Users_Uwe_Schindler_Projects_lucene_trunk_lusolr1_lucene_common_build_dot_xml:7) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93) at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294) at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1021) at groovy.lang.Closure.call(Closure.java:426) at groovy.lang.Closure.call(Closure.java:442) at org.codehaus.groovy.runtime.DefaultGroovyMethods.callClosureForLine(DefaultGroovyMethods.java:5236) at org.codehaus.groovy.runtime.IOGroovyMethods.eachLine(IOGroovyMethods.java:487) at org.codehaus.groovy.runtime.ResourceGroovyMethods.eachLine(ResourceGroovyMethods.java:292) at org.codehaus.groovy.runtime.ResourceGroovyMethods.eachLine(ResourceGroovyMethods.java:257) at org.codehaus.groovy.runtime.dgm$945.invoke(Unknown Source) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274) at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56) at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133) at embedded_script_in_C__Users_Uwe_Schindler_Projects_lucene_trunk_lusolr1_lucene_common_build_dot_xml.run(embedded_script_in_C__Users_Uwe_Schindler_Projects_lucene_trunk_lusolr1_lucene_common_build_dot_xml:5) at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:263) at groovy.lang.GroovyShell.run(GroovyShell.java:518) at groovy.lang.GroovyShell.run(GroovyShell.java:497) at org.codehaus.groovy.ant.Groovy.parseAndRunScript(Groovy.java:512) at org.codehaus.groovy.ant.Groovy.execGroovy(Groovy.java:448) at org.codehaus.groovy.ant.Groovy.execute(Groovy.java:313) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:392) at org.apache.tools.ant.Target.performTasks(Target.java:413) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:811) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) I have no idea what is causing this, we are just users of Groovy - it just breaks our build. For now we had to revert to build 147 of JDK 9 which works as it should. Any suggestions how to proceed? For Lucene the first issue is very important. Without unmapping support, Elasticsearch, Solr and Lucene cannot work with Java 9, sorry - but our users are strongly waiting for it (because of huge speed improvements in ByteBuffers, more security because of Jigsaw,...). Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From stephen.felts at oracle.com Fri Dec 9 23:01:39 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 9 Dec 2016 15:01:39 -0800 (PST) Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <013d01d2526c$321bbd30$96533790$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: Gradle/groovy are known to have problems with the restricted module access of b148. ? You can get around this specific problem by using the environment variable _JAVA_OPTIONS=--add-opens=java.base/java.lang=ALL-UNNAMED ? The packages that you need to open depend on what Java methods your gradle/groovy files happen to step on. In my case, I need to use the following for our gradle build. --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.lang.reflect=ALL-UNNAMED --add-opens=java.base/java.net=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.util.regex=ALL-UNNAMED --add-opens=java.base/java.util.jar=ALL-UNNAMED --add-opens=java.base/java.util.zip=ALL-UNNAMED --add-opens=java.base/javax.net=ALL-UNNAMED --add-opens=java.base/sun.net.www=ALL-UNNAMED --add-opens=java.base/sun.net.www.protocol.file=ALL-UNNAMED --add-opens=java.base/sun.nio.fs=ALL-UNNAMED --add-opens=java.xml/javax.xml.transform=ALL-UNNAMED --add-opens=java.xml/javax.xml.transform.stream=ALL-UNNAMED --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc=ALL-UNNAMED --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.compiler=ALL-UNNAMED --add-opens=java.xml/com.sun.org.apache.xalan.internal.xsltc.trax=ALL-UNNAMED ? -----Original Message----- From: Uwe Schindler [mailto:uschindler at apache.org] Sent: Friday, December 09, 2016 5:33 PM To: jigsaw-dev at openjdk.java.net; Core-Libs-Dev Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch ? Hi, ? I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: ? (1) Unmapping of direct buffers no longer works, although this API was marked as critical because there is no replacement up to now, so code can unmap memory mapped files, which is one of the most important things Apache Lucene needs to use to access huge random access files while reading the index. Without memory mapping, the slowdown for Lucene users will be huge ? This is caused by the recent Jigsaw changes, published in build 148. Unfortunately we did not test the Jigsaw builds, so we would have noticed that earlier. Basically the following peace of code fails now (with or without doPrivileged and with/without security manager): ? ????? final Class directBufferClass = Class.forName("java.nio.DirectByteBuffer"); ????? ??????final Method m = directBufferClass.getMethod("cleaner"); ????? m.setAccessible(true); ????? MethodHandle directBufferCleanerMethod = lookup.unreflect(m); ????? Class cleanerClass = directBufferCleanerMethod.type().returnType(); ????? // build method handle for unmapping, full code is here: https://goo.gl/TfQWl6 ? >From my understanding previous lengthy discussions on OpenJDKs mailing lists (and a discussion on last FOSDEM), we agreed, that this unmapping code will still be supported with Java 9 (it was already adapted to work with Java 8 and Java 9 in Lucene, see the full code at https://goo.gl/TfQWl6) and Java 10 might have a new "official" unmapping API. On FOSDEM we already had some discussions how to implement this (with Andrew Haley and Mark Reinholds). We would have a strong interest to start some proposal about this (JEP or similar, but how to proceed). The idea was to allow unmapping in some special Hotspot state and trigger a safepoint, keywords in the discussion were "volatile only on safepoints". ? So how to proceed with this. I know we can fix the issue with "--add-opens java.base/java.nio=ALL-UNNAMED", but for a product with huge impact like Elasticsearch or Solr, this is not a good way to go, especially as it will not work out of box anymore. From reading the module documentation, I had the feeling that there were some plans to support those "critical APIs" in the module definition (e.g., add exclusion from the checks for java.nio.DirectByteBuffer). An alternative is of course access to the (public) interface in the internal class sun.nio.ch.DirectBuffer, but we avoided this in our code, because it is also likely to break (I have not yet tried, if you have it declared as critical API). ? I just refer to the following issues that explicitely added APIs to allow unmapping (jdk.internal.Cleaner implements Runnable,...): https://bugs.openjdk.java.net/browse/JDK-8148117 https://bugs.openjdk.java.net/browse/JDK-8132928 http://cr.openjdk.java.net/~chegar/8148117/src/java.base/share/classes/jdk/internal/ref/Cleaner.java.udiff.html ? (2) A second thing? we noticed is that Groovy no longer works and dies with strange error messages. This does not affect Lucene's program code, but breaks our build system (Ant-based but with some scripts inside). Also Elasticsearch's usage of Gradle is affected. ? We see this: groovy.lang.MissingMethodException: No signature of method: static java.lang.Integer.valueOf() is applicable for argument types: (java.lang.String) values: [54] Possible solutions: plus(java.lang.String) ??????? at groovy.lang.MetaClassImpl.invokeStaticMissingMethod(MetaClassImpl.java:1500) ??????? at groovy.lang.MetaClassImpl.invokeStaticMethod(MetaClassImpl.java:1486) ??????? at org.codehaus.groovy.runtime.callsite.StaticMetaClassSite.call(StaticMetaClassSite.java:53) ??????? at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) ??????? at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) ??????? at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:125) ??????? at embedded_script_in_C__Users_Uwe_Schindler_Projects_lucene_trunk_lusolr1_lucene_common_build_dot_xml$_run_closure1.doCall(embedded_script_in_C__Users_Uwe_Schindler_Projects_lucene_trunk_lusolr1_lucene_common_build_dot_xml:7) ??????? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ??????? at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) ??????? at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ??????? at java.base/java.lang.reflect.Method.invoke(Method.java:538) ??????? at org.codehaus.groovy.reflection.CachedMethod.invoke(CachedMethod.java:93) ??????? at groovy.lang.MetaMethod.doMethodInvoke(MetaMethod.java:325) ??????? at org.codehaus.groovy.runtime.metaclass.ClosureMetaClass.invokeMethod(ClosureMetaClass.java:294) ??????? at groovy.lang.MetaClassImpl.invokeMethod(MetaClassImpl.java:1021) ??????? at groovy.lang.Closure.call(Closure.java:426) ??????? at groovy.lang.Closure.call(Closure.java:442) ??????? at org.codehaus.groovy.runtime.DefaultGroovyMethods.callClosureForLine(DefaultGroovyMethods.java:5236) ??????? at org.codehaus.groovy.runtime.IOGroovyMethods.eachLine(IOGroovyMethods.java:487) ??????? at org.codehaus.groovy.runtime.ResourceGroovyMethods.eachLine(ResourceGroovyMethods.java:292) ??????? at org.codehaus.groovy.runtime.ResourceGroovyMethods.eachLine(ResourceGroovyMethods.java:257) ??????? at org.codehaus.groovy.runtime.dgm$945.invoke(Unknown Source) ??????? at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite$PojoMetaMethodSiteNoUnwrapNoCoerce.invoke(PojoMetaMethodSite.java:274) ??????? at org.codehaus.groovy.runtime.callsite.PojoMetaMethodSite.call(PojoMetaMethodSite.java:56) ??????? at org.codehaus.groovy.runtime.callsite.CallSiteArray.defaultCall(CallSiteArray.java:48) ??????? at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:113) ??????? at org.codehaus.groovy.runtime.callsite.AbstractCallSite.call(AbstractCallSite.java:133) ??????? at embedded_script_in_C__Users_Uwe_Schindler_Projects_lucene_trunk_lusolr1_lucene_common_build_dot_xml.run(embedded_script_in_C__Users_Uwe_Schindler_Projects_lucene_trunk_lusolr1_lucene_common_build_dot_xml:5) ??????? at groovy.lang.GroovyShell.runScriptOrMainOrTestOrRunnable(GroovyShell.java:263) ??????? at groovy.lang.GroovyShell.run(GroovyShell.java:518) ??????? at groovy.lang.GroovyShell.run(GroovyShell.java:497) ??????? at org.codehaus.groovy.ant.Groovy.parseAndRunScript(Groovy.java:512) ??????? at org.codehaus.groovy.ant.Groovy.execGroovy(Groovy.java:448) ??????? at org.codehaus.groovy.ant.Groovy.execute(Groovy.java:313) ??????? at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) ??????? at jdk.internal.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) ??????? at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ??????? at java.base/java.lang.reflect.Method.invoke(Method.java:538) ??????? at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) ??????? at org.apache.tools.ant.Task.perform(Task.java:348) ??????? at org.apache.tools.ant.Target.execute(Target.java:392) ??????? at org.apache.tools.ant.Target.performTasks(Target.java:413) ??????? at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) ??????? at org.apache.tools.ant.Project.executeTarget(Project.java:1368) ??????? at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) ??????? at org.apache.tools.ant.Project.executeTargets(Project.java:1251) ??????? at org.apache.tools.ant.Main.runBuild(Main.java:811) ??????? at org.apache.tools.ant.Main.startAnt(Main.java:217) ??????? at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) ??????? at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) ? I have no idea what is causing this, we are just users of Groovy - it just breaks our build. ? For now we had to revert to build 147 of JDK 9 which works as it should. Any suggestions how to proceed? For Lucene the first issue is very important. Without unmapping support, Elasticsearch, Solr and Lucene cannot work with Java 9, sorry - but our users are strongly waiting for it (because of huge speed improvements in ByteBuffers, more security because of Jigsaw,...). ? Uwe ? ----- Uwe Schindler HYPERLINK "mailto:uschindler at apache.org"uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ ? ? ? From stephen.felts at oracle.com Fri Dec 9 23:06:53 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 9 Dec 2016 15:06:53 -0800 (PST) Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: I would highly recommend running with _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true It will tell you what add-options are required. One minor downside is that it will produce the warning in cases where the software is already correctly handling the exception from setAccessible, so there can be noise. From uschindler at apache.org Fri Dec 9 23:21:36 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 10 Dec 2016 00:21:36 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: <015101d25272$ff7717b0$fe654710$@apache.org> Hi, Thanks for the hints to fix Groovy, although this is hard to do with ANT (which is our build system). The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed, but it does not solve the underlying issue. Apache Solr/Lucene and Elasticsearch will no longer work with Java 9 unless you require users to add those strange options. Elasticsearch already runs with a SecurityManager by default, so the question is: why is this not handled by a security manager and a new permission like "crossModuleAccess/module/package"? Why must it be done on command line? This makes it impossible to ship something like Lucene that it work out of box together with correct policy files? And as said in my previous mail: The direct bytebuffer unmapping has still no "official" way to do it, but it is critical to large scale database systems like Lucene/Solr/Elasticsearch. You have replacements in Java 9 for Unsafe (VarHandles,...), but still no way to allow unmapping of byte buffers that sit on huge resources or disallow deleting of files on windows. It was discussed on last FOSDEM to do something in Java 10 (I would like to get information how to propose the required change as Java 10 dev started now!), and in the meantime it was confirmed that some APIs in the JDK are "critical" and will be supported. But this is now So please re-add the special critical APIs back to the whitelist, so code like getting (legacy) Unsafe or unmapping direct buffers works without command line parameters that confuse people. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Stephen Felts [mailto:stephen.felts at oracle.com] > Sent: Saturday, December 10, 2016 12:07 AM > To: Uwe Schindler ; jigsaw-dev at openjdk.java.net; > Core-Libs-Dev > Subject: RE: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > I would highly recommend running with _JAVA_OPTIONS=- > Dsun.reflect.debugModuleAccessChecks=true > It will tell you what add-options are required. > One minor downside is that it will produce the warning in cases where the > software is already correctly handling the exception from setAccessible, so > there can be noise. From kevin.rushforth at oracle.com Fri Dec 9 23:33:27 2016 From: kevin.rushforth at oracle.com (Kevin Rushforth) Date: Fri, 09 Dec 2016 15:33:27 -0800 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: <584B3F47.2090600@oracle.com> I second the recommendation of using "-Dsun.reflect.debugModuleAccessChecks=true". We use gradle to build JavaFX and I ended up needing the following to allow our build to run with jdk-9+148: export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED" -- Kevin Stephen Felts wrote: > I would highly recommend running with _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true > It will tell you what add-options are required. > One minor downside is that it will produce the warning in cases where the software is already correctly handling the exception from setAccessible, so there can be noise. > From stephen.felts at oracle.com Fri Dec 9 23:45:23 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 9 Dec 2016 15:45:23 -0800 (PST) Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <015101d25272$ff7717b0$fe654710$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <015101d25272$ff7717b0$fe654710$@apache.org> Message-ID: Unsafe is visible in JDK9. See the list at http://openjdk.java.net/jeps/260 I agree that requiring command line options is a problem. The experts don't want to merge module access into the security manager. The link above says "Suggested additions to this list, justified by real-world use cases and estimates of developer and end-user impact, are welcome". So you should make clear exactly API's that you want exposed. -----Original Message----- From: Uwe Schindler [mailto:uschindler at apache.org] Sent: Friday, December 09, 2016 6:22 PM To: Stephen Felts; jigsaw-dev at openjdk.java.net; Core-Libs-Dev Subject: RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch Hi, Thanks for the hints to fix Groovy, although this is hard to do with ANT (which is our build system). The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed, but it does not solve the underlying issue. Apache Solr/Lucene and Elasticsearch will no longer work with Java 9 unless you require users to add those strange options. Elasticsearch already runs with a SecurityManager by default, so the question is: why is this not handled by a security manager and a new permission like "crossModuleAccess/module/package"? Why must it be done on command line? This makes it impossible to ship something like Lucene that it work out of box together with correct policy files? And as said in my previous mail: The direct bytebuffer unmapping has still no "official" way to do it, but it is critical to large scale database systems like Lucene/Solr/Elasticsearch. You have replacements in Java 9 for Unsafe (VarHandles,...), but still no way to allow unmapping of byte buffers that sit on huge resources or disallow deleting of files on windows. It was discussed on last FOSDEM to do something in Java 10 (I would like to get information how to propose the required change as Java 10 dev started now!), and in the meantime it was confirmed that some APIs in the JDK are "critical" and will be supported. But this is now So please re-add the special critical APIs back to the whitelist, so code like getting (legacy) Unsafe or unmapping direct buffers works without command line parameters that confuse people. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Stephen Felts [mailto:stephen.felts at oracle.com] > Sent: Saturday, December 10, 2016 12:07 AM > To: Uwe Schindler ; > jigsaw-dev at openjdk.java.net; Core-Libs-Dev > > Subject: RE: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > I would highly recommend running with _JAVA_OPTIONS=- > Dsun.reflect.debugModuleAccessChecks=true > It will tell you what add-options are required. > One minor downside is that it will produce the warning in cases where > the software is already correctly handling the exception from > setAccessible, so there can be noise. From stephen.felts at oracle.com Fri Dec 9 23:51:47 2016 From: stephen.felts at oracle.com (Stephen Felts) Date: Fri, 9 Dec 2016 15:51:47 -0800 (PST) Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <584B3F47.2090600@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <584B3F47.2090600@oracle.com> Message-ID: <6db11c15-13b3-44c5-9f3b-e826c9b50fb9@default> A related problem is that opening these packages to satisfy gradle/grooy can mask other non-gradle problems with the same packages. I isolated these options in our shell that invokes Gradle, although that still isn't perfect since we run lots of Java programs during the build. -----Original Message----- From: Kevin Rushforth Sent: Friday, December 09, 2016 6:33 PM To: Stephen Felts Cc: Uwe Schindler; jigsaw-dev at openjdk.java.net; Core-Libs-Dev Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch I second the recommendation of using "-Dsun.reflect.debugModuleAccessChecks=true". We use gradle to build JavaFX and I ended up needing the following to allow our build to run with jdk-9+148: export _JAVA_OPTIONS="-Dsun.reflect.debugModuleAccessChecks=true --add-opens=java.base/java.lang=ALL-UNNAMED --add-opens=java.base/java.util=ALL-UNNAMED --add-opens=java.base/java.lang.invoke=ALL-UNNAMED --add-opens=java.base/java.io=ALL-UNNAMED --add-opens=java.base/java.util.concurrent=ALL-UNNAMED --add-opens=java.base/java.text=ALL-UNNAMED" -- Kevin Stephen Felts wrote: > I would highly recommend running with > _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true > It will tell you what add-options are required. > One minor downside is that it will produce the warning in cases where the software is already correctly handling the exception from setAccessible, so there can be noise. > From vincent.x.ryan at oracle.com Sat Dec 10 01:00:42 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 10 Dec 2016 01:00:42 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> Message-ID: <212B8ABE-78F1-4E96-8948-21CAA42B4E5D@oracle.com> Thanks for your review comments Alan. Responses below. > On 8 Dec 2016, at 19:44, Alan Bateman wrote: > > On 07/12/2016 16:32, Vincent Ryan wrote: > >> A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. >> Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing >> a very simple replacement in a new and supported class: java.util.HexDump. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ > I'm happy to see a proposal for an API in Java SE for this, it's always sad to bump into code that is using a utility method exposed in java.xml.bind or the JDK internal hex dumper. Yes it?s long overdue. > > I've skimmed the API. The class name and package look okay. I assume you can make HexDump final (I realize the ctor is private). OK. > > The toHexString/fromHexString methods are really useful but I think the javadoc needs to be fleshed out a bit. For example, fromHexString doesn't make it clear whether the A-F need to be in a specific case, the IAE description doesn't make it clear that it is thrown when there is invalid input. The description of toHexString can be clearer on the length of the returned string, the reader might wonder if there is a "0x" prepended for example. OK. > > I like dump(byte[]) but I could imagine calls to "customize" the returned string in many ways. After reading dumpToStream then I wonder if it might be better to drop dump and let users do their own layout. If you keep it then the javadoc needs work - the reader will have many questions. What is "non-printable", what is the character in the output that splits the lines, how is the last line handled when the input is not a multiple of 16 bytes. Given dumpToStream then I wonder if might be better to drop this method. The behaviour of the dump method can also be achieved by manipulating the stream generated by the dumpToStream method but that requires additional programming. The dump method does all that work for you so I?d prefer to keep it as a convenience method. > > dumpToStream(byte[]) is interesting too but again needs a lot more javadoc. I assume the spliterator will be replaced eventually as the size is known so you can do a good implementation. Yes. Paul has provided guidance on implementation details that and I will pick that up later once this class has been integrated. > > It would be useful to put in some @see references from methods like Integer.toHexString. Where? Just on toHexString ? > > I don't have comments on the implementation/test at this time. > > -Alan. From vincent.x.ryan at oracle.com Sat Dec 10 01:00:51 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 10 Dec 2016 01:00:51 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> Message-ID: Thanks for your review comments Paul. Responses below. > On 8 Dec 2016, at 20:08, Paul Sandoz wrote: > > Hi, > > It may take a few iterations to get the API settled. > > There are other byte sources we may want to consider such as InputStream and ByteBuffer. I?d prefer to keep this class simple for now but I?m happy to add additional methods later if there is demand. Adding support for InputStream is awkward because of its blocking nature. It?s simpler to allow the user to handle that aspect, populate a byte array, and present it to the HexDump methods. Some ByteBuffers can be converted to a byte[] without the penalty of a copy operation. If performance becomes an issue then we can re-visit supporting ByteBuffer. > > Comments below. > > Paul. > >> On 7 Dec 2016, at 08:32, Vincent Ryan wrote: >> >> A hexdump facility has been available for many, many years via an unsupported class: sun.misc.HexDumpEncoder. >> Although that class was always unsupported, it was still accessible. That accessibility changes with Jigsaw so I?m proposing >> a very simple replacement in a new and supported class: java.util.HexDump. >> >> Thanks. >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8170769 >> Webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.00/ >> > > 55 if (bytes == null) { > 56 throw new NullPointerException(); > 57 } > > Objects.requireNonNull OK > > > 78 * @throws IllegalArgumentException if {@code hexString} has an odd number > 79 * of digits > 80 * @throws NullPointerException if {@code hexString} is {@code null} > 81 */ > 82 public static byte[] fromHexString(String hexString) { > > This should accept a CharSequence, plus also have bounded range equivalent. toHexString and fromHexString are expected to operate on reasonably short byte arrays. I have added range equivalents for dump and dumpToStream where longer byte arrays are expected. > > Also throws IAE if the hexString contains non-convertible characters. > OK > > 106 /** > 107 * Generates a stream of hexadecimal strings, in 16-byte chunks, > 108 * from the contents of a binary buffer. > 109 * > 110 * @param bytes a binary buffer > 111 * @return a stream of hexadecimal strings > 112 * @throws NullPointerException if {@code bytes} is {@code null} > 113 */ > 114 public static Stream dumpToStream(byte[] bytes) { > 115 if (bytes == null) { > 116 throw new NullPointerException(); > 117 } > 118 return StreamSupport.stream( > 119 Spliterators.spliteratorUnknownSize( > 120 new HexDumpIterator(bytes), > 121 Spliterator.ORDERED | Spliterator.NONNULL), > 122 false); > 123 } > > I suspect there is no need for a HexDumpIterator and you can do: > > return IntStream.range(0, roundUp(bytes.length, 16)).mapToObject(?); > > and in the map function take care of the trailing bytes based on the byte[] length. That?s potentially simple enough there might be no need for a stream method. Where it gets more complicated is if the source is of unknown size such as InputStream, where the stream returning method probably has more value. > > Ideally what we want to return is Stream<[Long, String]>, then it?s really easy for others for format, but alas the current form would be ugly and inefficient. So i suspect the dump method has some legs but it?s real value may be for a fully streaming solution. > > > 140 public static String dump(byte[] bytes) { > 141 if (bytes == null) { > 142 throw new NullPointerException(); > 143 } > 144 > 145 int[] count = { -16 }; > 146 return dumpToStream(bytes).collect(Collector.of( > 147 StringBuilder::new, > 148 (stringBuilder, hexString) -> > 149 stringBuilder > 150 .append(String.format("%08x %s%n", > 151 (count[0] += CHUNK_LENGTH), > 152 explode(hexString))), > 153 StringBuilder::append, > 154 StringBuilder::toString)); > 155 } > > The encoding of the count and exploding could also append directly into the main string builder, reducing memory churn. > > And i think you can also start from IntStream.range(0, roundUp(bytes.length, 16)) avoiding the count state. Thanks for those suggested improvements. They look good but I'd prefer to make implementation changes in a follow-up. > > > 192 if (b < ' ' || b > '~') { > 193 sb.append(".?); > > Use ?.? OK > > > 194 } else { > 195 sb.append(new String(new byte[]{ b })); > > Cast the byte to a char instead. OK > > > 196 } > > > > > > > > > From vincent.x.ryan at oracle.com Sat Dec 10 01:02:14 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sat, 10 Dec 2016 01:02:14 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <212B8ABE-78F1-4E96-8948-21CAA42B4E5D@oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> <212B8ABE-78F1-4E96-8948-21CAA42B4E5D@oracle.com> Message-ID: Thanks to those who provided review comments. I have incorporated most of them and updated the webrev: http://cr.openjdk.java.net/~vinnie/8170769/webrev.01/ The main changes are to tighten up the javadoc spec and to add three additional methods to support byte array ranges. The total number of public methods is now 7. I have not added support for InputStream or ByteBuffer. I think what we have in place is sufficient for now and HexDump can be enhanced later if there is demand. The other issue is related to streams implementation and I?d like to defer that until later. I think the API is in good shape now but please let me know if there are any must-fix API issues. Otherwise I will consider the API finalised and move this forward. Thanks. From brian.burkhalter at oracle.com Sat Dec 10 01:15:46 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 9 Dec 2016 17:15:46 -0800 Subject: PollingWatchService possible issue In-Reply-To: <4FECE4B6-90E9-463F-904F-75F5262A61C8@cbfiddle.com> References: <4FECE4B6-90E9-463F-904F-75F5262A61C8@cbfiddle.com> Message-ID: <2068A676-8336-4EEC-9141-5E37512F00FD@oracle.com> Hello, This topic should be discussed on the nio-dev mailing list so I am re-directing the thread there. Please omit core-libs-dev from any replies, thanks. On Dec 4, 2016, at 12:50 PM, Alan Snyder wrote: > I notice that PollingWatchService never checks the file key when it reads a directory to see if it is reading from the same directory that it started with. To clarify, do you intend that this check should be prior to the creation of the DirectoryStream at [1]? > I suspect that creates a potential for incorrect behavior if the directory tree is rearranged (between polls) so that the original path accesses a different directory. > > Specifically, if the original directory remains available via some other path, then someone watching on that path or trying to register using that path will be using a watch service that is reading the wrong directory. This does seem like a potential problem. Thanks, Brian [1] http://hg.openjdk.java.net/jdk9/jdk9/jdk/file/3f4dab6bb48e/src/java.base/share/classes/sun/nio/fs/PollingWatchService.java#l345 From brent.christian at oracle.com Sat Dec 10 01:16:58 2016 From: brent.christian at oracle.com (Brent Christian) Date: Fri, 09 Dec 2016 17:16:58 -0800 Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint In-Reply-To: <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com> References: <584885AA.9060202@oracle.com> <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com> Message-ID: <584B578A.1030508@oracle.com> On 12/07/2016 04:05 PM, Mandy Chung wrote: > > I suggest to add two utility methods rather than the has method: > boolean dropClassLoaderName() > boolean dropModuleVersion() Done. > 430 if (m != null && m.isNamed() && > 431 (isHashedInJavaBase(m) || !m.getDescriptor().version().isPresent())) { > 432 bits |= JDK_NON_UPGRADEABLE_MODULE; > 433 } > > I think this should simply be: > if (isHashedInJavaBase(m)) {..} > Done. > Can you retain the javadoc of toLoaderModuleClassName, revised if appropriate, in the computeFormat method? Updated. > line 322-325: what about: > > The toString method may return two different values on two > StackTraceElement instances that are equal for example when > one created via the constructor and one obtained from Throwable > or StackFrame where an implementation may choose to omit some > element in the returned string. That sounds good. > Is @apiNote in equals necessary? Maybe the one added in toString is adequate? I'm fine without it - removed. I also fixed test code for a case which only works with the images build. Updated webrev: http://cr.openjdk.java.net/~bchristi/8169389/webrev.04/ -Brent From mandy.chung at oracle.com Sat Dec 10 01:31:16 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Fri, 9 Dec 2016 17:31:16 -0800 Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint In-Reply-To: <584B578A.1030508@oracle.com> References: <584885AA.9060202@oracle.com> <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com> <584B578A.1030508@oracle.com> Message-ID: > On Dec 9, 2016, at 5:16 PM, Brent Christian wrote: > > Updated webrev: > http://cr.openjdk.java.net/~bchristi/8169389/webrev.04/ Looks good. Mandy From Alan.Bateman at oracle.com Sat Dec 10 05:14:13 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 10 Dec 2016 05:14:13 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <013d01d2526c$321bbd30$96533790$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: On 09/12/2016 22:32, Uwe Schindler wrote: > Hi, > > I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: > > (1) Unmapping of direct buffers no longer works, although this API was marked as critical because there is no replacement up to now, so code can unmap memory mapped files, which is one of the most important things Apache Lucene needs to use to access huge random access files while reading the index. Without memory mapping, the slowdown for Lucene users will be huge sun.misc.Cleaner was indeed on the original list of APIs for JEP 260 to identify as a "critical internal API". It turned out not to be useful because it would have required some way to get the Cleaner in the first place. That lead to the "new" hack that is reading the private "cleaner" field from DBB and treating it as a Runnable. That hack now breaks because setAccessible has changed in jdk-9+148 to align with the JSR 376 proposal tracked as #AwkwardStrongEncapsulation. No need to panic though, there is an update to JEP 260 coming soon for this specific need. Details TDB but it will probably be a method in jdk.unsupported module. It does mean that libraries using the old (or "new") hacks will need to change. I hope it will be seen as a reasonable compromise for this generally awkward issue. -Alan From Alan.Bateman at oracle.com Sat Dec 10 05:25:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 10 Dec 2016 05:25:22 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: <1b6dd60a-b8c1-0214-30c6-fbdf01b46c3d@oracle.com> On 09/12/2016 23:06, Stephen Felts wrote: > I would highly recommend running with _JAVA_OPTIONS=-Dsun.reflect.debugModuleAccessChecks=true > It will tell you what add-options are required. > One minor downside is that it will produce the warning in cases where the software is already correctly handling the exception from setAccessible, so there can be noise. Yes, this is a useful property to debug cases where setAccessible fails because the package is not exported or opened to the caller. There is more on this in JEP 261. -Alan. From blackdrag at gmx.org Sat Dec 10 08:22:34 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 10 Dec 2016 09:22:34 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <013d01d2526c$321bbd30$96533790$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: <584BBB4A.9060603@gmx.org> On 09.12.2016 23:32, Uwe Schindler wrote: > Hi, > > I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: > > (1) Unmapping of direct buffers no longer works, although this API was marked as critical because there is no replacement up to now, so code can unmap memory mapped files, which is one of the most important things Apache Lucene needs to use to access huge random access files while reading the index. Without memory mapping, the slowdown for Lucene users will be huge > > This is caused by the recent Jigsaw changes, published in build 148. Unfortunately we did not test the Jigsaw builds, so we would have noticed that earlier. Basically the following peace of code fails now (with or without doPrivileged and with/without security manager): > > final Class directBufferClass = Class.forName("java.nio.DirectByteBuffer"); > > final Method m = directBufferClass.getMethod("cleaner"); > m.setAccessible(true); > MethodHandle directBufferCleanerMethod = lookup.unreflect(m); > Class cleanerClass = directBufferCleanerMethod.type().returnType(); > // build method handle for unmapping, full code is here: https://goo.gl/TfQWl6 I guess that is the effect of #AwkwardStrongEncapsulation. I would advise doing regular checks against the jigsaw builds to know about such problems in the future earlier... but seeing your code break without an obvious good solution sure is stressful. I feel with you. [...] > (2) A second thing we noticed is that Groovy no longer works and dies with strange error messages. That is because versions including Groovy 2.4.7 are using setAccessible(AccessibleObject[] array, true), and the array will also include private methods or fields. This worked till #AwkwardStrongEncapsulation because will then a class was either exported and its method can all be made accessible or not. For example on GAE or earlier versions of the module system. Now an exported class may break this, since its private methods can no longer be made accessible using setAccessible. A fix for this is already committed, we are only waiting for release of Groovy 2.4.8. Of course even with the fix Groovy code can possibly break... for example if you did the direct buffer access in Groovy. Btw, do not hesitate to ask about such problems on groovy-user, please. bye Jochen From blackdrag at gmx.org Sat Dec 10 09:13:53 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 10 Dec 2016 10:13:53 +0100 Subject: AccessbileObject setAccessible array version vs non-array version Message-ID: <584BC751.8090704@gmx.org> Hi all, motivated by the recent "Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch" thead, I thought I ask... there is AcccessibleObject#setAccessible(boolean), which will ask the SecurityManager for permissions and then make itself accessible according to the boolean flag. the array version takes an array of AccessibleObjects, asks the security manager *once* and then makes all of them accessible. So if you are in need to make a lot of objects accessible the array version is superior in performance. Now with jigsaw it is no longer a all or nothing for the class, now single methods or fields may no longer be made accessible, even without security manager. That means that even without a security manager set using the array version on File for example will fail with an exception (unless the module is opened from the command line, but we should leave that out for now) My question now basically is the following... why is this method not made deprecated? It is kind of useless now, even misleading I would say. bye Jochen From uschindler at apache.org Sat Dec 10 10:49:09 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 10 Dec 2016 11:49:09 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: <019401d252d3$0cd41b50$267c51f0$@apache.org> Thanks Alan, I will look forward to see a solution for this! THANKS! A static method somewhere in jdk.internal to trigger the unmapping of a MappedByteBuffer would be fine. This is easy to change in our code, we just need a MethodHandle to a function with the following signature: static void unmap(MappedByteBuffer) Our current code just generates the MethodHandle with exactly that signature and functionality by some guardWithTest, filterArguments,... and using the Cleaner as Java 8 internal class or as Runnable in Java 9: https://goo.gl/TfQWl6 The second thing was how to make a JEP proposal for solving the underlying problem in Java 10? As said before, on last FOSDEM we had some ideas how to make Hotspot able to unmap without the risk that the JVM SIGSEGV/SIGBUS or exposes private data. This would need some Hotspot changes ("volatile only during safepoints"), the idea was proposed by Andrew Haley. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Alan Bateman [mailto:Alan.Bateman at oracle.com] > Sent: Saturday, December 10, 2016 6:14 AM > To: Uwe Schindler ; jigsaw-dev at openjdk.java.net; > Core-Libs-Dev > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > On 09/12/2016 22:32, Uwe Schindler wrote: > > > Hi, > > > > I updated our Jenkins server for the JDK 9 preview testing to use build 148. > Previously we had build 140 and build 147, which both worked without any > issues. But after the update the following stuff goes wrong: > > > > (1) Unmapping of direct buffers no longer works, although this API was > marked as critical because there is no replacement up to now, so code can > unmap memory mapped files, which is one of the most important things > Apache Lucene needs to use to access huge random access files while > reading the index. Without memory mapping, the slowdown for Lucene > users will be huge > sun.misc.Cleaner was indeed on the original list of APIs for JEP 260 to > identify as a "critical internal API". It turned out not to be useful > because it would have required some way to get the Cleaner in the first > place. That lead to the "new" hack that is reading the private "cleaner" > field from DBB and treating it as a Runnable. That hack now breaks > because setAccessible has changed in jdk-9+148 to align with the JSR 376 > proposal tracked as #AwkwardStrongEncapsulation. > > No need to panic though, there is an update to JEP 260 coming soon for > this specific need. Details TDB but it will probably be a method in > jdk.unsupported module. It does mean that libraries using the old (or > "new") hacks will need to change. I hope it will be seen as a reasonable > compromise for this generally awkward issue. > > -Alan From peter.levart at gmail.com Sat Dec 10 11:09:42 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 10 Dec 2016 12:09:42 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> Message-ID: <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> Hi, On 12/10/2016 06:14 AM, Alan Bateman wrote: > On 09/12/2016 22:32, Uwe Schindler wrote: > >> Hi, >> >> I updated our Jenkins server for the JDK 9 preview testing to use >> build 148. Previously we had build 140 and build 147, which both >> worked without any issues. But after the update the following stuff >> goes wrong: >> >> (1) Unmapping of direct buffers no longer works, although this API >> was marked as critical because there is no replacement up to now, so >> code can unmap memory mapped files, which is one of the most >> important things Apache Lucene needs to use to access huge random >> access files while reading the index. Without memory mapping, the >> slowdown for Lucene users will be huge > sun.misc.Cleaner was indeed on the original list of APIs for JEP 260 > to identify as a "critical internal API". It turned out not to be > useful because it would have required some way to get the Cleaner in > the first place. That lead to the "new" hack that is reading the > private "cleaner" field from DBB and treating it as a Runnable. That > hack now breaks because setAccessible has changed in jdk-9+148 to > align with the JSR 376 proposal tracked as #AwkwardStrongEncapsulation. > > No need to panic though, there is an update to JEP 260 coming soon for > this specific need. Details TDB but it will probably be a method in > jdk.unsupported module. It does mean that libraries using the old (or > "new") hacks will need to change. I hope it will be seen as a > reasonable compromise for this generally awkward issue. > > -Alan Something like the following? http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/ Regards, Peter From Alan.Bateman at oracle.com Sat Dec 10 12:08:41 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 10 Dec 2016 12:08:41 +0000 Subject: AccessbileObject setAccessible array version vs non-array version In-Reply-To: <584BC751.8090704@gmx.org> References: <584BC751.8090704@gmx.org> Message-ID: <9a3ba156-8469-64f9-90e6-cd5af8f84b92@oracle.com> On 10/12/2016 09:13, Jochen Theodorou wrote: > Hi all, > > motivated by the recent "Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch" thead, I thought I ask... there is > AcccessibleObject#setAccessible(boolean), which will ask the > SecurityManager for permissions and then make itself accessible > according to the boolean flag. the array version takes an array of > AccessibleObjects, asks the security manager *once* and then makes all > of them accessible. So if you are in need to make a lot of objects > accessible the array version is superior in performance. > > Now with jigsaw it is no longer a all or nothing for the class, now > single methods or fields may no longer be made accessible, even > without security manager. That means that even without a security > manager set using the array version on File for example will fail with > an exception (unless the module is opened from the command line, but > we should leave that out for now) > > My question now basically is the following... why is this method not > made deprecated? It is kind of useless now, even misleading I would say. I'm not sure that I understand your mail. The permission check when running with a security manager has not changed. If you use the array version then there is one permission check. Maybe you mean that the array version will fail when the array contains at least one element where the access check cannot be suppressed? That is possible of course. You mentioned File and maybe you mean you the array has a mix of public methods and non-public members and fields? -Alan. From Alan.Bateman at oracle.com Sat Dec 10 12:12:45 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 10 Dec 2016 12:12:45 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> Message-ID: <6e8fde5b-ffd5-38b5-696f-7f9e8a3913fd@oracle.com> On 10/12/2016 11:09, Peter Levart wrote: > : > > Something like the following? > > http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/ Sort of although I think the proposal will be more specific, as in unmap(MappedByteBuffer) on an existing class. The other update to JEP 260 that is needed is to mention the additional methods in sun.reflect.RefectionFactory that are needed by custom serialization libraries to work with strong encapsulation. -Alan From Alan.Bateman at oracle.com Sat Dec 10 12:13:22 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sat, 10 Dec 2016 12:13:22 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <584BBB4A.9060603@gmx.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <584BBB4A.9060603@gmx.org> Message-ID: On 10/12/2016 08:22, Jochen Theodorou wrote: > : > > A fix for this is already committed, we are only waiting for release > of Groovy 2.4.8. Of course even with the fix Groovy code can possibly > break... for example if you did the direct buffer access in Groovy. Thanks for sharing, that is very useful to know. -Alan From uschindler at apache.org Sat Dec 10 12:33:42 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 10 Dec 2016 13:33:42 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> Message-ID: <019b01d252e1$a70fb770$f52f2650$@apache.org> Hi Peter, this would be a great fix! Thanks!!! I also think the non-static method is superior to my original proposal, because it allows us to do the security check *once*, which is really needed for Lucene. I am still fine if the permission is still checked on every unmapping, but we need to do the check up-front. If you look at our current unmapping code (https://goo.gl/TfQWl6), you will the that the detector checks for the extra runtime permission upfront, so we can be sure that the actual unmapping will work for sure. This is also the reason why we use MethodHandles: As those are compiled on investigation of possible unmapping variants depending on the VM, we can ?compile? the MethodHandle and later call it as often as we like, without the risk that it breaks for incompatibility reasons. The MethodHandle makes sure that all types are checked up front. About MappedByteBuffer vs ByteBuffer (or maybe just java.nio.Buffer!?): I?d make it generic so it works with any direct buffer (maybe also non-byte ones). For Lucene it does not matter, but other projects (I know Cassandra or other off-Heap frameworks) do the same with buffers that were allocated direct (not only mmapped). The method signature in your proposal is also compatible to our requirements: We can create the DirectBufferDeallocator up front and then produce a MH which is bound to the allocator. I will make a pull request to Lucene using your current proposal so you have a ?patch? to test this with Lucene before you commit something like this. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ From: Peter Levart [mailto:peter.levart at gmail.com] Sent: Saturday, December 10, 2016 12:10 PM To: Alan Bateman ; Uwe Schindler ; jigsaw-dev at openjdk.java.net; Core-Libs-Dev Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch Hi, On 12/10/2016 06:14 AM, Alan Bateman wrote: On 09/12/2016 22:32, Uwe Schindler wrote: Hi, I updated our Jenkins server for the JDK 9 preview testing to use build 148. Previously we had build 140 and build 147, which both worked without any issues. But after the update the following stuff goes wrong: (1) Unmapping of direct buffers no longer works, although this API was marked as critical because there is no replacement up to now, so code can unmap memory mapped files, which is one of the most important things Apache Lucene needs to use to access huge random access files while reading the index. Without memory mapping, the slowdown for Lucene users will be huge sun.misc.Cleaner was indeed on the original list of APIs for JEP 260 to identify as a "critical internal API". It turned out not to be useful because it would have required some way to get the Cleaner in the first place. That lead to the "new" hack that is reading the private "cleaner" field from DBB and treating it as a Runnable. That hack now breaks because setAccessible has changed in jdk-9+148 to align with the JSR 376 proposal tracked as #AwkwardStrongEncapsulation. No need to panic though, there is an update to JEP 260 coming soon for this specific need. Details TDB but it will probably be a method in jdk.unsupported module. It does mean that libraries using the old (or "new") hacks will need to change. I hope it will be seen as a reasonable compromise for this generally awkward issue. -Alan Something like the following? http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/ Regards, Peter From peter.levart at gmail.com Sat Dec 10 13:08:22 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 10 Dec 2016 14:08:22 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <019b01d252e1$a70fb770$f52f2650$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> Message-ID: Hi Uwe, On 12/10/2016 01:33 PM, Uwe Schindler wrote: > > Hi Peter, > > this would be a great fix! Thanks!!! > > I also think the non-static method is superior to my original > proposal, because it allows us to do the security check **once**, > which is really needed for Lucene. I am still fine if the permission > is still checked on every unmapping, but we need to do the check > up-front. If you look at our current unmapping code > (https://goo.gl/TfQWl6), you will the that the detector checks for the > extra runtime permission upfront, so we can be sure that the actual > unmapping will work for sure. This is also the reason why we use > MethodHandles: As those are compiled on investigation of possible > unmapping variants depending on the VM, we can ?compile? the > MethodHandle and later call it as often as we like, without the risk > that it breaks for incompatibility reasons. The MethodHandle makes > sure that all types are checked up front. > > About MappedByteBuffer vs ByteBuffer (or maybe just > java.nio.Buffer!?): I?d make it generic so it works with any direct > buffer (maybe also non-byte ones). For Lucene it does not matter, but > other projects (I know Cassandra or other off-Heap frameworks) do the > same with buffers that were allocated direct (not only mmapped). The > method signature in your proposal is also compatible to our > requirements: We can create the DirectBufferDeallocator up front and > then produce a MH which is bound to the allocator. > I choose to limit the method to ByteBuffer type because this is the public static type used in programs for instances that are possibly "owning" the underlying native memory. Other-typed buffers or even 2nd-level direct ByteBuffers obtained by duplicating or slicing are just views and do not "own" the underlying memory. While it would be possible to trigger deallocation / unmapping via any buffer that references the owning buffer, I think this might be prone to bugs. By limiting the method to 1st-level direct ByteBuffer(s), the programmer is forced to think about ownership and lifetime of derived buffers and consequently write better code. So on 2nd thought, the API might be even better to reject non-direct and 2nd-level direct ByteBuffer(s) by throwing an exception rather than silently ignoring the deallocation request. > I will make a pull request to Lucene using your current proposal so > you have a ?patch? to test this with Lucene before you commit > something like this. > Let us first wait for a proposal from Oracle to see what they have in mind... Regards, Peter > Uwe > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Apache Lucene PMC / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > *From:*Peter Levart [mailto:peter.levart at gmail.com] > *Sent:* Saturday, December 10, 2016 12:10 PM > *To:* Alan Bateman ; Uwe Schindler > ; jigsaw-dev at openjdk.java.net; Core-Libs-Dev > > *Subject:* Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Hi, > > On 12/10/2016 06:14 AM, Alan Bateman wrote: > > On 09/12/2016 22:32, Uwe Schindler wrote: > > > Hi, > > I updated our Jenkins server for the JDK 9 preview testing to > use build 148. Previously we had build 140 and build 147, > which both worked without any issues. But after the update the > following stuff goes wrong: > > (1) Unmapping of direct buffers no longer works, although this > API was marked as critical because there is no replacement up > to now, so code can unmap memory mapped files, which is one of > the most important things Apache Lucene needs to use to access > huge random access files while reading the index. Without > memory mapping, the slowdown for Lucene users will be huge > > sun.misc.Cleaner was indeed on the original list of APIs for JEP > 260 to identify as a "critical internal API". It turned out not to > be useful because it would have required some way to get the > Cleaner in the first place. That lead to the "new" hack that is > reading the private "cleaner" field from DBB and treating it as a > Runnable. That hack now breaks because setAccessible has changed > in jdk-9+148 to align with the JSR 376 proposal tracked as > #AwkwardStrongEncapsulation. > > No need to panic though, there is an update to JEP 260 coming soon > for this specific need. Details TDB but it will probably be a > method in jdk.unsupported module. It does mean that libraries > using the old (or "new") hacks will need to change. I hope it will > be seen as a reasonable compromise for this generally awkward issue. > > -Alan > > > Something like the following? > > http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/ > > > > Regards, Peter > From daniel.fuchs at oracle.com Sat Dec 10 14:51:48 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Sat, 10 Dec 2016 14:51:48 +0000 Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint In-Reply-To: <584B578A.1030508@oracle.com> References: <584885AA.9060202@oracle.com> <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com> <584B578A.1030508@oracle.com> Message-ID: <12e7a48c-f8ec-bb3b-9875-e9d31d84d784@oracle.com> Hi Brent, This looks really good now! best regards, -- daniel On 10/12/16 01:16, Brent Christian wrote: > On 12/07/2016 04:05 PM, Mandy Chung wrote: >> >> I suggest to add two utility methods rather than the has method: >> boolean dropClassLoaderName() >> boolean dropModuleVersion() > > Done. > >> 430 if (m != null && m.isNamed() && >> 431 (isHashedInJavaBase(m) || >> !m.getDescriptor().version().isPresent())) { >> 432 bits |= JDK_NON_UPGRADEABLE_MODULE; >> 433 } >> >> I think this should simply be: >> if (isHashedInJavaBase(m)) {..} >> > > Done. > >> Can you retain the javadoc of toLoaderModuleClassName, revised if >> appropriate, in the computeFormat method? > > Updated. > >> line 322-325: what about: >> >> The toString method may return two different values on two >> StackTraceElement instances that are equal for example when >> one created via the constructor and one obtained from Throwable >> or StackFrame where an implementation may choose to omit some >> element in the returned string. > > That sounds good. > >> Is @apiNote in equals necessary? Maybe the one added in toString is >> adequate? > > I'm fine without it - removed. > > > I also fixed test code for a case which only works with the images build. > > Updated webrev: > http://cr.openjdk.java.net/~bchristi/8169389/webrev.04/ > > -Brent From chris.hegarty at oracle.com Sat Dec 10 17:11:02 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sat, 10 Dec 2016 17:11:02 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> Message-ID: <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> I think it best to keep whatever we do here simple and straight forward. It is, after all, just a stop gap until a public API can be put in place in a future release ( which I believe is a realistic possibility given some of the discussions that I have heard about, but that is for another day). If we add a method to Unsafe, then we get the benefit of being protected by the security manager for free ( you need reflective access to get "theUnsafe" field). Most of the code I've seen in this area delves into Unsafe anyway. How about: Unsafe::deallocate(ByteBuffer directBuffer)? http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ We could attempt to limit this to the direct buffer that "owns" the memory, i.e. not a duplicate or a slice, but I'm not sure it is worth it. Once we reach agreement on the technical solution, I will add appropriate wording to JEP 260 to cover this case. -Chris. > On 10 Dec 2016, at 13:08, Peter Levart wrote: > > Hi Uwe, > > > On 12/10/2016 01:33 PM, Uwe Schindler wrote: >> >> Hi Peter, >> >> this would be a great fix! Thanks!!! >> >> I also think the non-static method is superior to my original proposal, because it allows us to do the security check **once**, which is really needed for Lucene. I am still fine if the permission is still checked on every unmapping, but we need to do the check up-front. If you look at our current unmapping code (https://goo.gl/TfQWl6), you will the that the detector checks for the extra runtime permission upfront, so we can be sure that the actual unmapping will work for sure. This is also the reason why we use MethodHandles: As those are compiled on investigation of possible unmapping variants depending on the VM, we can ?compile? the MethodHandle and later call it as often as we like, without the risk that it breaks for incompatibility reasons. The MethodHandle makes sure that all types are checked up front. >> >> About MappedByteBuffer vs ByteBuffer (or maybe just java.nio.Buffer!?): I?d make it generic so it works with any direct buffer (maybe also non-byte ones). For Lucene it does not matter, but other projects (I know Cassandra or other off-Heap frameworks) do the same with buffers that were allocated direct (not only mmapped). The method signature in your proposal is also compatible to our requirements: We can create the DirectBufferDeallocator up front and then produce a MH which is bound to the allocator. >> > > I choose to limit the method to ByteBuffer type because this is the public static type used in programs for instances that are possibly "owning" the underlying native memory. Other-typed buffers or even 2nd-level direct ByteBuffers obtained by duplicating or slicing are just views and do not "own" the underlying memory. While it would be possible to trigger deallocation / unmapping via any buffer that references the owning buffer, I think this might be prone to bugs. By limiting the method to 1st-level direct ByteBuffer(s), the programmer is forced to think about ownership and lifetime of derived buffers and consequently write better code. > > So on 2nd thought, the API might be even better to reject non-direct and 2nd-level direct ByteBuffer(s) by throwing an exception rather than silently ignoring the deallocation request. > >> I will make a pull request to Lucene using your current proposal so you have a ?patch? to test this with Lucene before you commit something like this. >> > > Let us first wait for a proposal from Oracle to see what they have in mind... > > Regards, Peter > >> Uwe >> >> ----- >> >> Uwe Schindler >> >> uschindler at apache.org >> >> ASF Member, Apache Lucene PMC / Committer >> >> Bremen, Germany >> >> http://lucene.apache.org/ >> >> *From:*Peter Levart [mailto:peter.levart at gmail.com] >> *Sent:* Saturday, December 10, 2016 12:10 PM >> *To:* Alan Bateman ; Uwe Schindler ; jigsaw-dev at openjdk.java.net; Core-Libs-Dev >> *Subject:* Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch >> >> Hi, >> >> On 12/10/2016 06:14 AM, Alan Bateman wrote: >> >> On 09/12/2016 22:32, Uwe Schindler wrote: >> >> >> Hi, >> >> I updated our Jenkins server for the JDK 9 preview testing to >> use build 148. Previously we had build 140 and build 147, >> which both worked without any issues. But after the update the >> following stuff goes wrong: >> >> (1) Unmapping of direct buffers no longer works, although this >> API was marked as critical because there is no replacement up >> to now, so code can unmap memory mapped files, which is one of >> the most important things Apache Lucene needs to use to access >> huge random access files while reading the index. Without >> memory mapping, the slowdown for Lucene users will be huge >> >> sun.misc.Cleaner was indeed on the original list of APIs for JEP >> 260 to identify as a "critical internal API". It turned out not to >> be useful because it would have required some way to get the >> Cleaner in the first place. That lead to the "new" hack that is >> reading the private "cleaner" field from DBB and treating it as a >> Runnable. That hack now breaks because setAccessible has changed >> in jdk-9+148 to align with the JSR 376 proposal tracked as >> #AwkwardStrongEncapsulation. >> >> No need to panic though, there is an update to JEP 260 coming soon >> for this specific need. Details TDB but it will probably be a >> method in jdk.unsupported module. It does mean that libraries >> using the old (or "new") hacks will need to change. I hope it will >> be seen as a reasonable compromise for this generally awkward issue. >> >> -Alan >> >> >> Something like the following? >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/DirectBufferDeallocator/webrev.01/ >> >> >> Regards, Peter >> > From blackdrag at gmx.org Sat Dec 10 18:11:39 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Sat, 10 Dec 2016 19:11:39 +0100 Subject: AccessbileObject setAccessible array version vs non-array version In-Reply-To: <9a3ba156-8469-64f9-90e6-cd5af8f84b92@oracle.com> References: <584BC751.8090704@gmx.org> <9a3ba156-8469-64f9-90e6-cd5af8f84b92@oracle.com> Message-ID: <584C455B.6020807@gmx.org> On 10.12.2016 13:08, Alan Bateman wrote: > On 10/12/2016 09:13, Jochen Theodorou wrote: > >> Hi all, >> >> motivated by the recent "Java 9 build 148 causes trouble in Apache >> Lucene/Solr/Elasticsearch" thead, I thought I ask... there is >> AcccessibleObject#setAccessible(boolean), which will ask the >> SecurityManager for permissions and then make itself accessible >> according to the boolean flag. the array version takes an array of >> AccessibleObjects, asks the security manager *once* and then makes all >> of them accessible. So if you are in need to make a lot of objects >> accessible the array version is superior in performance. >> >> Now with jigsaw it is no longer a all or nothing for the class, now >> single methods or fields may no longer be made accessible, even >> without security manager. That means that even without a security >> manager set using the array version on File for example will fail with >> an exception (unless the module is opened from the command line, but >> we should leave that out for now) >> >> My question now basically is the following... why is this method not >> made deprecated? It is kind of useless now, even misleading I would say. > I'm not sure that I understand your mail. The permission check when > running with a security manager has not changed. If you use the array > version then there is one permission check. > > Maybe you mean that the array version will fail when the array contains > at least one element where the access check cannot be suppressed? That > is possible of course. You mentioned File and maybe you mean you the > array has a mix of public methods and non-public members and fields? yes. You will not need to set them to accessible for public members after all bye Jochen From Roger.Riggs at Oracle.com Sat Dec 10 18:30:57 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Sat, 10 Dec 2016 13:30:57 -0500 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> <212B8ABE-78F1-4E96-8948-21CAA42B4E5D@oracle.com> Message-ID: <60d73899-27f5-e2ba-3683-d6a2e85bb601@Oracle.com> Hi Vinnie, I think this doesn't belong in the java.base module; it doesn't add enough value for a average developer and it is not essential to the core. I don't have another module suggestion but would suggest looking elsewhere. $.02, Roger On 12/9/2016 8:02 PM, Vincent Ryan wrote: > Thanks to those who provided review comments. > > I have incorporated most of them and updated the webrev: > http://cr.openjdk.java.net/~vinnie/8170769/webrev.01/ > > The main changes are to tighten up the javadoc spec and to add three additional methods > to support byte array ranges. The total number of public methods is now 7. > > I have not added support for InputStream or ByteBuffer. I think what we have in place is > sufficient for now and HexDump can be enhanced later if there is demand. > > The other issue is related to streams implementation and I?d like to defer that until later. > > > I think the API is in good shape now but please let me know if there are any must-fix API issues. > Otherwise I will consider the API finalised and move this forward. > > Thanks. > From peter.levart at gmail.com Sat Dec 10 19:47:46 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 10 Dec 2016 20:47:46 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> Message-ID: <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> Hi Chris, On 12/10/2016 06:11 PM, Chris Hegarty wrote: > How about: Unsafe::deallocate(ByteBuffer directBuffer)? > http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ Apart from the fact that Unsafe is (was?) reserved for low-level stuff, I think this approach is reasonable. Is the method in jdk.internal.misc.Unsafe needed? You could add the method just to the sun.misc.Unsafe (to keep internal Unsafe free from hacks) and export the two packages selectively to jdk.unsupported. > We could attempt to limit this to the direct buffer that "owns" the > memory, i.e. not a duplicate or a slice, but I'm not sure it is worth > it. What you have here *is* limited to direct ByteBuffer(s) that "own" the memory. Derived buffer(s) (duplicated or sliced) do not have a Cleaner instance (they have an 'attachment' to keep the 1st-level buffer reachable while they are reachable). I would even make it more unforgiving by throwing an IAE if the passed-in buffer didn't have a Cleaner. In addition I would specify this behavior. For example: "Deallocates the underlying memory associated with given directBuffer if the buffer was obtained from either {@link ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. In any other case (when the buffer is not a direct buffer or was obtained by {@link ByteBuffer#duplicate() duplicating} or {@link ByteBuffer#slice(int, int) slicing} a direct buffer), the method throws {@code IllegalArgumentException}. Regards, Peter From uschindler at apache.org Sat Dec 10 20:00:50 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sat, 10 Dec 2016 20:00:50 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> Message-ID: Hi, We noticed that buffers with zero length also have no cleaner. This is why we also have the null check in our code (see Github) and the guardWithTest in the MethodHandle, although we never free duplicates. So a noop is better imho. I like the Unsafe approach. To me both variants are fine. Uwe Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart : >Hi Chris, > > >On 12/10/2016 06:11 PM, Chris Hegarty wrote: >> How about: Unsafe::deallocate(ByteBuffer directBuffer)? >> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > >Apart from the fact that Unsafe is (was?) reserved for low-level stuff, > >I think this approach is reasonable. Is the method in >jdk.internal.misc.Unsafe needed? You could add the method just to the >sun.misc.Unsafe (to keep internal Unsafe free from hacks) and export >the >two packages selectively to jdk.unsupported. > >> We could attempt to limit this to the direct buffer that "owns" the >> memory, i.e. not a duplicate or a slice, but I'm not sure it is worth >> it. > >What you have here *is* limited to direct ByteBuffer(s) that "own" the >memory. Derived buffer(s) (duplicated or sliced) do not have a Cleaner >instance (they have an 'attachment' to keep the 1st-level buffer >reachable while they are reachable). I would even make it more >unforgiving by throwing an IAE if the passed-in buffer didn't have a >Cleaner. In addition I would specify this behavior. For example: > >"Deallocates the underlying memory associated with given directBuffer >if >the buffer was obtained from either {@link ByteBuffer#allocateDirect} >or >{@link FileChannel#map} methods. In any other case (when the buffer is >not a direct buffer or was obtained by {@link ByteBuffer#duplicate() >duplicating} or {@link ByteBuffer#slice(int, int) slicing} a direct >buffer), the method throws {@code IllegalArgumentException}. > >Regards, Peter From ecki at zusammenkunft.net Sat Dec 10 20:29:48 2016 From: ecki at zusammenkunft.net (Bernd Eckenfels) Date: Sat, 10 Dec 2016 20:29:48 +0000 (UTC) Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: <60d73899-27f5-e2ba-3683-d6a2e85bb601@Oracle.com> References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> <212B8ABE-78F1-4E96-8948-21CAA42B4E5D@oracle.com> <60d73899-27f5-e2ba-3683-d6a2e85bb601@Oracle.com> Message-ID: <57A008FAA9E6E1E3.1F00CBEA-A64E-42AF-9949-26FE93E790E7@mail.outlook.com> Hello, i would agree that a hexdumper is too specific for java.base module. But what about hex encoding and parsing (similiar to java.util.Base64. Since java.xml.bind is no longer in the base modules an alternative for DataTypeConverter in SE is missing. Gruss Bernd -- http://bernd.eckenfels.net On Sat, Dec 10, 2016 at 9:13 PM +0100, "Roger Riggs" wrote: Hi Vinnie, I think this doesn't belong in the java.base module; it doesn't add enough value for a average developer and it is not essential to the core. I don't have another module suggestion but would suggest looking elsewhere. $.02, Roger On 12/9/2016 8:02 PM, Vincent Ryan wrote: > Thanks to those who provided review comments. > > I have incorporated most of them and updated the webrev: > http://cr.openjdk.java.net/~vinnie/8170769/webrev.01/ > > The main changes are to tighten up the javadoc spec and to add three additional methods > to support byte array ranges. The total number of public methods is now 7. > > I have not added support for InputStream or ByteBuffer. I think what we have in place is > sufficient for now and HexDump can be enhanced later if there is demand. > > The other issue is related to streams implementation and I?d like to defer that until later. > > > I think the API is in good shape now but please let me know if there are any must-fix API issues. > Otherwise I will consider the API finalised and move this forward. > > Thanks. > From andrej.golovnin at gmail.com Sat Dec 10 21:06:06 2016 From: andrej.golovnin at gmail.com (Andrej Golovnin) Date: Sat, 10 Dec 2016 22:06:06 +0100 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> <212B8ABE-78F1-4E96-8948-21CAA42B4E5D@oracle.com> Message-ID: <189DB4C4-131B-47D3-8C41-A2E8D58D3D89@gmail.com> Hi Vincent, 177 public static Stream dumpToStream(byte[] bytes, int fromIndex, 178 int toIndex) { 179 Objects.requireNonNull(bytes); 180 Arrays.rangeCheck(bytes.length, fromIndex, toIndex); 181 182 return StreamSupport.stream( 183 Spliterators.spliteratorUnknownSize( 184 new HexDumpIterator(bytes), 185 Spliterator.ORDERED | Spliterator.NONNULL), 186 false); 187 } I think the implementation of this method is broken as it ignores the values of the parameters fromIndex and toIndex. Please use char literals in the lines: 251 sb.append(" "); 262 sb.append(" "); 279 sb.append("|"); And I would add an empty line after the lines 325 and 326. The test should include tests for all public methods. And I think the test should also check that all public methods throw exceptions as described in the JavaDocs. Best regards, Andrej Golovnin > On 10 Dec 2016, at 02:02, Vincent Ryan wrote: > > Thanks to those who provided review comments. > > I have incorporated most of them and updated the webrev: > http://cr.openjdk.java.net/~vinnie/8170769/webrev.01/ > > The main changes are to tighten up the javadoc spec and to add three additional methods > to support byte array ranges. The total number of public methods is now 7. > > I have not added support for InputStream or ByteBuffer. I think what we have in place is > sufficient for now and HexDump can be enhanced later if there is demand. > > The other issue is related to streams implementation and I?d like to defer that until later. > > > I think the API is in good shape now but please let me know if there are any must-fix API issues. > Otherwise I will consider the API finalised and move this forward. > > Thanks. > From peter.levart at gmail.com Sat Dec 10 21:23:27 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sat, 10 Dec 2016 22:23:27 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> Message-ID: <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> On 12/10/2016 09:00 PM, Uwe Schindler wrote: > Hi, > > We noticed that buffers with zero length also have no cleaner. This is > why we also have the null check in our code (see Github) and the > guardWithTest in the MethodHandle, although we never free duplicates. > So a noop is better imho. Oh yes, good catch. Then what about being noop just for zero length? I don't know, maybe I'm just being paranoid and those who would use this API know perfectly well what they are doing. I'm just imagining a situation where one would create and keep just a duplicate of a direct buffer and afterwards use it to try to deallocate the native memory. This would be a noop, but the developer would think it works as GC would finally do it for him. I think it's better to throw an exception to prevent such situations... Regards, Peter > > I like the Unsafe approach. To me both variants are fine. > > Uwe > > Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart > : > > Hi Chris, > > > On 12/10/2016 06:11 PM, Chris Hegarty wrote: >> How about: Unsafe::deallocate(ByteBuffer directBuffer)? >> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > > Apart from the fact that Unsafe is (was?) reserved for low-level > stuff, I think this approach is reasonable. Is the method in > jdk.internal.misc.Unsafe needed? You could add the method just to > the sun.misc.Unsafe (to keep internal Unsafe free from hacks) and > export the two packages selectively to jdk.unsupported. > >> We could attempt to limit this to the direct buffer that "owns" the >> memory, i.e. not a duplicate or a slice, but I'm not sure it is worth >> it. > > What you have here *is* limited to direct ByteBuffer(s) that "own" > the memory. Derived buffer(s) (duplicated or sliced) do not have a > Cleaner instance (they have an 'attachment' to keep the 1st-level > buffer reachable while they are reachable). I would even make it > more unforgiving by throwing an IAE if the passed-in buffer didn't > have a Cleaner. In addition I would specify this behavior. For > example: > > "Deallocates the underlying memory associated with given > directBuffer if the buffer was obtained from either {@link > ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. In > any other case (when the buffer is not a direct buffer or was > obtained by {@link ByteBuffer#duplicate() duplicating} or {@link > ByteBuffer#slice(int, int) slicing} a direct buffer), the method > throws {@code IllegalArgumentException}. > > Regards, Peter > From masayoshi.okutsu at oracle.com Sun Dec 11 02:26:12 2016 From: masayoshi.okutsu at oracle.com (Masayoshi Okutsu) Date: Sun, 11 Dec 2016 11:26:12 +0900 Subject: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era In-Reply-To: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> Message-ID: <178ecdb7-cc41-1fcb-a4b3-c55eae2adeaa@oracle.com> Thank you for the review comments. I realized that only TextStyle.NARROW and NARROW_STANDALONE should return the abbreviation to be consistent with locale data. I've changed the implementation, which should have "fixed" the NPE issue, and added more test cases. Revised webrev: http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.01/ While I was testing more, I realized the default implementation of Era.getDisplayName doesn't work with non-IsoChronology. I filed new bug report JDK-8171049. Thanks, Masayoshi On 12/8/2016 5:55 PM, Masayoshi Okutsu wrote: > Hi, > > Please review the fix for JDK-8054214. It was necessary to override > Era::getDisplayName to get era names from the specified property. This > one fixes getAbbreviation() as well. > > Issue: > https://bugs.openjdk.java.net/browse/JDK-8054214 > > Webrev: > http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/ > > Thanks, > Masayoshi > From chris.hegarty at oracle.com Sun Dec 11 09:26:42 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Sun, 11 Dec 2016 09:26:42 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> Message-ID: <07D3F784-8976-4AB0-88B3-1E50C8DD0336@oracle.com> > On 10 Dec 2016, at 19:47, Peter Levart wrote: > > Hi Chris, > > On 12/10/2016 06:11 PM, Chris Hegarty wrote: >> How about: Unsafe::deallocate(ByteBuffer directBuffer)? >> >> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > > Apart from the fact that Unsafe is (was?) reserved for low-level stuff, I think this approach is reasonable. Is the method in jdk.internal.misc.Unsafe needed? You could add the method just to the sun.misc.Unsafe (to keep internal Unsafe free from hacks) and export the two packages selectively to jdk.unsupported. Yes, possibly. >> We could attempt to limit this to the direct buffer that "owns" the >> memory, i.e. not a duplicate or a slice, but I'm not sure it is worth >> it. >> > > What you have here *is* limited to direct ByteBuffer(s) that "own" the memory. Understood, what I meant was throwing an exception if the given buffer does not ?own? the memory. > Derived buffer(s) (duplicated or sliced) do not have a Cleaner instance (they have an 'attachment' to keep the 1st-level buffer reachable while they are reachable). I would even make it more unforgiving by throwing an IAE if the passed-in buffer didn't have a Cleaner. In addition I would specify this behavior. For example: > > "Deallocates the underlying memory associated with given directBuffer if the buffer was obtained from either {@link ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. In any other case (when the buffer is not a direct buffer or was obtained by {@link ByteBuffer#duplicate() duplicating} or {@link ByteBuffer#slice(int, int) slicing} a direct buffer), the method throws {@code IllegalArgumentException}. Yes, but given a ByteBuffer it is not possible to determine if it ?owns? the memory, or not. So users of the API would have to have full knowledge of the buffers they pass to it. Maybe this is ok? -Chris. From Alan.Bateman at oracle.com Sun Dec 11 11:16:33 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Sun, 11 Dec 2016 11:16:33 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> Message-ID: <4aea5baf-4a9d-6244-dc73-9dbb996a85ec@oracle.com> On 10/12/2016 17:11, Chris Hegarty wrote: > : > > How about: Unsafe::deallocate(ByteBuffer directBuffer)? > http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > The alternative is of course: ByteBuffer wrap(long address, int capacity) void unmap(MappedByteBuffer) The wrap method allow be similar to JNI's NewDirectByteBuffer for those that are managing the underlying memory themselves. This makes it a more advanced method to avoid too much temptation to free the memory underlying a buffer created with ByteBuffer.allocateDirect. We can't do much with unmap but that at least won't be widely used. -Alan. From uschindler at apache.org Sun Dec 11 12:57:26 2016 From: uschindler at apache.org (Uwe Schindler) Date: Sun, 11 Dec 2016 13:57:26 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> Message-ID: <006001d253ae$227fa010$677ee030$@apache.org> Hi, How about the following: - Check that the buffer is direct, if not throw IAE(?not direct buffer?) - Check that buffer has attachment==null (this tells you that it?s not a slice/dup), if not throw IAE(?not allowed to free duplicates/slices?) - Finally do the standard if (cleaner!=null) cleaner.clean(), but don?t throw any exceptions if cleaner is null (as this is implementation detail) This allows for empty buffers without cleaner that are still marked as direct. But it disallows all slices or duplicates. I am fine with Alan?s proposal to restrict to MappedByteBuffer but that?s out of my interest ? I am happy to unmap mapped byte buffers. I would also place the method in the legacy sun.misc.Unsafe only, the JDK-internal private one is not accessible to the outside. Of course for consistency it could be in both, but primarily it must be in sun.misc.Unsafe ? that?s also what most code is using anyways. Uwe From: Peter Levart [mailto:peter.levart at gmail.com] Sent: Saturday, December 10, 2016 10:23 PM To: Uwe Schindler ; Chris Hegarty Cc: jigsaw-dev at openjdk.java.net; Core-Libs-Dev Subject: Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch On 12/10/2016 09:00 PM, Uwe Schindler wrote: Hi, We noticed that buffers with zero length also have no cleaner. This is why we also have the null check in our code (see Github) and the guardWithTest in the MethodHandle, although we never free duplicates. So a noop is better imho. Oh yes, good catch. Then what about being noop just for zero length? I don't know, maybe I'm just being paranoid and those who would use this API know perfectly well what they are doing. I'm just imagining a situation where one would create and keep just a duplicate of a direct buffer and afterwards use it to try to deallocate the native memory. This would be a noop, but the developer would think it works as GC would finally do it for him. I think it's better to throw an exception to prevent such situations... Regards, Peter I like the Unsafe approach. To me both variants are fine. Uwe Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart : Hi Chris, On 12/10/2016 06:11 PM, Chris Hegarty wrote: How about: Unsafe::deallocate(ByteBuffer directBuffer)? http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ Apart from the fact that Unsafe is (was?) reserved for low-level stuff, I think this approach is reasonable. Is the method in jdk.internal.misc.Unsafe needed? You could add the method just to the sun.misc.Unsafe (to keep internal Unsafe free from hacks) and export the two packages selectively to jdk.unsupported. We could attempt to limit this to the direct buffer that "owns" the memory, i.e. not a duplicate or a slice, but I'm not sure it is worth it. What you have here *is* limited to direct ByteBuffer(s) that "own" the memory. Derived buffer(s) (duplicated or sliced) do not have a Cleaner instance (they have an 'attachment' to keep the 1st-level buffer reachable while they are reachable). I would even make it more unforgiving by throwing an IAE if the passed-in buffer didn't have a Cleaner. In addition I would specify this behavior. For example: "Deallocates the underlying memory associated with given directBuffer if the buffer was obtained from either {@link ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. In any other case (when the buffer is not a direct buffer or was obtained by {@link ByteBuffer#duplicate() duplicating} or {@link ByteBuffer#slice(int, int) slicing} a direct buffer), the method throws {@code IllegalArgumentException}. Regards, Peter From vincent.x.ryan at oracle.com Sun Dec 11 14:04:08 2016 From: vincent.x.ryan at oracle.com (Vincent Ryan) Date: Sun, 11 Dec 2016 14:04:08 +0000 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> <212B8ABE-78F1-4E96-8948-21CAA42B4E5D@oracle.com> Message-ID: Unfortunately this feature has arrived a little too late so I?m withdrawing it from consideration for JDK 9. Thanks again to those who took time to review it. > On 10 Dec 2016, at 01:02, Vincent Ryan wrote: > > Thanks to those who provided review comments. > > I have incorporated most of them and updated the webrev: > http://cr.openjdk.java.net/~vinnie/8170769/webrev.01/ > > The main changes are to tighten up the javadoc spec and to add three additional methods > to support byte array ranges. The total number of public methods is now 7. > > I have not added support for InputStream or ByteBuffer. I think what we have in place is > sufficient for now and HexDump can be enhanced later if there is demand. > > The other issue is related to streams implementation and I?d like to defer that until later. > > > I think the API is in good shape now but please let me know if there are any must-fix API issues. > Otherwise I will consider the API finalised and move this forward. > > Thanks. > From peter.levart at gmail.com Sun Dec 11 18:33:36 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 11 Dec 2016 19:33:36 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <07D3F784-8976-4AB0-88B3-1E50C8DD0336@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <07D3F784-8976-4AB0-88B3-1E50C8DD0336@oracle.com> Message-ID: <80123a1a-1c5a-f52b-ec54-afe9cb2829b4@gmail.com> Hi Chris, On 12/11/2016 10:26 AM, Chris Hegarty wrote: >> >"Deallocates the underlying memory associated with given directBuffer if the buffer was obtained from either {@link ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. In any other case (when the buffer is not a direct buffer or was obtained by {@link ByteBuffer#duplicate() duplicating} or {@link ByteBuffer#slice(int, int) slicing} a direct buffer), the method throws {@code IllegalArgumentException}. > Yes, but given a ByteBuffer it is not possible to determine if it ?owns? the > memory, or not. So users of the API would have to have full knowledge of > the buffers they pass to it. Maybe this is ok? > > -Chris. In order for deallocation to be effective and, above all, safe, user has to know the whole story of a buffer (s)he intends to deallocate and the story of all possible derived buffers. I don't believe one can create a safe program by choosing to deallocate a direct buffer for which (s)he does not know where it came from, because then (s)he also doesn't know what other buffers might still be using the same piece of memory. Regards, Peter From ivan.gerasimov at oracle.com Sun Dec 11 20:26:04 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 11 Dec 2016 23:26:04 +0300 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> References: <58441EC4.4090104@oracle.com> <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> Message-ID: <3e67db3c-4ebd-1889-b22d-b7f6a29d508c@oracle.com> Thank you Paul for the comments and suggestions! > Add a fix version of 10, then it?s clear on the intent. Once tests are > added :-) we can review for that release. Yes, right. I've set the fix version to 10 and also added the @since 10 tag. I've added a couple of test cases to `test/java/lang/Appendable/Basic.java`, or do you think the appendN() method worth more testing? > Personally i would use Arrays.fill, i gather the pattern is already recognised: > > https://bugs.openjdk.java.net/browse/JDK-4809552 > http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d64a8c7aa9d5 > > The advantage of using Arrays.fill is we know that the pattern will be recognized (if not it?s a bug, and i suppose it could be made intrinsic to wire up faster). (see -XX:+TraceOptimizeFill). I suspect we should review the filling optimization to see if it can be enhanced with newer SIMD instructions, as i gather the current implementation writes a max of 8 bytes at a time (with an explicit unrolled loop for 32 bytes at a time, containing 4 separate stores). Okay, I replaced the first loop with a call to Arrays.fill(). Benchmark shows that for size == 1 the overhead is bigger then for adding exactly one char in a loop. For anything longer it appears to be faster. Benchmark (size) Mode Cnt Score Error Units MyBenchmark.test_0_New 0 avgt 85 0.004 ? 0.001 us/op MyBenchmark.test_0_New 1 avgt 85 0.016 ? 0.003 us/op MyBenchmark.test_0_New 5 avgt 85 0.017 ? 0.003 us/op MyBenchmark.test_0_New 10 avgt 85 0.020 ? 0.004 us/op MyBenchmark.test_0_New 20 avgt 85 0.021 ? 0.004 us/op MyBenchmark.test_1_Old 0 avgt 85 0.004 ? 0.001 us/op MyBenchmark.test_1_Old 1 avgt 85 0.007 ? 0.001 us/op MyBenchmark.test_1_Old 5 avgt 85 0.029 ? 0.006 us/op MyBenchmark.test_1_Old 10 avgt 85 0.048 ? 0.010 us/op MyBenchmark.test_1_Old 20 avgt 85 0.099 ? 0.019 us/op MyBenchmark.test_2_Solid 0 avgt 85 0.008 ? 0.001 us/op MyBenchmark.test_2_Solid 1 avgt 85 0.015 ? 0.002 us/op MyBenchmark.test_2_Solid 5 avgt 85 0.026 ? 0.005 us/op MyBenchmark.test_2_Solid 10 avgt 85 0.031 ? 0.004 us/op MyBenchmark.test_2_Solid 20 avgt 85 0.028 ? 0.005 us/op > > It?s good that you found places in the JDK, that adds justification for such methods, especially for BigInteger and that static array of strings full of ?0? characters. > > The updates to MethodHandleImpl are not perf sensitive, i question the usage here but it does reduce stuff in the constant pool i suppose. I think it also improves readability, as it's clear now the amount of spaces added. With kind regards, Ivan From peter.levart at gmail.com Sun Dec 11 20:31:45 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 11 Dec 2016 21:31:45 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <006001d253ae$227fa010$677ee030$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> Message-ID: Hi Uwe, On 12/11/2016 01:57 PM, Uwe Schindler wrote: > > Hi, > > How about the following: > > -Check that the buffer is direct, if not throw IAE(?not direct buffer?) > > -Check that buffer has attachment==null (this tells you that it?s not > a slice/dup), if not throw IAE(?not allowed to free duplicates/slices?) > > -Finally do the standard if (cleaner!=null) cleaner.clean(), but don?t > throw any exceptions if cleaner is null (as this is implementation detail) > > This allows for empty buffers without cleaner that are still marked as > direct. But it disallows all slices or duplicates. > Yes, this would be the right logic I agree. It would silently ignore the requests to free memory for buffers constructed via JNI's NewDirectByteBuffer calls, but I suppose this would not be a problem in practice. > I am fine with Alan?s proposal to restrict to MappedByteBuffer but > that?s out of my interest ? I am happy to unmap mapped byte buffers. I > would also place the method in the legacy sun.misc.Unsafe only, the > JDK-internal private one is not accessible to the outside. Of course > for consistency it could be in both, but primarily it must be in > sun.misc.Unsafe ? that?s also what most code is using anyways. > Yes, internally, at least in java.base, the code can always directly invoke the DirectBuffer's and Cleaner's methods... Regards, Peter > Uwe > > *From:*Peter Levart [mailto:peter.levart at gmail.com] > *Sent:* Saturday, December 10, 2016 10:23 PM > *To:* Uwe Schindler ; Chris Hegarty > > *Cc:* jigsaw-dev at openjdk.java.net; Core-Libs-Dev > > *Subject:* Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > On 12/10/2016 09:00 PM, Uwe Schindler wrote: > > Hi, > > We noticed that buffers with zero length also have no cleaner. > This is why we also have the null check in our code (see Github) > and the guardWithTest in the MethodHandle, although we never free > duplicates. So a noop is better imho. > > > Oh yes, good catch. Then what about being noop just for zero length? I > don't know, maybe I'm just being paranoid and those who would use this > API know perfectly well what they are doing. I'm just imagining a > situation where one would create and keep just a duplicate of a direct > buffer and afterwards use it to try to deallocate the native memory. > This would be a noop, but the developer would think it works as GC > would finally do it for him. I think it's better to throw an exception > to prevent such situations... > > Regards, Peter > > > > I like the Unsafe approach. To me both variants are fine. > > Uwe > > Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart > : > > Hi Chris, > > On 12/10/2016 06:11 PM, Chris Hegarty wrote: > > How about: Unsafe::deallocate(ByteBuffer directBuffer)? > > http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > > > > Apart from the fact that Unsafe is (was?) reserved for > low-level stuff, I think this approach is reasonable. Is the > method in jdk.internal.misc.Unsafe needed? You could add the > method just to the sun.misc.Unsafe (to keep internal Unsafe > free from hacks) and export the two packages selectively to > jdk.unsupported. > > > We could attempt to limit this to the direct buffer that "owns" the > > memory, i.e. not a duplicate or a slice, but I'm not sure it is worth > > it. > > > What you have here *is* limited to direct ByteBuffer(s) that > "own" the memory. Derived buffer(s) (duplicated or sliced) do > not have a Cleaner instance (they have an 'attachment' to keep > the 1st-level buffer reachable while they are reachable). I > would even make it more unforgiving by throwing an IAE if the > passed-in buffer didn't have a Cleaner. In addition I would > specify this behavior. For example: > > "Deallocates the underlying memory associated with given > directBuffer if the buffer was obtained from either {@link > ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. > In any other case (when the buffer is not a direct buffer or > was obtained by {@link ByteBuffer#duplicate() duplicating} or > {@link ByteBuffer#slice(int, int) slicing} a direct buffer), > the method throws {@code IllegalArgumentException}. > > Regards, Peter > From ivan.gerasimov at oracle.com Sun Dec 11 20:35:26 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 11 Dec 2016 23:35:26 +0300 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <9cf64c84-f010-608f-33d1-3bce2e6e4381@Oracle.com> References: <58441EC4.4090104@oracle.com> <5022913b-1880-6b35-2b46-8b7f1b74293a@oracle.com> <4A44CC96-403A-4D6C-9A89-DBF3B3317935@oracle.com> <9cf64c84-f010-608f-33d1-3bce2e6e4381@Oracle.com> Message-ID: <1d976771-e6f9-bc49-7804-0cd18686b7b8@oracle.com> Thank you Roger for the comments! On 08.12.2016 1:28, Roger Riggs wrote: > Hi Ivan, > > A few comments... > > Appendable.appendN default method: > I'd expect many time n is small so allocating a new StringBuilder > every time seems > not optimal. A simple loop with append(c) would have fewer > (memory) side effects. > And in particular for n=0, it could avoid doing anything. > The rationale here was to implement `all or nothing` approach. If we add chars one by one in a loop and hit OOM, then the Appendable would be partially modified, which is not good. A special case for the size of zero can be added, of course. > AbstractStringBuilder: > I agree with Claes' comment suggesting that IAE for negative > lengths is a pain > and defining it to append 0 would be natural in many use cases. > I see that most votes are for throwing the exception if n is negative. Let's leave it this way! > MethodHandleImpl.toString(): > You could beneficially replace StringBuffer with StringBuilder > while you are there. > (and maybe pre-size the builder). > Sure, let's use StringBuilder. I wasn't sure how to easily calculate the required capacity of the builder here though. Please find the updated webrev here: http://cr.openjdk.java.net/~igerasim/8170348/01/webrev/ With kind regards, Ivan From ivan.gerasimov at oracle.com Sun Dec 11 20:50:21 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Sun, 11 Dec 2016 23:50:21 +0300 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: References: Message-ID: <055a7abc-bacc-6847-c0dd-5b1cb3d107c2@oracle.com> Thank you Jason for the comments! On 06.12.2016 20:09, Jason Mehrens wrote: > Ivan, > > Will java.util.StringJoiner be modified too? I assume a nCopies char sequence object doesn't pan out performance wise? I don't think I've seen many such uses of StringJoiner as adding the same sequence several times. I would hesitate to propose an addition to the API without being sure it's going to be used. With kind regards, Ivan From peter.levart at gmail.com Sun Dec 11 20:59:03 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 11 Dec 2016 21:59:03 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <4aea5baf-4a9d-6244-dc73-9dbb996a85ec@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <4aea5baf-4a9d-6244-dc73-9dbb996a85ec@oracle.com> Message-ID: <4f29ccda-e2db-2a61-446e-5208f3881d90@gmail.com> Hi Alan, On 12/11/2016 12:16 PM, Alan Bateman wrote: > > > On 10/12/2016 17:11, Chris Hegarty wrote: >> : >> >> How about: Unsafe::deallocate(ByteBuffer directBuffer)? >> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ >> > The alternative is of course: > > ByteBuffer wrap(long address, int capacity) > void unmap(MappedByteBuffer) > > The wrap method allow be similar to JNI's NewDirectByteBuffer for > those that are managing the underlying memory themselves. This makes > it a more advanced method to avoid too much temptation to free the > memory underlying a buffer created with ByteBuffer.allocateDirect. We > can't do much with unmap but that at least won't be widely used. > > -Alan. So, If I understand correctly, you are proposing users to do their own memory allocation/management/deallocation with Unsafe and use wrap() just to create a view of the allocated memory in the form of ByteBuffer. Wouldn't this force them to use a different approach to managing ByteBuffer(s) from what they do now - they would have to keep the allocated memory's address somewhere outside the buffer in order to free the memory later... It is doable, but I think Uwe will not like it very much. About unmap()... Is it just the name and signature that would discourage freeing memory underlying a buffer created with ByteBuffer.allocateDirect() or do you propose to disallow such use and only allow actual unmapping? Regards, Peter From ivan.gerasimov at oracle.com Sun Dec 11 21:03:02 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Mon, 12 Dec 2016 00:03:02 +0300 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: <2902b940-cacf-eb90-d384-de714c0c6d7e@gmail.com> References: <2902b940-cacf-eb90-d384-de714c0c6d7e@gmail.com> Message-ID: Thank you Peter for the suggestion! > An alternative to a new virtual method on Appendable (or maybe a > complement to it) could be a special internal CharSequence > implementation (CharRepetitions) with a static factory method on > CharSequence like the following: > I think it's a clever idea! Though it might be harder to implement the special optimized handling of such sequences by Appendable implementations outside java.lang. > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_Appendable.appendN.alt/webrev.01/ > > > Together with special-case optimization in > AbstractStringBuilder.append(CharSequence) it can perform equally well > when JITed. I took your benchmark and modified it a bit: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_Appendable.appendN.alt/AppendNTest.java > > > ...I moved sb.setLength(0) into a special @Setup method so that it > doesn't cause the remaining tested code to be over-optimized. You can > try just this change in your benchmark and you'll notice a difference. Actually, in the benchmark I tried to follow the suggestions found here: http://hg.openjdk.java.net/code-tools/jmh/file/ef24f1b5de08/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_38_PerInvokeSetup.java Note, how the Level.Invocation setup is avoided in the measureRight benchmark. With kind regards, Ivan From peter.levart at gmail.com Sun Dec 11 21:27:14 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 11 Dec 2016 22:27:14 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <4f29ccda-e2db-2a61-446e-5208f3881d90@gmail.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <4aea5baf-4a9d-6244-dc73-9dbb996a85ec@oracle.com> <4f29ccda-e2db-2a61-446e-5208f3881d90@gmail.com> Message-ID: <27d77c4b-2b2d-9b32-b84a-f6c47bf63e60@gmail.com> On 12/11/2016 09:59 PM, Peter Levart wrote: >> The alternative is of course: >> >> ByteBuffer wrap(long address, int capacity) >> void unmap(MappedByteBuffer) >> >> The wrap method allow be similar to JNI's NewDirectByteBuffer for >> those that are managing the underlying memory themselves. This makes >> it a more advanced method to avoid too much temptation to free the >> memory underlying a buffer created with ByteBuffer.allocateDirect. We >> can't do much with unmap but that at least won't be widely used. >> >> -Alan. > > So, If I understand correctly, you are proposing users to do their own > memory allocation/management/deallocation with Unsafe and use wrap() > just to create a view of the allocated memory in the form of > ByteBuffer. Wouldn't this force them to use a different approach to > managing ByteBuffer(s) from what they do now - they would have to keep > the allocated memory's address somewhere outside the buffer in order > to free the memory later... It is doable, but I think Uwe will not > like it very much. Sorry, I just realized that Uwe is interested only in the unmapping case... > > About unmap()... Is it just the name and signature that would > discourage freeing memory underlying a buffer created with > ByteBuffer.allocateDirect() or do you propose to disallow such use and > only allow actual unmapping? From peter.levart at gmail.com Sun Dec 11 22:14:43 2016 From: peter.levart at gmail.com (Peter Levart) Date: Sun, 11 Dec 2016 23:14:43 +0100 Subject: RFR 8170348: Appendable.appendN(char, int) method to append multiple copies of char In-Reply-To: References: <2902b940-cacf-eb90-d384-de714c0c6d7e@gmail.com> Message-ID: <04bc5099-9d81-49f2-2d53-75b253807c06@gmail.com> Hi Ivan, On 12/11/2016 10:03 PM, Ivan Gerasimov wrote: > Thank you Peter for the suggestion! > > >> An alternative to a new virtual method on Appendable (or maybe a >> complement to it) could be a special internal CharSequence >> implementation (CharRepetitions) with a static factory method on >> CharSequence like the following: >> > > I think it's a clever idea! > > Though it might be harder to implement the special optimized handling > of such sequences by Appendable implementations outside java.lang. You are right. But even without such optimization, appending of such sequence is still faster than appending a solid String although slower than optimized appendN(). > > >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_Appendable.appendN.alt/webrev.01/ >> >> >> Together with special-case optimization in >> AbstractStringBuilder.append(CharSequence) it can perform equally >> well when JITed. I took your benchmark and modified it a bit: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_Appendable.appendN.alt/AppendNTest.java >> >> >> ...I moved sb.setLength(0) into a special @Setup method so that it >> doesn't cause the remaining tested code to be over-optimized. You can >> try just this change in your benchmark and you'll notice a difference. > Actually, in the benchmark I tried to follow the suggestions found here: > http://hg.openjdk.java.net/code-tools/jmh/file/ef24f1b5de08/jmh-samples/src/main/java/org/openjdk/jmh/samples/JMHSample_38_PerInvokeSetup.java > > Note, how the Level.Invocation setup is avoided in the measureRight > benchmark. Ups, I missed that comment on Level.Invocation. I suspected that something was not right since the results were so different (appending seemed much slower).... So here are the results with sb.setLength(0) moved back to benchmark methods: Benchmark (size) Mode Cnt Score Error Units AppendNTest.test_0_New 0 avgt 10 2.380 ? 0.081 ns/op AppendNTest.test_0_New 1 avgt 10 4.323 ? 0.139 ns/op AppendNTest.test_0_New 5 avgt 10 9.233 ? 0.859 ns/op AppendNTest.test_0_New 10 avgt 10 8.977 ? 0.577 ns/op AppendNTest.test_0_New 20 avgt 10 9.454 ? 0.157 ns/op AppendNTest.test_1_Old 0 avgt 10 2.262 ? 0.282 ns/op AppendNTest.test_1_Old 1 avgt 10 4.534 ? 0.037 ns/op AppendNTest.test_1_Old 5 avgt 10 15.798 ? 0.734 ns/op AppendNTest.test_1_Old 10 avgt 10 29.086 ? 0.757 ns/op AppendNTest.test_1_Old 20 avgt 10 56.417 ? 6.240 ns/op AppendNTest.test_2_Solid 0 avgt 10 6.124 ? 0.112 ns/op AppendNTest.test_2_Solid 1 avgt 10 10.305 ? 0.084 ns/op AppendNTest.test_2_Solid 5 avgt 10 10.599 ? 0.109 ns/op AppendNTest.test_2_Solid 10 avgt 10 11.574 ? 0.716 ns/op AppendNTest.test_2_Solid 20 avgt 10 11.646 ? 0.878 ns/op AppendNTest.test_3_Repeat 0 avgt 10 2.514 ? 0.187 ns/op AppendNTest.test_3_Repeat 1 avgt 10 4.457 ? 0.096 ns/op AppendNTest.test_3_Repeat 5 avgt 10 7.744 ? 0.295 ns/op AppendNTest.test_3_Repeat 10 avgt 10 9.523 ? 1.507 ns/op AppendNTest.test_3_Repeat 20 avgt 10 9.195 ? 0.009 ns/op Still comparable. Regards, Peter > > With kind regards, > Ivan > From varming at gmail.com Sun Dec 11 22:19:28 2016 From: varming at gmail.com (Carsten Varming) Date: Sun, 11 Dec 2016 17:19:28 -0500 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <4aea5baf-4a9d-6244-dc73-9dbb996a85ec@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <4aea5baf-4a9d-6244-dc73-9dbb996a85ec@oracle.com> Message-ID: Dear Alan, On Sun, Dec 11, 2016 at 6:16 AM, Alan Bateman wrote: > > The alternative is of course: > > ByteBuffer wrap(long address, int capacity) > void unmap(MappedByteBuffer) > > The wrap method allow be similar to JNI's NewDirectByteBuffer for those > that are managing the underlying memory themselves. This makes it a more > advanced method to avoid too much temptation to free the memory underlying > a buffer created with ByteBuffer.allocateDirect. We can't do much with > unmap but that at least won't be widely used. I previously patched Netty to use the Runnable cleaner, so I have some interesting in this discussion. Having a public method "ByteBuffer wrap(long adddress, int capacity) in the standard would simplify Netty code. Netty currently use the cleaner on ByteBuffers allocated by ByteBuffer.allocateDirect, but I believe that can be changed. Carsten From huaming.li at oracle.com Mon Dec 12 01:41:19 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 12 Dec 2016 09:41:19 +0800 Subject: RFR of JDK-7195382: TEST_BUG: java/rmi/activation/CommandEnvironment/SetChildEnv.java can fail In-Reply-To: <9984a5f7-0002-2005-4ce2-15b7c5b34736@Oracle.com> References: <134bca0b-06b6-0fbb-2570-09bb1f14dcff@oracle.com> <3f6087ae-bbac-0631-5cae-99f7acf18d90@oracle.com> <9984a5f7-0002-2005-4ce2-15b7c5b34736@Oracle.com> Message-ID: <608bcf08-a099-bd99-d4b1-0502ccf4fee2@oracle.com> Hi Roger, Thank you for revewing. On 2016/12/9 23:36, Roger Riggs wrote: > Hi Hamlin, > > The patch looks fine but I would wrap the long @run lines. I was thinking it's easily for reviewer to compare different @run's with long lines, but modified as you suggested. > > Looking "-Djava.compiler=NONE" made me wonder why that was important > to the test. I had same thought, it's removed. The code is pushed after modified as you suggested. Thank you -Hamlin > > Roger > > > On 12/8/2016 10:07 PM, Hamlin Li wrote: >> Is some one available to review the patch? >> >> Thank you >> -Hamlin >> >> On 2016/12/8 11:07, Hamlin Li wrote: >>> Would you please review the below patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-7195382 >>> webrev: http://cr.openjdk.java.net/~mli/7195382/webrev.00/ >>> >>> what's changed? >>> * Use createRMIDOnEphemeralPort to avoid "port in use" exception. >>> * Because createRMIDOnEphemeralPort will choose different ports for >>> rmid for multiple runs, it will fail subsequent ActivationGroup >>> except of first run, so have to run 4 test cases in different JVM by >>> putting them in rather in separate "@run main/othervm". >>> * Put rmid.cleanup() in finally block to avoid orphan process bug. >>> * delete dead code. >>> >>> Thank you >>> -Hamlin >> > From amy.lu at oracle.com Mon Dec 12 02:07:07 2016 From: amy.lu at oracle.com (Amy Lu) Date: Mon, 12 Dec 2016 10:07:07 +0800 Subject: JDK 9 RFR of JDK-8023898: Consolidate Map tests Collisions and InPlaceOpsCollisions into general Map-based test In-Reply-To: <1A3C9513-C23C-4457-9D55-FB785614A5E8@oracle.com> References: <1A3C9513-C23C-4457-9D55-FB785614A5E8@oracle.com> Message-ID: Yes :-) Fixed for Collisions.testIntegerIteration and Collisions.testStringIteration: http://cr.openjdk.java.net/~amlu/8023898/webrev.02/ Thanks, Amy On 12/10/16 1:01 AM, Paul Sandoz wrote: > Hi Amy, > > A nice refactoring and clean up. > > For some test cases in Collisions you don?t need to obtain the array of keys, you just need to know the key length, which can be obtained from map.size(). > > Paul. > >> On 8 Dec 2016, at 19:19, Amy Lu wrote: >> >> Please review this test refactoring to map test Collisions and InPlaceOpsCollisions. >> >> These tests have (almost) same code for creating test data, and the test data can be reused cross tests. With converting to testng, test data creating is now done and provided by MapWithCollisionsProviders.java, and each test now uses explicit data provider, which makes test more clear. >> >> Other changes include: >> * Removed the redundant test Collections.testContainsKey and unnecessary map size check in the beginning of each test. >> * Replaced 'check' with testng assertion method. >> * Renaming and reformatting to make it more clear. >> >> bug:https://bugs.openjdk.java.net/browse/JDK-8023898 >> webrev:http://cr.openjdk.java.net/~amlu/8023898/webrev.01/ >> >> Thanks, >> Amy From huaming.li at oracle.com Mon Dec 12 04:43:54 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 12 Dec 2016 12:43:54 +0800 Subject: RFR of JDK-8166763: java/rmi/* tests fail intermittently with "Port already in use" in RMID.start() Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8166763 webrev: http://cr.openjdk.java.net/~mli/8166763/webrev.00/ Not all modified tests failed, the patch is to improve the test quality. Thank you -Hamlin From matcdac at gmail.com Mon Dec 12 08:17:14 2016 From: matcdac at gmail.com (Prakhar Makhija) Date: Mon, 12 Dec 2016 13:47:14 +0530 Subject: core-libs-dev Digest, Vol 116, Issue 47 In-Reply-To: References: Message-ID: Just want to clarify, would there be any *.mar file, as a module archive? On Dec 12, 2016 2:33 AM, wrote: > Send core-libs-dev mailing list submissions to > core-libs-dev at openjdk.java.net > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.openjdk.java.net/mailman/listinfo/core-libs-dev > or, via email, send a message with subject or body 'help' to > core-libs-dev-request at openjdk.java.net > > You can reach the person managing the list at > core-libs-dev-owner at openjdk.java.net > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of core-libs-dev digest..." > > > Today's Topics: > > 1. Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char (Ivan Gerasimov) > 2. Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch (Peter Levart) > 3. Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char (Ivan Gerasimov) > 4. Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char (Ivan Gerasimov) > 5. Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch (Peter Levart) > 6. Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char (Ivan Gerasimov) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 11 Dec 2016 23:26:04 +0300 > From: Ivan Gerasimov > To: Paul Sandoz > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char > Message-ID: <3e67db3c-4ebd-1889-b22d-b7f6a29d508c at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Thank you Paul for the comments and suggestions! > > > > Add a fix version of 10, then it?s clear on the intent. Once tests are > > added :-) we can review for that release. > > Yes, right. I've set the fix version to 10 and also added the @since 10 > tag. > I've added a couple of test cases to > `test/java/lang/Appendable/Basic.java`, or do you think the appendN() > method worth more testing? > > > Personally i would use Arrays.fill, i gather the pattern is already > recognised: > > > > https://bugs.openjdk.java.net/browse/JDK-4809552 > > http://hg.openjdk.java.net/hsx/hsx19/baseline/rev/d64a8c7aa9d5 > > > > The advantage of using Arrays.fill is we know that the pattern will be > recognized (if not it?s a bug, and i suppose it could be made intrinsic to > wire up faster). (see -XX:+TraceOptimizeFill). I suspect we should review > the filling optimization to see if it can be enhanced with newer SIMD > instructions, as i gather the current implementation writes a max of 8 > bytes at a time (with an explicit unrolled loop for 32 bytes at a time, > containing 4 separate stores). > > Okay, I replaced the first loop with a call to Arrays.fill(). > Benchmark shows that for size == 1 the overhead is bigger then for > adding exactly one char in a loop. > For anything longer it appears to be faster. > > Benchmark (size) Mode Cnt Score Error Units > MyBenchmark.test_0_New 0 avgt 85 0.004 ? 0.001 us/op > MyBenchmark.test_0_New 1 avgt 85 0.016 ? 0.003 us/op > MyBenchmark.test_0_New 5 avgt 85 0.017 ? 0.003 us/op > MyBenchmark.test_0_New 10 avgt 85 0.020 ? 0.004 us/op > MyBenchmark.test_0_New 20 avgt 85 0.021 ? 0.004 us/op > MyBenchmark.test_1_Old 0 avgt 85 0.004 ? 0.001 us/op > MyBenchmark.test_1_Old 1 avgt 85 0.007 ? 0.001 us/op > MyBenchmark.test_1_Old 5 avgt 85 0.029 ? 0.006 us/op > MyBenchmark.test_1_Old 10 avgt 85 0.048 ? 0.010 us/op > MyBenchmark.test_1_Old 20 avgt 85 0.099 ? 0.019 us/op > MyBenchmark.test_2_Solid 0 avgt 85 0.008 ? 0.001 us/op > MyBenchmark.test_2_Solid 1 avgt 85 0.015 ? 0.002 us/op > MyBenchmark.test_2_Solid 5 avgt 85 0.026 ? 0.005 us/op > MyBenchmark.test_2_Solid 10 avgt 85 0.031 ? 0.004 us/op > MyBenchmark.test_2_Solid 20 avgt 85 0.028 ? 0.005 us/op > > > > > It?s good that you found places in the JDK, that adds justification for > such methods, especially for BigInteger and that static array of strings > full of ?0? characters. > > > > The updates to MethodHandleImpl are not perf sensitive, i question the > usage here but it does reduce stuff in the constant pool i suppose. > I think it also improves readability, as it's clear now the amount of > spaces added. > > > With kind regards, > Ivan > > > > ------------------------------ > > Message: 2 > Date: Sun, 11 Dec 2016 21:31:45 +0100 > From: Peter Levart > To: Uwe Schindler , 'Chris Hegarty' > , Alan Bateman < > Alan.Bateman at oracle.com> > Cc: jigsaw-dev at openjdk.java.net, 'Core-Libs-Dev' > > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Uwe, > > > On 12/11/2016 01:57 PM, Uwe Schindler wrote: > > > > Hi, > > > > How about the following: > > > > -Check that the buffer is direct, if not throw IAE(?not direct buffer?) > > > > -Check that buffer has attachment==null (this tells you that it?s not > > a slice/dup), if not throw IAE(?not allowed to free duplicates/slices?) > > > > -Finally do the standard if (cleaner!=null) cleaner.clean(), but don?t > > throw any exceptions if cleaner is null (as this is implementation > detail) > > > > This allows for empty buffers without cleaner that are still marked as > > direct. But it disallows all slices or duplicates. > > > > Yes, this would be the right logic I agree. It would silently ignore the > requests to free memory for buffers constructed via JNI's > NewDirectByteBuffer calls, but I suppose this would not be a problem in > practice. > > > I am fine with Alan?s proposal to restrict to MappedByteBuffer but > > that?s out of my interest ? I am happy to unmap mapped byte buffers. I > > would also place the method in the legacy sun.misc.Unsafe only, the > > JDK-internal private one is not accessible to the outside. Of course > > for consistency it could be in both, but primarily it must be in > > sun.misc.Unsafe ? that?s also what most code is using anyways. > > > > Yes, internally, at least in java.base, the code can always directly > invoke the DirectBuffer's and Cleaner's methods... > > Regards, Peter > > > > Uwe > > > > *From:*Peter Levart [mailto:peter.levart at gmail.com] > > *Sent:* Saturday, December 10, 2016 10:23 PM > > *To:* Uwe Schindler ; Chris Hegarty > > > > *Cc:* jigsaw-dev at openjdk.java.net; Core-Libs-Dev > > > > *Subject:* Re: Java 9 build 148 causes trouble in Apache > > Lucene/Solr/Elasticsearch > > > > On 12/10/2016 09:00 PM, Uwe Schindler wrote: > > > > Hi, > > > > We noticed that buffers with zero length also have no cleaner. > > This is why we also have the null check in our code (see Github) > > and the guardWithTest in the MethodHandle, although we never free > > duplicates. So a noop is better imho. > > > > > > Oh yes, good catch. Then what about being noop just for zero length? I > > don't know, maybe I'm just being paranoid and those who would use this > > API know perfectly well what they are doing. I'm just imagining a > > situation where one would create and keep just a duplicate of a direct > > buffer and afterwards use it to try to deallocate the native memory. > > This would be a noop, but the developer would think it works as GC > > would finally do it for him. I think it's better to throw an exception > > to prevent such situations... > > > > Regards, Peter > > > > > > > > I like the Unsafe approach. To me both variants are fine. > > > > Uwe > > > > Am 10. Dezember 2016 20:47:46 MEZ schrieb Peter Levart > > : > > > > Hi Chris, > > > > On 12/10/2016 06:11 PM, Chris Hegarty wrote: > > > > How about: Unsafe::deallocate(ByteBuffer directBuffer)? > > > > http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > > > > > > > > Apart from the fact that Unsafe is (was?) reserved for > > low-level stuff, I think this approach is reasonable. Is the > > method in jdk.internal.misc.Unsafe needed? You could add the > > method just to the sun.misc.Unsafe (to keep internal Unsafe > > free from hacks) and export the two packages selectively to > > jdk.unsupported. > > > > > > We could attempt to limit this to the direct buffer that > "owns" the > > > > memory, i.e. not a duplicate or a slice, but I'm not sure it > is worth > > > > it. > > > > > > What you have here *is* limited to direct ByteBuffer(s) that > > "own" the memory. Derived buffer(s) (duplicated or sliced) do > > not have a Cleaner instance (they have an 'attachment' to keep > > the 1st-level buffer reachable while they are reachable). I > > would even make it more unforgiving by throwing an IAE if the > > passed-in buffer didn't have a Cleaner. In addition I would > > specify this behavior. For example: > > > > "Deallocates the underlying memory associated with given > > directBuffer if the buffer was obtained from either {@link > > ByteBuffer#allocateDirect} or {@link FileChannel#map} methods. > > In any other case (when the buffer is not a direct buffer or > > was obtained by {@link ByteBuffer#duplicate() duplicating} or > > {@link ByteBuffer#slice(int, int) slicing} a direct buffer), > > the method throws {@code IllegalArgumentException}. > > > > Regards, Peter > > > > > > ------------------------------ > > Message: 3 > Date: Sun, 11 Dec 2016 23:35:26 +0300 > From: Ivan Gerasimov > To: Roger Riggs , > core-libs-dev at openjdk.java.net > Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char > Message-ID: <1d976771-e6f9-bc49-7804-0cd18686b7b8 at oracle.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Thank you Roger for the comments! > > > On 08.12.2016 1:28, Roger Riggs wrote: > > Hi Ivan, > > > > A few comments... > > > > Appendable.appendN default method: > > I'd expect many time n is small so allocating a new StringBuilder > > every time seems > > not optimal. A simple loop with append(c) would have fewer > > (memory) side effects. > > And in particular for n=0, it could avoid doing anything. > > > The rationale here was to implement `all or nothing` approach. > If we add chars one by one in a loop and hit OOM, then the Appendable > would be partially modified, which is not good. > A special case for the size of zero can be added, of course. > > > AbstractStringBuilder: > > I agree with Claes' comment suggesting that IAE for negative > > lengths is a pain > > and defining it to append 0 would be natural in many use cases. > > > I see that most votes are for throwing the exception if n is negative. > Let's leave it this way! > > > MethodHandleImpl.toString(): > > You could beneficially replace StringBuffer with StringBuilder > > while you are there. > > (and maybe pre-size the builder). > > > Sure, let's use StringBuilder. > I wasn't sure how to easily calculate the required capacity of the > builder here though. > > Please find the updated webrev here: > http://cr.openjdk.java.net/~igerasim/8170348/01/webrev/ > > With kind regards, > Ivan > > > ------------------------------ > > Message: 4 > Date: Sun, 11 Dec 2016 23:50:21 +0300 > From: Ivan Gerasimov > To: Jason Mehrens , > "core-libs-dev at openjdk.java.net" > Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char > Message-ID: <055a7abc-bacc-6847-c0dd-5b1cb3d107c2 at oracle.com> > Content-Type: text/plain; charset=windows-1252; format=flowed > > Thank you Jason for the comments! > > > On 06.12.2016 20:09, Jason Mehrens wrote: > > Ivan, > > > > Will java.util.StringJoiner be modified too? I assume a nCopies char > sequence object doesn't pan out performance wise? > I don't think I've seen many such uses of StringJoiner as adding the > same sequence several times. > I would hesitate to propose an addition to the API without being sure > it's going to be used. > > With kind regards, > Ivan > > > > ------------------------------ > > Message: 5 > Date: Sun, 11 Dec 2016 21:59:03 +0100 > From: Peter Levart > To: Alan Bateman , Chris Hegarty > > Cc: jigsaw-dev at openjdk.java.net, Core-Libs-Dev > > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > Message-ID: <4f29ccda-e2db-2a61-446e-5208f3881d90 at gmail.com> > Content-Type: text/plain; charset=utf-8; format=flowed > > Hi Alan, > > > On 12/11/2016 12:16 PM, Alan Bateman wrote: > > > > > > On 10/12/2016 17:11, Chris Hegarty wrote: > >> : > >> > >> How about: Unsafe::deallocate(ByteBuffer directBuffer)? > >> http://cr.openjdk.java.net/~chegar/Unsafe_deallocate/ > >> > > The alternative is of course: > > > > ByteBuffer wrap(long address, int capacity) > > void unmap(MappedByteBuffer) > > > > The wrap method allow be similar to JNI's NewDirectByteBuffer for > > those that are managing the underlying memory themselves. This makes > > it a more advanced method to avoid too much temptation to free the > > memory underlying a buffer created with ByteBuffer.allocateDirect. We > > can't do much with unmap but that at least won't be widely used. > > > > -Alan. > > So, If I understand correctly, you are proposing users to do their own > memory allocation/management/deallocation with Unsafe and use wrap() > just to create a view of the allocated memory in the form of ByteBuffer. > Wouldn't this force them to use a different approach to managing > ByteBuffer(s) from what they do now - they would have to keep the > allocated memory's address somewhere outside the buffer in order to free > the memory later... It is doable, but I think Uwe will not like it very > much. > > About unmap()... Is it just the name and signature that would discourage > freeing memory underlying a buffer created with > ByteBuffer.allocateDirect() or do you propose to disallow such use and > only allow actual unmapping? > > Regards, Peter > > > > ------------------------------ > > Message: 6 > Date: Mon, 12 Dec 2016 00:03:02 +0300 > From: Ivan Gerasimov > To: Peter Levart , > core-libs-dev at openjdk.java.net > Subject: Re: RFR 8170348: Appendable.appendN(char, int) method to > append multiple copies of char > Message-ID: > Content-Type: text/plain; charset=utf-8; format=flowed > > Thank you Peter for the suggestion! > > > > An alternative to a new virtual method on Appendable (or maybe a > > complement to it) could be a special internal CharSequence > > implementation (CharRepetitions) with a static factory method on > > CharSequence like the following: > > > > I think it's a clever idea! > > Though it might be harder to implement the special optimized handling of > such sequences by Appendable implementations outside java.lang. > > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_ > Appendable.appendN.alt/webrev.01/ > > > > > > Together with special-case optimization in > > AbstractStringBuilder.append(CharSequence) it can perform equally well > > when JITed. I took your benchmark and modified it a bit: > > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170348_ > Appendable.appendN.alt/AppendNTest.java > > > > > > ...I moved sb.setLength(0) into a special @Setup method so that it > > doesn't cause the remaining tested code to be over-optimized. You can > > try just this change in your benchmark and you'll notice a difference. > Actually, in the benchmark I tried to follow the suggestions found here: > http://hg.openjdk.java.net/code-tools/jmh/file/ > ef24f1b5de08/jmh-samples/src/main/java/org/openjdk/jmh/ > samples/JMHSample_38_PerInvokeSetup.java > Note, how the Level.Invocation setup is avoided in the measureRight > benchmark. > > With kind regards, > Ivan > > > > End of core-libs-dev Digest, Vol 116, Issue 47 > ********************************************** > From Alan.Bateman at oracle.com Mon Dec 12 08:41:07 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Mon, 12 Dec 2016 08:41:07 +0000 Subject: core-libs-dev Digest, Vol 116, Issue 47 In-Reply-To: References: Message-ID: On 12/12/2016 08:17, Prakhar Makhija wrote: > Just want to clarify, would there be any *.mar file, as a module archive? > Modules can be packaged as JAR (or more specifically modular JAR files), there isn't any ".mar" file. If you have questions on packaging modules then best to bring them up on jigsaw-dev rather than replying to digests. -Alan From goetz.lindenmaier at sap.com Mon Dec 12 08:47:35 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Mon, 12 Dec 2016 08:47:35 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <584B3015.2070008@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <054e0fbbbff042349dc2bc555fdd5be5@DEROTE13DE08.global.corp.sap> <584B3015.2070008@oracle.com> Message-ID: <2a309ff038864c53a6b1073cc07d343e@DEROTE13DE08.global.corp.sap> Hi Joe, I'm not happy with this, but I'll remove the change to asin from my patch. Thanks for looking at it. Best regards, Goetz. > -----Original Message----- > From: Joseph D. Darcy [mailto:joe.darcy at oracle.com] > Sent: Freitag, 9. Dezember 2016 23:29 > To: Lindenmaier, Goetz > Cc: Java Core Libs > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > Hi Goetz, > > Please leave fdlibm asin alone as part of this change. The fdlibm > library has some anachronistic coding idioms and certainly at least in > this one case misleading code, but I'd prefer to leave the code as-is > until it is ported to Java. > > Thanks, > > -Joe > > On 12/8/2016 6:32 AM, Lindenmaier, Goetz wrote: > > Hi Joe, > > > > could you please have a look at my change to e_asin.c: > > http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.04/src/java.base/share/native/libfdlibm/e_asin.c.udiff.html > > > > The change conserves the situation, I just added {} and comments. > > I would appreciate to clean this up as it's hard to understand and our > > code scan does not like it the way it is. > > > > We had talked about this in my thread where I learned to read this code :) > > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- > December/045165.html > > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: Martin Buchholz [mailto:martinrb at google.com] > >> Sent: Mittwoch, 7. Dezember 2016 18:09 > >> To: Lindenmaier, Goetz ; Joe Darcy > >> > >> Cc: Dmitry Samersoff ; Java Core Libs > >> libs-dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> This changes fdlibm, which has historically been untouched. Don't commit > >> without Joe Darcy's approval. > >> > >> On Wed, Dec 7, 2016 at 7:26 AM, Lindenmaier, Goetz > >> > > wrote: > >> > >> > >> Hi Dmitry, > >> > >> yes, new_jvmpath is consistent with the other variables. > >> I also merged the ifs in SDE.c. > >> > >> new webrev: > >> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.03/ >> corlib_s11y/webrev.03/> > >> > >> Best regards, > >> Goetz. > >> > >> > -----Original Message----- > >> > From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com > >> ] > >> > Sent: Wednesday, December 07, 2016 2:43 PM > >> > To: Lindenmaier, Goetz >> >; Java Core Libs > >> > >> dev at openjdk.java.net> >; serviceability-dev (serviceability- > >> > dev at openjdk.java.net ) > >> >> dev at openjdk.java.net> > > >> > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >> servicabilty > >> > coding. > >> > > >> > >> > Goetz, > >> > > >> > SDE.c: > >> > > >> > You might combine if at ll. 260 and 263 to one but it's just matter of > >> test. > >> > > >> > if (sti == baseStratumIndex || sti < 0) { > >> > return; /* Java stratum - return unchanged */ > >> > } > >> > > >> > > I'm not sure what you mean. I tried to fix it, but please > >> > > double-check the new webrev. > >> > > >> > if cnt is <= 0 loop at l.267 > >> > > >> > for (; cnt-- > 0; ++fromEntry) { > >> > > >> > is never run and we effectively do > >> > > >> > *entryCountPtr = 0; > >> > > >> > at l.283 > >> > > >> > So if we you suspect that cnt may become negative or 0: > >> > (your v.01 changes) > >> > > >> > 260 if (sti < 0 && cnt > 0) { > >> > 261 return; > >> > 262 } > >> > > >> > it's better to check it early. > >> > > >> > But I'm not sure we have to care about negative/zero cnt here. > >> > > >> > -Dmitry > >> > > >> > On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >> > > Hi Dmitry, > >> > > > >> > > thanks for looking at my change! > >> > > Updated webrev: > >> > > http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.02 >> corlib_s11y/webrev.02> > >> > > > >> > >> * src/java.base/unix/native/libjli/java_md_solinux.c > >> > >> Is this line correct? > >> > >> 519 jvmpath = JLI_StringDup(jvmpath); > >> > > > >> > > It seems pointless. Should I remove it? (The whole file is a horror.) > >> > > > >> > >> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >> > >> It might be better to return immediately if cnt < 0, > >> > >> regardless of value of sti. > >> > > > >> > > I'm not sure what you mean. I tried to fix it, but please > >> > > double-check the new webrev. > >> > > > >> > >> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >> > >> It might be better to write > >> > >> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >> > >> and leave one copy of setsockopt() call > >> > > > >> > > Yes, looks better. > >> > > > >> > > Best regards, > >> > > Goetz > >> > > > >> > > > >> > >> > >> > >> -Dmitry > >> > >> > >> > >> > >> > >> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >> > >>> Hi, > >> > >>> > >> > >>> > >> > >>> > >> > >>> This change fixes some minor issues found in our code scans. > >> > >>> > >> > >>> I hope this correctly addresses corelib and serviceability issues. > >> > >>> > >> > >>> > >> > >>> > >> > >>> Please review: > >> > >>> > >> > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> > >> > corlib_s11y/webrev.01/ > >> > >>> > >> > >>> > >> > >>> > >> > >>> Best regards, > >> > >>> > >> > >>> Goetz. > >> > >>> > >> > >>> > >> > >>> > >> > >>> Changes in detail: > >> > >>> > >> > >>> > >> > >>> > >> > >>> e_asin.c > >> > >>> > >> > >>> Code scan reports missing {}. > >> > >>> > >> > >>> > >> > >>> The code "if (huge+x>one) {" is only there to set the inexact flag > >> of > >> > >>> the processor. > >> > >>> It's a way to avoid the C compiler to optimize the code away. It is > >> > >>> always true, > >> > >>> so the parenthesis of the outer else don't matter. > >> > >>> > >> > >>> Although this basically just adds the {} I would like to submit this > >> to > >> > >>> > >> > >>> avoid anybody else spends more the 30sec on understanding > >> these > >> > >>> > >> > >>> if statements. > >> > >>> > >> > >>> > >> > >>> k_standard.c > >> > >>> > >> > >>> exc.retval is returned below and thus should always be initialized. > >> > >>> > >> > >>> > >> > >>> imageDecompressor.cpp > >> > >>> > >> > >>> Wrong destructor is used. Reported also by David CARLIER > >> > >>> > >> > >>> > >> > >>> java.c > >> > >>> > >> > >>> in line 1865 'name' was used, it should be 'alias'. > >> > >>> > >> > >>> > >> > >>> java_md_solinux.c > >> > >>> > >> > >>> "//" in path is useless. Further down a free is missing. > >> > >>> > >> > >>> > >> > >>> SDE.c > >> > >>> > >> > >>> Call to stratumTableIndex can return negative value if > >> defaultStratumId > >> > >>> == null. > >> > >>> > >> > >>> > >> > >>> socket_md.c > >> > >>> > >> > >>> arg.l_linger is passed to setsockopt uninitialized. Its use is hidden > >> in > >> > >>> the macros. > >> > >>> > >> > >>> > >> > >>> unpack.cpp > >> > >>> > >> > >>> n.slice should not get negative argument for end, which is passed > >> from > >> > >>> dollar1. > >> > >>> But dollar1 can get negative where it is set to the result of > >> > >>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >> > >>> > >> > >> > >> > >> > >> > >> -- > >> > >> Dmitry Samersoff > >> > >> Oracle Java development team, Saint Petersburg, Russia > >> > >> * I would love to change the world, but they won't give me the > >> sources. > >> > > >> > > >> > -- > >> > Dmitry Samersoff > >> > Oracle Java development team, Saint Petersburg, Russia > >> > * I would love to change the world, but they won't give me the > >> sources. > >> > >> From huaming.li at oracle.com Mon Dec 12 08:48:45 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 12 Dec 2016 16:48:45 +0800 Subject: RFR of JDK-8171072: java/rmi/transport/handshake*/Handshake*.java, exception is not thrown when reach failure test case Message-ID: <755b0046-6c18-6b77-f24d-1dd782414abb@oracle.com> Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171072 webrev: http://cr.openjdk.java.net/~mli/8171072/webrev.00/ Thank you -Hamlin From weijun.wang at oracle.com Mon Dec 12 09:01:51 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 12 Dec 2016 17:01:51 +0800 Subject: RFR 8168979: @implNote for invalid FilePermission Message-ID: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8168979/webrev.00/ This further clarifies what an invalid FilePermission behaves. A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. Thanks Max From daniel.fuchs at oracle.com Mon Dec 12 10:03:29 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 12 Dec 2016 10:03:29 +0000 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Message-ID: Hi Max, Don't count me as reviewer - but I see a mismatched comment in the file: 209 /** 210 * Creates FilePermission objects with special internals. 211 * See {@link FilePermCompat#newPermPlusAltPath(Permission)} and 212 * {@link FilePermCompat#newPermUsingAltPath(Permission)}. 213 */ 214 215 private static final Path here = builtInFS.getPath( 216 GetPropertyAction.privilegedGetProperty("user.dir")); I guess the comment is a left over from some merge or previous fix? Also I noticed the following later on: 541 * invalid {@code FilePermission}. Even if two {@code FilePermission} 542 * are created with the same invalid path, one does imply the other. should this be: Even if two {@code FilePermission} are created with the same invalid path, one does *not* imply the other. best regards, -- daniel On 12/12/16 09:01, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8168979/webrev.00/ > > This further clarifies what an invalid FilePermission behaves. A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. > > Thanks > Max > From chris.hegarty at oracle.com Mon Dec 12 10:11:20 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 12 Dec 2016 10:11:20 +0000 Subject: RFR of JDK-8166763: java/rmi/* tests fail intermittently with "Port already in use" in RMID.start() In-Reply-To: References: Message-ID: <90b57f24-e61d-f173-ca10-947e87b7947b@oracle.com> Looks good Hamlin. -Chris. On 12/12/16 04:43, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8166763 > webrev: http://cr.openjdk.java.net/~mli/8166763/webrev.00/ > > Not all modified tests failed, the patch is to improve the test quality. > > Thank you > -Hamlin From weijun.wang at oracle.com Mon Dec 12 14:07:15 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Mon, 12 Dec 2016 22:07:15 +0800 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Message-ID: > On Dec 12, 2016, at 6:03 PM, Daniel Fuchs wrote: > > Hi Max, > > Don't count me as reviewer - but I see a mismatched comment > in the file: > > 209 /** > 210 * Creates FilePermission objects with special internals. > 211 * See {@link FilePermCompat#newPermPlusAltPath(Permission)} and > 212 * {@link FilePermCompat#newPermUsingAltPath(Permission)}. > 213 */ > 214 > 215 private static final Path here = builtInFS.getPath( > 216 GetPropertyAction.privilegedGetProperty("user.dir")); > > I guess the comment is a left over from some merge or previous fix? These are 2 different methods: "Plus" and "Using". > > > Also I noticed the following later on: > > 541 * invalid {@code FilePermission}. Even if two {@code FilePermission} > 542 * are created with the same invalid path, one does imply the other. > > should this be: > > Even if two {@code FilePermission} are created with the same > invalid path, one does *not* imply the other. Ah, yes. Thanks Max > > best regards, > > -- daniel > > On 12/12/16 09:01, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8168979/webrev.00/ >> >> This further clarifies what an invalid FilePermission behaves. A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. >> >> Thanks >> Max >> > From peter.levart at gmail.com Mon Dec 12 15:10:10 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 12 Dec 2016 16:10:10 +0100 Subject: Review Request JDK-8170772: ResourceBundle improper caching causes tools/javadoc tests intermittently In-Reply-To: References: Message-ID: <887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com> Hi Mandy (once again for the list), On 12/09/2016 05:49 PM, Mandy Chung wrote: > Naoto, > > Can you review this ResourceBundle caching fix? The caller module > may be different than the specified module to > ResourceBundle.getBundle(String, Module) method and it should also > part of the cache key. > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ > > The new test shows the issue there and the first loading of the > resource bundle of a specific module (success or fail) will be put in > the cache and used by subsequent calls. > > Thanks Mandy I think that now callerModule is part of CacheKey, caching logic could be simplified. 1st the getBundleImpl method in line 1629: private static ResourceBundle getBundleImpl(String baseName, Locale locale, Class caller, ClassLoader loader, Control control) { if (caller != null && caller.getModule().isNamed()) { Module module = caller.getModule(); ClassLoader ml = getLoader(module); // get resource bundles for a named module only // if loader is the module's class loader if (loader == ml || (ml == null && loader == RBClassLoader.INSTANCE)) { return getBundleImpl(module, module, loader, baseName, locale, control); } } // find resource bundles from unnamed module Module unnamedModule = loader != null ? loader.getUnnamedModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); if (caller == null) { throw new InternalError("null caller"); } Module callerModule = caller.getModule(); return getBundleImpl(callerModule, unnamedModule, loader, baseName, locale, control); } ... could be cleaned up a bit without changing its semantics: private static ResourceBundle getBundleImpl(String baseName, Locale locale, Class caller, ClassLoader loader, Control control) { if (caller == null) { throw new InternalError("null caller"); } Module callerModule = caller.getModule(); if (callerModule.isNamed()) { ClassLoader ml = getLoader(callerModule); // get resource bundles for a named module only // if loader is the module's class loader if (loader == ml || (ml == null && loader == RBClassLoader.INSTANCE)) { return getBundleImpl(callerModule, callerModule, loader, baseName, locale, control); } } // find resource bundles from unnamed module Module unnamedModule = loader != null ? loader.getUnnamedModule() : ClassLoader.getSystemClassLoader().getUnnamedModule(); return getBundleImpl(callerModule, unnamedModule, loader, baseName, locale, control); } Next, I checked all callers of this method (there are 3 of them in lines: 1367, 1589, 1615) and all of them guard against passing a null 'loader' to this method: @CallerSensitive public static ResourceBundle getBundle(String baseName, Locale locale, ClassLoader loader) { if (loader == null) { throw new NullPointerException(); } Class caller = Reflection.getCallerClass(); return getBundleImpl(baseName, locale, caller, loader, getDefaultControl(caller, baseName)); } ... @CallerSensitive public static ResourceBundle getBundle(String baseName, Locale targetLocale, ClassLoader loader, Control control) { if (loader == null || control == null) { throw new NullPointerException(); } Class caller = Reflection.getCallerClass(); checkNamedModule(caller); return getBundleImpl(baseName, targetLocale, caller, loader, control); } ... private static ResourceBundle getBundleImpl(String baseName, Locale locale, Class caller, Control control) { return getBundleImpl(baseName, locale, caller, getLoader(caller), control); } private static ClassLoader getLoader(Class caller) { ClassLoader cl = caller == null ? null : caller.getClassLoader(); if (cl == null) { // When the caller's loader is the boot class loader, cl is null // here. In that case, ClassLoader.getSystemClassLoader() may // return the same class loader that the application is // using. We therefore use a wrapper ClassLoader to create a // separate scope for bundles loaded on behalf of the Java // runtime so that these bundles cannot be returned from the // cache to the application (5048280). cl = RBClassLoader.INSTANCE; } return cl; } Therefore the above method can be simplified further: private static ResourceBundle getBundleImpl(String baseName, Locale locale, Class caller, ClassLoader loader, Control control) { if (caller == null) { throw new InternalError("null caller"); } if (loader == null) { throw new InternalError("null loader"); } Module callerModule = caller.getModule(); if (callerModule.isNamed()) { ClassLoader ml = getLoader(callerModule); // get resource bundles for a named module only // if loader is the module's class loader if (loader == ml || (ml == null && loader == RBClassLoader.INSTANCE)) { return getBundleImpl(callerModule, callerModule, loader, baseName, locale, control); } } // find resource bundles from unnamed module Module unnamedModule = loader.getUnnamedModule(); return getBundleImpl(callerModule, unnamedModule, loader, baseName, locale, control); } ...here we can see that (callerModule, module, loader) triple passed to downstream getBundleImpl is either (callerModule, callerModule, callerModule's class loader) - with a RBClassLoader.INSTANCE substitute for bootstrap class loader, when the callerModule is a named module and requested loader is the callerModule's loader, or (callerModule, loader's unnamed module, loader) when loader is not callerModule's loader or callerModule is unnamed. other two callers of the downstream getBundleImpl are the JavaUtilResourceBundleAccess method: public ResourceBundle getBundle(String baseName, Locale locale, Module module) { // use the given module as the caller to bypass the access check return getBundleImpl(module, module, getLoader(module), baseName, locale, Control.INSTANCE); } ...which is used in logging - the module passed here can be either named or unnamed; ... and a method invoked from new JDK 9 public getBundle() methods taking explicit Module argument: private static ResourceBundle getBundleFromModule(Class caller, Module module, String baseName, Locale locale, Control control) { Objects.requireNonNull(module); Module callerModule = caller.getModule(); if (callerModule != module) { SecurityManager sm = System.getSecurityManager(); if (sm != null) { sm.checkPermission(GET_CLASSLOADER_PERMISSION); } } return getBundleImpl(callerModule, module, getLoader(module), baseName, locale, control); } In all of these cases, the loader passed to downstream getBundleImpl is the module's (2nd argument 'module') class loader (or a special substitute for bootstrap loader). Considering all this, I think class loader is not needed any more as the CacheKey component. The distinction between scopes of system class loader (when the caller is not a bootstrap class) and the RBClassLoader.INSTANCE (when the caller is the bootstrap class) is also not needed any more since the callerModule is now part of CacheKey. I modified your patch (just ResourceBundle.java) to include all these simplifications and some cleanup: http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/ This modification also contains a re-interpretation of clearCache() methods. Both existing clearCahe() methods together with the additional @since 9 method contain the following wording: "Removes all resource bundles from the cache that have been loaded by the caller's / given module..." What does it meant for a bundle to be loaded *by* some module? I think the right interpretation is that this is the caller module (the one that invokes ResourceBundle.getBundle() method). The module that calls ResourceBundle.getBundle() is usually also the module that is responsible for clearing the cache of entries that were cached by its loading requests, isn't it? So, what do you think? Regards, Peter From paul.sandoz at oracle.com Mon Dec 12 16:11:40 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Dec 2016 08:11:40 -0800 Subject: [9] RFR 8170769: Provide a simple hexdump facility for binary data In-Reply-To: References: <612F9783-14DE-479F-B5B2-9EE59A1015E6@oracle.com> <0612eabe-7dfe-aee7-a5df-7502fb7450dc@oracle.com> <212B8ABE-78F1-4E96-8948-21CAA42B4E5D@oracle.com> Message-ID: <25DB8A60-1AEA-4616-B0BA-7786D3CDEC66@oracle.com> > On 11 Dec 2016, at 06:04, Vincent Ryan wrote: > > Unfortunately this feature has arrived a little too late so I?m withdrawing it from consideration for JDK 9. > Thanks again to those who took time to review it. > +1 to defer to 10 (and review comments are of course not wasted). Paul. From eric at tibco.com Sat Dec 10 06:42:01 2016 From: eric at tibco.com (Eric Johnson) Date: Fri, 9 Dec 2016 22:42:01 -0800 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <015101d25272$ff7717b0$fe654710$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <015101d25272$ff7717b0$fe654710$@apache.org> Message-ID: On 12/9/16 3:21 PM, Uwe Schindler wrote: > The -Dsun.reflect.debugModuleAccessChecks=true options help to debug, indeed, but it does not solve the underlying issue. Apache Solr/Lucene and Elasticsearch will no longer work with Java 9 unless you require users to add those strange options. Elasticsearch already runs with a SecurityManager by default, so the question is: why is this not handled by a security manager and a new permission like "crossModuleAccess/module/package"? Why must it be done on command line? This makes it impossible to ship something like Lucene that it work out of box together with correct policy files? I've asked the question multiple times on this list, about what the threat model analysis is behind this new level of runtime "security". Alas, no answers so far. Eric. From paul.sandoz at oracle.com Mon Dec 12 18:59:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 12 Dec 2016 10:59:18 -0800 Subject: JDK 9 RFR of JDK-8023898: Consolidate Map tests Collisions and InPlaceOpsCollisions into general Map-based test In-Reply-To: References: <1A3C9513-C23C-4457-9D55-FB785614A5E8@oracle.com> Message-ID: > On 11 Dec 2016, at 18:07, Amy Lu wrote: > > Yes :-) > > Fixed for Collisions.testIntegerIteration and Collisions.testStringIteration: > http://cr.openjdk.java.net/~amlu/8023898/webrev.02/ > +1 Paul. From huizhe.wang at oracle.com Mon Dec 12 19:13:30 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 12 Dec 2016 11:13:30 -0800 Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 Message-ID: <584EF6DA.8080307@oracle.com> Hi, This was the cleanup portion of the change for JDK-8167340. As Lance suggested, it was split from the original webrev. In addition to that cleanup, I've added coverage to the entire StAX packages. This cleanup will reduce 138 warnings. jbs: https://bugs.openjdk.java.net/browse/JDK-8170556 webrev: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ Thanks, Joe From joe.darcy at oracle.com Tue Dec 13 00:35:50 2016 From: joe.darcy at oracle.com (Joseph D. Darcy) Date: Mon, 12 Dec 2016 16:35:50 -0800 Subject: JDK 9 RFR of JDK-8171131: Problem list ModuleNamesOrderTest.java until JDK-8171070 is fixed Message-ID: <584F4266.8040105@oracle.com> Hello, The test tools/jlink/ModuleNamesOrderTest.java has been seen to fail intermittently on different platforms. Until JDK-8171070 is fixed, the test should be problem listed. (Without having deeply investigated the issue, it looks like more @compile and @build directives are needed here.) Patch below. Thanks, -Joe diff -r 5a6a97703855 test/ProblemList.txt --- a/test/ProblemList.txt Mon Dec 12 14:40:56 2016 +0000 +++ b/test/ProblemList.txt Mon Dec 12 16:35:01 2016 -0800 @@ -263,6 +263,8 @@ tools/jimage/JImageListTest.java 8169713 generic-all tools/jimage/JImageVerifyTest.java 8169713 generic-all +tools/jlink/ModuleNamesOrderTest.java 8171070 generic-all + ############################################################################ # jdk_jdi From mandy.chung at oracle.com Tue Dec 13 00:40:46 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Dec 2016 16:40:46 -0800 Subject: JDK 9 RFR of JDK-8171131: Problem list ModuleNamesOrderTest.java until JDK-8171070 is fixed In-Reply-To: <584F4266.8040105@oracle.com> References: <584F4266.8040105@oracle.com> Message-ID: <058EA721-4274-475F-BF3B-AEF3634E345F@oracle.com> +1 Mandy > On Dec 12, 2016, at 4:35 PM, Joseph D. Darcy wrote: > > Hello, > > The test > > tools/jlink/ModuleNamesOrderTest.java > > has been seen to fail intermittently on different platforms. Until JDK-8171070 is fixed, the test should be problem listed. > > (Without having deeply investigated the issue, it looks like more @compile and @build directives are needed here.) > > Patch below. > > Thanks, > > -Joe > > diff -r 5a6a97703855 test/ProblemList.txt > --- a/test/ProblemList.txt Mon Dec 12 14:40:56 2016 +0000 > +++ b/test/ProblemList.txt Mon Dec 12 16:35:01 2016 -0800 > @@ -263,6 +263,8 @@ > tools/jimage/JImageListTest.java 8169713 generic-all > tools/jimage/JImageVerifyTest.java 8169713 generic-all > > +tools/jlink/ModuleNamesOrderTest.java 8171070 generic-all > + > ############################################################################ > > # jdk_jdi > From mandy.chung at oracle.com Tue Dec 13 05:09:10 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 12 Dec 2016 21:09:10 -0800 Subject: Review Request JDK-8170772: ResourceBundle improper caching causes tools/javadoc tests intermittently In-Reply-To: <887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com> References: <887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com> Message-ID: > On Dec 12, 2016, at 7:10 AM, Peter Levart wrote: > > : > Considering all this, I think class loader is not needed any more as the CacheKey component. The distinction between scopes of system class loader (when the caller is not a bootstrap class) and the RBClassLoader.INSTANCE (when the caller is the bootstrap class) is also not needed any more since the callerModule is now part of CacheKey. > I believe this is true. I was tempted to remove class loader from the CacheKey at one point. Resource bundles are hard to diagnose and I don?t know how good our test cases are. I decided to leave it for the owner of resource bundles to clean this up. I filed a JBS issue to track this: https://bugs.openjdk.java.net/browse/JDK-8171139 > I modified your patch (just ResourceBundle.java) to include all these simplifications and some cleanup: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/ > > > This modification also contains a re-interpretation of clearCache() methods. Both existing clearCahe() methods together with the additional @since 9 method contain the following wording: > > "Removes all resource bundles from the cache that have been loaded by the caller's / given module..." > > What does it meant for a bundle to be loaded *by* some module? I think the right interpretation is that this is the caller module (the one that invokes ResourceBundle.getBundle() method). The module that calls ResourceBundle.getBundle() is usually also the module that is responsible for clearing the cache of entries that were cached by its loading requests, isn't it? Good catch. I file https://bugs.openjdk.java.net/browse/JDK-8171140 . I will look into it. Mandy From huaming.li at oracle.com Tue Dec 13 05:11:55 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 13 Dec 2016 13:11:55 +0800 Subject: RFR of JDK-8171076: improve rmi tests by replacing TestLibrary.createRegistryOnUnusedPort, getUnusedRandomPort Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171076 webrev: http://cr.openjdk.java.net/~mli/8171076/webrev.00/ There are rmi tests using TestLibrary.createRegistryOnUnusedPort, getUnusedRandomPort, registry created by these 2 methods could cause "port in use" exception intermittently. For some of the tests, these 2 methods can and should be replaced with createRegistryOnEphemeralPort and getRegistryPort. Although not all the modified tests failed, it will help improve rmi test quality by replacing these methods. Because of JDK-8170728, we can not relay the call of createRegistryOnUnusedPort to createRegistryOnEphemeralPort, because some test are calling createRegistryOnUnusedPort more than once. Thank you -Hamlin From huaming.li at oracle.com Tue Dec 13 05:19:32 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 13 Dec 2016 13:19:32 +0800 Subject: RFR of JDK-8171072: java/rmi/transport/handshake*/Handshake*.java, exception is not thrown when reach failure test case In-Reply-To: <755b0046-6c18-6b77-f24d-1dd782414abb@oracle.com> References: <755b0046-6c18-6b77-f24d-1dd782414abb@oracle.com> Message-ID: Is some one available to review the patch? Thank you -Hamlin On 2016/12/12 16:48, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8171072 > webrev: http://cr.openjdk.java.net/~mli/8171072/webrev.00/ > > Thank you > -Hamlin From amy.lu at oracle.com Tue Dec 13 05:47:08 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 13 Dec 2016 13:47:08 +0800 Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64 In-Reply-To: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> Message-ID: Kindly reminder. On 12/5/16 4:23 PM, Amy Lu wrote: > java/io/pathNames/GeneralWin32.java > > When tests run concurrently (-conc:N), it?s possible that this test > will walk into and does some testing on other test?s working dir, > other than it?s own. > > Please review the patch to avoid this unexpected behavior by > restricting the "checkNames" to test's own working directory. > > bug: https://bugs.openjdk.java.net/browse/JDK-8156595 > webrev: http://cr.openjdk.java.net/~amlu/8156595/webrev.00 > > Thanks, > Amy From daniel.fuchs at oracle.com Tue Dec 13 10:14:00 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 13 Dec 2016 10:14:00 +0000 Subject: Review Request JDK-8170772: ResourceBundle improper caching causes tools/javadoc tests intermittently In-Reply-To: <887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com> References: <887b1af3-decf-5a9e-6577-4b2781e8183c@gmail.com> Message-ID: <0f17689a-84a6-7508-6802-6f440de93161@oracle.com> Hi Peter, This is a bold proposal, I would be frightened to touch at this code :-) Good observations about the simplifications induced by taking the caller's module as part of the cache key (in particular getting rid of RBClassLoader.INSTANCE). I have imported your patch (had to fight a bit because it includes changes that had already been pushed) and sent it through our internal testing system - and haven't seen any new failures that seemed linked to resource bundles. A few observations concerning CacheKey - if I'm not mistaken most of the key variables could be made final (in particular callerRef and moduleRef) - and since they are required to be non null - then getModule() and getCallerModule() could be simplified. Not sure whether making those final might require to add a copy constructor to support clone() though? It seems CacheKey::setName is never called - but it's probably safer to keep it (maybe it's called by tests). I am not an expert of ResourceBundle - though I had to dive into it a few times due it's use in logging. Hopefully others will jump on this. best regards, -- daniel On 12/12/16 15:10, Peter Levart wrote: > Hi Mandy (once again for the list), > > On 12/09/2016 05:49 PM, Mandy Chung wrote: >> Naoto, > > Can you review this ResourceBundle caching fix? The >> caller module >> may be different than the specified module to > > ResourceBundle.getBundle(String, Module) method and it should also > > part of the cache key. > > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8170772/webrev.00/ > > > The new test shows the issue there and the first loading of the > > resource bundle of a specific module (success or fail) will be put in > > the cache and used by subsequent calls. > > Thanks Mandy > > > I think that now callerModule is part of CacheKey, caching logic could > be simplified. 1st the getBundleImpl method in line 1629: > > private static ResourceBundle getBundleImpl(String baseName, > Locale locale, > Class caller, > ClassLoader loader, > Control control) { > if (caller != null && caller.getModule().isNamed()) { > Module module = caller.getModule(); > ClassLoader ml = getLoader(module); > // get resource bundles for a named module only > // if loader is the module's class loader > if (loader == ml || (ml == null && loader == > RBClassLoader.INSTANCE)) { > return getBundleImpl(module, module, loader, baseName, > locale, control); > } > } > // find resource bundles from unnamed module > Module unnamedModule = loader != null > ? loader.getUnnamedModule() > : ClassLoader.getSystemClassLoader().getUnnamedModule(); > > if (caller == null) { > throw new InternalError("null caller"); > } > > Module callerModule = caller.getModule(); > return getBundleImpl(callerModule, unnamedModule, loader, > baseName, locale, control); > } > > > ... could be cleaned up a bit without changing its semantics: > > private static ResourceBundle getBundleImpl(String baseName, > Locale locale, > Class caller, > ClassLoader loader, > Control control) { > if (caller == null) { > throw new InternalError("null caller"); > } > Module callerModule = caller.getModule(); > > if (callerModule.isNamed()) { > ClassLoader ml = getLoader(callerModule); > // get resource bundles for a named module only > // if loader is the module's class loader > if (loader == ml || (ml == null && loader == > RBClassLoader.INSTANCE)) { > return getBundleImpl(callerModule, callerModule, loader, > baseName, locale, control); > } > } > > // find resource bundles from unnamed module > Module unnamedModule = loader != null > ? loader.getUnnamedModule() > : ClassLoader.getSystemClassLoader().getUnnamedModule(); > > return getBundleImpl(callerModule, unnamedModule, loader, > baseName, locale, control); > } > > > Next, I checked all callers of this method (there are 3 of them in > lines: 1367, 1589, 1615) and all of them guard against passing a null > 'loader' to this method: > > @CallerSensitive > public static ResourceBundle getBundle(String baseName, Locale locale, > ClassLoader loader) > { > if (loader == null) { > throw new NullPointerException(); > } > Class caller = Reflection.getCallerClass(); > return getBundleImpl(baseName, locale, caller, loader, > getDefaultControl(caller, baseName)); > } > > ... > > @CallerSensitive > public static ResourceBundle getBundle(String baseName, Locale > targetLocale, > ClassLoader loader, Control > control) { > if (loader == null || control == null) { > throw new NullPointerException(); > } > Class caller = Reflection.getCallerClass(); > checkNamedModule(caller); > return getBundleImpl(baseName, targetLocale, caller, loader, > control); > } > > ... > > private static ResourceBundle getBundleImpl(String baseName, > Locale locale, > Class caller, > Control control) { > return getBundleImpl(baseName, locale, caller, > getLoader(caller), control); > } > > private static ClassLoader getLoader(Class caller) { > ClassLoader cl = caller == null ? null : caller.getClassLoader(); > if (cl == null) { > // When the caller's loader is the boot class loader, cl is > null > // here. In that case, ClassLoader.getSystemClassLoader() may > // return the same class loader that the application is > // using. We therefore use a wrapper ClassLoader to create a > // separate scope for bundles loaded on behalf of the Java > // runtime so that these bundles cannot be returned from the > // cache to the application (5048280). > cl = RBClassLoader.INSTANCE; > } > return cl; > } > > > Therefore the above method can be simplified further: > > private static ResourceBundle getBundleImpl(String baseName, > Locale locale, > Class caller, > ClassLoader loader, > Control control) { > if (caller == null) { > throw new InternalError("null caller"); > } > if (loader == null) { > throw new InternalError("null loader"); > } > Module callerModule = caller.getModule(); > > if (callerModule.isNamed()) { > ClassLoader ml = getLoader(callerModule); > // get resource bundles for a named module only > // if loader is the module's class loader > if (loader == ml || (ml == null && loader == > RBClassLoader.INSTANCE)) { > return getBundleImpl(callerModule, callerModule, loader, > baseName, locale, control); > } > } > > // find resource bundles from unnamed module > Module unnamedModule = loader.getUnnamedModule(); > return getBundleImpl(callerModule, unnamedModule, loader, > baseName, locale, control); > } > > > > ...here we can see that (callerModule, module, loader) triple passed to > downstream getBundleImpl is either (callerModule, callerModule, > callerModule's class loader) - with a RBClassLoader.INSTANCE substitute > for bootstrap class loader, when the callerModule is a named module and > requested loader is the callerModule's loader, or (callerModule, > loader's unnamed module, loader) when loader is not callerModule's > loader or callerModule is unnamed. > > other two callers of the downstream getBundleImpl are the > JavaUtilResourceBundleAccess method: > > public ResourceBundle getBundle(String baseName, Locale > locale, Module module) { > // use the given module as the caller to bypass the > access check > return getBundleImpl(module, module, getLoader(module), > baseName, locale, > Control.INSTANCE); > } > > ...which is used in logging - the module passed here can be either named > or unnamed; > > ... and a method invoked from new JDK 9 public getBundle() methods > taking explicit Module argument: > > private static ResourceBundle getBundleFromModule(Class caller, > Module module, > String baseName, > Locale locale, > Control control) { > Objects.requireNonNull(module); > Module callerModule = caller.getModule(); > if (callerModule != module) { > SecurityManager sm = System.getSecurityManager(); > if (sm != null) { > sm.checkPermission(GET_CLASSLOADER_PERMISSION); > } > } > return getBundleImpl(callerModule, module, getLoader(module), > baseName, locale, control); > } > > In all of these cases, the loader passed to downstream getBundleImpl is > the module's (2nd argument 'module') class loader (or a special > substitute for bootstrap loader). > > Considering all this, I think class loader is not needed any more as the > CacheKey component. The distinction between scopes of system class > loader (when the caller is not a bootstrap class) and the > RBClassLoader.INSTANCE (when the caller is the bootstrap class) is also > not needed any more since the callerModule is now part of CacheKey. > > I modified your patch (just ResourceBundle.java) to include all these > simplifications and some cleanup: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/ > > > > This modification also contains a re-interpretation of clearCache() > methods. Both existing clearCahe() methods together with the additional > @since 9 method contain the following wording: > > "Removes all resource bundles from the cache that have been loaded by > the caller's / given module..." > > What does it meant for a bundle to be loaded *by* some module? I think > the right interpretation is that this is the caller module (the one that > invokes ResourceBundle.getBundle() method). The module that calls > ResourceBundle.getBundle() is usually also the module that is > responsible for clearing the cache of entries that were cached by its > loading requests, isn't it? > > So, what do you think? > > Regards, Peter > From scolebourne at joda.org Tue Dec 13 13:24:35 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 13 Dec 2016 13:24:35 +0000 Subject: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era In-Reply-To: <178ecdb7-cc41-1fcb-a4b3-c55eae2adeaa@oracle.com> References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> <178ecdb7-cc41-1fcb-a4b3-c55eae2adeaa@oracle.com> Message-ID: The overridden method includes full Javadoc and an @since 9 tag. I believe that this Javadoc should not be present and the @since tag is wrong. Stephen On 11 December 2016 at 02:26, Masayoshi Okutsu wrote: > Thank you for the review comments. I realized that only TextStyle.NARROW and > NARROW_STANDALONE should return the abbreviation to be consistent with > locale data. I've changed the implementation, which should have "fixed" the > NPE issue, and added more test cases. > > Revised webrev: > http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.01/ > > While I was testing more, I realized the default implementation of > Era.getDisplayName doesn't work with non-IsoChronology. I filed new bug > report JDK-8171049. > > Thanks, > Masayoshi > > > On 12/8/2016 5:55 PM, Masayoshi Okutsu wrote: >> >> Hi, >> >> Please review the fix for JDK-8054214. It was necessary to override >> Era::getDisplayName to get era names from the specified property. This one >> fixes getAbbreviation() as well. >> >> Issue: >> https://bugs.openjdk.java.net/browse/JDK-8054214 >> >> Webrev: >> http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/ >> >> Thanks, >> Masayoshi >> > From Roger.Riggs at Oracle.com Tue Dec 13 14:34:37 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Dec 2016 09:34:37 -0500 Subject: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era In-Reply-To: References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> <178ecdb7-cc41-1fcb-a4b3-c55eae2adeaa@oracle.com> Message-ID: <8e829145-9bca-7c86-1024-426f08843c80@Oracle.com> Hi Masayoshi, looks fine; (without the javadoc) Roger On 12/13/2016 8:24 AM, Stephen Colebourne wrote: > The overridden method includes full Javadoc and an @since 9 tag. I > believe that this Javadoc should not be present and the @since tag is > wrong. > > Stephen > > > On 11 December 2016 at 02:26, Masayoshi Okutsu > wrote: >> Thank you for the review comments. I realized that only TextStyle.NARROW and >> NARROW_STANDALONE should return the abbreviation to be consistent with >> locale data. I've changed the implementation, which should have "fixed" the >> NPE issue, and added more test cases. >> >> Revised webrev: >> http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.01/ >> >> While I was testing more, I realized the default implementation of >> Era.getDisplayName doesn't work with non-IsoChronology. I filed new bug >> report JDK-8171049. >> >> Thanks, >> Masayoshi >> >> >> On 12/8/2016 5:55 PM, Masayoshi Okutsu wrote: >>> Hi, >>> >>> Please review the fix for JDK-8054214. It was necessary to override >>> Era::getDisplayName to get era names from the specified property. This one >>> fixes getAbbreviation() as well. >>> >>> Issue: >>> https://bugs.openjdk.java.net/browse/JDK-8054214 >>> >>> Webrev: >>> http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/ >>> >>> Thanks, >>> Masayoshi >>> From frank.yuan at oracle.com Tue Dec 13 14:55:48 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Tue, 13 Dec 2016 22:55:48 +0800 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName; " even if "entities" property is false Message-ID: <022601d25550$ff1a1610$fd4e4230$@oracle.com> Hi all Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ is for JDK-8087303 and JDK-8114834, I have to combine the fix because there is some interaction between them. Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 https://bugs.openjdk.java.net/browse/JDK-8114834 Besides fixed some issues in xml serializer, I made the following changes in this patch: 1. refined the handling for whitespace text 2. added support for xml:space attribute 3. changed the default indentation to 4 4. refined the handling for HTML block element and inline element Would you like to have a look at this review? Thanks, Frank From Roger.Riggs at Oracle.com Tue Dec 13 14:57:22 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Dec 2016 09:57:22 -0500 Subject: RFR of JDK-8171072: java/rmi/transport/handshake*/Handshake*.java, exception is not thrown when reach failure test case In-Reply-To: References: <755b0046-6c18-6b77-f24d-1dd782414abb@oracle.com> Message-ID: <91367e0b-20cd-4166-5c12-a36340d50df6@Oracle.com> Hi Hamlin, Sorry for the delay. Looks fine. Roger On 12/13/2016 12:19 AM, Hamlin Li wrote: > Is some one available to review the patch? > > Thank you > -Hamlin > > On 2016/12/12 16:48, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8171072 >> webrev: http://cr.openjdk.java.net/~mli/8171072/webrev.00/ >> >> Thank you >> -Hamlin > From Roger.Riggs at Oracle.com Tue Dec 13 15:05:09 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 13 Dec 2016 10:05:09 -0500 Subject: RFR of JDK-8171076: improve rmi tests by replacing TestLibrary.createRegistryOnUnusedPort, getUnusedRandomPort In-Reply-To: References: Message-ID: <88b3e58a-842c-4639-8688-5bc3816f6c7a@Oracle.com> Hi Hamlin, Looks fine. Thanks, Roger On 12/13/2016 12:11 AM, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8171076 > webrev: http://cr.openjdk.java.net/~mli/8171076/webrev.00/ > > There are rmi tests using TestLibrary.createRegistryOnUnusedPort, > getUnusedRandomPort, registry created by these 2 methods could cause > "port in use" exception intermittently. For some of the tests, these 2 > methods can and should be replaced with createRegistryOnEphemeralPort > and getRegistryPort. > Although not all the modified tests failed, it will help improve rmi > test quality by replacing these methods. > > Because of JDK-8170728, we can not relay the call of > createRegistryOnUnusedPort to createRegistryOnEphemeralPort, because > some test are calling createRegistryOnUnusedPort more than once. > > Thank you > -Hamlin From amanda.jiang at oracle.com Tue Dec 13 19:06:54 2016 From: amanda.jiang at oracle.com (Amanda Jiang) Date: Tue, 13 Dec 2016 11:06:54 -0800 Subject: RFR 8171179: Problem list LFSingleThreadCachingTest.java until JDK-8171149 is fixed Message-ID: <83c33539-2a95-7bf4-e53a-ae0a9e1c64d3@oracle.com> Hi All, The test java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java is failing on tier 1 platforms. UntilJDK-8171149 is fixed, the test should be problem listed. Please review the patch below: diff -r 6f76a77638cb test/ProblemList.txt --- a/test/ProblemList.txt Tue Dec 13 11:28:45 2016 +0800 +++ b/test/ProblemList.txt Tue Dec 13 10:52:46 2016 -0800 @@ -124,6 +124,7 @@ # jdk_lang java/lang/StringCoding/CheckEncodings.sh 7008363 generic-all +java/lang/invoke/LFCaching/LFSingleThreadCachingTest.java 8171149 generic-all ############################################################################ Thanks, Amanda From chris.hegarty at oracle.com Tue Dec 13 19:47:07 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Tue, 13 Dec 2016 19:47:07 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> Message-ID: Taking into account the feedback so far, and changing the method name ( since it is an attractive nuisance ), here is where I think we ended up. http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ If this is agreeable, I?ll file an issue in JIRA to track the code changes, and update JEP 260. -Chris. From christoph.langer at sap.com Tue Dec 13 20:31:06 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 13 Dec 2016 20:31:06 +0000 Subject: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type Message-ID: <3f0ee9feb8f9427a86efd4b4482a9b62@DEWDFE13DE03.global.corp.sap> Hi, this is the fix for the regression introduced with 8150704. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169112.0/ The problem occurs during "outlining" of a translet method. Outlining happens when the size of bytecode for a translet method exceeds the bytecode limit per method imposed by Java and means splitting the code into smaller methods. 8150704 added the new local variable "_domAdapter" to the implementation of "WithParam" without setting the end of its scope. This somehow leads to issues in outlining and the local variable in the new method might be loaded without being initialized. The problem is not observed for smaller translets where probably outlining is not performed. Shall I create a new jtreg test from the example attached to the bug? I would just run the sample transformation and the test is passed when no exception occurs. Best regards Christoph From brent.christian at oracle.com Tue Dec 13 20:53:01 2016 From: brent.christian at oracle.com (Brent Christian) Date: Tue, 13 Dec 2016 12:53:01 -0800 Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint In-Reply-To: <12e7a48c-f8ec-bb3b-9875-e9d31d84d784@oracle.com> References: <584885AA.9060202@oracle.com> <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com> <584B578A.1030508@oracle.com> <12e7a48c-f8ec-bb3b-9875-e9d31d84d784@oracle.com> Message-ID: <58505FAD.6060404@oracle.com> Thank you, Mandy and Daniel. As a point of interest, automated testing uncovered a couple things I had to change before pushing: http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/accf1676e416 * Updated the CHECK_OFFSET line, so fastdebug builds http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ddc8f2ae290b * In the test case, only check for a classloader named 'app' if we are using the system classloader. This is usually the case, but not when running regtests using the 'make' target (URLClassLoader). Thanks, -Brent On 12/10/2016 06:51 AM, Daniel Fuchs wrote: > Hi Brent, > > This looks really good now! > > best regards, > > -- daniel > > On 10/12/16 01:16, Brent Christian wrote: >> On 12/07/2016 04:05 PM, Mandy Chung wrote: >>> >>> I suggest to add two utility methods rather than the has method: >>> boolean dropClassLoaderName() >>> boolean dropModuleVersion() >> >> Done. >> >>> 430 if (m != null && m.isNamed() && >>> 431 (isHashedInJavaBase(m) || >>> !m.getDescriptor().version().isPresent())) { >>> 432 bits |= JDK_NON_UPGRADEABLE_MODULE; >>> 433 } >>> >>> I think this should simply be: >>> if (isHashedInJavaBase(m)) {..} >>> >> >> Done. >> >>> Can you retain the javadoc of toLoaderModuleClassName, revised if >>> appropriate, in the computeFormat method? >> >> Updated. >> >>> line 322-325: what about: >>> >>> The toString method may return two different values on two >>> StackTraceElement instances that are equal for example when >>> one created via the constructor and one obtained from Throwable >>> or StackFrame where an implementation may choose to omit some >>> element in the returned string. >> >> That sounds good. >> >>> Is @apiNote in equals necessary? Maybe the one added in toString is >>> adequate? >> >> I'm fine without it - removed. >> >> >> I also fixed test code for a case which only works with the images build. >> >> Updated webrev: >> http://cr.openjdk.java.net/~bchristi/8169389/webrev.04/ >> >> -Brent > From uschindler at apache.org Tue Dec 13 21:17:25 2016 From: uschindler at apache.org (Uwe Schindler) Date: Tue, 13 Dec 2016 22:17:25 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> Message-ID: <031501d25586$4f828c60$ee87a520$@apache.org> Hi, +1 to this approach. I can create a PR for Apache Lucene to test this! With our current code it is very easy to add support for this - which is great (at the end I just need a MethodHandle with a MethodType "(ByteBuffer)void")! Unfortunately I am not good in compiling OpenJDK, so if somebody could provide me a patched build for windows or linux, I'd be happy. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Tuesday, December 13, 2016 8:47 PM > To: Core-Libs-Dev ; jigsaw-dev dev at openjdk.java.net>; Uwe Schindler ; Peter > Levart > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Taking into account the feedback so far, and changing the method name ( > since > it is an attractive nuisance ), here is where I think we ended up. > > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > If this is agreeable, I?ll file an issue in JIRA to track the code changes, and > update JEP 260. > > -Chris.= From peter.levart at gmail.com Tue Dec 13 21:18:17 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 13 Dec 2016 22:18:17 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> Message-ID: I think this is OK. Just a couple of nits in test: 1. You create a static Path bob = Paths.get("bob") field, but then you don't use it in: 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), CREATE, WRITE)) { 2. badBuffers could include a duplicate and a slice of a direct buffer allocated with ByteBuffer.allocateDirect() 3. The comment in the test is referencing the old method name: 26 * @summary Basic test for Unsafe::deallocate Regards, Peter On 12/13/2016 08:47 PM, Chris Hegarty wrote: > Taking into account the feedback so far, and changing the method name ( since > it is an attractive nuisance ), here is where I think we ended up. > > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > If this is agreeable, I?ll file an issue in JIRA to track the code changes, and > update JEP 260. > > -Chris. From naoto.sato at oracle.com Tue Dec 13 21:31:23 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Tue, 13 Dec 2016 13:31:23 -0800 Subject: RFR: 8054214: JapaneseEra.getDisplayName doesn't return names if it's an additional era In-Reply-To: <8e829145-9bca-7c86-1024-426f08843c80@Oracle.com> References: <19defa12-d6fe-dde3-7ca2-dee89dee2d58@oracle.com> <178ecdb7-cc41-1fcb-a4b3-c55eae2adeaa@oracle.com> <8e829145-9bca-7c86-1024-426f08843c80@Oracle.com> Message-ID: <5d64a820-a2b3-7af1-0334-22633ba9c320@oracle.com> +1 Naoto On 12/13/16 6:34 AM, Roger Riggs wrote: > Hi Masayoshi, > > looks fine; (without the javadoc) > > Roger > > > On 12/13/2016 8:24 AM, Stephen Colebourne wrote: >> The overridden method includes full Javadoc and an @since 9 tag. I >> believe that this Javadoc should not be present and the @since tag is >> wrong. >> >> Stephen >> >> >> On 11 December 2016 at 02:26, Masayoshi Okutsu >> wrote: >>> Thank you for the review comments. I realized that only >>> TextStyle.NARROW and >>> NARROW_STANDALONE should return the abbreviation to be consistent with >>> locale data. I've changed the implementation, which should have >>> "fixed" the >>> NPE issue, and added more test cases. >>> >>> Revised webrev: >>> http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.01/ >>> >>> While I was testing more, I realized the default implementation of >>> Era.getDisplayName doesn't work with non-IsoChronology. I filed new bug >>> report JDK-8171049. >>> >>> Thanks, >>> Masayoshi >>> >>> >>> On 12/8/2016 5:55 PM, Masayoshi Okutsu wrote: >>>> Hi, >>>> >>>> Please review the fix for JDK-8054214. It was necessary to override >>>> Era::getDisplayName to get era names from the specified property. >>>> This one >>>> fixes getAbbreviation() as well. >>>> >>>> Issue: >>>> https://bugs.openjdk.java.net/browse/JDK-8054214 >>>> >>>> Webrev: >>>> http://cr.openjdk.java.net/~okutsu/9/8054214/webrev.00/ >>>> >>>> Thanks, >>>> Masayoshi >>>> > From christoph.langer at sap.com Tue Dec 13 22:14:46 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Tue, 13 Dec 2016 22:14:46 +0000 Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 In-Reply-To: <584EF6DA.8080307@oracle.com> References: <584EF6DA.8080307@oracle.com> Message-ID: <1efbdc1c876f48788eda832dce3b3d8f@DEWDFE13DE03.global.corp.sap> Hi Joe, looks nice, thanks for doing that. Here are a few findings: src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java: -> import statements could be ordered alphabetically 262 fEntityScanner = fEntityManager.getEntityScanner() ; -> spaces before ; 1317 protected List getEntityDecls(){ -> space before opening { 1322 if(entities.size() > 0){ -> spaces after if, before { 1344 protected List getNotationDecls(){ -> space before { 1352 if(notation!= null){ -> spaces src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java 145 } 146 /** -> insert blank line in between src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java 734 public List getNotationDecls(){ -> blank before { src/java.xml/share/classes/com/sun/xml/internal/stream/events/DTDEvent.java 66 public void setEntities(List entites){ -> space before {; variable name entites -> entities 77 public void setNotations(List notations){ -> space 94 protected final void init(){ -> space src/java.xml/share/classes/com/sun/xml/internal/stream/events/EndElementEvent.java -> order import statements alphabetically 48 QName fQName ; -> space 105 void addNamespace(Namespace ns){ -> space 106 if(ns != null){ -> spaces src/java.xml/share/classes/com/sun/xml/internal/stream/events/StartElementEvent.java -> import statements order, a few space issues src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java 68 public void add(javax.xml.stream.XMLEventReader xMLEventReader) throws XMLStreamException { 80 public void add(javax.xml.stream.events.XMLEvent xMLEvent) throws XMLStreamException { -> you should be able to use unqualified names for parameters src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java 906 ElementState elem; 907 908 while (!fElementStack.empty()) { 909 elem = fElementStack.pop(); -> I think elem can be declared in line 909 as well, scope is only within while() block Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Joe Wang > Sent: Montag, 12. Dezember 2016 20:14 > To: core-libs-dev at openjdk.java.net > Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 > > Hi, > > This was the cleanup portion of the change for JDK-8167340. As Lance > suggested, it was split from the original webrev. In addition to that > cleanup, I've added coverage to the entire StAX packages. This cleanup > will reduce 138 warnings. > > jbs: https://bugs.openjdk.java.net/browse/JDK-8170556 > webrev: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ > > Thanks, > Joe From huizhe.wang at oracle.com Tue Dec 13 22:17:52 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 13 Dec 2016 14:17:52 -0800 Subject: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type In-Reply-To: <3f0ee9feb8f9427a86efd4b4482a9b62@DEWDFE13DE03.global.corp.sap> References: <3f0ee9feb8f9427a86efd4b4482a9b62@DEWDFE13DE03.global.corp.sap> Message-ID: <58507390.3040009@oracle.com> Hi Christoph, For the test, yes, please add an unit test based on the test submitted, sanitize / remove any private information in the original test where necessary. Best regards, Joe On 12/13/16, 12:31 PM, Langer, Christoph wrote: > > Hi, > > this is the fix for the regression introduced with 8150704. Please review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169112.0/ > > > The problem occurs during "outlining" of a translet method. Outlining > happens when the size of bytecode for a translet method exceeds the > bytecode limit per method imposed by Java and means splitting the code > into smaller methods. 8150704 added the new local variable > "_domAdapter" to the implementation of "WithParam" without setting the > end of its scope. This somehow leads to issues in outlining and the > local variable in the new method might be loaded without being > initialized. The problem is not observed for smaller translets where > probably outlining is not performed. > > Shall I create a new jtreg test from the example attached to the bug? > I would just run the sample transformation and the test is passed when > no exception occurs. > > Best regards > > Christoph > From lance.andersen at oracle.com Tue Dec 13 22:35:04 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Tue, 13 Dec 2016 17:35:04 -0500 Subject: RFR: 8169806 - DriverManager javadoc clarifications Message-ID: Hi all, This review request addresses some a cleanup to the DriverManager javadocs. The CCC for the changes has been approved. The webrev can be found at http://cr.openjdk.java.net/~lancea/8169806/webrev.03/ Best, Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From aleksej.efimov at oracle.com Tue Dec 13 23:02:30 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 14 Dec 2016 02:02:30 +0300 Subject: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance Message-ID: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> Hello, Please, help to review the changes that addresses the file system contention caused by debug code in XPathFactoryFinder and XPathFactoryFinder classes [1]. Proposed fix wraps the debug output code in "if(debug)" block: http://cr.openjdk.java.net/~aefimov/8146271/9/00/ Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8146271 From martinrb at google.com Tue Dec 13 23:13:57 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 13 Dec 2016 15:13:57 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 Message-ID: We were supposed to be winding down jdk9, and there are a lot of changes here, but ... it would be a shame not to have fast specialized implementations for new collection methods added in Java 8. There's also a fix for a serious bug in LinkedBlockingQueue. http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ As with wave 12, very collection oriented. From huizhe.wang at oracle.com Wed Dec 14 00:35:09 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 13 Dec 2016 16:35:09 -0800 Subject: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance In-Reply-To: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> References: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> Message-ID: <585093BD.1020904@oracle.com> Hi Aleksej, You may want to improve the debugPrintln or its usage to remove the String concatenations or method calls such as f.getClass().getName() that are unnecessary when debug == false. Where we are here, could you expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) where similar problems exist. Best, Joe On 12/13/16, 3:02 PM, Aleks Efimov wrote: > Hello, > > Please, help to review the changes that addresses the file system > contention caused by debug code in XPathFactoryFinder and > XPathFactoryFinder classes [1]. Proposed fix wraps the debug output > code in "if(debug)" block: > http://cr.openjdk.java.net/~aefimov/8146271/9/00/ > > Best Regards, > Aleksej > > [1] https://bugs.openjdk.java.net/browse/JDK-8146271 > From huizhe.wang at oracle.com Wed Dec 14 00:42:00 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 13 Dec 2016 16:42:00 -0800 Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 In-Reply-To: <1efbdc1c876f48788eda832dce3b3d8f@DEWDFE13DE03.global.corp.sap> References: <584EF6DA.8080307@oracle.com> <1efbdc1c876f48788eda832dce3b3d8f@DEWDFE13DE03.global.corp.sap> Message-ID: <58509558.8070607@oracle.com> Thanks Christoph! I updated the webrev for the classes you mentioned below, in a few cases, used NetBeans' source format feature -- not for all of the classes though (esp. the crazily large XMLDocumentFragmentScannerImpl.java, it gets better though, overtime). http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ Best regards, Joe On 12/13/16, 2:14 PM, Langer, Christoph wrote: > Hi Joe, > > looks nice, thanks for doing that. > > Here are a few findings: > > src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java: > -> import statements could be ordered alphabetically > 262 fEntityScanner = fEntityManager.getEntityScanner() ; > -> spaces before ; > 1317 protected List getEntityDecls(){ > -> space before opening { > 1322 if(entities.size()> 0){ > -> spaces after if, before { > 1344 protected List getNotationDecls(){ > -> space before { > 1352 if(notation!= null){ > -> spaces > > src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java > 145 } > 146 /** > -> insert blank line in between > > src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java > 734 public List getNotationDecls(){ > -> blank before { > > src/java.xml/share/classes/com/sun/xml/internal/stream/events/DTDEvent.java > 66 public void setEntities(List entites){ > -> space before {; variable name entites -> entities > 77 public void setNotations(List notations){ > -> space > 94 protected final void init(){ > -> space > > src/java.xml/share/classes/com/sun/xml/internal/stream/events/EndElementEvent.java > -> order import statements alphabetically > 48 QName fQName ; > -> space > 105 void addNamespace(Namespace ns){ > -> space > 106 if(ns != null){ > -> spaces > > src/java.xml/share/classes/com/sun/xml/internal/stream/events/StartElementEvent.java > -> import statements order, a few space issues > > src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java > 68 public void add(javax.xml.stream.XMLEventReader xMLEventReader) throws XMLStreamException { > 80 public void add(javax.xml.stream.events.XMLEvent xMLEvent) throws XMLStreamException { > -> you should be able to use unqualified names for parameters > > src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java > 906 ElementState elem; > 907 > 908 while (!fElementStack.empty()) { > 909 elem = fElementStack.pop(); > -> I think elem can be declared in line 909 as well, scope is only within while() block > > Best regards > Christoph > > > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Joe Wang >> Sent: Montag, 12. Dezember 2016 20:14 >> To: core-libs-dev at openjdk.java.net >> Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 >> >> Hi, >> >> This was the cleanup portion of the change for JDK-8167340. As Lance >> suggested, it was split from the original webrev. In addition to that >> cleanup, I've added coverage to the entire StAX packages. This cleanup >> will reduce 138 warnings. >> >> jbs: https://bugs.openjdk.java.net/browse/JDK-8170556 >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ >> >> Thanks, >> Joe From paul.sandoz at oracle.com Wed Dec 14 01:26:55 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 13 Dec 2016 17:26:55 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: Working my way through it? One general question: why did you replace Arrays.fill with an explicit loop in many cases? Paul. > On 13 Dec 2016, at 15:13, Martin Buchholz wrote: > > We were supposed to be winding down jdk9, and there are a lot of changes here, but ... it would be a shame not to have fast specialized implementations for new collection methods added in Java 8. There's also a fix for a serious bug in LinkedBlockingQueue. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > As with wave 12, very collection oriented. From weijun.wang at oracle.com Wed Dec 14 01:45:05 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 09:45:05 +0800 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Message-ID: Webrev updated at http://cr.openjdk.java.net/~weijun/8168979/webrev.01 One comment is moved to its correct position and a typo fixed. Thanks Daniel for the comment. Can someone with a reviewer hat take a look? Thanks Max > On Dec 12, 2016, at 6:03 PM, Daniel Fuchs wrote: > > Hi Max, > > Don't count me as reviewer - but I see a mismatched comment > in the file: > > 209 /** > 210 * Creates FilePermission objects with special internals. > 211 * See {@link FilePermCompat#newPermPlusAltPath(Permission)} and > 212 * {@link FilePermCompat#newPermUsingAltPath(Permission)}. > 213 */ > 214 > 215 private static final Path here = builtInFS.getPath( > 216 GetPropertyAction.privilegedGetProperty("user.dir")); > > I guess the comment is a left over from some merge or previous fix? > > > Also I noticed the following later on: > > 541 * invalid {@code FilePermission}. Even if two {@code FilePermission} > 542 * are created with the same invalid path, one does imply the other. > > should this be: > > Even if two {@code FilePermission} are created with the same > invalid path, one does *not* imply the other. > > best regards, > > -- daniel > > On 12/12/16 09:01, Wang Weijun wrote: >> Please take a review at >> >> http://cr.openjdk.java.net/~weijun/8168979/webrev.00/ >> >> This further clarifies what an invalid FilePermission behaves. A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. >> >> Thanks >> Max >> > From xuelei.fan at oracle.com Wed Dec 14 02:11:16 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Tue, 13 Dec 2016 18:11:16 -0800 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> Message-ID: <35ec0955-b04e-00cd-6367-a88eeda883bc@oracle.com> On 12/13/2016 5:45 PM, Wang Weijun wrote: > A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. Looks like two sides of the same coin. If there is an invalid <> (not existing in practice, I think), it now implies all; if no change on this point, <> does not imply invalid one. The existing behavior looks more safe to me. What's you concern to make this behavior change? Otherwise, looks fine to me. Xuelei From weijun.wang at oracle.com Wed Dec 14 02:14:40 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 10:14:40 +0800 Subject: RFR 8168979: @implNote for invalid FilePermission In-Reply-To: <35ec0955-b04e-00cd-6367-a88eeda883bc@oracle.com> References: <89DB2BB5-7521-43E5-B06A-7F2CA802BCB1@oracle.com> <35ec0955-b04e-00cd-6367-a88eeda883bc@oracle.com> Message-ID: <05C423C1-69E3-4D5D-A8C2-349634B9B8CB@oracle.com> > On Dec 14, 2016, at 10:11 AM, Xuelei Fan wrote: > > On 12/13/2016 5:45 PM, Wang Weijun wrote: >> A major behavior change is that <> now implies an invalid permission, I hope this is good to minimize incompatibility. > Looks like two sides of the same coin. If there is an invalid <> (not existing in practice, I think), Not existing in theory either. As the change says, invalid happens when the conversion of string to NIO Path fails. For <>, there will be no such conversion. > it now implies all; if no change on this point, <> does not imply invalid one. The existing behavior looks more safe to me. What's you concern to make this behavior change? Just safer. Sometimes an app can recover from a FileNotExistException but not a SecurityException. Thanks Max > > Otherwise, looks fine to me. > > Xuelei From huizhe.wang at oracle.com Wed Dec 14 03:09:24 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 13 Dec 2016 19:09:24 -0800 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName;" even if "entities" property is false In-Reply-To: <022601d25550$ff1a1610$fd4e4230$@oracle.com> References: <022601d25550$ff1a1610$fd4e4230$@oracle.com> Message-ID: <5850B7E4.1060907@oracle.com> Hi Frank, Thanks for the diligent work! I think we've made a great improvement over the PrettyPrint (tremendous ;-) ) Could you look into extracting the XML literal strings in the test into plain files (similar to the other 'gold' files)? What I'm hoping to see is that they'd look easily prettier in a text editor, and for that matter, the original xml files were a mess. The tests set PrettyPrint, and by default for html. It would be good to test the cases when it's turned off, that would help verify the non-pretty format was not changed. Thanks, Joe On 12/13/16, 6:55 AM, Frank Yuan wrote: > Hi all > > Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ is for JDK-8087303 and JDK-8114834, I have to combine the fix > because there is some interaction between them. > Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 https://bugs.openjdk.java.net/browse/JDK-8114834 > > Besides fixed some issues in xml serializer, I made the following changes in this patch: > 1. refined the handling for whitespace text > 2. added support for xml:space attribute > 3. changed the default indentation to 4 > 4. refined the handling for HTML block element and inline element > > Would you like to have a look at this review? > > Thanks, > > Frank > > From martinrb at google.com Wed Dec 14 03:37:10 2016 From: martinrb at google.com (Martin Buchholz) Date: Tue, 13 Dec 2016 19:37:10 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: Hotspot appears to have support for the array filling code pattern, but Arrays.fill itself is not intrinsified. There are bounds checks which hotspot may not be able to elide. For almost all software, Arrays.fill is good enough, but core library collections are an exception. Also, we introduce other little abstractions like shiftTailOverGap and circularClear. Another possibility is to introduce our own tiny helper method without checks nullOutSlice(Object[] a, int from, int to) On Tue, Dec 13, 2016 at 5:26 PM, Paul Sandoz wrote: > > One general question: why did you replace Arrays.fill with an explicit > loop in many cases? > > From mandy.chung at oracle.com Wed Dec 14 03:59:06 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Dec 2016 19:59:06 -0800 Subject: RFR: 8169806 - DriverManager javadoc clarifications In-Reply-To: References: Message-ID: > On Dec 13, 2016, at 2:35 PM, Lance Andersen wrote: > > Hi all, > > This review request addresses some a cleanup to the DriverManager javadocs. The CCC for the changes has been approved. > > The webrev can be found at http://cr.openjdk.java.net/~lancea/8169806/webrev.03/ +1 Mandy From mandy.chung at oracle.com Wed Dec 14 04:10:15 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 13 Dec 2016 20:10:15 -0800 Subject: RFR 8169389 : Use a bitmap to control StackTraceElement::toString format and save footprint In-Reply-To: <58505FAD.6060404@oracle.com> References: <584885AA.9060202@oracle.com> <53E12B9B-1C58-4096-B729-4BB24378B5BD@oracle.com> <584B578A.1030508@oracle.com> <12e7a48c-f8ec-bb3b-9875-e9d31d84d784@oracle.com> <58505FAD.6060404@oracle.com> Message-ID: > On Dec 13, 2016, at 12:53 PM, Brent Christian wrote: > > Thank you, Mandy and Daniel. > > As a point of interest, automated testing uncovered a couple things I had to change before pushing: > > http://hg.openjdk.java.net/jdk9/dev/hotspot/rev/accf1676e416 > > * Updated the CHECK_OFFSET line, so fastdebug builds > > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/ddc8f2ae290b > > * In the test case, only check for a classloader named 'app' if we are using the system classloader. This is usually the case, but not when running regtests using the 'make' target (URLClassLoader). Thanks for the update. Looks fine to me. Mandy From weijun.wang at oracle.com Wed Dec 14 05:53:47 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Wed, 14 Dec 2016 13:53:47 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) Message-ID: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> An clarification is added to FilePermission::implies: * @implNote .... * a simple {@code npath} is recursively inside a wildcard {@code npath} * if and only if {@code simple_npath.relativize(wildcard_npath)} - * is a series of one or more "..". An invalid {@code FilePermission} does + * is a series of one or more "..". Note that this means "/-" does not + * imply "foo". An invalid {@code FilePermission} does * not imply any object except for itself. The newly added sentence is Note that this means "/-" does not imply "foo". JCK has agreed to update their test. Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. Thanks Max From abhijit.r.roy at oracle.com Wed Dec 14 06:18:29 2016 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Tue, 13 Dec 2016 22:18:29 -0800 (PST) Subject: RFR: JDK-8164923, JDK-8170566, JDK-8169482, JDK-8170653 Message-ID: <4ddd2ba3-bf3f-4668-ba02-015a2d19c6a9@default> Hi all, Please review the java doc fixes for the below bugs: Bug: https://bugs.openjdk.java.net/browse/JDK-8164923 Description: Error in the documentation for java.lang.Random Webrev: http://cr.openjdk.java.net/%7Erpatil/8164923/webrev.00/ Bug : https://bugs.openjdk.java.net/browse/JDK-8170566 Description: Incorrect phrase usage in javadocs documentation Webrev: http://cr.openjdk.java.net/%7Erpatil/8170566/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8169482 Description: java.time.DateTimeFormatter javadoc: F is not week-of-month Webrev: http://cr.openjdk.java.net/%7Erpatil/8169482/webrev.00/ Bug: https://bugs.openjdk.java.net/browse/JDK-8170653 Description: The javadoc of ZoneRules.previousTransition() is wrong Webrev: http://cr.openjdk.java.net/%7Erpatil/8170653/webrev.00/ I have just rectified and modified those errors. And moving forward it for review. Regards, Abhijit From christoph.langer at sap.com Wed Dec 14 07:53:00 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 14 Dec 2016 07:53:00 +0000 Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 In-Reply-To: <58509558.8070607@oracle.com> References: <584EF6DA.8080307@oracle.com> <1efbdc1c876f48788eda832dce3b3d8f@DEWDFE13DE03.global.corp.sap> <58509558.8070607@oracle.com> Message-ID: <50e1e534b3924d59b16d4d4467badab6@DEWDFE13DE03.global.corp.sap> Thanks, Joe. Overall, this looks better. > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 01:42 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 > > Thanks Christoph! > > I updated the webrev for the classes you mentioned below, in a few > cases, used NetBeans' source format feature -- not for all of the > classes though (esp. the crazily large > XMLDocumentFragmentScannerImpl.java, it gets better though, overtime). > > http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ > > Best regards, > Joe > > On 12/13/16, 2:14 PM, Langer, Christoph wrote: > > Hi Joe, > > > > looks nice, thanks for doing that. > > > > Here are a few findings: > > > > > src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStre > amReaderImpl.java: > > -> import statements could be ordered alphabetically > > 262 fEntityScanner = fEntityManager.getEntityScanner() ; > > -> spaces before ; > > 1317 protected List getEntityDecls(){ > > -> space before opening { > > 1322 if(entities.size()> 0){ > > -> spaces after if, before { > > 1344 protected List getNotationDecls(){ > > -> space before { > > 1352 if(notation!= null){ > > -> spaces > > > > > src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.jav > a > > 145 } > > 146 /** > > -> insert blank line in between > > > > > src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DT > DGrammar.java > > 734 public List getNotationDecls(){ > > -> blank before { > > > > > src/java.xml/share/classes/com/sun/xml/internal/stream/events/DTDEvent.jav > a > > 66 public void setEntities(List entites){ > > -> space before {; variable name entites -> entities > > 77 public void setNotations(List notations){ > > -> space > > 94 protected final void init(){ > > -> space > > > > > src/java.xml/share/classes/com/sun/xml/internal/stream/events/EndElementE > vent.java > > -> order import statements alphabetically > > 48 QName fQName ; > > -> space > > 105 void addNamespace(Namespace ns){ > > -> space > > 106 if(ns != null){ > > -> spaces > > > > > src/java.xml/share/classes/com/sun/xml/internal/stream/events/StartElement > Event.java > > -> import statements order, a few space issues > > > > > src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLEventWr > iterImpl.java > > 68 public void add(javax.xml.stream.XMLEventReader xMLEventReader) > throws XMLStreamException { > > 80 public void add(javax.xml.stream.events.XMLEvent xMLEvent) throws > XMLStreamException { > > -> you should be able to use unqualified names for parameters > > > > > src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStream > WriterImpl.java > > 906 ElementState elem; > > 907 > > 908 while (!fElementStack.empty()) { > > 909 elem = fElementStack.pop(); > > -> I think elem can be declared in line 909 as well, scope is only within > while() block > > > > Best regards > > Christoph > > > > > > > >> -----Original Message----- > >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf > >> Of Joe Wang > >> Sent: Montag, 12. Dezember 2016 20:14 > >> To: core-libs-dev at openjdk.java.net > >> Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 > >> > >> Hi, > >> > >> This was the cleanup portion of the change for JDK-8167340. As Lance > >> suggested, it was split from the original webrev. In addition to that > >> cleanup, I've added coverage to the entire StAX packages. This cleanup > >> will reduce 138 warnings. > >> > >> jbs: https://bugs.openjdk.java.net/browse/JDK-8170556 > >> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ > >> > >> Thanks, > >> Joe From goetz.lindenmaier at sap.com Wed Dec 14 09:48:30 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 09:48:30 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> Message-ID: <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> Hi, 8066474 has not been promoted. I'll remove the strlen // fix for aix from this change and push it without it. I'd like to get this done. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Donnerstag, 8. Dezember 2016 23:03 > To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > ; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > > On 12/8/16 1:59 PM, David Holmes wrote: > >> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> thanks for looking at the change. New webrev: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >>> > >>>> src/java.base/share/native/libjli/java.c > >>>> As far as I can see the existing code is working perfectly fine. > >>> Ah, thanks for the explanation, now I got it! Removed. > >>> > >>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>> expanded with: > >>>> "%s/lib/%s/jli:" > >>> I first edited this against jdk9/hs, where the arch is gone since > >>> 8066474, > >>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>> but the // was not adapted. Then I moved the change to jdk9/dev because > >>> I thought I have to push it there. And yes, in that coding // would > >>> be correct. > >>> So I have to wait until hs is promoted ... > >> > >> So just based on the current file, the change proposed - to remove one > >> / - is not correct until the arch directory is removed. > > > > That change is already in JDK9-hs: > > > > Changeset: c14f9a7b4cab > > Author: erikj > > Date: 2016-12-05 17:55 +0100 > > URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > > > > 8066474: Remove the lib/ directory from Linux and Solaris images > > Reviewed-by: tbell, ihse > > > > along with changesets in the jdk and hotspot repos along with a few > > closed repos. > > Thanks Dan. So we need to see a webrev based on latest hs code - where > removing the extra / would be correct. > > David > ----- > > > Dan > > > > > > > >> > >> David > >> ----- > >> > >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>> comment on > >>>> the strdup would have sufficed IMO. > >>> Dmitry asked me to add it. But I think it's ok. > >>> > >>> Can I consider this reviewed now? I.e. could I push it once 8066474 is > >>> promoted and Joe Darcy agreed? > >>> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>> To: Lindenmaier, Goetz ; 'Dmitry > Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>> servicabilty > >>>> coding. > >>>> > >>>> Hi Goetz, > >>>> > >>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>> Hi Dmitry, > >>>>> > >>>>> yes, new_jvmpath is consistent with the other variables. > >>>>> I also merged the ifs in SDE.c. > >>>>> > >>>>> new webrev: > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ > >>>> > >>>> src/java.base/share/native/libjli/java.c > >>>> > >>>> As far as I can see the existing code is working perfectly fine. > >>>> Given a > >>>> jvm.cfg with: > >>>> > >>>> -server KNOWN > >>>> -client IGNORE > >>>> -myvm KNOWN > >>>> -oldvm ALIASED_TO -server > >>>> > >>>> The usage text is: > >>>> > >>>> -server to select the "server" VM > >>>> -myvm to select the "myvm" VM > >>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>> The default VM is server, > >>>> because you are running on a server-class machine. > >>>> > >>>> which is exactly what I would expect. Why do you think there is a bug? > >>>> > >>>> --- > >>>> > >>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>> > >>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>> expanded with: > >>>> > >>>> "%s/lib/%s/jli:" > >>>> > >>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>> is exactly what the existing code does: > >>>> > >>>> + JLI_StrLen("/lib//jli:") > >>>> > >>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>> comment on > >>>> the strdup would have sufficed IMO. > >>>> > >>>> Thanks, > >>>> David > >>>> ----- > >>>> > >>>> > >>>> > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>> To: Lindenmaier, Goetz ; Java Core Libs > >>>>>> ; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>> servicabilty > >>>>>> coding. > >>>>>> > >>>>>> Goetz, > >>>>>> > >>>>>> SDE.c: > >>>>>> > >>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>> matter of test. > >>>>>> > >>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>> return; /* Java stratum - return unchanged */ > >>>>>> } > >>>>>> > >>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>> double-check the new webrev. > >>>>>> > >>>>>> if cnt is <= 0 loop at l.267 > >>>>>> > >>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>> > >>>>>> is never run and we effectively do > >>>>>> > >>>>>> *entryCountPtr = 0; > >>>>>> > >>>>>> at l.283 > >>>>>> > >>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>> (your v.01 changes) > >>>>>> > >>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>> 261 return; > >>>>>> 262 } > >>>>>> > >>>>>> it's better to check it early. > >>>>>> > >>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>> > >>>>>> -Dmitry > >>>>>> > >>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>> Hi Dmitry, > >>>>>>> > >>>>>>> thanks for looking at my change! > >>>>>>> Updated webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.02 > >>>>>>> > >>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>> Is this line correct? > >>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>> > >>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>> horror.) > >>>>>>> > >>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>> regardless of value of sti. > >>>>>>> > >>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>> double-check the new webrev. > >>>>>>> > >>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>> It might be better to write > >>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>> and leave one copy of setsockopt() call > >>>>>>> > >>>>>>> Yes, looks better. > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> -Dmitry > >>>>>>>> > >>>>>>>> > >>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi, > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> This change fixes some minor issues found in our code scans. > >>>>>>>>> > >>>>>>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Please review: > >>>>>>>>> > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>> corlib_s11y/webrev.01/ > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Changes in detail: > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> e_asin.c > >>>>>>>>> > >>>>>>>>> Code scan reports missing {}. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>> flag of > >>>>>>>>> the processor. > >>>>>>>>> It's a way to avoid the C compiler to optimize the code away. > >>>>>>>>> It is > >>>>>>>>> always true, > >>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>> > >>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>> this to > >>>>>>>>> > >>>>>>>>> avoid anybody else spends more the 30sec on understanding these > >>>>>>>>> > >>>>>>>>> if statements. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> k_standard.c > >>>>>>>>> > >>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>> initialized. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> imageDecompressor.cpp > >>>>>>>>> > >>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> java.c > >>>>>>>>> > >>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> java_md_solinux.c > >>>>>>>>> > >>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> SDE.c > >>>>>>>>> > >>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>> defaultStratumId > >>>>>>>>> == null. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> socket_md.c > >>>>>>>>> > >>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>> hidden in > >>>>>>>>> the macros. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> unpack.cpp > >>>>>>>>> > >>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>> passed from > >>>>>>>>> dollar1. > >>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Dmitry Samersoff > >>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>> sources. > >>>>>> > >>>>>> > >>>>>> -- > >>>>>> Dmitry Samersoff > >>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>> * I would love to change the world, but they won't give me the > >>>>>> sources. > > From david.holmes at oracle.com Wed Dec 14 10:03:53 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2016 20:03:53 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> Message-ID: <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > Hi, > > 8066474 has not been promoted. hs has not been able to push up to dev yet. > I'll remove the strlen // fix for aix from this change and > push it without it. I'd like to get this done. I've lost track of what is now left in this set of changes ?? David > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Donnerstag, 8. Dezember 2016 23:03 >> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >> ; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>> On 12/8/16 1:59 PM, David Holmes wrote: >>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> thanks for looking at the change. New webrev: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >>>>> >>>>>> src/java.base/share/native/libjli/java.c >>>>>> As far as I can see the existing code is working perfectly fine. >>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>> >>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>> expanded with: >>>>>> "%s/lib/%s/jli:" >>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>> 8066474, >>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>> but the // was not adapted. Then I moved the change to jdk9/dev because >>>>> I thought I have to push it there. And yes, in that coding // would >>>>> be correct. >>>>> So I have to wait until hs is promoted ... >>>> >>>> So just based on the current file, the change proposed - to remove one >>>> / - is not correct until the arch directory is removed. >>> >>> That change is already in JDK9-hs: >>> >>> Changeset: c14f9a7b4cab >>> Author: erikj >>> Date: 2016-12-05 17:55 +0100 >>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>> >>> 8066474: Remove the lib/ directory from Linux and Solaris images >>> Reviewed-by: tbell, ihse >>> >>> along with changesets in the jdk and hotspot repos along with a few >>> closed repos. >> >> Thanks Dan. So we need to see a webrev based on latest hs code - where >> removing the extra / would be correct. >> >> David >> ----- >> >>> Dan >>> >>> >>> >>>> >>>> David >>>> ----- >>>> >>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>> comment on >>>>>> the strdup would have sufficed IMO. >>>>> Dmitry asked me to add it. But I think it's ok. >>>>> >>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is >>>>> promoted and Joe Darcy agreed? >>>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>> To: Lindenmaier, Goetz ; 'Dmitry >> Samersoff' >>>>>> ; Java Core Libs >>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>> servicabilty >>>>>> coding. >>>>>> >>>>>> Hi Goetz, >>>>>> >>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi Dmitry, >>>>>>> >>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>> I also merged the ifs in SDE.c. >>>>>>> >>>>>>> new webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.03/ >>>>>> >>>>>> src/java.base/share/native/libjli/java.c >>>>>> >>>>>> As far as I can see the existing code is working perfectly fine. >>>>>> Given a >>>>>> jvm.cfg with: >>>>>> >>>>>> -server KNOWN >>>>>> -client IGNORE >>>>>> -myvm KNOWN >>>>>> -oldvm ALIASED_TO -server >>>>>> >>>>>> The usage text is: >>>>>> >>>>>> -server to select the "server" VM >>>>>> -myvm to select the "myvm" VM >>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>> The default VM is server, >>>>>> because you are running on a server-class machine. >>>>>> >>>>>> which is exactly what I would expect. Why do you think there is a bug? >>>>>> >>>>>> --- >>>>>> >>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>> >>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>> expanded with: >>>>>> >>>>>> "%s/lib/%s/jli:" >>>>>> >>>>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>>>> is exactly what the existing code does: >>>>>> >>>>>> + JLI_StrLen("/lib//jli:") >>>>>> >>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>> comment on >>>>>> the strdup would have sufficed IMO. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> ----- >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>> To: Lindenmaier, Goetz ; Java Core Libs >>>>>>>> ; serviceability-dev (serviceability- >>>>>>>> dev at openjdk.java.net) >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>> servicabilty >>>>>>>> coding. >>>>>>>> >>>>>>>> Goetz, >>>>>>>> >>>>>>>> SDE.c: >>>>>>>> >>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>> matter of test. >>>>>>>> >>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>> } >>>>>>>> >>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>> double-check the new webrev. >>>>>>>> >>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>> >>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>> >>>>>>>> is never run and we effectively do >>>>>>>> >>>>>>>> *entryCountPtr = 0; >>>>>>>> >>>>>>>> at l.283 >>>>>>>> >>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>> (your v.01 changes) >>>>>>>> >>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>> 261 return; >>>>>>>> 262 } >>>>>>>> >>>>>>>> it's better to check it early. >>>>>>>> >>>>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>>>> >>>>>>>> -Dmitry >>>>>>>> >>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> thanks for looking at my change! >>>>>>>>> Updated webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.02 >>>>>>>>> >>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>> Is this line correct? >>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>> >>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>> horror.) >>>>>>>>> >>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>> regardless of value of sti. >>>>>>>>> >>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>> double-check the new webrev. >>>>>>>>> >>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>> It might be better to write >>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>> >>>>>>>>> Yes, looks better. >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>>>>> >>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Please review: >>>>>>>>>>> >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Changes in detail: >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> e_asin.c >>>>>>>>>>> >>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>>>> flag of >>>>>>>>>>> the processor. >>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>>>>> It is >>>>>>>>>>> always true, >>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>> >>>>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>>>> this to >>>>>>>>>>> >>>>>>>>>>> avoid anybody else spends more the 30sec on understanding these >>>>>>>>>>> >>>>>>>>>>> if statements. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> k_standard.c >>>>>>>>>>> >>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>> initialized. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>> >>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> java.c >>>>>>>>>>> >>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> java_md_solinux.c >>>>>>>>>>> >>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> SDE.c >>>>>>>>>>> >>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>> defaultStratumId >>>>>>>>>>> == null. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> socket_md.c >>>>>>>>>>> >>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>>>> hidden in >>>>>>>>>>> the macros. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> unpack.cpp >>>>>>>>>>> >>>>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>>>> passed from >>>>>>>>>>> dollar1. >>>>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dmitry Samersoff >>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>> sources. >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> Dmitry Samersoff >>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>> sources. >>> From goetz.lindenmaier at sap.com Wed Dec 14 10:23:25 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 10:23:25 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> Message-ID: <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> Hi David, I found "8169317: [s390] Various minor bug fixes and adaptions." in jdk9/dev this morning, so I thought it has been promoted based on some older change. I waited for that quite a while because tests in jdk9/dev kept failing on s390. How can I get the information when what was promoted? This always is a wild guess for me ... as well as when what will be promoted :) Do you think the promotion will happen tonight, or will it take another week? I removed - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") + + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + from http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 11:04 > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > 8066474 has not been promoted. > > hs has not been able to push up to dev yet. > > > I'll remove the strlen // fix for aix from this change and > > push it without it. I'd like to get this done. > > I've lost track of what is now left in this set of changes ?? > > David > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Donnerstag, 8. Dezember 2016 23:03 > >> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >> ; 'Dmitry Samersoff' > >> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > >>> On 12/8/16 1:59 PM, David Holmes wrote: > >>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> thanks for looking at the change. New webrev: > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >>>>> > >>>>>> src/java.base/share/native/libjli/java.c > >>>>>> As far as I can see the existing code is working perfectly fine. > >>>>> Ah, thanks for the explanation, now I got it! Removed. > >>>>> > >>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>> expanded with: > >>>>>> "%s/lib/%s/jli:" > >>>>> I first edited this against jdk9/hs, where the arch is gone since > >>>>> 8066474, > >>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>>>> but the // was not adapted. Then I moved the change to jdk9/dev > because > >>>>> I thought I have to push it there. And yes, in that coding // would > >>>>> be correct. > >>>>> So I have to wait until hs is promoted ... > >>>> > >>>> So just based on the current file, the change proposed - to remove one > >>>> / - is not correct until the arch directory is removed. > >>> > >>> That change is already in JDK9-hs: > >>> > >>> Changeset: c14f9a7b4cab > >>> Author: erikj > >>> Date: 2016-12-05 17:55 +0100 > >>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > >>> > >>> 8066474: Remove the lib/ directory from Linux and Solaris images > >>> Reviewed-by: tbell, ihse > >>> > >>> along with changesets in the jdk and hotspot repos along with a few > >>> closed repos. > >> > >> Thanks Dan. So we need to see a webrev based on latest hs code - where > >> removing the extra / would be correct. > >> > >> David > >> ----- > >> > >>> Dan > >>> > >>> > >>> > >>>> > >>>> David > >>>> ----- > >>>> > >>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>> comment on > >>>>>> the strdup would have sufficed IMO. > >>>>> Dmitry asked me to add it. But I think it's ok. > >>>>> > >>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is > >>>>> promoted and Joe Darcy agreed? > >>>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>>>> To: Lindenmaier, Goetz ; 'Dmitry > >> Samersoff' > >>>>>> ; Java Core Libs >>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>> servicabilty > >>>>>> coding. > >>>>>> > >>>>>> Hi Goetz, > >>>>>> > >>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>>>> Hi Dmitry, > >>>>>>> > >>>>>>> yes, new_jvmpath is consistent with the other variables. > >>>>>>> I also merged the ifs in SDE.c. > >>>>>>> > >>>>>>> new webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.03/ > >>>>>> > >>>>>> src/java.base/share/native/libjli/java.c > >>>>>> > >>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>> Given a > >>>>>> jvm.cfg with: > >>>>>> > >>>>>> -server KNOWN > >>>>>> -client IGNORE > >>>>>> -myvm KNOWN > >>>>>> -oldvm ALIASED_TO -server > >>>>>> > >>>>>> The usage text is: > >>>>>> > >>>>>> -server to select the "server" VM > >>>>>> -myvm to select the "myvm" VM > >>>>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>>>> The default VM is server, > >>>>>> because you are running on a server-class machine. > >>>>>> > >>>>>> which is exactly what I would expect. Why do you think there is a bug? > >>>>>> > >>>>>> --- > >>>>>> > >>>>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>> > >>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>> expanded with: > >>>>>> > >>>>>> "%s/lib/%s/jli:" > >>>>>> > >>>>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>>>> is exactly what the existing code does: > >>>>>> > >>>>>> + JLI_StrLen("/lib//jli:") > >>>>>> > >>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>> comment on > >>>>>> the strdup would have sufficed IMO. > >>>>>> > >>>>>> Thanks, > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>> > >>>>>> > >>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>>>> To: Lindenmaier, Goetz ; Java Core > Libs > >>>>>>>> ; serviceability-dev (serviceability- > >>>>>>>> dev at openjdk.java.net) > >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>> servicabilty > >>>>>>>> coding. > >>>>>>>> > >>>>>>>> Goetz, > >>>>>>>> > >>>>>>>> SDE.c: > >>>>>>>> > >>>>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>>>> matter of test. > >>>>>>>> > >>>>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>>>> return; /* Java stratum - return unchanged */ > >>>>>>>> } > >>>>>>>> > >>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>> double-check the new webrev. > >>>>>>>> > >>>>>>>> if cnt is <= 0 loop at l.267 > >>>>>>>> > >>>>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>>>> > >>>>>>>> is never run and we effectively do > >>>>>>>> > >>>>>>>> *entryCountPtr = 0; > >>>>>>>> > >>>>>>>> at l.283 > >>>>>>>> > >>>>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>>>> (your v.01 changes) > >>>>>>>> > >>>>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>>>> 261 return; > >>>>>>>> 262 } > >>>>>>>> > >>>>>>>> it's better to check it early. > >>>>>>>> > >>>>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>>>> > >>>>>>>> -Dmitry > >>>>>>>> > >>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi Dmitry, > >>>>>>>>> > >>>>>>>>> thanks for looking at my change! > >>>>>>>>> Updated webrev: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.02 > >>>>>>>>> > >>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>> Is this line correct? > >>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>>>> > >>>>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>>>> horror.) > >>>>>>>>> > >>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>>>> regardless of value of sti. > >>>>>>>>> > >>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>> double-check the new webrev. > >>>>>>>>> > >>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>>>> It might be better to write > >>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>>>> and leave one copy of setsockopt() call > >>>>>>>>> > >>>>>>>>> Yes, looks better. > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -Dmitry > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi, > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> This change fixes some minor issues found in our code scans. > >>>>>>>>>>> > >>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Please review: > >>>>>>>>>>> > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>> corlib_s11y/webrev.01/ > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Changes in detail: > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> e_asin.c > >>>>>>>>>>> > >>>>>>>>>>> Code scan reports missing {}. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>>>> flag of > >>>>>>>>>>> the processor. > >>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. > >>>>>>>>>>> It is > >>>>>>>>>>> always true, > >>>>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>>>> > >>>>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>>>> this to > >>>>>>>>>>> > >>>>>>>>>>> avoid anybody else spends more the 30sec on understanding > these > >>>>>>>>>>> > >>>>>>>>>>> if statements. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> k_standard.c > >>>>>>>>>>> > >>>>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>>>> initialized. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> imageDecompressor.cpp > >>>>>>>>>>> > >>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> java.c > >>>>>>>>>>> > >>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> java_md_solinux.c > >>>>>>>>>>> > >>>>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> SDE.c > >>>>>>>>>>> > >>>>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>>>> defaultStratumId > >>>>>>>>>>> == null. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> socket_md.c > >>>>>>>>>>> > >>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>>>> hidden in > >>>>>>>>>>> the macros. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> unpack.cpp > >>>>>>>>>>> > >>>>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>>>> passed from > >>>>>>>>>>> dollar1. > >>>>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Dmitry Samersoff > >>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>>>> sources. > >>>>>>>> > >>>>>>>> > >>>>>>>> -- > >>>>>>>> Dmitry Samersoff > >>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>> sources. > >>> From david.holmes at oracle.com Wed Dec 14 10:42:26 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2016 20:42:26 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> Message-ID: <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: > Hi David, > > I found "8169317: [s390] Various minor bug fixes and adaptions." > in jdk9/dev this morning, so I thought it has been promoted based > on some older change. I waited for that quite a while because tests > in jdk9/dev kept failing on s390. > How can I get the information when what was promoted? This always > is a wild guess for me ... as well as when what will be promoted :) Yeah there's no notification in the bug report of when hs pushes up to dev. The changeset email is the only record of exactly when it happens. > Do you think the promotion will happen tonight, or will it take > another week? hs goes through Pre-Integration Testing (PIT) before it is pushed to dev. There have been delays in getting that started and so a delay in it finishing and being analyzed. It may still be a couple of days. > I removed > - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") + > + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + > from > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ With that gone that file only has the jvmpath rename - which isn't fixing anything. Joe also asked for the fdlibm changes to dropped. Thanks, David > Best regards, > Goetz. > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 14. Dezember 2016 11:04 >> To: Lindenmaier, Goetz ; >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> 8066474 has not been promoted. >> >> hs has not been able to push up to dev yet. >> >>> I'll remove the strlen // fix for aix from this change and >>> push it without it. I'd like to get this done. >> >> I've lost track of what is now left in this set of changes ?? >> >> David >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Donnerstag, 8. Dezember 2016 23:03 >>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >>>> ; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>>>> On 12/8/16 1:59 PM, David Holmes wrote: >>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> thanks for looking at the change. New webrev: >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >>>>>>> >>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>>>> >>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>> expanded with: >>>>>>>> "%s/lib/%s/jli:" >>>>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>>>> 8066474, >>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev >> because >>>>>>> I thought I have to push it there. And yes, in that coding // would >>>>>>> be correct. >>>>>>> So I have to wait until hs is promoted ... >>>>>> >>>>>> So just based on the current file, the change proposed - to remove one >>>>>> / - is not correct until the arch directory is removed. >>>>> >>>>> That change is already in JDK9-hs: >>>>> >>>>> Changeset: c14f9a7b4cab >>>>> Author: erikj >>>>> Date: 2016-12-05 17:55 +0100 >>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>>>> >>>>> 8066474: Remove the lib/ directory from Linux and Solaris images >>>>> Reviewed-by: tbell, ihse >>>>> >>>>> along with changesets in the jdk and hotspot repos along with a few >>>>> closed repos. >>>> >>>> Thanks Dan. So we need to see a webrev based on latest hs code - where >>>> removing the extra / would be correct. >>>> >>>> David >>>> ----- >>>> >>>>> Dan >>>>> >>>>> >>>>> >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>> comment on >>>>>>>> the strdup would have sufficed IMO. >>>>>>> Dmitry asked me to add it. But I think it's ok. >>>>>>> >>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is >>>>>>> promoted and Joe Darcy agreed? >>>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry >>>> Samersoff' >>>>>>>> ; Java Core Libs >>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>> dev at openjdk.java.net) >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>> servicabilty >>>>>>>> coding. >>>>>>>> >>>>>>>> Hi Goetz, >>>>>>>> >>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi Dmitry, >>>>>>>>> >>>>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>>>> I also merged the ifs in SDE.c. >>>>>>>>> >>>>>>>>> new webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.03/ >>>>>>>> >>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>> >>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>> Given a >>>>>>>> jvm.cfg with: >>>>>>>> >>>>>>>> -server KNOWN >>>>>>>> -client IGNORE >>>>>>>> -myvm KNOWN >>>>>>>> -oldvm ALIASED_TO -server >>>>>>>> >>>>>>>> The usage text is: >>>>>>>> >>>>>>>> -server to select the "server" VM >>>>>>>> -myvm to select the "myvm" VM >>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>>>> The default VM is server, >>>>>>>> because you are running on a server-class machine. >>>>>>>> >>>>>>>> which is exactly what I would expect. Why do you think there is a bug? >>>>>>>> >>>>>>>> --- >>>>>>>> >>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>> >>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>> expanded with: >>>>>>>> >>>>>>>> "%s/lib/%s/jli:" >>>>>>>> >>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>>>>>> is exactly what the existing code does: >>>>>>>> >>>>>>>> + JLI_StrLen("/lib//jli:") >>>>>>>> >>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>> comment on >>>>>>>> the strdup would have sufficed IMO. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>>>> To: Lindenmaier, Goetz ; Java Core >> Libs >>>>>>>>>> ; serviceability-dev (serviceability- >>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>> servicabilty >>>>>>>>>> coding. >>>>>>>>>> >>>>>>>>>> Goetz, >>>>>>>>>> >>>>>>>>>> SDE.c: >>>>>>>>>> >>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>>>> matter of test. >>>>>>>>>> >>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>>>> } >>>>>>>>>> >>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>> double-check the new webrev. >>>>>>>>>> >>>>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>>>> >>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>>>> >>>>>>>>>> is never run and we effectively do >>>>>>>>>> >>>>>>>>>> *entryCountPtr = 0; >>>>>>>>>> >>>>>>>>>> at l.283 >>>>>>>>>> >>>>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>>>> (your v.01 changes) >>>>>>>>>> >>>>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>>>> 261 return; >>>>>>>>>> 262 } >>>>>>>>>> >>>>>>>>>> it's better to check it early. >>>>>>>>>> >>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>>>>>> >>>>>>>>>> -Dmitry >>>>>>>>>> >>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> thanks for looking at my change! >>>>>>>>>>> Updated webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>> corlib_s11y/webrev.02 >>>>>>>>>>> >>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>> Is this line correct? >>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>>>> >>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>>>> horror.) >>>>>>>>>>> >>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>>>> regardless of value of sti. >>>>>>>>>>> >>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>> double-check the new webrev. >>>>>>>>>>> >>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>>>> It might be better to write >>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>>>> >>>>>>>>>>> Yes, looks better. >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>>>>>>> >>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Please review: >>>>>>>>>>>>> >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> Changes in detail: >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> e_asin.c >>>>>>>>>>>>> >>>>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>>>>>> flag of >>>>>>>>>>>>> the processor. >>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>>>>>>> It is >>>>>>>>>>>>> always true, >>>>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>>>> >>>>>>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>>>>>> this to >>>>>>>>>>>>> >>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding >> these >>>>>>>>>>>>> >>>>>>>>>>>>> if statements. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> k_standard.c >>>>>>>>>>>>> >>>>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>>>> initialized. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> java.c >>>>>>>>>>>>> >>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> java_md_solinux.c >>>>>>>>>>>>> >>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> SDE.c >>>>>>>>>>>>> >>>>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>>>> defaultStratumId >>>>>>>>>>>>> == null. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> socket_md.c >>>>>>>>>>>>> >>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>>>>>> hidden in >>>>>>>>>>>>> the macros. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>> unpack.cpp >>>>>>>>>>>>> >>>>>>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>>>>>> passed from >>>>>>>>>>>>> dollar1. >>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>>> sources. >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> Dmitry Samersoff >>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>> sources. >>>>> From goetz.lindenmaier at sap.com Wed Dec 14 11:00:46 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 11:00:46 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> Message-ID: <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> Hi, You're right, I had removed the change to e_asin.c. New webrev anyways: http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 11:42 > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: > > Hi David, > > > > I found "8169317: [s390] Various minor bug fixes and adaptions." > > in jdk9/dev this morning, so I thought it has been promoted based > > on some older change. I waited for that quite a while because tests > > in jdk9/dev kept failing on s390. > > How can I get the information when what was promoted? This always > > is a wild guess for me ... as well as when what will be promoted :) > > Yeah there's no notification in the bug report of when hs pushes up to > dev. The changeset email is the only record of exactly when it happens. > > > Do you think the promotion will happen tonight, or will it take > > another week? > > hs goes through Pre-Integration Testing (PIT) before it is pushed to > dev. There have been delays in getting that started and so a delay in it > finishing and being analyzed. It may still be a couple of days. > > > I removed > > - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") + > > + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + > > from > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > > With that gone that file only has the jvmpath rename - which isn't > fixing anything. > > Joe also asked for the fdlibm changes to dropped. > > Thanks, > David > > > Best regards, > > Goetz. > > > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 14. Dezember 2016 11:04 > >> To: Lindenmaier, Goetz ; > >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> 8066474 has not been promoted. > >> > >> hs has not been able to push up to dev yet. > >> > >>> I'll remove the strlen // fix for aix from this change and > >>> push it without it. I'd like to get this done. > >> > >> I've lost track of what is now left in this set of changes ?? > >> > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Donnerstag, 8. Dezember 2016 23:03 > >>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >>>> ; 'Dmitry Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >>>> coding. > >>>> > >>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > >>>>> On 12/8/16 1:59 PM, David Holmes wrote: > >>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>>>>>> Hi David, > >>>>>>> > >>>>>>> thanks for looking at the change. New webrev: > >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.04/ > >>>>>>> > >>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>> Ah, thanks for the explanation, now I got it! Removed. > >>>>>>> > >>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>>>> expanded with: > >>>>>>>> "%s/lib/%s/jli:" > >>>>>>> I first edited this against jdk9/hs, where the arch is gone since > >>>>>>> 8066474, > >>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev > >> because > >>>>>>> I thought I have to push it there. And yes, in that coding // would > >>>>>>> be correct. > >>>>>>> So I have to wait until hs is promoted ... > >>>>>> > >>>>>> So just based on the current file, the change proposed - to remove one > >>>>>> / - is not correct until the arch directory is removed. > >>>>> > >>>>> That change is already in JDK9-hs: > >>>>> > >>>>> Changeset: c14f9a7b4cab > >>>>> Author: erikj > >>>>> Date: 2016-12-05 17:55 +0100 > >>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > >>>>> > >>>>> 8066474: Remove the lib/ directory from Linux and Solaris images > >>>>> Reviewed-by: tbell, ihse > >>>>> > >>>>> along with changesets in the jdk and hotspot repos along with a few > >>>>> closed repos. > >>>> > >>>> Thanks Dan. So we need to see a webrev based on latest hs code - where > >>>> removing the extra / would be correct. > >>>> > >>>> David > >>>> ----- > >>>> > >>>>> Dan > >>>>> > >>>>> > >>>>> > >>>>>> > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>>>> comment on > >>>>>>>> the strdup would have sufficed IMO. > >>>>>>> Dmitry asked me to add it. But I think it's ok. > >>>>>>> > >>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is > >>>>>>> promoted and Joe Darcy agreed? > >>>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry > >>>> Samersoff' > >>>>>>>> ; Java Core Libs >>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>>>> dev at openjdk.java.net) > >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>> servicabilty > >>>>>>>> coding. > >>>>>>>> > >>>>>>>> Hi Goetz, > >>>>>>>> > >>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi Dmitry, > >>>>>>>>> > >>>>>>>>> yes, new_jvmpath is consistent with the other variables. > >>>>>>>>> I also merged the ifs in SDE.c. > >>>>>>>>> > >>>>>>>>> new webrev: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.03/ > >>>>>>>> > >>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>> > >>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>> Given a > >>>>>>>> jvm.cfg with: > >>>>>>>> > >>>>>>>> -server KNOWN > >>>>>>>> -client IGNORE > >>>>>>>> -myvm KNOWN > >>>>>>>> -oldvm ALIASED_TO -server > >>>>>>>> > >>>>>>>> The usage text is: > >>>>>>>> > >>>>>>>> -server to select the "server" VM > >>>>>>>> -myvm to select the "myvm" VM > >>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>>>>>> The default VM is server, > >>>>>>>> because you are running on a server-class machine. > >>>>>>>> > >>>>>>>> which is exactly what I would expect. Why do you think there is a > bug? > >>>>>>>> > >>>>>>>> --- > >>>>>>>> > >>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>> > >>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>>>> expanded with: > >>>>>>>> > >>>>>>>> "%s/lib/%s/jli:" > >>>>>>>> > >>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>>>>>> is exactly what the existing code does: > >>>>>>>> > >>>>>>>> + JLI_StrLen("/lib//jli:") > >>>>>>>> > >>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>>>> comment on > >>>>>>>> the strdup would have sufficed IMO. > >>>>>>>> > >>>>>>>> Thanks, > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>>>>>> To: Lindenmaier, Goetz ; Java Core > >> Libs > >>>>>>>>>> ; serviceability-dev > (serviceability- > >>>>>>>>>> dev at openjdk.java.net) > >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>>>> servicabilty > >>>>>>>>>> coding. > >>>>>>>>>> > >>>>>>>>>> Goetz, > >>>>>>>>>> > >>>>>>>>>> SDE.c: > >>>>>>>>>> > >>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>>>>>> matter of test. > >>>>>>>>>> > >>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>>>>>> return; /* Java stratum - return unchanged */ > >>>>>>>>>> } > >>>>>>>>>> > >>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>> double-check the new webrev. > >>>>>>>>>> > >>>>>>>>>> if cnt is <= 0 loop at l.267 > >>>>>>>>>> > >>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>>>>>> > >>>>>>>>>> is never run and we effectively do > >>>>>>>>>> > >>>>>>>>>> *entryCountPtr = 0; > >>>>>>>>>> > >>>>>>>>>> at l.283 > >>>>>>>>>> > >>>>>>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>>>>>> (your v.01 changes) > >>>>>>>>>> > >>>>>>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>>>>>> 261 return; > >>>>>>>>>> 262 } > >>>>>>>>>> > >>>>>>>>>> it's better to check it early. > >>>>>>>>>> > >>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>>>>>> > >>>>>>>>>> -Dmitry > >>>>>>>>>> > >>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>> > >>>>>>>>>>> thanks for looking at my change! > >>>>>>>>>>> Updated webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>> corlib_s11y/webrev.02 > >>>>>>>>>>> > >>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>>>> Is this line correct? > >>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>>>>>> > >>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>>>>>> horror.) > >>>>>>>>>>> > >>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>>>>>> regardless of value of sti. > >>>>>>>>>>> > >>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>> > >>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>>>>>> It might be better to write > >>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>>>>>> and leave one copy of setsockopt() call > >>>>>>>>>>> > >>>>>>>>>>> Yes, looks better. > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -Dmitry > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi, > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> This change fixes some minor issues found in our code scans. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Please review: > >>>>>>>>>>>>> > >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>>>> corlib_s11y/webrev.01/ > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> > >>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> Changes in detail: > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> e_asin.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> Code scan reports missing {}. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>>>>>> flag of > >>>>>>>>>>>>> the processor. > >>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. > >>>>>>>>>>>>> It is > >>>>>>>>>>>>> always true, > >>>>>>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>>>>>> this to > >>>>>>>>>>>>> > >>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding > >> these > >>>>>>>>>>>>> > >>>>>>>>>>>>> if statements. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> k_standard.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>>>>>> initialized. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> imageDecompressor.cpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> java.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> java_md_solinux.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> SDE.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>>>>>> defaultStratumId > >>>>>>>>>>>>> == null. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> socket_md.c > >>>>>>>>>>>>> > >>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>>>>>> hidden in > >>>>>>>>>>>>> the macros. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> unpack.cpp > >>>>>>>>>>>>> > >>>>>>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>>>>>> passed from > >>>>>>>>>>>>> dollar1. > >>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Dmitry Samersoff > >>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>>>>>> sources. > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> -- > >>>>>>>>>> Dmitry Samersoff > >>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>>>> sources. > >>>>> From david.holmes at oracle.com Wed Dec 14 11:28:39 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 14 Dec 2016 21:28:39 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> Message-ID: <1238bad1-1805-e57a-2360-196e44770521@oracle.com> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: > Hi, > > You're right, I had removed the change to e_asin.c. You only pointed Joe to that file AFAICS. I would expect he would also object to the change to k_standard.c for the same reason. > New webrev anyways: > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ > > java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. Okay. Thanks. David > Best regards, > Goetz. > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 14. Dezember 2016 11:42 >> To: Lindenmaier, Goetz ; >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: >>> Hi David, >>> >>> I found "8169317: [s390] Various minor bug fixes and adaptions." >>> in jdk9/dev this morning, so I thought it has been promoted based >>> on some older change. I waited for that quite a while because tests >>> in jdk9/dev kept failing on s390. >>> How can I get the information when what was promoted? This always >>> is a wild guess for me ... as well as when what will be promoted :) >> >> Yeah there's no notification in the bug report of when hs pushes up to >> dev. The changeset email is the only record of exactly when it happens. >> >>> Do you think the promotion will happen tonight, or will it take >>> another week? >> >> hs goes through Pre-Integration Testing (PIT) before it is pushed to >> dev. There have been delays in getting that started and so a delay in it >> finishing and being analyzed. It may still be a couple of days. >> >>> I removed >>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") + >>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + >>> from >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >> >> With that gone that file only has the jvmpath rename - which isn't >> fixing anything. >> >> Joe also asked for the fdlibm changes to dropped. >> >> Thanks, >> David >> >>> Best regards, >>> Goetz. >>> >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 14. Dezember 2016 11:04 >>>> To: Lindenmaier, Goetz ; >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> 8066474 has not been promoted. >>>> >>>> hs has not been able to push up to dev yet. >>>> >>>>> I'll remove the strlen // fix for aix from this change and >>>>> push it without it. I'd like to get this done. >>>> >>>> I've lost track of what is now left in this set of changes ?? >>>> >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 >>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >>>>>> ; 'Dmitry Samersoff' >>>>>> ; Java Core Libs >>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>>>> coding. >>>>>> >>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: >>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi David, >>>>>>>>> >>>>>>>>> thanks for looking at the change. New webrev: >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.04/ >>>>>>>>> >>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>>>>>> >>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>>>> expanded with: >>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>>>>>> 8066474, >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev >>>> because >>>>>>>>> I thought I have to push it there. And yes, in that coding // would >>>>>>>>> be correct. >>>>>>>>> So I have to wait until hs is promoted ... >>>>>>>> >>>>>>>> So just based on the current file, the change proposed - to remove one >>>>>>>> / - is not correct until the arch directory is removed. >>>>>>> >>>>>>> That change is already in JDK9-hs: >>>>>>> >>>>>>> Changeset: c14f9a7b4cab >>>>>>> Author: erikj >>>>>>> Date: 2016-12-05 17:55 +0100 >>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>>>>>> >>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris images >>>>>>> Reviewed-by: tbell, ihse >>>>>>> >>>>>>> along with changesets in the jdk and hotspot repos along with a few >>>>>>> closed repos. >>>>>> >>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - where >>>>>> removing the extra / would be correct. >>>>>> >>>>>> David >>>>>> ----- >>>>>> >>>>>>> Dan >>>>>>> >>>>>>> >>>>>>> >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>>>> comment on >>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>> Dmitry asked me to add it. But I think it's ok. >>>>>>>>> >>>>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 is >>>>>>>>> promoted and Joe Darcy agreed? >>>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry >>>>>> Samersoff' >>>>>>>>>> ; Java Core Libs >>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>> servicabilty >>>>>>>>>> coding. >>>>>>>>>> >>>>>>>>>> Hi Goetz, >>>>>>>>>> >>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi Dmitry, >>>>>>>>>>> >>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>>>>>> I also merged the ifs in SDE.c. >>>>>>>>>>> >>>>>>>>>>> new webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>> corlib_s11y/webrev.03/ >>>>>>>>>> >>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>> >>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>> Given a >>>>>>>>>> jvm.cfg with: >>>>>>>>>> >>>>>>>>>> -server KNOWN >>>>>>>>>> -client IGNORE >>>>>>>>>> -myvm KNOWN >>>>>>>>>> -oldvm ALIASED_TO -server >>>>>>>>>> >>>>>>>>>> The usage text is: >>>>>>>>>> >>>>>>>>>> -server to select the "server" VM >>>>>>>>>> -myvm to select the "myvm" VM >>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>>>>>> The default VM is server, >>>>>>>>>> because you are running on a server-class machine. >>>>>>>>>> >>>>>>>>>> which is exactly what I would expect. Why do you think there is a >> bug? >>>>>>>>>> >>>>>>>>>> --- >>>>>>>>>> >>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>> >>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>>>> expanded with: >>>>>>>>>> >>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>> >>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>>>>>>>> is exactly what the existing code does: >>>>>>>>>> >>>>>>>>>> + JLI_StrLen("/lib//jli:") >>>>>>>>>> >>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>>>> comment on >>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>> >>>>>>>>>> Thanks, >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>>>>>> To: Lindenmaier, Goetz ; Java Core >>>> Libs >>>>>>>>>>>> ; serviceability-dev >> (serviceability- >>>>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>>>> servicabilty >>>>>>>>>>>> coding. >>>>>>>>>>>> >>>>>>>>>>>> Goetz, >>>>>>>>>>>> >>>>>>>>>>>> SDE.c: >>>>>>>>>>>> >>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>>>>>> matter of test. >>>>>>>>>>>> >>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>>>>>> } >>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>> >>>>>>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>>>>>> >>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>>>>>> >>>>>>>>>>>> is never run and we effectively do >>>>>>>>>>>> >>>>>>>>>>>> *entryCountPtr = 0; >>>>>>>>>>>> >>>>>>>>>>>> at l.283 >>>>>>>>>>>> >>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>>>>>> (your v.01 changes) >>>>>>>>>>>> >>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>>>>>> 261 return; >>>>>>>>>>>> 262 } >>>>>>>>>>>> >>>>>>>>>>>> it's better to check it early. >>>>>>>>>>>> >>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>>>>>>>> >>>>>>>>>>>> -Dmitry >>>>>>>>>>>> >>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks for looking at my change! >>>>>>>>>>>>> Updated webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>> corlib_s11y/webrev.02 >>>>>>>>>>>>> >>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>>>> Is this line correct? >>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>>>>>> >>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>>>>>> horror.) >>>>>>>>>>>>> >>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>>>>>> regardless of value of sti. >>>>>>>>>>>>> >>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>> >>>>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>>>>>> It might be better to write >>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>>>>>> >>>>>>>>>>>>> Yes, looks better. >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> This change fixes some minor issues found in our code scans. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability issues. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Please review: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Changes in detail: >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> e_asin.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>>>>>>>> flag of >>>>>>>>>>>>>>> the processor. >>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code away. >>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>> always true, >>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>>>>>>>> this to >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding >>>> these >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> if statements. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> k_standard.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>>>>>> initialized. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> java_md_solinux.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> SDE.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>>>>>> defaultStratumId >>>>>>>>>>>>>>> == null. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> socket_md.c >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>>>>>>>> hidden in >>>>>>>>>>>>>>> the macros. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> unpack.cpp >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>>>>>>>> passed from >>>>>>>>>>>>>>> dollar1. >>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>>>>> sources. >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> -- >>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>>> sources. >>>>>>> From goetz.lindenmaier at sap.com Wed Dec 14 11:46:23 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Wed, 14 Dec 2016 11:46:23 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <1238bad1-1805-e57a-2360-196e44770521@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> <1238bad1-1805-e57a-2360-196e44770521@oracle.com> Message-ID: > object to the change to k_standard.c for the same reason. Ok, I remove that too. Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Mittwoch, 14. Dezember 2016 12:29 > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: > > Hi, > > > > You're right, I had removed the change to e_asin.c. > > You only pointed Joe to that file AFAICS. I would expect he would also > object to the change to k_standard.c for the same reason. > > > New webrev anyways: > > http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ > > > > java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. > > Okay. Thanks. > > David > > > Best regards, > > Goetz. > > > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 14. Dezember 2016 11:42 > >> To: Lindenmaier, Goetz ; > >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: > >>> Hi David, > >>> > >>> I found "8169317: [s390] Various minor bug fixes and adaptions." > >>> in jdk9/dev this morning, so I thought it has been promoted based > >>> on some older change. I waited for that quite a while because tests > >>> in jdk9/dev kept failing on s390. > >>> How can I get the information when what was promoted? This always > >>> is a wild guess for me ... as well as when what will be promoted :) > >> > >> Yeah there's no notification in the bug report of when hs pushes up to > >> dev. The changeset email is the only record of exactly when it happens. > >> > >>> Do you think the promotion will happen tonight, or will it take > >>> another week? > >> > >> hs goes through Pre-Integration Testing (PIT) before it is pushed to > >> dev. There have been delays in getting that started and so a delay in it > >> finishing and being analyzed. It may still be a couple of days. > >> > >>> I removed > >>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") > + > >>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + > >>> from > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ > >> > >> With that gone that file only has the jvmpath rename - which isn't > >> fixing anything. > >> > >> Joe also asked for the fdlibm changes to dropped. > >> > >> Thanks, > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 14. Dezember 2016 11:04 > >>>> To: Lindenmaier, Goetz ; > >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >>>> coding. > >>>> > >>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > >>>>> Hi, > >>>>> > >>>>> 8066474 has not been promoted. > >>>> > >>>> hs has not been able to push up to dev yet. > >>>> > >>>>> I'll remove the strlen // fix for aix from this change and > >>>>> push it without it. I'd like to get this done. > >>>> > >>>> I've lost track of what is now left in this set of changes ?? > >>>> > >>>> David > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 > >>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >>>>>> ; 'Dmitry Samersoff' > >>>>>> ; Java Core Libs >>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > >>>>>> coding. > >>>>>> > >>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > >>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: > >>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>>>>>>>> Hi David, > >>>>>>>>> > >>>>>>>>> thanks for looking at the change. New webrev: > >>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >> corlib_s11y/webrev.04/ > >>>>>>>>> > >>>>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. > >>>>>>>>> > >>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>>>>>> expanded with: > >>>>>>>>>> "%s/lib/%s/jli:" > >>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since > >>>>>>>>> 8066474, > >>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>>>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev > >>>> because > >>>>>>>>> I thought I have to push it there. And yes, in that coding // would > >>>>>>>>> be correct. > >>>>>>>>> So I have to wait until hs is promoted ... > >>>>>>>> > >>>>>>>> So just based on the current file, the change proposed - to remove > one > >>>>>>>> / - is not correct until the arch directory is removed. > >>>>>>> > >>>>>>> That change is already in JDK9-hs: > >>>>>>> > >>>>>>> Changeset: c14f9a7b4cab > >>>>>>> Author: erikj > >>>>>>> Date: 2016-12-05 17:55 +0100 > >>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > >>>>>>> > >>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris images > >>>>>>> Reviewed-by: tbell, ihse > >>>>>>> > >>>>>>> along with changesets in the jdk and hotspot repos along with a few > >>>>>>> closed repos. > >>>>>> > >>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - > where > >>>>>> removing the extra / would be correct. > >>>>>> > >>>>>> David > >>>>>> ----- > >>>>>> > >>>>>>> Dan > >>>>>>> > >>>>>>> > >>>>>>> > >>>>>>>> > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>>>>>> comment on > >>>>>>>>>> the strdup would have sufficed IMO. > >>>>>>>>> Dmitry asked me to add it. But I think it's ok. > >>>>>>>>> > >>>>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 > is > >>>>>>>>> promoted and Joe Darcy agreed? > >>>>>>>>> > >>>>>>>>> Best regards, > >>>>>>>>> Goetz. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry > >>>>>> Samersoff' > >>>>>>>>>> ; Java Core Libs >>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>>>>>> dev at openjdk.java.net) > >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>>>> servicabilty > >>>>>>>>>> coding. > >>>>>>>>>> > >>>>>>>>>> Hi Goetz, > >>>>>>>>>> > >>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>> > >>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. > >>>>>>>>>>> I also merged the ifs in SDE.c. > >>>>>>>>>>> > >>>>>>>>>>> new webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>> corlib_s11y/webrev.03/ > >>>>>>>>>> > >>>>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>>>> > >>>>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>>>> Given a > >>>>>>>>>> jvm.cfg with: > >>>>>>>>>> > >>>>>>>>>> -server KNOWN > >>>>>>>>>> -client IGNORE > >>>>>>>>>> -myvm KNOWN > >>>>>>>>>> -oldvm ALIASED_TO -server > >>>>>>>>>> > >>>>>>>>>> The usage text is: > >>>>>>>>>> > >>>>>>>>>> -server to select the "server" VM > >>>>>>>>>> -myvm to select the "myvm" VM > >>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>>>>>>>> The default VM is server, > >>>>>>>>>> because you are running on a server-class machine. > >>>>>>>>>> > >>>>>>>>>> which is exactly what I would expect. Why do you think there is a > >> bug? > >>>>>>>>>> > >>>>>>>>>> --- > >>>>>>>>>> > >>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>> > >>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is > >>>>>>>>>> expanded with: > >>>>>>>>>> > >>>>>>>>>> "%s/lib/%s/jli:" > >>>>>>>>>> > >>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that > >>>>>>>>>> is exactly what the existing code does: > >>>>>>>>>> > >>>>>>>>>> + JLI_StrLen("/lib//jli:") > >>>>>>>>>> > >>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a > >>>>>>>>>> comment on > >>>>>>>>>> the strdup would have sufficed IMO. > >>>>>>>>>> > >>>>>>>>>> Thanks, > >>>>>>>>>> David > >>>>>>>>>> ----- > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] > >>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>>>>>>>> To: Lindenmaier, Goetz ; Java > Core > >>>> Libs > >>>>>>>>>>>> ; serviceability-dev > >> (serviceability- > >>>>>>>>>>>> dev at openjdk.java.net) > >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>>>>>> servicabilty > >>>>>>>>>>>> coding. > >>>>>>>>>>>> > >>>>>>>>>>>> Goetz, > >>>>>>>>>>>> > >>>>>>>>>>>> SDE.c: > >>>>>>>>>>>> > >>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>>>>>>>> matter of test. > >>>>>>>>>>>> > >>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>>>>>>>> return; /* Java stratum - return unchanged */ > >>>>>>>>>>>> } > >>>>>>>>>>>> > >>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>>> > >>>>>>>>>>>> if cnt is <= 0 loop at l.267 > >>>>>>>>>>>> > >>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>>>>>>>> > >>>>>>>>>>>> is never run and we effectively do > >>>>>>>>>>>> > >>>>>>>>>>>> *entryCountPtr = 0; > >>>>>>>>>>>> > >>>>>>>>>>>> at l.283 > >>>>>>>>>>>> > >>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>>>>>>>> (your v.01 changes) > >>>>>>>>>>>> > >>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>>>>>>>> 261 return; > >>>>>>>>>>>> 262 } > >>>>>>>>>>>> > >>>>>>>>>>>> it's better to check it early. > >>>>>>>>>>>> > >>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. > >>>>>>>>>>>> > >>>>>>>>>>>> -Dmitry > >>>>>>>>>>>> > >>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>>>> > >>>>>>>>>>>>> thanks for looking at my change! > >>>>>>>>>>>>> Updated webrev: > >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>> corlib_s11y/webrev.02 > >>>>>>>>>>>>> > >>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>>>>>> Is this line correct? > >>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>>>>>>>> > >>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>>>>>>>> horror.) > >>>>>>>>>>>>> > >>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>>>>>>>> regardless of value of sti. > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>>>>>>>> It might be better to write > >>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>>>>>>>> and leave one copy of setsockopt() call > >>>>>>>>>>>>> > >>>>>>>>>>>>> Yes, looks better. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Goetz > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -Dmitry > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> This change fixes some minor issues found in our code > scans. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability > issues. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Please review: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>>>>>> corlib_s11y/webrev.01/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Changes in detail: > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> e_asin.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Code scan reports missing {}. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact > >>>>>>>>>>>>>>> flag of > >>>>>>>>>>>>>>> the processor. > >>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code > away. > >>>>>>>>>>>>>>> It is > >>>>>>>>>>>>>>> always true, > >>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Although this basically just adds the {} I would like to submit > >>>>>>>>>>>>>>> this to > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding > >>>> these > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> if statements. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> k_standard.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>>>>>>>> initialized. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> imageDecompressor.cpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> java.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> java_md_solinux.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> SDE.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>>>>>>>> defaultStratumId > >>>>>>>>>>>>>>> == null. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> socket_md.c > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is > >>>>>>>>>>>>>>> hidden in > >>>>>>>>>>>>>>> the macros. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> unpack.cpp > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> n.slice should not get negative argument for end, which is > >>>>>>>>>>>>>>> passed from > >>>>>>>>>>>>>>> dollar1. > >>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of > >>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Dmitry Samersoff > >>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>>>>>> * I would love to change the world, but they won't give me > the > >>>>>>>>>>>>>> sources. > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> -- > >>>>>>>>>>>> Dmitry Samersoff > >>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>>>> * I would love to change the world, but they won't give me the > >>>>>>>>>>>> sources. > >>>>>>> From chris.hegarty at oracle.com Wed Dec 14 11:58:12 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Wed, 14 Dec 2016 11:58:12 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> Message-ID: <66199530-cc41-b3a6-4276-89f2bc9773a8@oracle.com> Webrev updated in-place. http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ -Chris. On 13/12/16 21:18, Peter Levart wrote: > I think this is OK. > > Just a couple of nits in test: > > 1. You create a static Path bob = Paths.get("bob") field, but then you > don't use it in: > > 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), > CREATE, WRITE)) { > > 2. badBuffers could include a duplicate and a slice of a direct buffer > allocated with ByteBuffer.allocateDirect() > > 3. The comment in the test is referencing the old method name: > > 26 * @summary Basic test for Unsafe::deallocate > > > Regards, Peter > > On 12/13/2016 08:47 PM, Chris Hegarty wrote: >> Taking into account the feedback so far, and changing the method name ( since >> it is an attractive nuisance ), here is where I think we ended up. >> >> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ >> >> If this is agreeable, I?ll file an issue in JIRA to track the code changes, and >> update JEP 260. >> >> -Chris. > From amy.lu at oracle.com Wed Dec 14 13:06:05 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 14 Dec 2016 21:06:05 +0800 Subject: JDK 9 RFR of JDK-8171234: Remove intermittent key from test java/nio/charset/coders/BashStreams.java Message-ID: java/nio/charset/coders/BashStreams.java This test was failing intermittently, related issue JDK-8149712 does not exist anymore. Test has been brought back to run since 9/142 and no open bugs (no failure reported) since then. This patch is to remove @key intermittent from the test. bug: https://bugs.openjdk.java.net/browse/JDK-8171234 webrev: http://cr.openjdk.java.net/~amlu/8171234/webrev.00/ Thanks, Amy --- old/test/java/nio/charset/coders/BashStreams.java 2016-12-14 21:03:14.000000000 +0800 +++ new/test/java/nio/charset/coders/BashStreams.java 2016-12-14 21:03:14.000000000 +0800 @@ -23,7 +23,7 @@ /* @test * @summary Stochastic test of charset-based streams - * @key randomness intermittent + * @key randomness */ import java.io.*; From Alan.Bateman at oracle.com Wed Dec 14 14:08:48 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Wed, 14 Dec 2016 14:08:48 +0000 Subject: JDK 9 RFR of JDK-8171234: Remove intermittent key from test java/nio/charset/coders/BashStreams.java In-Reply-To: References: Message-ID: Looks fine. On 14/12/2016 13:06, Amy Lu wrote: > java/nio/charset/coders/BashStreams.java > > This test was failing intermittently, related issue JDK-8149712 does > not exist anymore. > Test has been brought back to run since 9/142 and no open bugs (no > failure reported) since then. > > This patch is to remove @key intermittent from the test. > > bug: https://bugs.openjdk.java.net/browse/JDK-8171234 > webrev: http://cr.openjdk.java.net/~amlu/8171234/webrev.00/ > > Thanks, > Amy > > --- old/test/java/nio/charset/coders/BashStreams.java 2016-12-14 > 21:03:14.000000000 +0800 > +++ new/test/java/nio/charset/coders/BashStreams.java 2016-12-14 > 21:03:14.000000000 +0800 > @@ -23,7 +23,7 @@ > > /* @test > * @summary Stochastic test of charset-based streams > - * @key randomness intermittent > + * @key randomness > */ > > import java.io.*; > > > From Roger.Riggs at Oracle.com Wed Dec 14 15:00:22 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Wed, 14 Dec 2016 10:00:22 -0500 Subject: RFR: JDK-8164923, JDK-8170566, JDK-8169482, JDK-8170653 In-Reply-To: <4ddd2ba3-bf3f-4668-ba02-015a2d19c6a9@default> References: <4ddd2ba3-bf3f-4668-ba02-015a2d19c6a9@default> Message-ID: <5a6564d7-98d9-a999-4187-8fbaf983c8e5@Oracle.com> Hi Abhijit, These editorial corrections are fine. Roger On 12/14/2016 1:18 AM, Abhijit Roy wrote: > Hi all, > > > > Please review the java doc fixes for the below bugs: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164923 > > Description: Error in the documentation for java.lang.Random > > Webrev: http://cr.openjdk.java.net/%7Erpatil/8164923/webrev.00/ > > > > Bug : https://bugs.openjdk.java.net/browse/JDK-8170566 > > Description: Incorrect phrase usage in javadocs documentation > > Webrev: http://cr.openjdk.java.net/%7Erpatil/8170566/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169482 > > Description: java.time.DateTimeFormatter javadoc: F is not week-of-month > > Webrev: http://cr.openjdk.java.net/%7Erpatil/8169482/webrev.00/ > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8170653 > > Description: The javadoc of ZoneRules.previousTransition() is wrong > > Webrev: http://cr.openjdk.java.net/%7Erpatil/8170653/webrev.00/ > > > > I have just rectified and modified those errors. And moving forward it for review. > > > > Regards, > > Abhijit From rob.mckenna at oracle.com Wed Dec 14 15:59:13 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Wed, 14 Dec 2016 15:59:13 +0000 Subject: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections Message-ID: <20161214155913.GC2524@tecra> Hi folks, Looking for a review of this change: http://cr.openjdk.java.net/~robm/8169465/webrev.01/ This is necessary to fix a potential problem where recursive ldap calls can potentially cause a deadlock with the PoolCleaner thread. See: https://bugs.openjdk.java.net/browse/JDK-8169465 -Rob From christoph.langer at sap.com Wed Dec 14 16:28:34 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 14 Dec 2016 16:28:34 +0000 Subject: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type In-Reply-To: <58507390.3040009@oracle.com> References: <3f0ee9feb8f9427a86efd4b4482a9b62@DEWDFE13DE03.global.corp.sap> <58507390.3040009@oracle.com> Message-ID: <11b65ab2a3cc4e079bf3128361d4ef64@DEWDFE13DE03.global.corp.sap> Hi Joe, ok, the test is added: http://cr.openjdk.java.net/~clanger/webrevs/8169112.1/ I'm ready to push, once you are ok with it. One question: Is the copyright year of WithParam.java really 2016 or should it be corrected? I guess I should also request a downport to jdk8 immediately, as it is a regression, right? Best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Dienstag, 13. Dezember 2016 23:18 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net; Aleks Efimov ; jeff Dinkins Subject: Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) Register 10 contains wrong type Hi Christoph, For the test, yes, please add an unit test based on the test submitted, sanitize / remove any private information in the original test where necessary. Best regards, Joe On 12/13/16, 12:31 PM, Langer, Christoph wrote: Hi, this is the fix for the regression introduced with 8150704. Please review. Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169112.0/ The problem occurs during "outlining" of a translet method. Outlining happens when the size of bytecode for a translet method exceeds the bytecode limit per method imposed by Java and means splitting the code into smaller methods. 8150704 added the new local variable "_domAdapter" to the implementation of "WithParam" without setting the end of its scope. This somehow leads to issues in outlining and the local variable in the new method might be loaded without being initialized. The problem is not observed for smaller translets where probably outlining is not performed. Shall I create a new jtreg test from the example attached to the bug? I would just run the sample transformation and the test is passed when no exception occurs. Best regards Christoph From paul.sandoz at oracle.com Wed Dec 14 16:30:04 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Wed, 14 Dec 2016 08:30:04 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: > On 13 Dec 2016, at 19:37, Martin Buchholz wrote: > > Hotspot appears to have support for the array filling code pattern, but Arrays.fill itself is not intrinsified. Yes. I suspect in general it should be ok here. FWIW i still would like to make it an explicit intrinsic and improve the code generation. > There are bounds checks which hotspot may not be able to elide. Ah, yes, its the range fill that performs explicit checks (also with the IAE vs IOOBE, we are inconsistent in the handling of this in other places). If this is an issue I think we could probably improve this, since the loop anyway has to check the bounds, so perhaps could branch on >=, then branch on >. Paul. > For almost all software, Arrays.fill is good enough, but core library collections are an exception. Also, we introduce other little abstractions like shiftTailOverGap and circularClear. Another possibility is to introduce our own tiny helper method without checks > > nullOutSlice(Object[] a, int from, int to) > > On Tue, Dec 13, 2016 at 5:26 PM, Paul Sandoz > wrote: > > One general question: why did you replace Arrays.fill with an explicit loop in many cases? > From daniel.fuchs at oracle.com Wed Dec 14 16:58:57 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Wed, 14 Dec 2016 16:58:57 +0000 Subject: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections In-Reply-To: <20161214155913.GC2524@tecra> References: <20161214155913.GC2524@tecra> Message-ID: <058ced05-487e-5f0a-c4e8-4d0680811d57@oracle.com> Hi Rob, The expire(long) method is already synchronized, so there's no need to call synchronized(this) inside, unless you forgot to to remove synchronized from the method declaration? I wonder if 'conns' could be created as a CopyOnWriteArrayList. Then maybe no synchronization would be needed? It's the first time I'm looking at this file - so please accept this as a suggestion for a simpler (and possibly insufficient) alternative ... best regards, -- daniel On 14/12/16 15:59, Rob McKenna wrote: > Hi folks, > > Looking for a review of this change: > > http://cr.openjdk.java.net/~robm/8169465/webrev.01/ > > This is necessary to fix a potential problem where recursive ldap calls > can potentially cause a deadlock with the PoolCleaner thread. > > See: https://bugs.openjdk.java.net/browse/JDK-8169465 > > -Rob > From martinrb at google.com Wed Dec 14 17:07:42 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 Dec 2016 09:07:42 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: Yeah, I'm not happy with Arrays.rangeCheck. It's hotspot's job to do (and optimize away) array bounds checks, and provide informative exception messages when a check fails. On at least one occasion I wanted to have fromIndex > toIndex be a no-op. The exceptions on Arrays.fill are all spec'ed out - I'm not hoping to be able to change them. On Wed, Dec 14, 2016 at 8:30 AM, Paul Sandoz wrote: > > On 13 Dec 2016, at 19:37, Martin Buchholz wrote: > > Hotspot appears to have support for the array filling code pattern, but > Arrays.fill itself is not intrinsified. > > > Yes. I suspect in general it should be ok here. FWIW i still would like to > make it an explicit intrinsic and improve the code generation. > > > There are bounds checks which hotspot may not be able to elide. > > > Ah, yes, its the range fill that performs explicit checks (also with the > IAE vs IOOBE, we are inconsistent in the handling of this in other places). > > If this is an issue I think we could probably improve this, since the loop > anyway has to check the bounds, so perhaps could branch on >=, then branch > on >. > > Paul. > > For almost all software, Arrays.fill is good enough, but core library > collections are an exception. Also, we introduce other little abstractions > like shiftTailOverGap and circularClear. Another possibility is to > introduce our own tiny helper method without checks > > nullOutSlice(Object[] a, int from, int to) > > On Tue, Dec 13, 2016 at 5:26 PM, Paul Sandoz > wrote: > >> >> One general question: why did you replace Arrays.fill with an explicit >> loop in many cases? >> >> > From aleksej.efimov at oracle.com Wed Dec 14 18:04:08 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 14 Dec 2016 21:04:08 +0300 Subject: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance In-Reply-To: <585093BD.1020904@oracle.com> References: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> <585093BD.1020904@oracle.com> Message-ID: <803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com> Hi Joe, Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier' instead of 'String'? Such approach will give us a possibility to do the output string calculation only when debugging is switched on. Such approach can be illustrated by this webrev: http://cr.openjdk.java.net/~aefimov/8146271/9/01 Best Regards, Aleksej On 14/12/16 03:35, Joe Wang wrote: > Hi Aleksej, > > You may want to improve the debugPrintln or its usage to remove the > String concatenations or method calls such as f.getClass().getName() > that are unnecessary when debug == false. Where we are here, could you > expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) > where similar problems exist. > > Best, > Joe > > On 12/13/16, 3:02 PM, Aleks Efimov wrote: >> Hello, >> >> Please, help to review the changes that addresses the file system >> contention caused by debug code in XPathFactoryFinder and >> XPathFactoryFinder classes [1]. Proposed fix wraps the debug output >> code in "if(debug)" block: >> http://cr.openjdk.java.net/~aefimov/8146271/9/00/ >> >> Best Regards, >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8146271 >> From erik.joelsson at oracle.com Wed Dec 14 18:23:45 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 14 Dec 2016 19:23:45 +0100 Subject: (urgent) RFR: JDK-8171245: Solaris builds fails after JDK-8170663 Message-ID: Hello, Please review this small fix for a warning in java_md_solinux.c which was introduced with JDK-8170663. The error message is: "/opt/jprt/jprtadm/erik/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 519: error: declaration can not follow a statement (E_DECLARATION_IN_CODE) My attempted fix just adds a new scope around the new variable declaration and it's use. That pattern seems to be used several times already in the file. This bug is currently preventing all Solaris builds at Oracle. Bug: https://bugs.openjdk.java.net/browse/JDK-8171245 Webrev: http://cr.openjdk.java.net/~erikj/8171245/webrev.01/ /Erik From naoto.sato at oracle.com Wed Dec 14 18:24:15 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Wed, 14 Dec 2016 10:24:15 -0800 Subject: (urgent) RFR: JDK-8171245: Solaris builds fails after JDK-8170663 In-Reply-To: References: Message-ID: <1318f8f0-4f69-19e2-1031-147ca29587a0@oracle.com> Looks good. Naoto On 12/14/16 10:23 AM, Erik Joelsson wrote: > Hello, > > Please review this small fix for a warning in java_md_solinux.c which > was introduced with JDK-8170663. The error message is: > > "/opt/jprt/jprtadm/erik/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", > line 519: error: declaration can not follow a statement > (E_DECLARATION_IN_CODE) > > My attempted fix just adds a new scope around the new variable > declaration and it's use. That pattern seems to be used several times > already in the file. > > This bug is currently preventing all Solaris builds at Oracle. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171245 > > Webrev: http://cr.openjdk.java.net/~erikj/8171245/webrev.01/ > > /Erik > From uschindler at apache.org Wed Dec 14 19:10:43 2016 From: uschindler at apache.org (Uwe Schindler) Date: Wed, 14 Dec 2016 20:10:43 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <66199530-cc41-b3a6-4276-89f2bc9773a8@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> <66199530-cc41-b3a6-4276-89f2bc9773a8@oracle.com> Message-ID: <00f001d2563d$c86bafa0$59430ee0$@apache.org> Hi Chris, looks good to me. I already created a patch / branch of Apache Lucene that uses your proposed API and removes the Runnable hack. You can see it and check it out on Github: For your info the issue description and description is: If you would like to test it against your patch, check out this branch, run "ant ivy-bootstrap" and then cd into the lucene/core dirto execute: $ ant test -Dtestcase=TestMmapDirectory Those tests should run without any error message (disabled test because unmapping not supported): [junit4] Started J0 PID(3464 at localhost). [junit4] Suite: org.apache.lucene.store.TestMmapDirectory [junit4] OK 0.07s | TestMmapDirectory.testIllegalEOF [junit4] OK 0.01s | TestMmapDirectory.testShort [junit4] OK 0.06s | TestMmapDirectory.testRandomInt [junit4] OK 0.02s | TestMmapDirectory.testFsyncDoesntCreateNewFiles [junit4] OK 0.01s | TestMmapDirectory.testSetOfStrings [junit4] OK 0.01s | TestMmapDirectory.testLargeWrites [junit4] OK 0.01s | TestMmapDirectory.testMapOfStrings [junit4] OK 0.01s | TestMmapDirectory.testSliceOfSlice [junit4] OK 0.01s | TestMmapDirectory.testByte [junit4] OK 0.01s | TestMmapDirectory.testVInt [junit4] OK 0.01s | TestMmapDirectory.testChecksum [junit4] OK 0.02s | TestMmapDirectory.testZLong [junit4] OK 0.06s | TestMmapDirectory.testRandomShort [junit4] OK 0.01s | TestMmapDirectory.testRename [junit4] OK 0.10s | TestMmapDirectory.testCreateTempOutput [junit4] OK 0.01s | TestMmapDirectory.testZInt [junit4] OK 0.01s | TestMmapDirectory.testIndexOutputToString [junit4] OK 0.01s | TestMmapDirectory.testDetectClose [junit4] OK 0.03s | TestMmapDirectory.testListAllIsSorted [junit4] OK 0.01s | TestMmapDirectory.testDoubleCloseDirectory [junit4] OK 0.00s | TestMmapDirectory.testDirectoryFilter [junit4] OK 0.11s | TestMmapDirectory.testPendingDeletions [junit4] OK 0.04s | TestMmapDirectory.testCopyFromDestination [junit4] OK 0.01s | TestMmapDirectory.testDeleteFile [junit4] OK 0.04s | TestMmapDirectory.testCopyBytesWithThreads [junit4] OK 0.03s | TestMmapDirectory.testRandomByte [junit4] IGNORED 0.00s | TestMmapDirectory.testAceWithThreads [junit4] > Cause: Annotated @Ignore(This test is for JVM testing purposes. There are no guarantees that it may not fail with SIGSEGV!) [junit4] OK 0.02s | TestMmapDirectory.testNoDir [junit4] OK 0.01s | TestMmapDirectory.testSeekBeyondEndOfFile [junit4] OK 0.13s | TestMmapDirectory.testRandomLong [junit4] OK 0.01s | TestMmapDirectory.testDoubleCloseInput [junit4] OK 0.01s | TestMmapDirectory.testSliceOutOfBounds [junit4] OK 2.75s | TestMmapDirectory.testThreadSafety [junit4] OK 0.01s | TestMmapDirectory.testSeekToEndOfFile [junit4] OK 0.00s | TestMmapDirectory.testLong [junit4] OK 0.01s | TestMmapDirectory.testCopyFrom [junit4] OK 0.00s | TestMmapDirectory.testString [junit4] OK 0.01s | TestMmapDirectory.testSeekToEOFThenBack [junit4] OK 0.00s | TestMmapDirectory.testInt [junit4] OK 0.01s | TestMmapDirectory.testSeekPastEOF [junit4] OK 0.02s | TestMmapDirectory.testCopyBytes [junit4] OK 0.01s | TestMmapDirectory.testVLong [junit4] OK 0.01s | TestMmapDirectory.testDoubleCloseOutput [junit4] Completed [1/1] in 5.14s, 43 tests, 1 skipped With Java 9 build 148 it currently looks like this: [junit4] Suite: org.apache.lucene.store.TestMmapDirectory [junit4] IGNOR/A 0.04s | TestMmapDirectory.testShort [junit4] > Assumption #1: test requires a jre that supports unmapping: Unmapping is not supported on this platform, because internal Java APIs are not compatible to this Lucene version: java.lang.reflect.InaccessibleObjectException: Unable to make public jdk.internal.ref.Cleaner java.nio.DirectByteBuffer.cleaner() accessible: module java.base does not "opens java.nio" to unnamed module @45c7ad7f Don't care about the Groovy error printed later, this one is known, but does not affect testing. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Wednesday, December 14, 2016 12:58 PM > To: Peter Levart ; Core-Libs-Dev dev at openjdk.java.net>; jigsaw-dev ; Uwe > Schindler > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Webrev updated in-place. > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > -Chris. > > On 13/12/16 21:18, Peter Levart wrote: > > I think this is OK. > > > > Just a couple of nits in test: > > > > 1. You create a static Path bob = Paths.get("bob") field, but then you > > don't use it in: > > > > 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), > > CREATE, WRITE)) { > > > > 2. badBuffers could include a duplicate and a slice of a direct buffer > > allocated with ByteBuffer.allocateDirect() > > > > 3. The comment in the test is referencing the old method name: > > > > 26 * @summary Basic test for Unsafe::deallocate > > > > > > Regards, Peter > > > > On 12/13/2016 08:47 PM, Chris Hegarty wrote: > >> Taking into account the feedback so far, and changing the method name ( > since > >> it is an attractive nuisance ), here is where I think we ended up. > >> > >> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > >> > >> If this is agreeable, I?ll file an issue in JIRA to track the code changes, and > >> update JEP 260. > >> > >> -Chris. > > From huizhe.wang at oracle.com Wed Dec 14 19:25:32 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 14 Dec 2016 11:25:32 -0800 Subject: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance In-Reply-To: <803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com> References: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> <585093BD.1020904@oracle.com> <803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com> Message-ID: <58519CAC.1060604@oracle.com> Hi Aleksej, Looks good. Thanks for covering the whole packages! Best, Joe On 12/14/16, 10:04 AM, Aleks Efimov wrote: > Hi Joe, > > Thank you for the suggestions. What about modifying the 'debugPrintln' > and 'dPrint' functions to accept 'j.u.function.Supplier' > instead of 'String'? Such approach will give us a possibility to do > the output string calculation only when debugging is switched on. Such > approach can be illustrated by this webrev: > http://cr.openjdk.java.net/~aefimov/8146271/9/01 > > Best Regards, > Aleksej > > > On 14/12/16 03:35, Joe Wang wrote: >> Hi Aleksej, >> >> You may want to improve the debugPrintln or its usage to remove the >> String concatenations or method calls such as f.getClass().getName() >> that are unnecessary when debug == false. Where we are here, could >> you expand the patch to cover other jaxp packages (e.g. >> javax.xml.parsers) where similar problems exist. >> >> Best, >> Joe >> >> On 12/13/16, 3:02 PM, Aleks Efimov wrote: >>> Hello, >>> >>> Please, help to review the changes that addresses the file system >>> contention caused by debug code in XPathFactoryFinder and >>> XPathFactoryFinder classes [1]. Proposed fix wraps the debug output >>> code in "if(debug)" block: >>> http://cr.openjdk.java.net/~aefimov/8146271/9/00/ >>> >>> Best Regards, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8146271 >>> > From huizhe.wang at oracle.com Wed Dec 14 20:52:02 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 14 Dec 2016 12:52:02 -0800 Subject: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type In-Reply-To: <11b65ab2a3cc4e079bf3128361d4ef64@DEWDFE13DE03.global.corp.sap> References: <3f0ee9feb8f9427a86efd4b4482a9b62@DEWDFE13DE03.global.corp.sap> <58507390.3040009@oracle.com> <11b65ab2a3cc4e079bf3128361d4ef64@DEWDFE13DE03.global.corp.sap> Message-ID: <5851B0F2.6060102@oracle.com> On 12/14/16, 8:28 AM, Langer, Christoph wrote: > > Hi Joe, > > ok, the test is added: > http://cr.openjdk.java.net/~clanger/webrevs/8169112.1/ > > > I'm ready to push, once you are ok with it. > Yes, looks good. > > One question: Is the copyright year of WithParam.java really 2016 or > should it be corrected? > That's fine. It just means that no change has been made to the original class before 2016. > > I guess I should also request a downport to jdk8 immediately, as it is > a regression, right? > Yes, that would be great. Please create a patch for JDK 8 or work with Aleksej (Aleksej backported your previous patch), and ask for approval through the jdk8-dev alias. Best, Joe > Best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Dienstag, 13. Dezember 2016 23:18 > *To:* Langer, Christoph > *Cc:* core-libs-dev at openjdk.java.net; Aleks Efimov > ; jeff Dinkins > *Subject:* Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: > GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) > Register 10 contains wrong type > > Hi Christoph, > > For the test, yes, please add an unit test based on the test > submitted, sanitize / remove any private information in the original > test where necessary. > > Best regards, > Joe > > On 12/13/16, 12:31 PM, Langer, Christoph wrote: > > Hi, > > this is the fix for the regression introduced with 8150704. Please > review. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8169112.0/ > > > The problem occurs during "outlining" of a translet method. > Outlining happens when the size of bytecode for a translet method > exceeds the bytecode limit per method imposed by Java and means > splitting the code into smaller methods. 8150704 added the new > local variable "_domAdapter" to the implementation of "WithParam" > without setting the end of its scope. This somehow leads to issues > in outlining and the local variable in the new method might be > loaded without being initialized. The problem is not observed for > smaller translets where probably outlining is not performed. > > Shall I create a new jtreg test from the example attached to the > bug? I would just run the sample transformation and the test is > passed when no exception occurs. > > Best regards > > Christoph > From huizhe.wang at oracle.com Wed Dec 14 20:52:58 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Wed, 14 Dec 2016 12:52:58 -0800 Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 In-Reply-To: <50e1e534b3924d59b16d4d4467badab6@DEWDFE13DE03.global.corp.sap> References: <584EF6DA.8080307@oracle.com> <1efbdc1c876f48788eda832dce3b3d8f@DEWDFE13DE03.global.corp.sap> <58509558.8070607@oracle.com> <50e1e534b3924d59b16d4d4467badab6@DEWDFE13DE03.global.corp.sap> Message-ID: <5851B12A.6060602@oracle.com> Thanks Christoph! On 12/13/16, 11:53 PM, Langer, Christoph wrote: > Thanks, Joe. > > Overall, this looks better. > >> -----Original Message----- >> From: Joe Wang [mailto:huizhe.wang at oracle.com] >> Sent: Mittwoch, 14. Dezember 2016 01:42 >> To: Langer, Christoph >> Cc: core-libs-dev at openjdk.java.net >> Subject: Re: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 >> >> Thanks Christoph! >> >> I updated the webrev for the classes you mentioned below, in a few >> cases, used NetBeans' source format feature -- not for all of the >> classes though (esp. the crazily large >> XMLDocumentFragmentScannerImpl.java, it gets better though, overtime). >> >> http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ >> >> Best regards, >> Joe >> >> On 12/13/16, 2:14 PM, Langer, Christoph wrote: >>> Hi Joe, >>> >>> looks nice, thanks for doing that. >>> >>> Here are a few findings: >>> >>> >> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStre >> amReaderImpl.java: >>> -> import statements could be ordered alphabetically >>> 262 fEntityScanner = fEntityManager.getEntityScanner() ; >>> -> spaces before ; >>> 1317 protected List getEntityDecls(){ >>> -> space before opening { >>> 1322 if(entities.size()> 0){ >>> -> spaces after if, before { >>> 1344 protected List getNotationDecls(){ >>> -> space before { >>> 1352 if(notation!= null){ >>> -> spaces >>> >>> >> src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.jav >> a >>> 145 } >>> 146 /** >>> -> insert blank line in between >>> >>> >> src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DT >> DGrammar.java >>> 734 public List getNotationDecls(){ >>> -> blank before { >>> >>> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/DTDEvent.jav >> a >>> 66 public void setEntities(List entites){ >>> -> space before {; variable name entites -> entities >>> 77 public void setNotations(List notations){ >>> -> space >>> 94 protected final void init(){ >>> -> space >>> >>> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/EndElementE >> vent.java >>> -> order import statements alphabetically >>> 48 QName fQName ; >>> -> space >>> 105 void addNamespace(Namespace ns){ >>> -> space >>> 106 if(ns != null){ >>> -> spaces >>> >>> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/StartElement >> Event.java >>> -> import statements order, a few space issues >>> >>> >> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLEventWr >> iterImpl.java >>> 68 public void add(javax.xml.stream.XMLEventReader xMLEventReader) >> throws XMLStreamException { >>> 80 public void add(javax.xml.stream.events.XMLEvent xMLEvent) throws >> XMLStreamException { >>> -> you should be able to use unqualified names for parameters >>> >>> >> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStream >> WriterImpl.java >>> 906 ElementState elem; >>> 907 >>> 908 while (!fElementStack.empty()) { >>> 909 elem = fElementStack.pop(); >>> -> I think elem can be declared in line 909 as well, scope is only within >> while() block >>> Best regards >>> Christoph >>> >>> >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On >> Behalf >>>> Of Joe Wang >>>> Sent: Montag, 12. Dezember 2016 20:14 >>>> To: core-libs-dev at openjdk.java.net >>>> Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 >>>> >>>> Hi, >>>> >>>> This was the cleanup portion of the change for JDK-8167340. As Lance >>>> suggested, it was split from the original webrev. In addition to that >>>> cleanup, I've added coverage to the entire StAX packages. This cleanup >>>> will reduce 138 warnings. >>>> >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8170556 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ >>>> >>>> Thanks, >>>> Joe From david.holmes at oracle.com Wed Dec 14 20:54:36 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2016 06:54:36 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> <1238bad1-1805-e57a-2360-196e44770521@oracle.com> Message-ID: <3072c9a4-f810-4abf-0f8e-3b025af92b3e@oracle.com> Hi Goetz, On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote: > >> object to the change to k_standard.c for the same reason. > Ok, I remove that too. I had not realized this was to be pushed directly to jdk9/dev. It broke builds on Solaris and so was obviously not tested. David > Best regards, > Goetz. > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Mittwoch, 14. Dezember 2016 12:29 >> To: Lindenmaier, Goetz ; >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: >>> Hi, >>> >>> You're right, I had removed the change to e_asin.c. >> >> You only pointed Joe to that file AFAICS. I would expect he would also >> object to the change to k_standard.c for the same reason. >> >>> New webrev anyways: >>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.05/ >>> >>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. >> >> Okay. Thanks. >> >> David >> >>> Best regards, >>> Goetz. >>> >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 14. Dezember 2016 11:42 >>>> To: Lindenmaier, Goetz ; >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: >>>>> Hi David, >>>>> >>>>> I found "8169317: [s390] Various minor bug fixes and adaptions." >>>>> in jdk9/dev this morning, so I thought it has been promoted based >>>>> on some older change. I waited for that quite a while because tests >>>>> in jdk9/dev kept failing on s390. >>>>> How can I get the information when what was promoted? This always >>>>> is a wild guess for me ... as well as when what will be promoted :) >>>> >>>> Yeah there's no notification in the bug report of when hs pushes up to >>>> dev. The changeset email is the only record of exactly when it happens. >>>> >>>>> Do you think the promotion will happen tonight, or will it take >>>>> another week? >>>> >>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to >>>> dev. There have been delays in getting that started and so a delay in it >>>> finishing and being analyzed. It may still be a couple of days. >>>> >>>>> I removed >>>>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib//jli:") >> + >>>>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + JLI_StrLen("/lib/jli:") + >>>>> from >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663-corlib_s11y/webrev.04/ >>>> >>>> With that gone that file only has the jvmpath rename - which isn't >>>> fixing anything. >>>> >>>> Joe also asked for the fdlibm changes to dropped. >>>> >>>> Thanks, >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 14. Dezember 2016 11:04 >>>>>> To: Lindenmaier, Goetz ; >>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>>>> ; Java Core Libs >>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>>>> coding. >>>>>> >>>>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi, >>>>>>> >>>>>>> 8066474 has not been promoted. >>>>>> >>>>>> hs has not been able to push up to dev yet. >>>>>> >>>>>>> I'll remove the strlen // fix for aix from this change and >>>>>>> push it without it. I'd like to get this done. >>>>>> >>>>>> I've lost track of what is now left in this set of changes ?? >>>>>> >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 >>>>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >>>>>>>> ; 'Dmitry Samersoff' >>>>>>>> ; Java Core Libs >>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>> dev at openjdk.java.net) >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >> servicabilty >>>>>>>> coding. >>>>>>>> >>>>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>>>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: >>>>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>> Hi David, >>>>>>>>>>> >>>>>>>>>>> thanks for looking at the change. New webrev: >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>> corlib_s11y/webrev.04/ >>>>>>>>>>> >>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>>>>>>>> >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>>>>>> expanded with: >>>>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>>>>>>>> 8066474, >>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>>>>>>>> but the // was not adapted. Then I moved the change to jdk9/dev >>>>>> because >>>>>>>>>>> I thought I have to push it there. And yes, in that coding // would >>>>>>>>>>> be correct. >>>>>>>>>>> So I have to wait until hs is promoted ... >>>>>>>>>> >>>>>>>>>> So just based on the current file, the change proposed - to remove >> one >>>>>>>>>> / - is not correct until the arch directory is removed. >>>>>>>>> >>>>>>>>> That change is already in JDK9-hs: >>>>>>>>> >>>>>>>>> Changeset: c14f9a7b4cab >>>>>>>>> Author: erikj >>>>>>>>> Date: 2016-12-05 17:55 +0100 >>>>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>>>>>>>> >>>>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris images >>>>>>>>> Reviewed-by: tbell, ihse >>>>>>>>> >>>>>>>>> along with changesets in the jdk and hotspot repos along with a few >>>>>>>>> closed repos. >>>>>>>> >>>>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - >> where >>>>>>>> removing the extra / would be correct. >>>>>>>> >>>>>>>> David >>>>>>>> ----- >>>>>>>> >>>>>>>>> Dan >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>>>>>> comment on >>>>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>>> Dmitry asked me to add it. But I think it's ok. >>>>>>>>>>> >>>>>>>>>>> Can I consider this reviewed now? I.e. could I push it once 8066474 >> is >>>>>>>>>>> promoted and Joe Darcy agreed? >>>>>>>>>>> >>>>>>>>>>> Best regards, >>>>>>>>>>> Goetz. >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>>>>>>>> To: Lindenmaier, Goetz ; 'Dmitry >>>>>>>> Samersoff' >>>>>>>>>>>> ; Java Core Libs >>>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>>>> servicabilty >>>>>>>>>>>> coding. >>>>>>>>>>>> >>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>> >>>>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>> >>>>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>>>>>>>> I also merged the ifs in SDE.c. >>>>>>>>>>>>> >>>>>>>>>>>>> new webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>> corlib_s11y/webrev.03/ >>>>>>>>>>>> >>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>> >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>>>> Given a >>>>>>>>>>>> jvm.cfg with: >>>>>>>>>>>> >>>>>>>>>>>> -server KNOWN >>>>>>>>>>>> -client IGNORE >>>>>>>>>>>> -myvm KNOWN >>>>>>>>>>>> -oldvm ALIASED_TO -server >>>>>>>>>>>> >>>>>>>>>>>> The usage text is: >>>>>>>>>>>> >>>>>>>>>>>> -server to select the "server" VM >>>>>>>>>>>> -myvm to select the "myvm" VM >>>>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>>>>>>>> The default VM is server, >>>>>>>>>>>> because you are running on a server-class machine. >>>>>>>>>>>> >>>>>>>>>>>> which is exactly what I would expect. Why do you think there is a >>>> bug? >>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> >>>>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>> >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output string is >>>>>>>>>>>> expanded with: >>>>>>>>>>>> >>>>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>>>> >>>>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - and that >>>>>>>>>>>> is exactly what the existing code does: >>>>>>>>>>>> >>>>>>>>>>>> + JLI_StrLen("/lib//jli:") >>>>>>>>>>>> >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - a >>>>>>>>>>>> comment on >>>>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>>>> >>>>>>>>>>>> Thanks, >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: Dmitry Samersoff [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; Java >> Core >>>>>> Libs >>>>>>>>>>>>>> ; serviceability-dev >>>> (serviceability- >>>>>>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>>>>>> servicabilty >>>>>>>>>>>>>> coding. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> SDE.c: >>>>>>>>>>>>>> >>>>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>>>>>>>> matter of test. >>>>>>>>>>>>>> >>>>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>>>>>>>> } >>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>>> >>>>>>>>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>>>>>>>> >>>>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>>>>>>>> >>>>>>>>>>>>>> is never run and we effectively do >>>>>>>>>>>>>> >>>>>>>>>>>>>> *entryCountPtr = 0; >>>>>>>>>>>>>> >>>>>>>>>>>>>> at l.283 >>>>>>>>>>>>>> >>>>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>>>>>>>> (your v.01 changes) >>>>>>>>>>>>>> >>>>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>>>>>>>> 261 return; >>>>>>>>>>>>>> 262 } >>>>>>>>>>>>>> >>>>>>>>>>>>>> it's better to check it early. >>>>>>>>>>>>>> >>>>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt here. >>>>>>>>>>>>>> >>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> thanks for looking at my change! >>>>>>>>>>>>>>> Updated webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>> corlib_s11y/webrev.02 >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>>>>>> Is this line correct? >>>>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>>>>>>>> horror.) >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>>>>>>>> regardless of value of sti. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>>>>>>>> It might be better to write >>>>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Yes, looks better. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> This change fixes some minor issues found in our code >> scans. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability >> issues. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Please review: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Changes in detail: >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> e_asin.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the inexact >>>>>>>>>>>>>>>>> flag of >>>>>>>>>>>>>>>>> the processor. >>>>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code >> away. >>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>> always true, >>>>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Although this basically just adds the {} I would like to submit >>>>>>>>>>>>>>>>> this to >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on understanding >>>>>> these >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> if statements. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> k_standard.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>>>>>>>> initialized. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David CARLIER >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> java.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> java_md_solinux.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> SDE.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>>>>>>>> defaultStratumId >>>>>>>>>>>>>>>>> == null. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> socket_md.c >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use is >>>>>>>>>>>>>>>>> hidden in >>>>>>>>>>>>>>>>> the macros. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> unpack.cpp >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> n.slice should not get negative argument for end, which is >>>>>>>>>>>>>>>>> passed from >>>>>>>>>>>>>>>>> dollar1. >>>>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result of >>>>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>>>>>> * I would love to change the world, but they won't give me >> the >>>>>>>>>>>>>>>> sources. >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> -- >>>>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>>>> * I would love to change the world, but they won't give me the >>>>>>>>>>>>>> sources. >>>>>>>>> From christoph.langer at sap.com Wed Dec 14 20:52:54 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Wed, 14 Dec 2016 20:52:54 +0000 Subject: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance In-Reply-To: <58519CAC.1060604@oracle.com> References: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> <585093BD.1020904@oracle.com> <803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com> <58519CAC.1060604@oracle.com> Message-ID: +1 This is cool :) > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Joe Wang > Sent: Mittwoch, 14. Dezember 2016 20:26 > To: Aleks Efimov > Cc: core-libs-dev > Subject: Re: RFR (JAXP) 8146271: File system contention in debug print via > XPathFactory.newInstance > > Hi Aleksej, > > Looks good. Thanks for covering the whole packages! > > Best, > Joe > > On 12/14/16, 10:04 AM, Aleks Efimov wrote: > > Hi Joe, > > > > Thank you for the suggestions. What about modifying the 'debugPrintln' > > and 'dPrint' functions to accept 'j.u.function.Supplier' > > instead of 'String'? Such approach will give us a possibility to do > > the output string calculation only when debugging is switched on. Such > > approach can be illustrated by this webrev: > > http://cr.openjdk.java.net/~aefimov/8146271/9/01 > > > > Best Regards, > > Aleksej > > > > > > On 14/12/16 03:35, Joe Wang wrote: > >> Hi Aleksej, > >> > >> You may want to improve the debugPrintln or its usage to remove the > >> String concatenations or method calls such as f.getClass().getName() > >> that are unnecessary when debug == false. Where we are here, could > >> you expand the patch to cover other jaxp packages (e.g. > >> javax.xml.parsers) where similar problems exist. > >> > >> Best, > >> Joe > >> > >> On 12/13/16, 3:02 PM, Aleks Efimov wrote: > >>> Hello, > >>> > >>> Please, help to review the changes that addresses the file system > >>> contention caused by debug code in XPathFactoryFinder and > >>> XPathFactoryFinder classes [1]. Proposed fix wraps the debug output > >>> code in "if(debug)" block: > >>> http://cr.openjdk.java.net/~aefimov/8146271/9/00/ > >>> > >>> Best Regards, > >>> Aleksej > >>> > >>> [1] https://bugs.openjdk.java.net/browse/JDK-8146271 > >>> > > From david.holmes at oracle.com Wed Dec 14 21:09:22 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2016 07:09:22 +1000 Subject: (urgent) RFR: JDK-8171245: Solaris builds fails after JDK-8170663 In-Reply-To: References: Message-ID: Thanks Erik. On 15/12/2016 4:23 AM, Erik Joelsson wrote: > Hello, > > Please review this small fix for a warning in java_md_solinux.c which > was introduced with JDK-8170663. The error message is: > > "/opt/jprt/jprtadm/erik/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", > line 519: error: declaration can not follow a statement > (E_DECLARATION_IN_CODE) Very surprised the Solaris compiler does not handle declarations at any point. I thought only the Visual Studio compiler still had such archaic limitations. That aside the change should have been tested before being pushed - preferably through JPRT - but was not. David ----- > My attempted fix just adds a new scope around the new variable > declaration and it's use. That pattern seems to be used several times > already in the file. > > This bug is currently preventing all Solaris builds at Oracle. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171245 > > Webrev: http://cr.openjdk.java.net/~erikj/8171245/webrev.01/ > > /Erik > From lance.andersen at oracle.com Wed Dec 14 21:16:15 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 14 Dec 2016 16:16:15 -0500 Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 In-Reply-To: <58509558.8070607@oracle.com> References: <584EF6DA.8080307@oracle.com> <1efbdc1c876f48788eda832dce3b3d8f@DEWDFE13DE03.global.corp.sap> <58509558.8070607@oracle.com> Message-ID: Hi Joe, I just finished looking at this also and it seems fine. > On Dec 13, 2016, at 7:42 PM, Joe Wang wrote: > > Thanks Christoph! > > I updated the webrev for the classes you mentioned below, in a few cases, used NetBeans' source format feature -- not for all of the classes though (esp. the crazily large XMLDocumentFragmentScannerImpl.java, it gets better though, overtime). > > http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ > > Best regards, > Joe > > On 12/13/16, 2:14 PM, Langer, Christoph wrote: >> Hi Joe, >> >> looks nice, thanks for doing that. >> >> Here are a few findings: >> >> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java: >> -> import statements could be ordered alphabetically >> 262 fEntityScanner = fEntityManager.getEntityScanner() ; >> -> spaces before ; >> 1317 protected List getEntityDecls(){ >> -> space before opening { >> 1322 if(entities.size()> 0){ >> -> spaces after if, before { >> 1344 protected List getNotationDecls(){ >> -> space before { >> 1352 if(notation!= null){ >> -> spaces >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java >> 145 } >> 146 /** >> -> insert blank line in between >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java >> 734 public List getNotationDecls(){ >> -> blank before { >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/DTDEvent.java >> 66 public void setEntities(List entites){ >> -> space before {; variable name entites -> entities >> 77 public void setNotations(List notations){ >> -> space >> 94 protected final void init(){ >> -> space >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/EndElementEvent.java >> -> order import statements alphabetically >> 48 QName fQName ; >> -> space >> 105 void addNamespace(Namespace ns){ >> -> space >> 106 if(ns != null){ >> -> spaces >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/StartElementEvent.java >> -> import statements order, a few space issues >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java >> 68 public void add(javax.xml.stream.XMLEventReader xMLEventReader) throws XMLStreamException { >> 80 public void add(javax.xml.stream.events.XMLEvent xMLEvent) throws XMLStreamException { >> -> you should be able to use unqualified names for parameters >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java >> 906 ElementState elem; >> 907 >> 908 while (!fElementStack.empty()) { >> 909 elem = fElementStack.pop(); >> -> I think elem can be declared in line 909 as well, scope is only within while() block >> >> Best regards >> Christoph >> >> >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>> Of Joe Wang >>> Sent: Montag, 12. Dezember 2016 20:14 >>> To: core-libs-dev at openjdk.java.net >>> Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 >>> >>> Hi, >>> >>> This was the cleanup portion of the change for JDK-8167340. As Lance >>> suggested, it was split from the original webrev. In addition to that >>> cleanup, I've added coverage to the entire StAX packages. This cleanup >>> will reduce 138 warnings. >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8170556 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ >>> >>> Thanks, >>> Joe Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From brian.burkhalter at oracle.com Wed Dec 14 23:20:37 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Wed, 14 Dec 2016 15:20:37 -0800 Subject: JDK 9 RFC on 8151955: java.util.prefs: removeNode() / removeNodeSpi(): Node is permanently removed even when no flush() is invoked Message-ID: <97213C55-F3BB-497C-A9A0-0BFB7F922D6F@oracle.com> The issue [1] does not seem like a bug to me as the behavior appears to be as expected from the specification but I would like to see whether anyone else agrees. Assuming the nodes ?userRoot/a? and ?userRoot/a/a1? do not already exist, if the test [2] is run twice in succession, the printed output of the first run is "a" exists: false "a1" exists: false and that of the second run is "a" exists: true "a1" exists: false This appears to be consistent with this statement in the class level specification of j.u.Preferences [3]: "Normal termination of the Java Virtual Machine will not result in the loss of pending updates -- an explicit flush invocation is not required upon termination to ensure that pending updates are made persistent.? I verified that the behavior is consistent with this across Linux, OS X, and Windows. Any comment would be appreciated. Thanks, Brian [1] https://bugs.openjdk.java.net/browse/JDK-8151955 [2] RemoveNodeTest.java import java.util.prefs.BackingStoreException; import java.util.prefs.Preferences; public class RemoveNodeTest { public static void main(String[] args) throws BackingStoreException { Preferences userRoot = Preferences.userRoot(); System.out.printf("\"a\" exists: %s%n", userRoot.nodeExists("a")); Preferences a = userRoot.node("a"); System.out.printf("\"a1\" exists: %s%n", a.nodeExists("a1")); Preferences a1 = a.node("a1"); a.flush(); a1.removeNode(); } } [3] http://download.java.net/java/jdk9/docs/api/java/util/prefs/Preferences.html From pango853 at gmail.com Thu Dec 15 02:41:59 2016 From: pango853 at gmail.com (Pango) Date: Thu, 15 Dec 2016 11:41:59 +0900 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: References: Message-ID: Hi all, May I ask has there been any progress on this issue? Actually we are also struggling with this problem. The software that we are working on do publish with 0.0.0.0 and we got this BindException while migrating to JDK 8. We tried several workarounds but it will be very inconvenient for the end users to follow. Now we are planning to release our product around next January, and really hope that there will be some good news announced by then. It would be very appreciated if anyone can give some information regarding the backport of this fix to JDK 8 update in advance. Thanks for all your hard work and contributions. Best regards, Pango Chan 2016-08-04 09:35 GMT+09:00 KUBOTA Yuji : > Hi Aleksej, > > Thank you very much! > If you need some help about the patch, please mention me :) > > Thanks, > Yuji > > 2016-08-03 19:56 GMT+09:00 Aleks Efimov : >> Hi Yuji, >> >> I've created JDK8 backport [1] for this issue and will work on it in the >> upcoming months. >> >> Best Regards, >> >> Aleksej >> >> [1] https://bugs.openjdk.java.net/browse/JDK-8162941 >> >> >> >> On 02/08/16 08:33, KUBOTA Yuji wrote: >>> >>> Hi all, >>> >>> Could you let me know when this fix will be backport to JDK 8? >>> We need this backport to migrate our system from JDK 7 to JDK 8. >>> >>> Thanks, >>> Yuji >>> >>> 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji : >>>> >>>> Hi Miroslav, >>>> >>>> Thank you for your sponsor! : >>>> https://bugs.openjdk.java.net/browse/JDK-8146086 >>>> >>>> Can I ask the schedule when does this fix backport to JDK8 ? >>>> >>>> Thanks, >>>> Yuji >>>> >>>> 2015-12-02 22:39 GMT+09:00 Miroslav Kos : >>>>> >>>>> Hi Yuji, >>>>> thanks for the patch - it fixes the issue and looks ok to me. I'll >>>>> integrate >>>>> it to standalone JAX-WS repo and it will be integrated into openjdk >>>>> during >>>>> next syncup. >>>>> >>>>> Thanks >>>>> Miran >>>>> >>>>> >>>>> >>>>> >>>>> On 01/12/15 11:11, KUBOTA Yuji wrote: >>>>>> >>>>>> Hi Miroslav and all, >>>>>> >>>>>> Could you please review the below issue and patch? >>>>>> >>>>>> I got the advice by Alan at net-dev. So I want to ask you. >>>>>> >>>>>> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html >>>>>> >>>>>> ---- >>>>>> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK >>>>>> community. This's second times from JavaOne14. :) >>>>>> >>>>>> We find an unexpected exception in JAX-WS, so I write a patch to fix >>>>>> it. >>>>>> We think that this issue may block the migration to JDK9 from JDK7. >>>>>> >>>>>> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the >>>>>> following test code, JDK9 (and JDK8) returns "java.net.BindException: >>>>>> Address already in use.? as the below. But JDK7 does NOT return the >>>>>> exception. >>>>>> >>>>>> - Test code for reproduce >>>>>> --- >>>>>> import javax.jws.*; >>>>>> import javax.xml.ws.*; >>>>>> >>>>>> public class WSTest{ >>>>>> >>>>>> @WebService >>>>>> public static class Method1{ >>>>>> @WebMethod >>>>>> public String getMethod1Value(){ >>>>>> return "from Method1"; >>>>>> } >>>>>> } >>>>>> >>>>>> @WebService >>>>>> public static class Method2{ >>>>>> @WebMethod >>>>>> public String getMethod2Value(){ >>>>>> return "from Method2"; >>>>>> } >>>>>> } >>>>>> >>>>>> public static void main(String[] args) throws Exception{ >>>>>> Endpoint endPoint1 = >>>>>> Endpoint.publish("http://0.0.0.0:8081/method1", >>>>>> new >>>>>> Method1()); >>>>>> Endpoint endPoint2 = >>>>>> Endpoint.publish("http://0.0.0.0:8081/method2", >>>>>> new >>>>>> Method2()); >>>>>> >>>>>> System.out.println("Sleep 3 secs..."); >>>>>> >>>>>> Thread.sleep(3000); >>>>>> >>>>>> endPoint2.stop(); >>>>>> endPoint1.stop(); >>>>>> } >>>>>> >>>>>> } >>>>>> --- >>>>>> >>>>>> - StackTrace >>>>>> --- >>>>>> Exception in thread "main" >>>>>> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime >>>>>> Error: java.net.BindException: Address already in use >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) >>>>>> at javax.xml.ws.Endpoint.publish(Endpoint.java:240) >>>>>> at wstest.WSTest.main(WSTest.java:27) >>>>>> Caused by: java.net.BindException: Address already in use >>>>>> at sun.nio.ch.Net.bind0(Native Method) >>>>>> at sun.nio.ch.Net.bind(Net.java:432) >>>>>> at sun.nio.ch.Net.bind(Net.java:424) >>>>>> at >>>>>> >>>>>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) >>>>>> at >>>>>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) >>>>>> at sun.net.httpserver.ServerImpl.(ServerImpl.java:102) >>>>>> at >>>>>> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50) >>>>>> at >>>>>> >>>>>> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) >>>>>> at >>>>>> com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) >>>>>> at >>>>>> >>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) >>>>>> ... 5 more >>>>>> ----- >>>>>> >>>>>> To publishes the Endpoint, JAX-WS checks whether the HttpContext has >>>>>> been created by given address, then creates a HttpContext if do not >>>>>> exist. >>>>>> If we sets 0.0.0.0 as given address, JAX-WS checks by >>>>>> ServerSocket#getLocalSocketAddress() (server local address), so >>>>>> returns BindException when 0.0.0.0 has been blinded already. >>>>>> >>>>>> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think >>>>>> about above situation. And JAX_WS-941 does not back port to JDK7. >>>>>> >>>>>> So I write a patch which is based jdk9/dev/jaxws >>>>>> (changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941. >>>>>> >>>>>> Please review this patch :) >>>>>> >>>>>> [1]: https://java.net/jira/browse/JAX_WS-941 >>>>>> >>>>>> - Patch >>>>>> --- >>>>>> diff -r 2d84c6f4cbba >>>>>> >>>>>> >>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>> --- >>>>>> >>>>>> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>> Thu Oct 22 08:47:47 2015 -0700 >>>>>> +++ >>>>>> >>>>>> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>> Tue Oct 27 19:48:35 2015 +0900 >>>>>> @@ -38,6 +38,7 @@ >>>>>> import java.util.concurrent.ExecutorService; >>>>>> import java.util.concurrent.Executors; >>>>>> import java.util.logging.Logger; >>>>>> +import java.util.Optional; >>>>>> >>>>>> /** >>>>>> * Manages all the WebService HTTP servers created by JAXWS runtime. >>>>>> @@ -81,24 +82,38 @@ >>>>>> synchronized(servers) { >>>>>> state = servers.get(inetAddress); >>>>>> if (state == null) { >>>>>> - logger.fine("Creating new HTTP Server at >>>>>> "+inetAddress); >>>>>> - // Creates server with default socket backlog >>>>>> - server = HttpServer.create(inetAddress, 0); >>>>>> - >>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>> - String path = url.toURI().getPath(); >>>>>> - logger.fine("Creating HTTP Context at = "+path); >>>>>> - HttpContext context = server.createContext(path); >>>>>> - server.start(); >>>>>> + final int finalPortNum = port; >>>>>> + Optional stateOpt = >>>>>> + servers.values() >>>>>> + .stream() >>>>>> + .filter(s -> s.getServer() >>>>>> + .getAddress() >>>>>> + .getPort() == >>>>>> finalPortNum) >>>>>> + .findAny(); >>>>>> >>>>>> - // we have to get actual inetAddress from server, >>>>>> which can differ from the original in some cases. >>>>>> - // e.g. A port number of zero will let the system >>>>>> pick up an ephemeral port in a bind operation, >>>>>> - // or IP: 0.0.0.0 - which is used to monitor >>>>>> network traffic from any valid IP address >>>>>> - inetAddress = server.getAddress(); >>>>>> + if (inetAddress.getAddress().isAnyLocalAddress() >>>>>> && >>>>>> + stateOpt.isPresent()) { >>>>>> + state = stateOpt.get(); >>>>>> + } else { >>>>>> + logger.fine("Creating new HTTP Server at >>>>>> "+inetAddress); >>>>>> + // Creates server with default socket backlog >>>>>> + server = HttpServer.create(inetAddress, 0); >>>>>> + >>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>> + String path = url.toURI().getPath(); >>>>>> + logger.fine("Creating HTTP Context at = >>>>>> "+path); >>>>>> + HttpContext context = >>>>>> server.createContext(path); >>>>>> + server.start(); >>>>>> >>>>>> - logger.fine("HTTP server started = "+inetAddress); >>>>>> - state = new ServerState(server, path); >>>>>> - servers.put(inetAddress, state); >>>>>> - return context; >>>>>> + // we have to get actual inetAddress from >>>>>> server, which can differ from the original in some cases. >>>>>> + // e.g. A port number of zero will let the >>>>>> system pick up an ephemeral port in a bind operation, >>>>>> + // or IP: 0.0.0.0 - which is used to monitor >>>>>> network traffic from any valid IP address >>>>>> + inetAddress = server.getAddress(); >>>>>> + >>>>>> + logger.fine("HTTP server started = >>>>>> "+inetAddress); >>>>>> + state = new ServerState(server, path); >>>>>> + servers.put(inetAddress, state); >>>>>> + return context; >>>>>> + } >>>>>> } >>>>>> } >>>>>> server = state.getServer(); >>>>>> --- >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>>> >>>>> >> -- Best regards, Pango Chan From huaming.li at oracle.com Thu Dec 15 03:19:37 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Thu, 15 Dec 2016 11:19:37 +0800 Subject: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..) Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171133 webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/ java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..): if LocateRegistry.createRegistry(port) return null when port is in use. Thank you -Hamlin ------------------------------------------------------------------------ diff -r ddd192238fcb test/java/rmi/registry/reexport/Reexport.java --- a/test/java/rmi/registry/reexport/Reexport.java Tue Dec 13 18:47:23 2016 -0800 +++ b/test/java/rmi/registry/reexport/Reexport.java Wed Dec 14 19:06:40 2016 -0800 @@ -105,6 +105,9 @@ try { reg = LocateRegistry.createRegistry(port); + if (remoteOk) { + TestLibrary.bomb("Remote registry is up, an Exception is expected!"); + } } catch (Throwable e) { if (remoteOk) { System.err.println("EXPECTING PORT IN USE EXCEPTION:"); From martinrb at google.com Thu Dec 15 03:54:15 2016 From: martinrb at google.com (Martin Buchholz) Date: Wed, 14 Dec 2016 19:54:15 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: I see that SpliteratorTraversingAndSplittingTest tests far more collection implementations than Collection8Test does, but we now have tests that caught spliterator bugs not caught by SpliteratorTraversingAndSplittingTest. Our tests of Spliterators are often comingled with other test methods, e.g. in testIteratorEquivalence. So, possible future work: testing could be improved in both dimensions of increasing number of implementations and increasing number of tests. From goetz.lindenmaier at sap.com Thu Dec 15 06:55:06 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 15 Dec 2016 06:55:06 +0000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <3072c9a4-f810-4abf-0f8e-3b025af92b3e@oracle.com> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <85ec77210bb143aa9cc4dee9b557ec5c@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> <1238bad1-1805-e57a-2360-196e44770521@oracle.com> <3072c9a4-f810-4abf-0f8e-3b025af92b3e@oracle.com> Message-ID: <213d5bb18a90421f9e1fe2dbaa59db17@DEROTE13DE08.global.corp.sap> Hi, I'm sorry for that. Our solaris builds were fine. I saw the fix. Thanks Erik for fixing! I thought windows was the last platform not to support declarations in the code. Do you mind sharing what compiler choked on this? Maybe we can setup our build accordingly. And, is there a wiki page that describes which files are owned by which mailing list, and to which repo to push the corresponding changes? I've no idea on the jdk side where to post etc. Opening up jprt will be a great step forward! Best regards, Goetz. > -----Original Message----- > From: David Holmes [mailto:david.holmes at oracle.com] > Sent: Wednesday, December 14, 2016 9:55 PM > To: Lindenmaier, Goetz ; > daniel.daugherty at oracle.com; 'Dmitry Samersoff' > ; Java Core Libs dev at openjdk.java.net>; serviceability-dev (serviceability- > dev at openjdk.java.net) > Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > coding. > > Hi Goetz, > > On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote: > > > >> object to the change to k_standard.c for the same reason. > > Ok, I remove that too. > > I had not realized this was to be pushed directly to jdk9/dev. It broke > builds on Solaris and so was obviously not tested. > > David > > > Best regards, > > Goetz. > > > >> -----Original Message----- > >> From: David Holmes [mailto:david.holmes at oracle.com] > >> Sent: Mittwoch, 14. Dezember 2016 12:29 > >> To: Lindenmaier, Goetz ; > >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >> ; Java Core Libs >> dev at openjdk.java.net>; serviceability-dev (serviceability- > >> dev at openjdk.java.net) > >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty > >> coding. > >> > >> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: > >>> Hi, > >>> > >>> You're right, I had removed the change to e_asin.c. > >> > >> You only pointed Joe to that file AFAICS. I would expect he would also > >> object to the change to k_standard.c for the same reason. > >> > >>> New webrev anyways: > >>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.05/ > >>> > >>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. > >> > >> Okay. Thanks. > >> > >> David > >> > >>> Best regards, > >>> Goetz. > >>> > >>> > >>>> -----Original Message----- > >>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>> Sent: Mittwoch, 14. Dezember 2016 11:42 > >>>> To: Lindenmaier, Goetz ; > >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >>>> ; Java Core Libs >>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>> dev at openjdk.java.net) > >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > >>>> coding. > >>>> > >>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: > >>>>> Hi David, > >>>>> > >>>>> I found "8169317: [s390] Various minor bug fixes and adaptions." > >>>>> in jdk9/dev this morning, so I thought it has been promoted based > >>>>> on some older change. I waited for that quite a while because tests > >>>>> in jdk9/dev kept failing on s390. > >>>>> How can I get the information when what was promoted? This always > >>>>> is a wild guess for me ... as well as when what will be promoted :) > >>>> > >>>> Yeah there's no notification in the bug report of when hs pushes up to > >>>> dev. The changeset email is the only record of exactly when it happens. > >>>> > >>>>> Do you think the promotion will happen tonight, or will it take > >>>>> another week? > >>>> > >>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to > >>>> dev. There have been delays in getting that started and so a delay in it > >>>> finishing and being analyzed. It may still be a couple of days. > >>>> > >>>>> I removed > >>>>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + > JLI_StrLen("/lib//jli:") > >> + > >>>>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + > JLI_StrLen("/lib/jli:") + > >>>>> from > >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > corlib_s11y/webrev.04/ > >>>> > >>>> With that gone that file only has the jvmpath rename - which isn't > >>>> fixing anything. > >>>> > >>>> Joe also asked for the fdlibm changes to dropped. > >>>> > >>>> Thanks, > >>>> David > >>>> > >>>>> Best regards, > >>>>> Goetz. > >>>>> > >>>>> > >>>>> > >>>>>> -----Original Message----- > >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>> Sent: Mittwoch, 14. Dezember 2016 11:04 > >>>>>> To: Lindenmaier, Goetz ; > >>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' > >>>>>> ; Java Core Libs >>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>> dev at openjdk.java.net) > >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > servicabilty > >>>>>> coding. > >>>>>> > >>>>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: > >>>>>>> Hi, > >>>>>>> > >>>>>>> 8066474 has not been promoted. > >>>>>> > >>>>>> hs has not been able to push up to dev yet. > >>>>>> > >>>>>>> I'll remove the strlen // fix for aix from this change and > >>>>>>> push it without it. I'd like to get this done. > >>>>>> > >>>>>> I've lost track of what is now left in this set of changes ?? > >>>>>> > >>>>>> David > >>>>>> > >>>>>>> Best regards, > >>>>>>> Goetz. > >>>>>>> > >>>>>>>> -----Original Message----- > >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 > >>>>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz > >>>>>>>> ; 'Dmitry Samersoff' > >>>>>>>> ; Java Core Libs >>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>>>> dev at openjdk.java.net) > >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >> servicabilty > >>>>>>>> coding. > >>>>>>>> > >>>>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: > >>>>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: > >>>>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: > >>>>>>>>>>> Hi David, > >>>>>>>>>>> > >>>>>>>>>>> thanks for looking at the change. New webrev: > >>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>> corlib_s11y/webrev.04/ > >>>>>>>>>>> > >>>>>>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. > >>>>>>>>>>> > >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output > string is > >>>>>>>>>>>> expanded with: > >>>>>>>>>>>> "%s/lib/%s/jli:" > >>>>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since > >>>>>>>>>>> 8066474, > >>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc > >>>>>>>>>>> but the // was not adapted. Then I moved the change to > jdk9/dev > >>>>>> because > >>>>>>>>>>> I thought I have to push it there. And yes, in that coding // > would > >>>>>>>>>>> be correct. > >>>>>>>>>>> So I have to wait until hs is promoted ... > >>>>>>>>>> > >>>>>>>>>> So just based on the current file, the change proposed - to > remove > >> one > >>>>>>>>>> / - is not correct until the arch directory is removed. > >>>>>>>>> > >>>>>>>>> That change is already in JDK9-hs: > >>>>>>>>> > >>>>>>>>> Changeset: c14f9a7b4cab > >>>>>>>>> Author: erikj > >>>>>>>>> Date: 2016-12-05 17:55 +0100 > >>>>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab > >>>>>>>>> > >>>>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris > images > >>>>>>>>> Reviewed-by: tbell, ihse > >>>>>>>>> > >>>>>>>>> along with changesets in the jdk and hotspot repos along with a > few > >>>>>>>>> closed repos. > >>>>>>>> > >>>>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - > >> where > >>>>>>>> removing the extra / would be correct. > >>>>>>>> > >>>>>>>> David > >>>>>>>> ----- > >>>>>>>> > >>>>>>>>> Dan > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> David > >>>>>>>>>> ----- > >>>>>>>>>> > >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - > a > >>>>>>>>>>>> comment on > >>>>>>>>>>>> the strdup would have sufficed IMO. > >>>>>>>>>>> Dmitry asked me to add it. But I think it's ok. > >>>>>>>>>>> > >>>>>>>>>>> Can I consider this reviewed now? I.e. could I push it once > 8066474 > >> is > >>>>>>>>>>> promoted and Joe Darcy agreed? > >>>>>>>>>>> > >>>>>>>>>>> Best regards, > >>>>>>>>>>> Goetz. > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] > >>>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 > >>>>>>>>>>>> To: Lindenmaier, Goetz ; > 'Dmitry > >>>>>>>> Samersoff' > >>>>>>>>>>>> ; Java Core Libs >>>>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- > >>>>>>>>>>>> dev at openjdk.java.net) > >>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and > >>>>>>>>>>>> servicabilty > >>>>>>>>>>>> coding. > >>>>>>>>>>>> > >>>>>>>>>>>> Hi Goetz, > >>>>>>>>>>>> > >>>>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>>>> > >>>>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. > >>>>>>>>>>>>> I also merged the ifs in SDE.c. > >>>>>>>>>>>>> > >>>>>>>>>>>>> new webrev: > >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>> corlib_s11y/webrev.03/ > >>>>>>>>>>>> > >>>>>>>>>>>> src/java.base/share/native/libjli/java.c > >>>>>>>>>>>> > >>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. > >>>>>>>>>>>> Given a > >>>>>>>>>>>> jvm.cfg with: > >>>>>>>>>>>> > >>>>>>>>>>>> -server KNOWN > >>>>>>>>>>>> -client IGNORE > >>>>>>>>>>>> -myvm KNOWN > >>>>>>>>>>>> -oldvm ALIASED_TO -server > >>>>>>>>>>>> > >>>>>>>>>>>> The usage text is: > >>>>>>>>>>>> > >>>>>>>>>>>> -server to select the "server" VM > >>>>>>>>>>>> -myvm to select the "myvm" VM > >>>>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] > >>>>>>>>>>>> The default VM is server, > >>>>>>>>>>>> because you are running on a server-class machine. > >>>>>>>>>>>> > >>>>>>>>>>>> which is exactly what I would expect. Why do you think there > is a > >>>> bug? > >>>>>>>>>>>> > >>>>>>>>>>>> --- > >>>>>>>>>>>> > >>>>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>>>> > >>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output > string is > >>>>>>>>>>>> expanded with: > >>>>>>>>>>>> > >>>>>>>>>>>> "%s/lib/%s/jli:" > >>>>>>>>>>>> > >>>>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - > and that > >>>>>>>>>>>> is exactly what the existing code does: > >>>>>>>>>>>> > >>>>>>>>>>>> + JLI_StrLen("/lib//jli:") > >>>>>>>>>>>> > >>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - > a > >>>>>>>>>>>> comment on > >>>>>>>>>>>> the strdup would have sufficed IMO. > >>>>>>>>>>>> > >>>>>>>>>>>> Thanks, > >>>>>>>>>>>> David > >>>>>>>>>>>> ----- > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Dmitry Samersoff > [mailto:dmitry.samersoff at oracle.com] > >>>>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM > >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; > Java > >> Core > >>>>>> Libs > >>>>>>>>>>>>>> ; serviceability-dev > >>>> (serviceability- > >>>>>>>>>>>>>> dev at openjdk.java.net) dev at openjdk.java.net> > >>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib > and > >>>>>>>>>>>>>> servicabilty > >>>>>>>>>>>>>> coding. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Goetz, > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> SDE.c: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just > >>>>>>>>>>>>>> matter of test. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { > >>>>>>>>>>>>>> return; /* Java stratum - return unchanged */ > >>>>>>>>>>>>>> } > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> if cnt is <= 0 loop at l.267 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> is never run and we effectively do > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> *entryCountPtr = 0; > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> at l.283 > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: > >>>>>>>>>>>>>> (your v.01 changes) > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { > >>>>>>>>>>>>>> 261 return; > >>>>>>>>>>>>>> 262 } > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> it's better to check it early. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt > here. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -Dmitry > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>> Hi Dmitry, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> thanks for looking at my change! > >>>>>>>>>>>>>>> Updated webrev: > >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>> corlib_s11y/webrev.02 > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c > >>>>>>>>>>>>>>>> Is this line correct? > >>>>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a > >>>>>>>>>>>>>>> horror.) > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c > >>>>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, > >>>>>>>>>>>>>>>> regardless of value of sti. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please > >>>>>>>>>>>>>>> double-check the new webrev. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> * > src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c > >>>>>>>>>>>>>>>> It might be better to write > >>>>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; > >>>>>>>>>>>>>>>> and leave one copy of setsockopt() call > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Yes, looks better. > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>> Goetz > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -Dmitry > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: > >>>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> This change fixes some minor issues found in our code > >> scans. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability > >> issues. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Please review: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- > >>>>>>>>>>>>>> corlib_s11y/webrev.01/ > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Best regards, > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Goetz. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Changes in detail: > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> e_asin.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Code scan reports missing {}. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the > inexact > >>>>>>>>>>>>>>>>> flag of > >>>>>>>>>>>>>>>>> the processor. > >>>>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code > >> away. > >>>>>>>>>>>>>>>>> It is > >>>>>>>>>>>>>>>>> always true, > >>>>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Although this basically just adds the {} I would like to > submit > >>>>>>>>>>>>>>>>> this to > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on > understanding > >>>>>> these > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> if statements. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> k_standard.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> exc.retval is returned below and thus should always be > >>>>>>>>>>>>>>>>> initialized. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> imageDecompressor.cpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David > CARLIER > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> java.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> java_md_solinux.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> SDE.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if > >>>>>>>>>>>>>>>>> defaultStratumId > >>>>>>>>>>>>>>>>> == null. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> socket_md.c > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use > is > >>>>>>>>>>>>>>>>> hidden in > >>>>>>>>>>>>>>>>> the macros. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> unpack.cpp > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> n.slice should not get negative argument for end, which > is > >>>>>>>>>>>>>>>>> passed from > >>>>>>>>>>>>>>>>> dollar1. > >>>>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result > of > >>>>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>> Dmitry Samersoff > >>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>>>>>>>> * I would love to change the world, but they won't give > me > >> the > >>>>>>>>>>>>>>>> sources. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -- > >>>>>>>>>>>>>> Dmitry Samersoff > >>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia > >>>>>>>>>>>>>> * I would love to change the world, but they won't give me > the > >>>>>>>>>>>>>> sources. > >>>>>>>>> From christoph.langer at sap.com Thu Dec 15 07:48:17 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 15 Dec 2016 07:48:17 +0000 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName;" even if "entities" property is false In-Reply-To: <5850B7E4.1060907@oracle.com> References: <022601d25550$ff1a1610$fd4e4230$@oracle.com> <5850B7E4.1060907@oracle.com> Message-ID: <38d95b4913314bf2bab872316d920192@DEWDFE13DE03.global.corp.sap> Hi Frank, this is awesome. Some minor things I saw while looking through the webrev: src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java Update copryright year Remove: 20 /* 21 * $Id: AbstractTranslet.java,v 1.6 2006/06/19 19:49:03 spericas Exp $ 22 */ src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java Remove: 20 /* 21 * $Id: TransformerImpl.java,v 1.10 2007/06/13 01:57:09 joehw Exp $ 22 */ src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java 462 protected boolean isInEntityRef() 463 { Put the brace on line 462 as well src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java -> sort import statements Method 773 public void startElement( -> use SAXException without package name. It is imported on top. This can be done in various places throughout the file. 780 //will add extra one if having namespace but no matter -> space between // and will... 821 if ((null != elemContext.m_elementName) -> For me it reads better if it were if ((elemContext.m_elementName != null) 1971 private void initToHTMLStream() 1972 { 1973 // m_elementDesc = null; 1974 m_isprevblock = false; 1975 m_inDTD = false; 1976 // m_isRawStack.clear(); 1977 m_omitMetaTag = false; 1978 m_specialEscapeURLs = true; 1979 } -> I guess you could remove the commented statements src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java 116 protected boolean m_ispreserveSpace = false; 117 118 -> remove one empty line (117) 1894 m_ispreserve = false; 1895 1896 1897 -> newly inserted lines 1896 and 1897 should be removed src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output_html.properties -> maybe the Oracle copyright header can be inserted and the "$Id: output_html.properties..." part can be removed? Best regards Christoph > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > Of Joe Wang > Sent: Mittwoch, 14. Dezember 2016 04:09 > To: Frank Yuan > Cc: core-libs-dev at openjdk.java.net > Subject: Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work > anymore and JDK-8114834 LSSerializerImpl always serializes an entity > reference node to" &entityName;" even if "entities" property is false > > Hi Frank, > > Thanks for the diligent work! I think we've made a great improvement > over the PrettyPrint (tremendous ;-) ) > > Could you look into extracting the XML literal strings in the test into > plain files (similar to the other 'gold' files)? What I'm hoping to see > is that they'd look easily prettier in a text editor, and for that > matter, the original xml files were a mess. > > The tests set PrettyPrint, and by default for html. It would be good to > test the cases when it's turned off, that would help verify the > non-pretty format was not changed. > > Thanks, > Joe > > On 12/13/16, 6:55 AM, Frank Yuan wrote: > > Hi all > > > > Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ is > for JDK-8087303 and JDK-8114834, I have to combine the fix > > because there is some interaction between them. > > Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 > https://bugs.openjdk.java.net/browse/JDK-8114834 > > > > Besides fixed some issues in xml serializer, I made the following changes in > this patch: > > 1. refined the handling for whitespace text > > 2. added support for xml:space attribute > > 3. changed the default indentation to 4 > > 4. refined the handling for HTML block element and inline element > > > > Would you like to have a look at this review? > > > > Thanks, > > > > Frank > > > > From david.holmes at oracle.com Thu Dec 15 08:28:55 2016 From: david.holmes at oracle.com (David Holmes) Date: Thu, 15 Dec 2016 18:28:55 +1000 Subject: RFR(M): 8170663: Fix minor issues in corelib and servicabilty coding. In-Reply-To: <213d5bb18a90421f9e1fe2dbaa59db17@DEROTE13DE08.global.corp.sap> References: <299bc2fbc03d42df94561f829354af36@DEROTE13DE08.global.corp.sap> <1051f7d0-8bea-6b63-0d3f-1581563c426f@oracle.com> <185a0008-8ed6-212a-7471-64837d86eff8@oracle.com> <5a34322068454551ba4441db05111603@DEROTE13DE08.global.corp.sap> <398517d0-59d3-90e9-ba75-0369e51d0b05@oracle.com> <4834063ecbab4971bf4767e637e032a3@DEROTE13DE08.global.corp.sap> <78ebe654-8f75-3a30-dc0f-8a459aa59dbb@oracle.com> <4f2ce01887c74725b9ede388daf707be@DEROTE13DE08.global.corp.sap> <1238bad1-1805-e57a-2360-196e44770521@oracle.com> <3072c9a4-f810-4abf-0f8e-3b025af92b3e@oracle.com> <213d5bb18a90421f9e1fe2dbaa59db17@DEROTE13DE08.global.corp.sap> Message-ID: <6c59f87f-3cb9-c20c-4ff8-9beb62b72d90@oracle.com> Hi Goetz, On 15/12/2016 4:55 PM, Lindenmaier, Goetz wrote: > Hi, > > I'm sorry for that. Our solaris builds were fine. > I saw the fix. Thanks Erik for fixing! I thought > windows was the last platform not to support > declarations in the code. Me too! And I'm sure we have declarations all over the place in hotspot. But this isn't hotspot code ... > Do you mind sharing what compiler choked on this? > Maybe we can setup our build accordingly. Solaris Studio 12u4 is our official compiler for JDK 9. Seems the problem is caused by the use of -xc99=%none which generates a warning: warning: declaration can not follow a statement which warnings-as-errors seems to turn into: /scratch/dh198349/jdk9-dev/jdk/src/java.base/unix/native/libjli/java_md_solinux.c", line 519: error: declaration can not follow a statement (E_DECLARATION_IN_CODE) > And, is there a wiki page that describes which > files are owned by which mailing list, and to which > repo to push the corresponding changes? I've no > idea on the jdk side where to post etc. Not in detail. Different files are owned by different OpenJDK groups - and each group has its mailing list(s). The main four would be: http://openjdk.java.net/groups/build http://openjdk.java.net/groups/core-libs http://openjdk.java.net/groups/hotspot http://openjdk.java.net/groups/serviceability > Opening up jprt will be a great step forward! Yes indeed! Thanks, David > Best regards, > Goetz. > > > >> -----Original Message----- >> From: David Holmes [mailto:david.holmes at oracle.com] >> Sent: Wednesday, December 14, 2016 9:55 PM >> To: Lindenmaier, Goetz ; >> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >> ; Java Core Libs > dev at openjdk.java.net>; serviceability-dev (serviceability- >> dev at openjdk.java.net) >> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >> coding. >> >> Hi Goetz, >> >> On 14/12/2016 9:46 PM, Lindenmaier, Goetz wrote: >>> >>>> object to the change to k_standard.c for the same reason. >>> Ok, I remove that too. >> >> I had not realized this was to be pushed directly to jdk9/dev. It broke >> builds on Solaris and so was obviously not tested. >> >> David >> >>> Best regards, >>> Goetz. >>> >>>> -----Original Message----- >>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>> Sent: Mittwoch, 14. Dezember 2016 12:29 >>>> To: Lindenmaier, Goetz ; >>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>> ; Java Core Libs >>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>> dev at openjdk.java.net) >>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and servicabilty >>>> coding. >>>> >>>> On 14/12/2016 9:00 PM, Lindenmaier, Goetz wrote: >>>>> Hi, >>>>> >>>>> You're right, I had removed the change to e_asin.c. >>>> >>>> You only pointed Joe to that file AFAICS. I would expect he would also >>>> object to the change to k_standard.c for the same reason. >>>> >>>>> New webrev anyways: >>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.05/ >>>>> >>>>> java_md_solinux.c adds JLI_MemFree(new_jvmpath) that was missing. >>>> >>>> Okay. Thanks. >>>> >>>> David >>>> >>>>> Best regards, >>>>> Goetz. >>>>> >>>>> >>>>>> -----Original Message----- >>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>> Sent: Mittwoch, 14. Dezember 2016 11:42 >>>>>> To: Lindenmaier, Goetz ; >>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>>>> ; Java Core Libs >>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>> dev at openjdk.java.net) >>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >> servicabilty >>>>>> coding. >>>>>> >>>>>> On 14/12/2016 8:23 PM, Lindenmaier, Goetz wrote: >>>>>>> Hi David, >>>>>>> >>>>>>> I found "8169317: [s390] Various minor bug fixes and adaptions." >>>>>>> in jdk9/dev this morning, so I thought it has been promoted based >>>>>>> on some older change. I waited for that quite a while because tests >>>>>>> in jdk9/dev kept failing on s390. >>>>>>> How can I get the information when what was promoted? This always >>>>>>> is a wild guess for me ... as well as when what will be promoted :) >>>>>> >>>>>> Yeah there's no notification in the bug report of when hs pushes up to >>>>>> dev. The changeset email is the only record of exactly when it happens. >>>>>> >>>>>>> Do you think the promotion will happen tonight, or will it take >>>>>>> another week? >>>>>> >>>>>> hs goes through Pre-Integration Testing (PIT) before it is pushed to >>>>>> dev. There have been delays in getting that started and so a delay in it >>>>>> finishing and being analyzed. It may still be a couple of days. >>>>>> >>>>>>> I removed >>>>>>> - JLI_StrLen(jrepath) + JLI_StrLen(arch) + >> JLI_StrLen("/lib//jli:") >>>> + >>>>>>> + JLI_StrLen(jrepath) + JLI_StrLen(arch) + >> JLI_StrLen("/lib/jli:") + >>>>>>> from >>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >> corlib_s11y/webrev.04/ >>>>>> >>>>>> With that gone that file only has the jvmpath rename - which isn't >>>>>> fixing anything. >>>>>> >>>>>> Joe also asked for the fdlibm changes to dropped. >>>>>> >>>>>> Thanks, >>>>>> David >>>>>> >>>>>>> Best regards, >>>>>>> Goetz. >>>>>>> >>>>>>> >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>> Sent: Mittwoch, 14. Dezember 2016 11:04 >>>>>>>> To: Lindenmaier, Goetz ; >>>>>>>> daniel.daugherty at oracle.com; 'Dmitry Samersoff' >>>>>>>> ; Java Core Libs >>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>> dev at openjdk.java.net) >>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >> servicabilty >>>>>>>> coding. >>>>>>>> >>>>>>>> On 14/12/2016 7:48 PM, Lindenmaier, Goetz wrote: >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> 8066474 has not been promoted. >>>>>>>> >>>>>>>> hs has not been able to push up to dev yet. >>>>>>>> >>>>>>>>> I'll remove the strlen // fix for aix from this change and >>>>>>>>> push it without it. I'd like to get this done. >>>>>>>> >>>>>>>> I've lost track of what is now left in this set of changes ?? >>>>>>>> >>>>>>>> David >>>>>>>> >>>>>>>>> Best regards, >>>>>>>>> Goetz. >>>>>>>>> >>>>>>>>>> -----Original Message----- >>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 23:03 >>>>>>>>>> To: daniel.daugherty at oracle.com; Lindenmaier, Goetz >>>>>>>>>> ; 'Dmitry Samersoff' >>>>>>>>>> ; Java Core Libs >>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>> servicabilty >>>>>>>>>> coding. >>>>>>>>>> >>>>>>>>>> On 9/12/2016 7:31 AM, Daniel D. Daugherty wrote: >>>>>>>>>>> On 12/8/16 1:59 PM, David Holmes wrote: >>>>>>>>>>>> On 9/12/2016 12:21 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>> Hi David, >>>>>>>>>>>>> >>>>>>>>>>>>> thanks for looking at the change. New webrev: >>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>> corlib_s11y/webrev.04/ >>>>>>>>>>>>> >>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>>>>> Ah, thanks for the explanation, now I got it! Removed. >>>>>>>>>>>>> >>>>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output >> string is >>>>>>>>>>>>>> expanded with: >>>>>>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>>>>> I first edited this against jdk9/hs, where the arch is gone since >>>>>>>>>>>>> 8066474, >>>>>>>>>>>>> http://hg.openjdk.java.net/jdk9/hs/jdk/rev/81508186e5bc >>>>>>>>>>>>> but the // was not adapted. Then I moved the change to >> jdk9/dev >>>>>>>> because >>>>>>>>>>>>> I thought I have to push it there. And yes, in that coding // >> would >>>>>>>>>>>>> be correct. >>>>>>>>>>>>> So I have to wait until hs is promoted ... >>>>>>>>>>>> >>>>>>>>>>>> So just based on the current file, the change proposed - to >> remove >>>> one >>>>>>>>>>>> / - is not correct until the arch directory is removed. >>>>>>>>>>> >>>>>>>>>>> That change is already in JDK9-hs: >>>>>>>>>>> >>>>>>>>>>> Changeset: c14f9a7b4cab >>>>>>>>>>> Author: erikj >>>>>>>>>>> Date: 2016-12-05 17:55 +0100 >>>>>>>>>>> URL: http://hg.openjdk.java.net/jdk9/hs/rev/c14f9a7b4cab >>>>>>>>>>> >>>>>>>>>>> 8066474: Remove the lib/ directory from Linux and Solaris >> images >>>>>>>>>>> Reviewed-by: tbell, ihse >>>>>>>>>>> >>>>>>>>>>> along with changesets in the jdk and hotspot repos along with a >> few >>>>>>>>>>> closed repos. >>>>>>>>>> >>>>>>>>>> Thanks Dan. So we need to see a webrev based on latest hs code - >>>> where >>>>>>>>>> removing the extra / would be correct. >>>>>>>>>> >>>>>>>>>> David >>>>>>>>>> ----- >>>>>>>>>> >>>>>>>>>>> Dan >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> David >>>>>>>>>>>> ----- >>>>>>>>>>>> >>>>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - >> a >>>>>>>>>>>>>> comment on >>>>>>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>>>>> Dmitry asked me to add it. But I think it's ok. >>>>>>>>>>>>> >>>>>>>>>>>>> Can I consider this reviewed now? I.e. could I push it once >> 8066474 >>>> is >>>>>>>>>>>>> promoted and Joe Darcy agreed? >>>>>>>>>>>>> >>>>>>>>>>>>> Best regards, >>>>>>>>>>>>> Goetz. >>>>>>>>>>>>> >>>>>>>>>>>>> >>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>> From: David Holmes [mailto:david.holmes at oracle.com] >>>>>>>>>>>>>> Sent: Donnerstag, 8. Dezember 2016 09:14 >>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> 'Dmitry >>>>>>>>>> Samersoff' >>>>>>>>>>>>>> ; Java Core Libs >>>>>>>>>>>>> dev at openjdk.java.net>; serviceability-dev (serviceability- >>>>>>>>>>>>>> dev at openjdk.java.net) >>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib and >>>>>>>>>>>>>> servicabilty >>>>>>>>>>>>>> coding. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hi Goetz, >>>>>>>>>>>>>> >>>>>>>>>>>>>> On 8/12/2016 1:26 AM, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> yes, new_jvmpath is consistent with the other variables. >>>>>>>>>>>>>>> I also merged the ifs in SDE.c. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>> new webrev: >>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>> corlib_s11y/webrev.03/ >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/java.base/share/native/libjli/java.c >>>>>>>>>>>>>> >>>>>>>>>>>>>> As far as I can see the existing code is working perfectly fine. >>>>>>>>>>>>>> Given a >>>>>>>>>>>>>> jvm.cfg with: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -server KNOWN >>>>>>>>>>>>>> -client IGNORE >>>>>>>>>>>>>> -myvm KNOWN >>>>>>>>>>>>>> -oldvm ALIASED_TO -server >>>>>>>>>>>>>> >>>>>>>>>>>>>> The usage text is: >>>>>>>>>>>>>> >>>>>>>>>>>>>> -server to select the "server" VM >>>>>>>>>>>>>> -myvm to select the "myvm" VM >>>>>>>>>>>>>> -oldvm is a synonym for the "server" VM [deprecated] >>>>>>>>>>>>>> The default VM is server, >>>>>>>>>>>>>> because you are running on a server-class machine. >>>>>>>>>>>>>> >>>>>>>>>>>>>> which is exactly what I would expect. Why do you think there >> is a >>>>>> bug? >>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> >>>>>>>>>>>>>> src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>>>> >>>>>>>>>>>>>> Again I'm not sure what the bug is here. On AIX the output >> string is >>>>>>>>>>>>>> expanded with: >>>>>>>>>>>>>> >>>>>>>>>>>>>> "%s/lib/%s/jli:" >>>>>>>>>>>>>> >>>>>>>>>>>>>> so it needs to account for the extra "/lib//jli:" characters - >> and that >>>>>>>>>>>>>> is exactly what the existing code does: >>>>>>>>>>>>>> >>>>>>>>>>>>>> + JLI_StrLen("/lib//jli:") >>>>>>>>>>>>>> >>>>>>>>>>>>>> The jvmpath -> jvm_newpath change wasn't really necessary - >> a >>>>>>>>>>>>>> comment on >>>>>>>>>>>>>> the strdup would have sufficed IMO. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Thanks, >>>>>>>>>>>>>> David >>>>>>>>>>>>>> ----- >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -----Original Message----- >>>>>>>>>>>>>>>> From: Dmitry Samersoff >> [mailto:dmitry.samersoff at oracle.com] >>>>>>>>>>>>>>>> Sent: Wednesday, December 07, 2016 2:43 PM >>>>>>>>>>>>>>>> To: Lindenmaier, Goetz ; >> Java >>>> Core >>>>>>>> Libs >>>>>>>>>>>>>>>> ; serviceability-dev >>>>>> (serviceability- >>>>>>>>>>>>>>>> dev at openjdk.java.net) > dev at openjdk.java.net> >>>>>>>>>>>>>>>> Subject: Re: RFR(M): 8170663: Fix minor issues in corelib >> and >>>>>>>>>>>>>>>> servicabilty >>>>>>>>>>>>>>>> coding. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> Goetz, >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> SDE.c: >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> You might combine if at ll. 260 and 263 to one but it's just >>>>>>>>>>>>>>>> matter of test. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if (sti == baseStratumIndex || sti < 0) { >>>>>>>>>>>>>>>> return; /* Java stratum - return unchanged */ >>>>>>>>>>>>>>>> } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> if cnt is <= 0 loop at l.267 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> for (; cnt-- > 0; ++fromEntry) { >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> is never run and we effectively do >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> *entryCountPtr = 0; >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> at l.283 >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> So if we you suspect that cnt may become negative or 0: >>>>>>>>>>>>>>>> (your v.01 changes) >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> 260 if (sti < 0 && cnt > 0) { >>>>>>>>>>>>>>>> 261 return; >>>>>>>>>>>>>>>> 262 } >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> it's better to check it early. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> But I'm not sure we have to care about negative/zero cnt >> here. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> On 2016-12-07 11:37, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>> Hi Dmitry, >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> thanks for looking at my change! >>>>>>>>>>>>>>>>> Updated webrev: >>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>> corlib_s11y/webrev.02 >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * src/java.base/unix/native/libjli/java_md_solinux.c >>>>>>>>>>>>>>>>>> Is this line correct? >>>>>>>>>>>>>>>>>> 519 jvmpath = JLI_StringDup(jvmpath); >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> It seems pointless. Should I remove it? (The whole file is a >>>>>>>>>>>>>>>>> horror.) >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * src/jdk.jdwp.agent/share/native/libjdwp/SDE.c >>>>>>>>>>>>>>>>>> It might be better to return immediately if cnt < 0, >>>>>>>>>>>>>>>>>> regardless of value of sti. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> I'm not sure what you mean. I tried to fix it, but please >>>>>>>>>>>>>>>>> double-check the new webrev. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> * >> src/jdk.jdwp.agent/unix/native/libdt_socket/socket_md.c >>>>>>>>>>>>>>>>>> It might be better to write >>>>>>>>>>>>>>>>>> arg.l_linger = (on) ? (unsigned short)value.i : 0; >>>>>>>>>>>>>>>>>> and leave one copy of setsockopt() call >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Yes, looks better. >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>> Goetz >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -Dmitry >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> On 2016-12-06 16:12, Lindenmaier, Goetz wrote: >>>>>>>>>>>>>>>>>>> Hi, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> This change fixes some minor issues found in our code >>>> scans. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> I hope this correctly addresses corelib and serviceability >>>> issues. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Please review: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> http://cr.openjdk.java.net/~goetz/wr16/8170663- >>>>>>>>>>>>>>>> corlib_s11y/webrev.01/ >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Best regards, >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Goetz. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Changes in detail: >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> e_asin.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Code scan reports missing {}. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> The code "if (huge+x>one) {" is only there to set the >> inexact >>>>>>>>>>>>>>>>>>> flag of >>>>>>>>>>>>>>>>>>> the processor. >>>>>>>>>>>>>>>>>>> It's a way to avoid the C compiler to optimize the code >>>> away. >>>>>>>>>>>>>>>>>>> It is >>>>>>>>>>>>>>>>>>> always true, >>>>>>>>>>>>>>>>>>> so the parenthesis of the outer else don't matter. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Although this basically just adds the {} I would like to >> submit >>>>>>>>>>>>>>>>>>> this to >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> avoid anybody else spends more the 30sec on >> understanding >>>>>>>> these >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> if statements. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> k_standard.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> exc.retval is returned below and thus should always be >>>>>>>>>>>>>>>>>>> initialized. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> imageDecompressor.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Wrong destructor is used. Reported also by David >> CARLIER >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> java.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> in line 1865 'name' was used, it should be 'alias'. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> java_md_solinux.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> "//" in path is useless. Further down a free is missing. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> SDE.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> Call to stratumTableIndex can return negative value if >>>>>>>>>>>>>>>>>>> defaultStratumId >>>>>>>>>>>>>>>>>>> == null. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> socket_md.c >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> arg.l_linger is passed to setsockopt uninitialized. Its use >> is >>>>>>>>>>>>>>>>>>> hidden in >>>>>>>>>>>>>>>>>>> the macros. >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> unpack.cpp >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>>> n.slice should not get negative argument for end, which >> is >>>>>>>>>>>>>>>>>>> passed from >>>>>>>>>>>>>>>>>>> dollar1. >>>>>>>>>>>>>>>>>>> But dollar1 can get negative where it is set to the result >> of >>>>>>>>>>>>>>>>>>> lastIndexOf(DOLLAR_MIN, DOLLAR_MAX, n, dollar2 - 1). >>>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>>>>>>>> * I would love to change the world, but they won't give >> me >>>> the >>>>>>>>>>>>>>>>>> sources. >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> >>>>>>>>>>>>>>>> -- >>>>>>>>>>>>>>>> Dmitry Samersoff >>>>>>>>>>>>>>>> Oracle Java development team, Saint Petersburg, Russia >>>>>>>>>>>>>>>> * I would love to change the world, but they won't give me >> the >>>>>>>>>>>>>>>> sources. >>>>>>>>>>> From frank.yuan at oracle.com Thu Dec 15 10:52:01 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 15 Dec 2016 18:52:01 +0800 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName; " even if "entities" property is false In-Reply-To: <5850B7E4.1060907@oracle.com> References: <022601d25550$ff1a1610$fd4e4230$@oracle.com> <5850B7E4.1060907@oracle.com> Message-ID: <059901d256c1$470f0810$d52d1830$@oracle.com> Hi Joe Thank you very much for your comments! I have made a new webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.01/ as your suggestions, please check. Thanks Frank > -----Original Message----- > From: Joe Wang [mailto:huizhe.wang at oracle.com] > Subject: Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an > entity reference node to" &entityName;" even if "entities" property is false > > Hi Frank, > > Thanks for the diligent work! I think we've made a great improvement > over the PrettyPrint (tremendous ;-) ) > > Could you look into extracting the XML literal strings in the test into > plain files (similar to the other 'gold' files)? What I'm hoping to see > is that they'd look easily prettier in a text editor, and for that > matter, the original xml files were a mess. > > The tests set PrettyPrint, and by default for html. It would be good to > test the cases when it's turned off, that would help verify the > non-pretty format was not changed. > > Thanks, > Joe > > On 12/13/16, 6:55 AM, Frank Yuan wrote: > > Hi all > > > > Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ is for JDK-8087303 and JDK-8114834, I have to combine the fix > > because there is some interaction between them. > > Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 https://bugs.openjdk.java.net/browse/JDK-8114834 > > > > Besides fixed some issues in xml serializer, I made the following changes in this patch: > > 1. refined the handling for whitespace text > > 2. added support for xml:space attribute > > 3. changed the default indentation to 4 > > 4. refined the handling for HTML block element and inline element > > > > Would you like to have a look at this review? > > > > Thanks, > > > > Frank > > > > From frank.yuan at oracle.com Thu Dec 15 10:52:13 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 15 Dec 2016 18:52:13 +0800 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName; " even if "entities" property is false Message-ID: <059b01d256c1$4c8817f0$e59847d0$@oracle.com> Hi Christoph Thank you for the review! Please check http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.01/. I have updated the code as your comments except output_html.properties, I am not sure for the license of this file. To Joe Could you confirm Christoph's comment for output_html.properties? Thanks Frank > -----Original Message----- > From: Langer, Christoph [mailto:christoph.langer at sap.com] > Subject: RE: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an > entity reference node to" &entityName;" even if "entities" property is false > > Hi Frank, > > this is awesome. > > Some minor things I saw while looking through the webrev: > > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java > Update copryright year > Remove: > 20 /* > 21 * $Id: AbstractTranslet.java,v 1.6 2006/06/19 19:49:03 spericas Exp $ > 22 */ > > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java > Remove: > 20 /* > 21 * $Id: TransformerImpl.java,v 1.10 2007/06/13 01:57:09 joehw Exp $ > 22 */ > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java > 462 protected boolean isInEntityRef() > 463 { > Put the brace on line 462 as well > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java > -> sort import statements > Method > 773 public void startElement( > -> use SAXException without package name. It is imported on top. This can be done in various places throughout the file. > 780 //will add extra one if having namespace but no matter > -> space between // and will... > 821 if ((null != elemContext.m_elementName) > -> For me it reads better if it were if ((elemContext.m_elementName != null) > > 1971 private void initToHTMLStream() > 1972 { > 1973 // m_elementDesc = null; > 1974 m_isprevblock = false; > 1975 m_inDTD = false; > 1976 // m_isRawStack.clear(); > 1977 m_omitMetaTag = false; > 1978 m_specialEscapeURLs = true; > 1979 } > -> I guess you could remove the commented statements > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java > 116 protected boolean m_ispreserveSpace = false; > 117 > 118 > -> remove one empty line (117) > > 1894 m_ispreserve = false; > 1895 > 1896 > 1897 > -> newly inserted lines 1896 and 1897 should be removed > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output_html.properties > -> maybe the Oracle copyright header can be inserted and the "$Id: output_html.properties..." part can be removed? > > Best regards > Christoph > > > -----Original Message----- > > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf > > Of Joe Wang > > Sent: Mittwoch, 14. Dezember 2016 04:09 > > To: Frank Yuan > > Cc: core-libs-dev at openjdk.java.net > > Subject: Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work > > anymore and JDK-8114834 LSSerializerImpl always serializes an entity > > reference node to" &entityName;" even if "entities" property is false > > > > Hi Frank, > > > > Thanks for the diligent work! I think we've made a great improvement > > over the PrettyPrint (tremendous ;-) ) > > > > Could you look into extracting the XML literal strings in the test into > > plain files (similar to the other 'gold' files)? What I'm hoping to see > > is that they'd look easily prettier in a text editor, and for that > > matter, the original xml files were a mess. > > > > The tests set PrettyPrint, and by default for html. It would be good to > > test the cases when it's turned off, that would help verify the > > non-pretty format was not changed. > > > > Thanks, > > Joe > > > > On 12/13/16, 6:55 AM, Frank Yuan wrote: > > > Hi all > > > > > > Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ is > > for JDK-8087303 and JDK-8114834, I have to combine the fix > > > because there is some interaction between them. > > > Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 > > https://bugs.openjdk.java.net/browse/JDK-8114834 > > > > > > Besides fixed some issues in xml serializer, I made the following changes in > > this patch: > > > 1. refined the handling for whitespace text > > > 2. added support for xml:space attribute > > > 3. changed the default indentation to 4 > > > 4. refined the handling for HTML block element and inline element > > > > > > Would you like to have a look at this review? > > > > > > Thanks, > > > > > > Frank > > > > > > From aleksej.efimov at oracle.com Thu Dec 15 11:04:26 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 15 Dec 2016 14:04:26 +0300 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: References: Message-ID: <8821bcd9-35aa-5a21-7a45-1fb6ed22c857@oracle.com> Hi Pango, The backport is done and I will send backport and review request for JDK8 later today (I'm pending testing results). Best Regards, Aleksej On 15/12/16 05:41, Pango wrote: > Hi all, > > May I ask has there been any progress on this issue? > > Actually we are also struggling with this problem. The software that > we are working on do publish with 0.0.0.0 and we got this > BindException while migrating to JDK 8. We tried several workarounds > but it will be very inconvenient for the end users to follow. > > Now we are planning to release our product around next January, and > really hope that there will be some good news announced by then. > > It would be very appreciated if anyone can give some information > regarding the backport of this fix to JDK 8 update in advance. > > Thanks for all your hard work and contributions. > > Best regards, > Pango Chan > > > 2016-08-04 09:35 GMT+09:00 KUBOTA Yuji : >> Hi Aleksej, >> >> Thank you very much! >> If you need some help about the patch, please mention me :) >> >> Thanks, >> Yuji >> >> 2016-08-03 19:56 GMT+09:00 Aleks Efimov : >>> Hi Yuji, >>> >>> I've created JDK8 backport [1] for this issue and will work on it in the >>> upcoming months. >>> >>> Best Regards, >>> >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8162941 >>> >>> >>> >>> On 02/08/16 08:33, KUBOTA Yuji wrote: >>>> Hi all, >>>> >>>> Could you let me know when this fix will be backport to JDK 8? >>>> We need this backport to migrate our system from JDK 7 to JDK 8. >>>> >>>> Thanks, >>>> Yuji >>>> >>>> 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji : >>>>> Hi Miroslav, >>>>> >>>>> Thank you for your sponsor! : >>>>> https://bugs.openjdk.java.net/browse/JDK-8146086 >>>>> >>>>> Can I ask the schedule when does this fix backport to JDK8 ? >>>>> >>>>> Thanks, >>>>> Yuji >>>>> >>>>> 2015-12-02 22:39 GMT+09:00 Miroslav Kos : >>>>>> Hi Yuji, >>>>>> thanks for the patch - it fixes the issue and looks ok to me. I'll >>>>>> integrate >>>>>> it to standalone JAX-WS repo and it will be integrated into openjdk >>>>>> during >>>>>> next syncup. >>>>>> >>>>>> Thanks >>>>>> Miran >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 01/12/15 11:11, KUBOTA Yuji wrote: >>>>>>> Hi Miroslav and all, >>>>>>> >>>>>>> Could you please review the below issue and patch? >>>>>>> >>>>>>> I got the advice by Alan at net-dev. So I want to ask you. >>>>>>> >>>>>>> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html >>>>>>> >>>>>>> ---- >>>>>>> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK >>>>>>> community. This's second times from JavaOne14. :) >>>>>>> >>>>>>> We find an unexpected exception in JAX-WS, so I write a patch to fix >>>>>>> it. >>>>>>> We think that this issue may block the migration to JDK9 from JDK7. >>>>>>> >>>>>>> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the >>>>>>> following test code, JDK9 (and JDK8) returns "java.net.BindException: >>>>>>> Address already in use.? as the below. But JDK7 does NOT return the >>>>>>> exception. >>>>>>> >>>>>>> - Test code for reproduce >>>>>>> --- >>>>>>> import javax.jws.*; >>>>>>> import javax.xml.ws.*; >>>>>>> >>>>>>> public class WSTest{ >>>>>>> >>>>>>> @WebService >>>>>>> public static class Method1{ >>>>>>> @WebMethod >>>>>>> public String getMethod1Value(){ >>>>>>> return "from Method1"; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> @WebService >>>>>>> public static class Method2{ >>>>>>> @WebMethod >>>>>>> public String getMethod2Value(){ >>>>>>> return "from Method2"; >>>>>>> } >>>>>>> } >>>>>>> >>>>>>> public static void main(String[] args) throws Exception{ >>>>>>> Endpoint endPoint1 = >>>>>>> Endpoint.publish("http://0.0.0.0:8081/method1", >>>>>>> new >>>>>>> Method1()); >>>>>>> Endpoint endPoint2 = >>>>>>> Endpoint.publish("http://0.0.0.0:8081/method2", >>>>>>> new >>>>>>> Method2()); >>>>>>> >>>>>>> System.out.println("Sleep 3 secs..."); >>>>>>> >>>>>>> Thread.sleep(3000); >>>>>>> >>>>>>> endPoint2.stop(); >>>>>>> endPoint1.stop(); >>>>>>> } >>>>>>> >>>>>>> } >>>>>>> --- >>>>>>> >>>>>>> - StackTrace >>>>>>> --- >>>>>>> Exception in thread "main" >>>>>>> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime >>>>>>> Error: java.net.BindException: Address already in use >>>>>>> at >>>>>>> >>>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) >>>>>>> at >>>>>>> >>>>>>> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) >>>>>>> at >>>>>>> >>>>>>> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) >>>>>>> at >>>>>>> >>>>>>> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) >>>>>>> at javax.xml.ws.Endpoint.publish(Endpoint.java:240) >>>>>>> at wstest.WSTest.main(WSTest.java:27) >>>>>>> Caused by: java.net.BindException: Address already in use >>>>>>> at sun.nio.ch.Net.bind0(Native Method) >>>>>>> at sun.nio.ch.Net.bind(Net.java:432) >>>>>>> at sun.nio.ch.Net.bind(Net.java:424) >>>>>>> at >>>>>>> >>>>>>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) >>>>>>> at >>>>>>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) >>>>>>> at sun.net.httpserver.ServerImpl.(ServerImpl.java:102) >>>>>>> at >>>>>>> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50) >>>>>>> at >>>>>>> >>>>>>> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) >>>>>>> at >>>>>>> com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) >>>>>>> at >>>>>>> >>>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) >>>>>>> ... 5 more >>>>>>> ----- >>>>>>> >>>>>>> To publishes the Endpoint, JAX-WS checks whether the HttpContext has >>>>>>> been created by given address, then creates a HttpContext if do not >>>>>>> exist. >>>>>>> If we sets 0.0.0.0 as given address, JAX-WS checks by >>>>>>> ServerSocket#getLocalSocketAddress() (server local address), so >>>>>>> returns BindException when 0.0.0.0 has been blinded already. >>>>>>> >>>>>>> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think >>>>>>> about above situation. And JAX_WS-941 does not back port to JDK7. >>>>>>> >>>>>>> So I write a patch which is based jdk9/dev/jaxws >>>>>>> (changeset:637:2d84c6f4cbba) to fix the BindException with JAX_WS-941. >>>>>>> >>>>>>> Please review this patch :) >>>>>>> >>>>>>> [1]: https://java.net/jira/browse/JAX_WS-941 >>>>>>> >>>>>>> - Patch >>>>>>> --- >>>>>>> diff -r 2d84c6f4cbba >>>>>>> >>>>>>> >>>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>> --- >>>>>>> >>>>>>> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>> Thu Oct 22 08:47:47 2015 -0700 >>>>>>> +++ >>>>>>> >>>>>>> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>> Tue Oct 27 19:48:35 2015 +0900 >>>>>>> @@ -38,6 +38,7 @@ >>>>>>> import java.util.concurrent.ExecutorService; >>>>>>> import java.util.concurrent.Executors; >>>>>>> import java.util.logging.Logger; >>>>>>> +import java.util.Optional; >>>>>>> >>>>>>> /** >>>>>>> * Manages all the WebService HTTP servers created by JAXWS runtime. >>>>>>> @@ -81,24 +82,38 @@ >>>>>>> synchronized(servers) { >>>>>>> state = servers.get(inetAddress); >>>>>>> if (state == null) { >>>>>>> - logger.fine("Creating new HTTP Server at >>>>>>> "+inetAddress); >>>>>>> - // Creates server with default socket backlog >>>>>>> - server = HttpServer.create(inetAddress, 0); >>>>>>> - >>>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>>> - String path = url.toURI().getPath(); >>>>>>> - logger.fine("Creating HTTP Context at = "+path); >>>>>>> - HttpContext context = server.createContext(path); >>>>>>> - server.start(); >>>>>>> + final int finalPortNum = port; >>>>>>> + Optional stateOpt = >>>>>>> + servers.values() >>>>>>> + .stream() >>>>>>> + .filter(s -> s.getServer() >>>>>>> + .getAddress() >>>>>>> + .getPort() == >>>>>>> finalPortNum) >>>>>>> + .findAny(); >>>>>>> >>>>>>> - // we have to get actual inetAddress from server, >>>>>>> which can differ from the original in some cases. >>>>>>> - // e.g. A port number of zero will let the system >>>>>>> pick up an ephemeral port in a bind operation, >>>>>>> - // or IP: 0.0.0.0 - which is used to monitor >>>>>>> network traffic from any valid IP address >>>>>>> - inetAddress = server.getAddress(); >>>>>>> + if (inetAddress.getAddress().isAnyLocalAddress() >>>>>>> && >>>>>>> + stateOpt.isPresent()) { >>>>>>> + state = stateOpt.get(); >>>>>>> + } else { >>>>>>> + logger.fine("Creating new HTTP Server at >>>>>>> "+inetAddress); >>>>>>> + // Creates server with default socket backlog >>>>>>> + server = HttpServer.create(inetAddress, 0); >>>>>>> + >>>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>>> + String path = url.toURI().getPath(); >>>>>>> + logger.fine("Creating HTTP Context at = >>>>>>> "+path); >>>>>>> + HttpContext context = >>>>>>> server.createContext(path); >>>>>>> + server.start(); >>>>>>> >>>>>>> - logger.fine("HTTP server started = "+inetAddress); >>>>>>> - state = new ServerState(server, path); >>>>>>> - servers.put(inetAddress, state); >>>>>>> - return context; >>>>>>> + // we have to get actual inetAddress from >>>>>>> server, which can differ from the original in some cases. >>>>>>> + // e.g. A port number of zero will let the >>>>>>> system pick up an ephemeral port in a bind operation, >>>>>>> + // or IP: 0.0.0.0 - which is used to monitor >>>>>>> network traffic from any valid IP address >>>>>>> + inetAddress = server.getAddress(); >>>>>>> + >>>>>>> + logger.fine("HTTP server started = >>>>>>> "+inetAddress); >>>>>>> + state = new ServerState(server, path); >>>>>>> + servers.put(inetAddress, state); >>>>>>> + return context; >>>>>>> + } >>>>>>> } >>>>>>> } >>>>>>> server = state.getServer(); >>>>>>> --- >>>>>>> >>>>>>> Thanks, >>>>>>> Yuji >>>>>> > > From Alan.Bateman at oracle.com Thu Dec 15 12:24:55 2016 From: Alan.Bateman at oracle.com (Alan Bateman) Date: Thu, 15 Dec 2016 12:24:55 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> Message-ID: On 13/12/2016 21:18, Peter Levart wrote: > I think this is OK. > > Just a couple of nits in test: > > 1. You create a static Path bob = Paths.get("bob") field, but then you > don't use it in: > > 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), > CREATE, WRITE)) { > Adding to Peter's comment, this can be further changed to use Files.write(bob, srcData). Otherwise I think the patch looks okay although it does feel like invokeCleaner needs a warning in the javadoc, maybe being in Unsafe is enough. -Alan From christoph.langer at sap.com Thu Dec 15 12:27:41 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 15 Dec 2016 12:27:41 +0000 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName;" even if "entities" property is false In-Reply-To: <059b01d256c1$4c8817f0$e59847d0$@oracle.com> References: <059b01d256c1$4c8817f0$e59847d0$@oracle.com> Message-ID: Hi Frank, thanks, looks good :) Best Christoph > -----Original Message----- > From: Frank Yuan [mailto:frank.yuan at oracle.com] > Sent: Donnerstag, 15. Dezember 2016 11:52 > To: Langer, Christoph ; 'Joe Wang' > > Cc: core-libs-dev at openjdk.java.net > Subject: RE: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work > anymore and JDK-8114834 LSSerializerImpl always serializes an entity > reference node to" &entityName;" even if "entities" property is false > > Hi Christoph > > Thank you for the review! > > Please check http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.01/. > > I have updated the code as your comments except output_html.properties, I am > not sure for the license of this file. > > To Joe > Could you confirm Christoph's comment for output_html.properties? > > > Thanks > Frank > > > -----Original Message----- > > From: Langer, Christoph [mailto:christoph.langer at sap.com] > > Subject: RE: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work > anymore and JDK-8114834 LSSerializerImpl always > serializes an > > entity reference node to" &entityName;" even if "entities" property is false > > > > Hi Frank, > > > > this is awesome. > > > > Some minor things I saw while looking through the webrev: > > > > > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/ > AbstractTranslet.java > > Update copryright year > > Remove: > > 20 /* > > 21 * $Id: AbstractTranslet.java,v 1.6 2006/06/19 19:49:03 spericas Exp $ > > 22 */ > > > > > src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/Tran > sformerImpl.java > > Remove: > > 20 /* > > 21 * $Id: TransformerImpl.java,v 1.10 2007/06/13 01:57:09 joehw Exp $ > > 22 */ > > > > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/Seriali > zerBase.java > > 462 protected boolean isInEntityRef() > > 463 { > > Put the brace on line 462 as well > > > > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHT > MLStream.java > > -> sort import statements > > Method > > 773 public void startElement( > > -> use SAXException without package name. It is imported on top. This can be > done in various places throughout the file. > > 780 //will add extra one if having namespace but no matter > > -> space between // and will... > > 821 if ((null != elemContext.m_elementName) > > -> For me it reads better if it were if ((elemContext.m_elementName != null) > > > > 1971 private void initToHTMLStream() > > 1972 { > > 1973 // m_elementDesc = null; > > 1974 m_isprevblock = false; > > 1975 m_inDTD = false; > > 1976 // m_isRawStack.clear(); > > 1977 m_omitMetaTag = false; > > 1978 m_specialEscapeURLs = true; > > 1979 } > > -> I guess you could remove the commented statements > > > > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStre > am.java > > 116 protected boolean m_ispreserveSpace = false; > > 117 > > 118 > > -> remove one empty line (117) > > > > 1894 m_ispreserve = false; > > 1895 > > 1896 > > 1897 > > -> newly inserted lines 1896 and 1897 should be removed > > > > > src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output > _html.properties > > -> maybe the Oracle copyright header can be inserted and the "$Id: > output_html.properties..." part can be removed? > > > > Best regards > > Christoph > > > > > -----Original Message----- > > > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf > > > Of Joe Wang > > > Sent: Mittwoch, 14. Dezember 2016 04:09 > > > To: Frank Yuan > > > Cc: core-libs-dev at openjdk.java.net > > > Subject: Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work > > > anymore and JDK-8114834 LSSerializerImpl always serializes an entity > > > reference node to" &entityName;" even if "entities" property is false > > > > > > Hi Frank, > > > > > > Thanks for the diligent work! I think we've made a great improvement > > > over the PrettyPrint (tremendous ;-) ) > > > > > > Could you look into extracting the XML literal strings in the test into > > > plain files (similar to the other 'gold' files)? What I'm hoping to see > > > is that they'd look easily prettier in a text editor, and for that > > > matter, the original xml files were a mess. > > > > > > The tests set PrettyPrint, and by default for html. It would be good to > > > test the cases when it's turned off, that would help verify the > > > non-pretty format was not changed. > > > > > > Thanks, > > > Joe > > > > > > On 12/13/16, 6:55 AM, Frank Yuan wrote: > > > > Hi all > > > > > > > > Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ > is > > > for JDK-8087303 and JDK-8114834, I have to combine the fix > > > > because there is some interaction between them. > > > > Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 > > > https://bugs.openjdk.java.net/browse/JDK-8114834 > > > > > > > > Besides fixed some issues in xml serializer, I made the following changes > in > > > this patch: > > > > 1. refined the handling for whitespace text > > > > 2. added support for xml:space attribute > > > > 3. changed the default indentation to 4 > > > > 4. refined the handling for HTML block element and inline element > > > > > > > > Would you like to have a look at this review? > > > > > > > > Thanks, > > > > > > > > Frank > > > > > > > > From spliterator at gmail.com Thu Dec 15 12:36:52 2016 From: spliterator at gmail.com (Stefan Zobel) Date: Thu, 15 Dec 2016 13:36:52 +0100 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: SubmissionPublisherTest, line 420: "s1.awaitSubscribe();" I might be wrong, shouldn't this be "s2.awaitSubscribe();"? Regards, Stefan 2016-12-14 0:13 GMT+01:00 Martin Buchholz : > We were supposed to be winding down jdk9, and there are a lot of changes > here, but ... it would be a shame not to have fast specialized > implementations for new collection methods added in Java 8. There's also a > fix for a serious bug in LinkedBlockingQueue. > > http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ > > As with wave 12, very collection oriented. From aleksej.efimov at oracle.com Thu Dec 15 14:06:10 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 15 Dec 2016 17:06:10 +0300 Subject: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use" Message-ID: <82e0af2a-b250-a48f-75a3-34890755d6d3@oracle.com> Hi, Can I, please, have an approval to backport JDK-8146086 to 8u-dev. The source fix was slightly modified to remove stream/lamdba usages, therefore the fix is a subject to review. Webrev with 8u-dev changes: http://cr.openjdk.java.net/~aefimov/8146086/8/00/ The fix was tested with JPRT on all platforms - no failures observed. Best Regards, Aleksej JBS: https://bugs.openjdk.java.net/browse/JDK-8146086 JDK9 review thread: http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037984.html JDK9 changesets: http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/daffd583eb35 http://hg.openjdk.java.net/jdk9/dev/jdk/rev/099e432fe59c From christoph.langer at sap.com Thu Dec 15 14:11:38 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 15 Dec 2016 14:11:38 +0000 Subject: 8u-dev: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type Message-ID: <7c791e24543d4c63ae8629ce8b6e0567@DEWDFE13DE03.global.corp.sap> Hi, please review(@Joe) & approve the downport of this regression fix. As it is a JAXP issue and includes a testcase, the change needs to be split into a jaxp part and a jdk part. The jaxp part applies cleanly after unshuffling, the JDK part had to be modified to fit into the jdk8 layout. Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 JAXP: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jaxp.8udev/ JDK: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/ Thanks & best regards Christoph From: Joe Wang [mailto:huizhe.wang at oracle.com] Sent: Mittwoch, 14. Dezember 2016 21:52 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net; Aleks Efimov ; jeff Dinkins Subject: Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) Register 10 contains wrong type I guess I should also request a downport to jdk8 immediately, as it is a regression, right? Yes, that would be great. Please create a patch for JDK 8 or work with Aleksej (Aleksej backported your previous patch), and ask for approval through the jdk8-dev alias. Best, Joe From daniel.fuchs at oracle.com Thu Dec 15 14:38:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 15 Dec 2016 14:38:13 +0000 Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 In-Reply-To: <58509558.8070607@oracle.com> References: <584EF6DA.8080307@oracle.com> <1efbdc1c876f48788eda832dce3b3d8f@DEWDFE13DE03.global.corp.sap> <58509558.8070607@oracle.com> Message-ID: <5b0bbf60-8e5c-bdf8-ef35-6eb28a8d70e9@oracle.com> On 14/12/16 00:42, Joe Wang wrote: > Thanks Christoph! > > I updated the webrev for the classes you mentioned below, in a few > cases, used NetBeans' source format feature -- not for all of the > classes though (esp. the crazily large > XMLDocumentFragmentScannerImpl.java, it gets better though, overtime). Hi Joe, The 'bufferConent' jumped out at me :-) I suspect that XMLDocumentFragmentScannerImpl::bufferConent should be renamed XMLDocumentFragmentScannerImpl::bufferContent best regards, -- daniel > > http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ > > Best regards, > Joe > > On 12/13/16, 2:14 PM, Langer, Christoph wrote: >> Hi Joe, >> >> looks nice, thanks for doing that. >> >> Here are a few findings: >> >> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java: >> >> -> import statements could be ordered alphabetically >> 262 fEntityScanner = fEntityManager.getEntityScanner() ; >> -> spaces before ; >> 1317 protected List getEntityDecls(){ >> -> space before opening { >> 1322 if(entities.size()> 0){ >> -> spaces after if, before { >> 1344 protected List getNotationDecls(){ >> -> space before { >> 1352 if(notation!= null){ >> -> spaces >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java >> >> 145 } >> 146 /** >> -> insert blank line in between >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java >> >> 734 public List getNotationDecls(){ >> -> blank before { >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/DTDEvent.java >> >> 66 public void setEntities(List entites){ >> -> space before {; variable name entites -> entities >> 77 public void setNotations(List notations){ >> -> space >> 94 protected final void init(){ >> -> space >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/EndElementEvent.java >> >> -> order import statements alphabetically >> 48 QName fQName ; >> -> space >> 105 void addNamespace(Namespace ns){ >> -> space >> 106 if(ns != null){ >> -> spaces >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/events/StartElementEvent.java >> >> -> import statements order, a few space issues >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java >> >> 68 public void add(javax.xml.stream.XMLEventReader xMLEventReader) >> throws XMLStreamException { >> 80 public void add(javax.xml.stream.events.XMLEvent xMLEvent) >> throws XMLStreamException { >> -> you should be able to use unqualified names for parameters >> >> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java >> >> 906 ElementState elem; >> 907 >> 908 while (!fElementStack.empty()) { >> 909 elem = fElementStack.pop(); >> -> I think elem can be declared in line 909 as well, scope is only >> within while() block >> >> Best regards >> Christoph >> >> >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] >>> On Behalf >>> Of Joe Wang >>> Sent: Montag, 12. Dezember 2016 20:14 >>> To: core-libs-dev at openjdk.java.net >>> Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 >>> >>> Hi, >>> >>> This was the cleanup portion of the change for JDK-8167340. As Lance >>> suggested, it was split from the original webrev. In addition to that >>> cleanup, I've added coverage to the entire StAX packages. This cleanup >>> will reduce 138 warnings. >>> >>> jbs: https://bugs.openjdk.java.net/browse/JDK-8170556 >>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ >>> >>> Thanks, >>> Joe From daniel.fuchs at oracle.com Thu Dec 15 14:43:36 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Thu, 15 Dec 2016 14:43:36 +0000 Subject: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..) In-Reply-To: References: Message-ID: <30732ea9-63cc-886a-0fb4-4be651276029@oracle.com> Hi Hamlin, Looks good, but I would suggest to rename the parameter 'remoteOk' into something more natural, like 'shouldFail'. This should better help to understand the logic in createReg, which otherwise appears a bit obscure. No need to regenerate the webrev. best regards, -- daniel On 15/12/16 03:19, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8171133 > webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/ > > java/rmi/registry/reexport/Reexport.java, there is a missing case check > in createReg(..): if LocateRegistry.createRegistry(port) return null > when port is in use. > > Thank you > -Hamlin > ------------------------------------------------------------------------ > diff -r ddd192238fcb test/java/rmi/registry/reexport/Reexport.java > --- a/test/java/rmi/registry/reexport/Reexport.java Tue Dec 13 > 18:47:23 2016 -0800 > +++ b/test/java/rmi/registry/reexport/Reexport.java Wed Dec 14 > 19:06:40 2016 -0800 > @@ -105,6 +105,9 @@ > > try { > reg = LocateRegistry.createRegistry(port); > + if (remoteOk) { > + TestLibrary.bomb("Remote registry is up, an Exception > is expected!"); > + } > } catch (Throwable e) { > if (remoteOk) { > System.err.println("EXPECTING PORT IN USE EXCEPTION:"); > From Roger.Riggs at Oracle.com Thu Dec 15 14:45:20 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 15 Dec 2016 09:45:20 -0500 Subject: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..) In-Reply-To: References: Message-ID: Hi Hamlin, If this is supposed to fix the call from line 68: then doesn't the test for reg != null at line 70 already have the same effect? Roger On 12/14/2016 10:19 PM, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8171133 > webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/ > > java/rmi/registry/reexport/Reexport.java, there is a missing case > check in createReg(..): if LocateRegistry.createRegistry(port) return > null when port is in use. > > Thank you > -Hamlin > ------------------------------------------------------------------------ > diff -r ddd192238fcb test/java/rmi/registry/reexport/Reexport.java > --- a/test/java/rmi/registry/reexport/Reexport.java Tue Dec 13 > 18:47:23 2016 -0800 > +++ b/test/java/rmi/registry/reexport/Reexport.java Wed Dec 14 > 19:06:40 2016 -0800 > @@ -105,6 +105,9 @@ > > try { > reg = LocateRegistry.createRegistry(port); > + if (remoteOk) { > + TestLibrary.bomb("Remote registry is up, an Exception > is expected!"); > + } > } catch (Throwable e) { > if (remoteOk) { > System.err.println("EXPECTING PORT IN USE EXCEPTION:"); > From rob.mckenna at oracle.com Thu Dec 15 14:57:27 2016 From: rob.mckenna at oracle.com (Rob McKenna) Date: Thu, 15 Dec 2016 14:57:27 +0000 Subject: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections In-Reply-To: <058ced05-487e-5f0a-c4e8-4d0680811d57@oracle.com> References: <20161214155913.GC2524@tecra> <058ced05-487e-5f0a-c4e8-4d0680811d57@oracle.com> Message-ID: <20161215145727.GA2475@vimes> Gah, thanks Daniel. I originally worked this fix on 8u and neglected to remove synchronized when forward porting. I've been having a few discussions on altering how we do locking in this code in general and CoWArrayList is a nice idea. I'd like to leave this change until I get to that work though. Thanks for the suggestion. Updated webrev at: http://cr.openjdk.java.net/~robm/8169465/webrev.02/ -Rob On 14/12/16 04:58, Daniel Fuchs wrote: > Hi Rob, > > The expire(long) method is already synchronized, so there's no > need to call synchronized(this) inside, unless you forgot to > to remove synchronized from the method declaration? > > I wonder if 'conns' could be created as a CopyOnWriteArrayList. > Then maybe no synchronization would be needed? It's the first time > I'm looking at this file - so please accept this as a suggestion > for a simpler (and possibly insufficient) alternative ... > > best regards, > > -- daniel > > On 14/12/16 15:59, Rob McKenna wrote: > >Hi folks, > > > >Looking for a review of this change: > > > >http://cr.openjdk.java.net/~robm/8169465/webrev.01/ > > > >This is necessary to fix a potential problem where recursive ldap calls > >can potentially cause a deadlock with the PoolCleaner thread. > > > >See: https://bugs.openjdk.java.net/browse/JDK-8169465 > > > > -Rob > > > From Roger.Riggs at Oracle.com Thu Dec 15 15:21:05 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Thu, 15 Dec 2016 10:21:05 -0500 Subject: JDK 9 RFC on 8151955: java.util.prefs: removeNode() / removeNodeSpi(): Node is permanently removed even when no flush() is invoked In-Reply-To: <97213C55-F3BB-497C-A9A0-0BFB7F922D6F@oracle.com> References: <97213C55-F3BB-497C-A9A0-0BFB7F922D6F@oracle.com> Message-ID: <7313de9c-cd14-b3cf-74e4-8d0e2ea10247@Oracle.com> Hi Brian, I read it to say that changes can become permanent at any time (lazy or aggressive) and are guaranteed to be permanent only with a flush(). It does indicate for normal termination, the equivalent of flush occurs, making pending changes permanent. There is no statement that ensures a change will *not* become permanent until a specific action. So, not a bug. $.02, Roger On 12/14/2016 6:20 PM, Brian Burkhalter wrote: > The issue [1] does not seem like a bug to me as the behavior appears to be as expected from the specification but I would like to see whether anyone else agrees. > > Assuming the nodes ?userRoot/a? and ?userRoot/a/a1? do not already exist, if the test [2] is run twice in succession, the printed output of the first run is > > "a" exists: false > "a1" exists: false > > and that of the second run is > > "a" exists: true > "a1" exists: false > > This appears to be consistent with this statement in the class level specification of j.u.Preferences [3]: > > "Normal termination of the Java Virtual Machine will not result in the loss of pending updates -- an explicit flush invocation is not required upon termination to ensure that pending updates are made persistent.? > > I verified that the behavior is consistent with this across Linux, OS X, and Windows. > > Any comment would be appreciated. > > Thanks, > > Brian > > [1] https://bugs.openjdk.java.net/browse/JDK-8151955 > [2] RemoveNodeTest.java > > import java.util.prefs.BackingStoreException; > import java.util.prefs.Preferences; > > public class RemoveNodeTest { > public static void main(String[] args) throws BackingStoreException { > Preferences userRoot = Preferences.userRoot(); > System.out.printf("\"a\" exists: %s%n", userRoot.nodeExists("a")); > Preferences a = userRoot.node("a"); > System.out.printf("\"a1\" exists: %s%n", a.nodeExists("a1")); > Preferences a1 = a.node("a1"); > a.flush(); > a1.removeNode(); > } > } > > [3] http://download.java.net/java/jdk9/docs/api/java/util/prefs/Preferences.html From brian.burkhalter at oracle.com Thu Dec 15 16:49:47 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 15 Dec 2016 08:49:47 -0800 Subject: JDK 9 RFC on 8151955: java.util.prefs: removeNode() / removeNodeSpi(): Node is permanently removed even when no flush() is invoked In-Reply-To: <7313de9c-cd14-b3cf-74e4-8d0e2ea10247@Oracle.com> References: <97213C55-F3BB-497C-A9A0-0BFB7F922D6F@oracle.com> <7313de9c-cd14-b3cf-74e4-8d0e2ea10247@Oracle.com> Message-ID: <7B4F4251-3146-4B53-B3ED-D4C2CEEC4B55@oracle.com> Hi Roger, On Dec 15, 2016, at 7:21 AM, Roger Riggs wrote: > I read it to say that changes can become permanent at any time (lazy or aggressive) and > are guaranteed to be permanent only with a flush(). > It does indicate for normal termination, the equivalent of flush occurs, making pending changes permanent. > There is no statement that ensures a change will *not* become permanent until a specific action. All my reading as well. A flush of pending changes occurs at termination on Linux and OS X by means of a shutdown hook; on Windows the change is immediate as it is done via a registry call. > So, not a bug. I will resolve it as ?Not an Issue? this week unless I hear an objection from someone else. Thanks, Brian From aleksej.efimov at oracle.com Thu Dec 15 17:13:07 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 15 Dec 2016 20:13:07 +0300 Subject: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance In-Reply-To: References: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> <585093BD.1020904@oracle.com> <803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com> <58519CAC.1060604@oracle.com> Message-ID: Joe, Christoph, Thanks for your reviews! Best Regards, Aleksej On 14/12/16 23:52, Langer, Christoph wrote: > +1 > > This is cool :) > >> -----Original Message----- >> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >> Of Joe Wang >> Sent: Mittwoch, 14. Dezember 2016 20:26 >> To: Aleks Efimov >> Cc: core-libs-dev >> Subject: Re: RFR (JAXP) 8146271: File system contention in debug print via >> XPathFactory.newInstance >> >> Hi Aleksej, >> >> Looks good. Thanks for covering the whole packages! >> >> Best, >> Joe >> >> On 12/14/16, 10:04 AM, Aleks Efimov wrote: >>> Hi Joe, >>> >>> Thank you for the suggestions. What about modifying the 'debugPrintln' >>> and 'dPrint' functions to accept 'j.u.function.Supplier' >>> instead of 'String'? Such approach will give us a possibility to do >>> the output string calculation only when debugging is switched on. Such >>> approach can be illustrated by this webrev: >>> http://cr.openjdk.java.net/~aefimov/8146271/9/01 >>> >>> Best Regards, >>> Aleksej >>> >>> >>> On 14/12/16 03:35, Joe Wang wrote: >>>> Hi Aleksej, >>>> >>>> You may want to improve the debugPrintln or its usage to remove the >>>> String concatenations or method calls such as f.getClass().getName() >>>> that are unnecessary when debug == false. Where we are here, could >>>> you expand the patch to cover other jaxp packages (e.g. >>>> javax.xml.parsers) where similar problems exist. >>>> >>>> Best, >>>> Joe >>>> >>>> On 12/13/16, 3:02 PM, Aleks Efimov wrote: >>>>> Hello, >>>>> >>>>> Please, help to review the changes that addresses the file system >>>>> contention caused by debug code in XPathFactoryFinder and >>>>> XPathFactoryFinder classes [1]. Proposed fix wraps the debug output >>>>> code in "if(debug)" block: >>>>> http://cr.openjdk.java.net/~aefimov/8146271/9/00/ >>>>> >>>>> Best Regards, >>>>> Aleksej >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146271 >>>>> From tom.schindl at bestsolution.at Thu Dec 15 17:22:43 2016 From: tom.schindl at bestsolution.at (Tom Schindl) Date: Thu, 15 Dec 2016 18:22:43 +0100 Subject: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance In-Reply-To: <803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com> References: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> <585093BD.1020904@oracle.com> <803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com> Message-ID: <1D9B1E48-ECAE-4293-A774-BB9E52C42EC2@bestsolution.at> Wouldn't it be better to use a function/bifunction instead of a supplier because the supplier is a capturing? Tom Von meinem iPhone gesendet > Am 14.12.2016 um 19:04 schrieb Aleks Efimov : > > Hi Joe, > > Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier' instead of 'String'? Such approach will give us a possibility to do the output string calculation only when debugging is switched on. Such approach can be illustrated by this webrev: > http://cr.openjdk.java.net/~aefimov/8146271/9/01 > > Best Regards, > Aleksej > > >> On 14/12/16 03:35, Joe Wang wrote: >> Hi Aleksej, >> >> You may want to improve the debugPrintln or its usage to remove the String concatenations or method calls such as f.getClass().getName() that are unnecessary when debug == false. Where we are here, could you expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) where similar problems exist. >> >> Best, >> Joe >> >>> On 12/13/16, 3:02 PM, Aleks Efimov wrote: >>> Hello, >>> >>> Please, help to review the changes that addresses the file system contention caused by debug code in XPathFactoryFinder and XPathFactoryFinder classes [1]. Proposed fix wraps the debug output code in "if(debug)" block: >>> http://cr.openjdk.java.net/~aefimov/8146271/9/00/ >>> >>> Best Regards, >>> Aleksej >>> >>> [1] https://bugs.openjdk.java.net/browse/JDK-8146271 >>> > From dl at cs.oswego.edu Thu Dec 15 17:35:04 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Thu, 15 Dec 2016 12:35:04 -0500 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: On 12/15/2016 07:36 AM, Stefan Zobel wrote: > SubmissionPublisherTest, line 420: "s1.awaitSubscribe();" > > I might be wrong, shouldn't this be "s2.awaitSubscribe();"? > Thanks. Changed. Using s1 on that line wasn't wrong, but wasn't intentional. (The first use of s1 catches error-before-subscribe; the "s2" cases just check against side effects, but they should use s2 consistently for uniformity.) -Doug > > Regards, > Stefan > > > 2016-12-14 0:13 GMT+01:00 Martin Buchholz : >> We were supposed to be winding down jdk9, and there are a lot of changes >> here, but ... it would be a shame not to have fast specialized >> implementations for new collection methods added in Java 8. There's also a >> fix for a serious bug in LinkedBlockingQueue. >> >> http://cr.openjdk.java.net/~martin/webrevs/openjdk9/jsr166-jdk9-integration/ >> >> As with wave 12, very collection oriented. > From paul.sandoz at oracle.com Thu Dec 15 17:58:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Thu, 15 Dec 2016 09:58:18 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: > On 14 Dec 2016, at 19:54, Martin Buchholz wrote: > > I see that SpliteratorTraversingAndSplittingTest tests far more collection implementations than Collection8Test does, but we now have tests that caught spliterator bugs not caught by SpliteratorTraversingAndSplittingTest. Our tests of Spliterators are often comingled with other test methods, e.g. in testIteratorEquivalence. > Yes, the scopes are different and intersect somewhat. The Spliterator traversing tests do not test for weakly consistent behaviour of concurrent collections. I recently separated out the fail fast and late binding tests (so ArrayDeque is included in the latter but not the former). Those do not test concurrent collections, since i think a more specific set of weakly consistent tests are needed. It would be useful to refactor out the underlying spliterator tests into a library, since they can be used for collections or for the spliterator obtained from the head stream. (There is a bug open to track that.) Paul. > So, possible future work: testing could be improved in both dimensions of increasing number of implementations and increasing number of tests. From huizhe.wang at oracle.com Thu Dec 15 18:08:03 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 15 Dec 2016 10:08:03 -0800 Subject: 8u-dev: RFR (JAXP): 8169112: java.lang.VerifyError: (class: GregorSamsa, method: template-bash signature: (LGregorSamsa8; )V) Register 10 contains wrong type In-Reply-To: <7c791e24543d4c63ae8629ce8b6e0567@DEWDFE13DE03.global.corp.sap> References: <7c791e24543d4c63ae8629ce8b6e0567@DEWDFE13DE03.global.corp.sap> Message-ID: <5852DC03.1060503@oracle.com> Hi Christoph, The patches look good to me. Thanks, Joe On 12/15/16, 6:11 AM, Langer, Christoph wrote: > > Hi, > > please review(@Joe) & approve the downport of this regression fix. As > it is a JAXP issue and includes a testcase, the change needs to be > split into a jaxp part and a jdk part. > > The jaxp part applies cleanly after unshuffling, the JDK part had to > be modified to fit into the jdk8 layout. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8169112 > > JAXP: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jaxp.8udev/ > > > JDK: http://cr.openjdk.java.net/~clanger/webrevs/8169112_jdk.8udev/ > > > Thanks & best regards > > Christoph > > *From:*Joe Wang [mailto:huizhe.wang at oracle.com] > *Sent:* Mittwoch, 14. Dezember 2016 21:52 > *To:* Langer, Christoph > *Cc:* core-libs-dev at openjdk.java.net; Aleks Efimov > ; jeff Dinkins > *Subject:* Re: RFR (JAXP): 8169112: java.lang.VerifyError: (class: > GregorSamsa, method: template-bash signature: (LGregorSamsa8;)V) > Register 10 contains wrong type > > > I guess I should also request a downport to jdk8 immediately, as > it is a regression, right? > > > Yes, that would be great. Please create a patch for JDK 8 or work with > Aleksej (Aleksej backported your previous patch), and ask for approval > through the jdk8-dev alias. > > Best, > Joe > From spliterator at gmail.com Thu Dec 15 18:17:11 2016 From: spliterator at gmail.com (Stefan Zobel) Date: Thu, 15 Dec 2016 19:17:11 +0100 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: > 2016-12-15 18:35 GMT+01:00 Doug Lea

      : > > Thanks. Changed. > Using s1 on that line wasn't wrong, but wasn't intentional. > (The first use of s1 catches error-before-subscribe; the > "s2" cases just check against side effects, but they should > use s2 consistently for uniformity.) > > -Doug > Ah, I see, thanks. Something else (unrelated) about SubmissionPublisher: I recently noticed that javac creates a synthetic class and a bridge constructor for SubmissionPublisher.ThreadPerTaskExecutor because its generated constructor is private. I don't know if it really matters but that could be avoided by declaring a package-private constructor that does nothing. > /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */ > private static final class ThreadPerTaskExecutor implements Executor { > // avoid creation of synthetic class and bridge constructor > ThreadPerTaskExecutor() {} > public void execute(Runnable r) { new Thread(r).start(); } > } Regards, Stefan From huizhe.wang at oracle.com Thu Dec 15 18:19:11 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 15 Dec 2016 10:19:11 -0800 Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 In-Reply-To: <5b0bbf60-8e5c-bdf8-ef35-6eb28a8d70e9@oracle.com> References: <584EF6DA.8080307@oracle.com> <1efbdc1c876f48788eda832dce3b3d8f@DEWDFE13DE03.global.corp.sap> <58509558.8070607@oracle.com> <5b0bbf60-8e5c-bdf8-ef35-6eb28a8d70e9@oracle.com> Message-ID: <5852DE9F.2070206@oracle.com> On 12/15/16, 6:38 AM, Daniel Fuchs wrote: > On 14/12/16 00:42, Joe Wang wrote: >> Thanks Christoph! >> >> I updated the webrev for the classes you mentioned below, in a few >> cases, used NetBeans' source format feature -- not for all of the >> classes though (esp. the crazily large >> XMLDocumentFragmentScannerImpl.java, it gets better though, overtime). > > Hi Joe, > > The 'bufferConent' jumped out at me :-) Yikes, inventing word fail :-) > > I suspect that XMLDocumentFragmentScannerImpl::bufferConent should be > renamed XMLDocumentFragmentScannerImpl::bufferContent Updated: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ Thanks, Joe > > best regards, > > -- daniel > >> >> http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ >> >> Best regards, >> Joe >> >> On 12/13/16, 2:14 PM, Langer, Christoph wrote: >>> Hi Joe, >>> >>> looks nice, thanks for doing that. >>> >>> Here are a few findings: >>> >>> src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/XMLStreamReaderImpl.java: >>> >>> >>> -> import statements could be ordered alphabetically >>> 262 fEntityScanner = fEntityManager.getEntityScanner() ; >>> -> spaces before ; >>> 1317 protected List getEntityDecls(){ >>> -> space before opening { >>> 1322 if(entities.size()> 0){ >>> -> spaces after if, before { >>> 1344 protected List getNotationDecls(){ >>> -> space before { >>> 1352 if(notation!= null){ >>> -> spaces >>> >>> src/java.xml/share/classes/com/sun/xml/internal/stream/XMLEntityStorage.java >>> >>> >>> 145 } >>> 146 /** >>> -> insert blank line in between >>> >>> src/java.xml/share/classes/com/sun/xml/internal/stream/dtd/nonvalidating/DTDGrammar.java >>> >>> >>> 734 public List getNotationDecls(){ >>> -> blank before { >>> >>> src/java.xml/share/classes/com/sun/xml/internal/stream/events/DTDEvent.java >>> >>> >>> 66 public void setEntities(List entites){ >>> -> space before {; variable name entites -> entities >>> 77 public void setNotations(List notations){ >>> -> space >>> 94 protected final void init(){ >>> -> space >>> >>> src/java.xml/share/classes/com/sun/xml/internal/stream/events/EndElementEvent.java >>> >>> >>> -> order import statements alphabetically >>> 48 QName fQName ; >>> -> space >>> 105 void addNamespace(Namespace ns){ >>> -> space >>> 106 if(ns != null){ >>> -> spaces >>> >>> src/java.xml/share/classes/com/sun/xml/internal/stream/events/StartElementEvent.java >>> >>> >>> -> import statements order, a few space issues >>> >>> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLEventWriterImpl.java >>> >>> >>> 68 public void add(javax.xml.stream.XMLEventReader xMLEventReader) >>> throws XMLStreamException { >>> 80 public void add(javax.xml.stream.events.XMLEvent xMLEvent) >>> throws XMLStreamException { >>> -> you should be able to use unqualified names for parameters >>> >>> src/java.xml/share/classes/com/sun/xml/internal/stream/writers/XMLStreamWriterImpl.java >>> >>> >>> 906 ElementState elem; >>> 907 >>> 908 while (!fElementStack.empty()) { >>> 909 elem = fElementStack.pop(); >>> -> I think elem can be declared in line 909 as well, scope is only >>> within while() block >>> >>> Best regards >>> Christoph >>> >>> >>> >>>> -----Original Message----- >>>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] >>>> On Behalf >>>> Of Joe Wang >>>> Sent: Montag, 12. Dezember 2016 20:14 >>>> To: core-libs-dev at openjdk.java.net >>>> Subject: RFR (JAXP) 8170556: Warnings cleanup related to JDK-8167340 >>>> >>>> Hi, >>>> >>>> This was the cleanup portion of the change for JDK-8167340. As Lance >>>> suggested, it was split from the original webrev. In addition to that >>>> cleanup, I've added coverage to the entire StAX packages. This cleanup >>>> will reduce 138 warnings. >>>> >>>> jbs: https://bugs.openjdk.java.net/browse/JDK-8170556 >>>> webrev: http://cr.openjdk.java.net/~joehw/jdk9/8170556/webrev/ >>>> >>>> Thanks, >>>> Joe > From joe.darcy at oracle.com Thu Dec 15 20:25:23 2016 From: joe.darcy at oracle.com (joe darcy) Date: Thu, 15 Dec 2016 12:25:23 -0800 Subject: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java Message-ID: <213d5b02-a4d9-2171-73ef-44b5cdc46b17@oracle.com> Hello, Next up in porting fdlibm to Java after cbrt (JDK-8136799), pow (JDK-8134795) and hypot (JDK-7130085) earlier in JDK 9 is exp: JDK-8139688 Port fdlibm exp to Java http://cr.openjdk.java.net/~darcy/8139688.5/ Same methodology followed as when porting the earlier functions. Thanks, -Joe From aleksej.efimov at oracle.com Thu Dec 15 20:45:17 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Thu, 15 Dec 2016 23:45:17 +0300 Subject: RFR (JAXP) 8146271: File system contention in debug print via XPathFactory.newInstance In-Reply-To: <1D9B1E48-ECAE-4293-A774-BB9E52C42EC2@bestsolution.at> References: <2d1445dc-b748-4442-20b0-26ca887a2f82@oracle.com> <585093BD.1020904@oracle.com> <803efb79-2b7b-b892-351a-a7268c85f3c9@oracle.com> <1D9B1E48-ECAE-4293-A774-BB9E52C42EC2@bestsolution.at> Message-ID: Hi Tom, The main purpose of this fix is to postpone debug message string parts calculation/concatenation till when the actual output is needed, i.e. we don't want to call which(clazz) until the debug output is needed (debug=true) in XPathFactoryFinder ). I'm not sure that function/bifunction can give us such possibility due to different ways of messages construction in dPrint and debugPrintln usages. Best, Aleksej On 15/12/16 20:22, Tom Schindl wrote: > Wouldn't it be better to use a function/bifunction instead of a supplier because the supplier is a capturing? > > Tom > > Von meinem iPhone gesendet > >> Am 14.12.2016 um 19:04 schrieb Aleks Efimov : >> >> Hi Joe, >> >> Thank you for the suggestions. What about modifying the 'debugPrintln' and 'dPrint' functions to accept 'j.u.function.Supplier' instead of 'String'? Such approach will give us a possibility to do the output string calculation only when debugging is switched on. Such approach can be illustrated by this webrev: >> http://cr.openjdk.java.net/~aefimov/8146271/9/01 >> >> Best Regards, >> Aleksej >> >> >>> On 14/12/16 03:35, Joe Wang wrote: >>> Hi Aleksej, >>> >>> You may want to improve the debugPrintln or its usage to remove the String concatenations or method calls such as f.getClass().getName() that are unnecessary when debug == false. Where we are here, could you expand the patch to cover other jaxp packages (e.g. javax.xml.parsers) where similar problems exist. >>> >>> Best, >>> Joe >>> >>>> On 12/13/16, 3:02 PM, Aleks Efimov wrote: >>>> Hello, >>>> >>>> Please, help to review the changes that addresses the file system contention caused by debug code in XPathFactoryFinder and XPathFactoryFinder classes [1]. Proposed fix wraps the debug output code in "if(debug)" block: >>>> http://cr.openjdk.java.net/~aefimov/8146271/9/00/ >>>> >>>> Best Regards, >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8146271 >>>> From huizhe.wang at oracle.com Thu Dec 15 22:55:05 2016 From: huizhe.wang at oracle.com (Joe Wang) Date: Thu, 15 Dec 2016 14:55:05 -0800 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName;" even if "entities" property is false In-Reply-To: <059b01d256c1$4c8817f0$e59847d0$@oracle.com> References: <059b01d256c1$4c8817f0$e59847d0$@oracle.com> Message-ID: <58531F49.6030205@oracle.com> Hi Frank, Thanks for the update. It looks good. The license header for output_html.properties can be updated as the follows: ########################################################################### # Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. ########################################################################### ## # Licensed to the Apache Software Foundation (ASF) under one # or more contributor license agreements. See the NOTICE file # distributed with this work for additional information # regarding copyright ownership. The ASF licenses this file # to you under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ## # # Specify defaults when method="html". These defaults use output_xml.properties # as a base. # Best, Joe On 12/15/16, 2:52 AM, Frank Yuan wrote: > Hi Christoph > > Thank you for the review! > > Please check http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.01/. > > I have updated the code as your comments except output_html.properties, I am not sure for the license of this file. > > To Joe > Could you confirm Christoph's comment for output_html.properties? > > > Thanks > Frank > >> -----Original Message----- >> From: Langer, Christoph [mailto:christoph.langer at sap.com] >> Subject: RE: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always > serializes an >> entity reference node to"&entityName;" even if "entities" property is false >> >> Hi Frank, >> >> this is awesome. >> >> Some minor things I saw while looking through the webrev: >> >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java >> Update copryright year >> Remove: >> 20 /* >> 21 * $Id: AbstractTranslet.java,v 1.6 2006/06/19 19:49:03 spericas Exp $ >> 22 */ >> >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java >> Remove: >> 20 /* >> 21 * $Id: TransformerImpl.java,v 1.10 2007/06/13 01:57:09 joehw Exp $ >> 22 */ >> >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java >> 462 protected boolean isInEntityRef() >> 463 { >> Put the brace on line 462 as well >> >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java >> -> sort import statements >> Method >> 773 public void startElement( >> -> use SAXException without package name. It is imported on top. This can be done in various places throughout the file. >> 780 //will add extra one if having namespace but no matter >> -> space between // and will... >> 821 if ((null != elemContext.m_elementName) >> -> For me it reads better if it were if ((elemContext.m_elementName != null) >> >> 1971 private void initToHTMLStream() >> 1972 { >> 1973 // m_elementDesc = null; >> 1974 m_isprevblock = false; >> 1975 m_inDTD = false; >> 1976 // m_isRawStack.clear(); >> 1977 m_omitMetaTag = false; >> 1978 m_specialEscapeURLs = true; >> 1979 } >> -> I guess you could remove the commented statements >> >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java >> 116 protected boolean m_ispreserveSpace = false; >> 117 >> 118 >> -> remove one empty line (117) >> >> 1894 m_ispreserve = false; >> 1895 >> 1896 >> 1897 >> -> newly inserted lines 1896 and 1897 should be removed >> >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output_html.properties >> -> maybe the Oracle copyright header can be inserted and the "$Id: output_html.properties..." part can be removed? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>> Of Joe Wang >>> Sent: Mittwoch, 14. Dezember 2016 04:09 >>> To: Frank Yuan >>> Cc: core-libs-dev at openjdk.java.net >>> Subject: Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work >>> anymore and JDK-8114834 LSSerializerImpl always serializes an entity >>> reference node to"&entityName;" even if "entities" property is false >>> >>> Hi Frank, >>> >>> Thanks for the diligent work! I think we've made a great improvement >>> over the PrettyPrint (tremendous ;-) ) >>> >>> Could you look into extracting the XML literal strings in the test into >>> plain files (similar to the other 'gold' files)? What I'm hoping to see >>> is that they'd look easily prettier in a text editor, and for that >>> matter, the original xml files were a mess. >>> >>> The tests set PrettyPrint, and by default for html. It would be good to >>> test the cases when it's turned off, that would help verify the >>> non-pretty format was not changed. >>> >>> Thanks, >>> Joe >>> >>> On 12/13/16, 6:55 AM, Frank Yuan wrote: >>>> Hi all >>>> >>>> Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ is >>> for JDK-8087303 and JDK-8114834, I have to combine the fix >>>> because there is some interaction between them. >>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 >>> https://bugs.openjdk.java.net/browse/JDK-8114834 >>>> Besides fixed some issues in xml serializer, I made the following changes in >>> this patch: >>>> 1. refined the handling for whitespace text >>>> 2. added support for xml:space attribute >>>> 3. changed the default indentation to 4 >>>> 4. refined the handling for HTML block element and inline element >>>> >>>> Would you like to have a look at this review? >>>> >>>> Thanks, >>>> >>>> Frank >>>> >>>> From huaming.li at oracle.com Fri Dec 16 02:42:45 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 16 Dec 2016 10:42:45 +0800 Subject: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..) In-Reply-To: References: Message-ID: Hi Roger, Daniel, Thank you for reviewing. On 2016/12/15 22:45, Roger Riggs wrote: > Hi Hamlin, > > If this is supposed to fix the call from line 68: then doesn't the > test for reg != null > at line 70 already have the same effect? Please consider the situation: LocateRegistry.createRegistry(port) in createReg(true, port) does not throw exception but just return null when remoteOk is true. this case is missed by current test. Although we know that should not happen by checking the product code, but the test should not assume how it is implemented. And I think the patch will make logic more clear, maybe we could remove the check of reg != null at the same time after modify the code in createReg(...). Thank you -Hamlin > > Roger > > > On 12/14/2016 10:19 PM, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8171133 >> webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/ >> >> java/rmi/registry/reexport/Reexport.java, there is a missing case >> check in createReg(..): if LocateRegistry.createRegistry(port) return >> null when port is in use. >> >> Thank you >> -Hamlin >> ------------------------------------------------------------------------ >> diff -r ddd192238fcb test/java/rmi/registry/reexport/Reexport.java >> --- a/test/java/rmi/registry/reexport/Reexport.java Tue Dec 13 >> 18:47:23 2016 -0800 >> +++ b/test/java/rmi/registry/reexport/Reexport.java Wed Dec 14 >> 19:06:40 2016 -0800 >> @@ -105,6 +105,9 @@ >> >> try { >> reg = LocateRegistry.createRegistry(port); >> + if (remoteOk) { >> + TestLibrary.bomb("Remote registry is up, an >> Exception is expected!"); >> + } >> } catch (Throwable e) { >> if (remoteOk) { >> System.err.println("EXPECTING PORT IN USE EXCEPTION:"); >> > From vyom.tewari at oracle.com Fri Dec 16 03:21:55 2016 From: vyom.tewari at oracle.com (Vyom Tewari) Date: Fri, 16 Dec 2016 08:51:55 +0530 Subject: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections In-Reply-To: <20161215145727.GA2475@vimes> References: <20161214155913.GC2524@tecra> <058ced05-487e-5f0a-c4e8-4d0680811d57@oracle.com> <20161215145727.GA2475@vimes> Message-ID: Hi Rob, Code changes looks good to me. Thanks, Vyom On Thursday 15 December 2016 08:27 PM, Rob McKenna wrote: > Gah, thanks Daniel. I originally worked this fix on 8u and neglected to > remove synchronized when forward porting. > > I've been having a few discussions on altering how we do locking in this > code in general and CoWArrayList is a nice idea. I'd like to leave this > change until I get to that work though. Thanks for the suggestion. > > Updated webrev at: http://cr.openjdk.java.net/~robm/8169465/webrev.02/ > > -Rob > > On 14/12/16 04:58, Daniel Fuchs wrote: >> Hi Rob, >> >> The expire(long) method is already synchronized, so there's no >> need to call synchronized(this) inside, unless you forgot to >> to remove synchronized from the method declaration? >> >> I wonder if 'conns' could be created as a CopyOnWriteArrayList. >> Then maybe no synchronization would be needed? It's the first time >> I'm looking at this file - so please accept this as a suggestion >> for a simpler (and possibly insufficient) alternative ... >> >> best regards, >> >> -- daniel >> >> On 14/12/16 15:59, Rob McKenna wrote: >>> Hi folks, >>> >>> Looking for a review of this change: >>> >>> http://cr.openjdk.java.net/~robm/8169465/webrev.01/ >>> >>> This is necessary to fix a potential problem where recursive ldap calls >>> can potentially cause a deadlock with the PoolCleaner thread. >>> >>> See: https://bugs.openjdk.java.net/browse/JDK-8169465 >>> >>> -Rob >>> From weijun.wang at oracle.com Fri Dec 16 03:43:19 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Fri, 16 Dec 2016 11:43:19 +0800 Subject: RFR 8171340: HttpNegotiateServer/java test should not use system proxy on Mac Message-ID: <40f9a2d2-d4af-f5c5-2770-ce84949d1c24@oracle.com> Please take a review at http://cr.openjdk.java.net/~weijun/8171340/webrev.00/ All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)". Everything else is whitespace change. Thanks Max From huaming.li at oracle.com Fri Dec 16 05:04:33 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Fri, 16 Dec 2016 13:04:33 +0800 Subject: RFR of JDK-8171298: ProblemList java/rmi/registry/readTest/readTest.sh due to JDK-7146543 Message-ID: <5513e6bd-d1e3-5261-f5c2-729dc9456a9d@oracle.com> Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8171298 diff -r 63e82d0eb4f6 test/ProblemList.txt --- a/test/ProblemList.txt Wed Dec 14 19:23:08 2016 -0800 +++ b/test/ProblemList.txt Thu Dec 15 21:01:34 2016 -0800 @@ -205,6 +205,8 @@ java/rmi/transport/dgcDeadLock/DGCDeadLock.java 8029360 macosx-all +java/rmi/registry/readTest/readTest.sh 7146543 generic-all + ############################################################################ # jdk_security Thank you -Hamlin From pango853 at gmail.com Fri Dec 16 05:32:10 2016 From: pango853 at gmail.com (Pango) Date: Fri, 16 Dec 2016 14:32:10 +0900 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: <8821bcd9-35aa-5a21-7a45-1fb6ed22c857@oracle.com> References: <8821bcd9-35aa-5a21-7a45-1fb6ed22c857@oracle.com> Message-ID: Hi Aleksej, Thank you. Really appreciate your prompt response. Hope this fix could be included in the next release (8u122?). Best Regards, Pango Chan 2016-12-15 20:04 GMT+09:00 Aleks Efimov : > Hi Pango, > The backport is done and I will send backport and review request for JDK8 > later today (I'm pending testing results). > > Best Regards, > Aleksej > > > On 15/12/16 05:41, Pango wrote: >> >> Hi all, >> >> May I ask has there been any progress on this issue? >> >> Actually we are also struggling with this problem. The software that >> we are working on do publish with 0.0.0.0 and we got this >> BindException while migrating to JDK 8. We tried several workarounds >> but it will be very inconvenient for the end users to follow. >> >> Now we are planning to release our product around next January, and >> really hope that there will be some good news announced by then. >> >> It would be very appreciated if anyone can give some information >> regarding the backport of this fix to JDK 8 update in advance. >> >> Thanks for all your hard work and contributions. >> >> Best regards, >> Pango Chan >> >> >> 2016-08-04 09:35 GMT+09:00 KUBOTA Yuji : >>> >>> Hi Aleksej, >>> >>> Thank you very much! >>> If you need some help about the patch, please mention me :) >>> >>> Thanks, >>> Yuji >>> >>> 2016-08-03 19:56 GMT+09:00 Aleks Efimov : >>>> >>>> Hi Yuji, >>>> >>>> I've created JDK8 backport [1] for this issue and will work on it in the >>>> upcoming months. >>>> >>>> Best Regards, >>>> >>>> Aleksej >>>> >>>> [1] https://bugs.openjdk.java.net/browse/JDK-8162941 >>>> >>>> >>>> >>>> On 02/08/16 08:33, KUBOTA Yuji wrote: >>>>> >>>>> Hi all, >>>>> >>>>> Could you let me know when this fix will be backport to JDK 8? >>>>> We need this backport to migrate our system from JDK 7 to JDK 8. >>>>> >>>>> Thanks, >>>>> Yuji >>>>> >>>>> 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji : >>>>>> >>>>>> Hi Miroslav, >>>>>> >>>>>> Thank you for your sponsor! : >>>>>> https://bugs.openjdk.java.net/browse/JDK-8146086 >>>>>> >>>>>> Can I ask the schedule when does this fix backport to JDK8 ? >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>>>> >>>>>> 2015-12-02 22:39 GMT+09:00 Miroslav Kos : >>>>>>> >>>>>>> Hi Yuji, >>>>>>> thanks for the patch - it fixes the issue and looks ok to me. I'll >>>>>>> integrate >>>>>>> it to standalone JAX-WS repo and it will be integrated into openjdk >>>>>>> during >>>>>>> next syncup. >>>>>>> >>>>>>> Thanks >>>>>>> Miran >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 01/12/15 11:11, KUBOTA Yuji wrote: >>>>>>>> >>>>>>>> Hi Miroslav and all, >>>>>>>> >>>>>>>> Could you please review the below issue and patch? >>>>>>>> >>>>>>>> I got the advice by Alan at net-dev. So I want to ask you. >>>>>>>> >>>>>>>> >>>>>>>> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html >>>>>>>> >>>>>>>> ---- >>>>>>>> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK >>>>>>>> community. This's second times from JavaOne14. :) >>>>>>>> >>>>>>>> We find an unexpected exception in JAX-WS, so I write a patch to fix >>>>>>>> it. >>>>>>>> We think that this issue may block the migration to JDK9 from JDK7. >>>>>>>> >>>>>>>> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the >>>>>>>> following test code, JDK9 (and JDK8) returns >>>>>>>> "java.net.BindException: >>>>>>>> Address already in use.? as the below. But JDK7 does NOT return the >>>>>>>> exception. >>>>>>>> >>>>>>>> - Test code for reproduce >>>>>>>> --- >>>>>>>> import javax.jws.*; >>>>>>>> import javax.xml.ws.*; >>>>>>>> >>>>>>>> public class WSTest{ >>>>>>>> >>>>>>>> @WebService >>>>>>>> public static class Method1{ >>>>>>>> @WebMethod >>>>>>>> public String getMethod1Value(){ >>>>>>>> return "from Method1"; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> @WebService >>>>>>>> public static class Method2{ >>>>>>>> @WebMethod >>>>>>>> public String getMethod2Value(){ >>>>>>>> return "from Method2"; >>>>>>>> } >>>>>>>> } >>>>>>>> >>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>> Endpoint endPoint1 = >>>>>>>> Endpoint.publish("http://0.0.0.0:8081/method1", >>>>>>>> >>>>>>>> new >>>>>>>> Method1()); >>>>>>>> Endpoint endPoint2 = >>>>>>>> Endpoint.publish("http://0.0.0.0:8081/method2", >>>>>>>> >>>>>>>> new >>>>>>>> Method2()); >>>>>>>> >>>>>>>> System.out.println("Sleep 3 secs..."); >>>>>>>> >>>>>>>> Thread.sleep(3000); >>>>>>>> >>>>>>>> endPoint2.stop(); >>>>>>>> endPoint1.stop(); >>>>>>>> } >>>>>>>> >>>>>>>> } >>>>>>>> --- >>>>>>>> >>>>>>>> - StackTrace >>>>>>>> --- >>>>>>>> Exception in thread "main" >>>>>>>> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime >>>>>>>> Error: java.net.BindException: Address already in use >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) >>>>>>>> at javax.xml.ws.Endpoint.publish(Endpoint.java:240) >>>>>>>> at wstest.WSTest.main(WSTest.java:27) >>>>>>>> Caused by: java.net.BindException: Address already in use >>>>>>>> at sun.nio.ch.Net.bind0(Native Method) >>>>>>>> at sun.nio.ch.Net.bind(Net.java:432) >>>>>>>> at sun.nio.ch.Net.bind(Net.java:424) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) >>>>>>>> at >>>>>>>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) >>>>>>>> at >>>>>>>> sun.net.httpserver.ServerImpl.(ServerImpl.java:102) >>>>>>>> at >>>>>>>> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) >>>>>>>> at >>>>>>>> com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) >>>>>>>> at >>>>>>>> >>>>>>>> >>>>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) >>>>>>>> ... 5 more >>>>>>>> ----- >>>>>>>> >>>>>>>> To publishes the Endpoint, JAX-WS checks whether the HttpContext has >>>>>>>> been created by given address, then creates a HttpContext if do not >>>>>>>> exist. >>>>>>>> If we sets 0.0.0.0 as given address, JAX-WS checks by >>>>>>>> ServerSocket#getLocalSocketAddress() (server local address), so >>>>>>>> returns BindException when 0.0.0.0 has been blinded already. >>>>>>>> >>>>>>>> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think >>>>>>>> about above situation. And JAX_WS-941 does not back port to JDK7. >>>>>>>> >>>>>>>> So I write a patch which is based jdk9/dev/jaxws >>>>>>>> (changeset:637:2d84c6f4cbba) to fix the BindException with >>>>>>>> JAX_WS-941. >>>>>>>> >>>>>>>> Please review this patch :) >>>>>>>> >>>>>>>> [1]: https://java.net/jira/browse/JAX_WS-941 >>>>>>>> >>>>>>>> - Patch >>>>>>>> --- >>>>>>>> diff -r 2d84c6f4cbba >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>>> --- >>>>>>>> >>>>>>>> >>>>>>>> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>>> Thu Oct 22 08:47:47 2015 -0700 >>>>>>>> +++ >>>>>>>> >>>>>>>> >>>>>>>> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>>> Tue Oct 27 19:48:35 2015 +0900 >>>>>>>> @@ -38,6 +38,7 @@ >>>>>>>> import java.util.concurrent.ExecutorService; >>>>>>>> import java.util.concurrent.Executors; >>>>>>>> import java.util.logging.Logger; >>>>>>>> +import java.util.Optional; >>>>>>>> >>>>>>>> /** >>>>>>>> * Manages all the WebService HTTP servers created by JAXWS >>>>>>>> runtime. >>>>>>>> @@ -81,24 +82,38 @@ >>>>>>>> synchronized(servers) { >>>>>>>> state = servers.get(inetAddress); >>>>>>>> if (state == null) { >>>>>>>> - logger.fine("Creating new HTTP Server at >>>>>>>> "+inetAddress); >>>>>>>> - // Creates server with default socket backlog >>>>>>>> - server = HttpServer.create(inetAddress, 0); >>>>>>>> - >>>>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>>>> - String path = url.toURI().getPath(); >>>>>>>> - logger.fine("Creating HTTP Context at = >>>>>>>> "+path); >>>>>>>> - HttpContext context = >>>>>>>> server.createContext(path); >>>>>>>> - server.start(); >>>>>>>> + final int finalPortNum = port; >>>>>>>> + Optional stateOpt = >>>>>>>> + servers.values() >>>>>>>> + .stream() >>>>>>>> + .filter(s -> s.getServer() >>>>>>>> + .getAddress() >>>>>>>> + .getPort() == >>>>>>>> finalPortNum) >>>>>>>> + .findAny(); >>>>>>>> >>>>>>>> - // we have to get actual inetAddress from >>>>>>>> server, >>>>>>>> which can differ from the original in some cases. >>>>>>>> - // e.g. A port number of zero will let the >>>>>>>> system >>>>>>>> pick up an ephemeral port in a bind operation, >>>>>>>> - // or IP: 0.0.0.0 - which is used to monitor >>>>>>>> network traffic from any valid IP address >>>>>>>> - inetAddress = server.getAddress(); >>>>>>>> + if >>>>>>>> (inetAddress.getAddress().isAnyLocalAddress() >>>>>>>> && >>>>>>>> + stateOpt.isPresent()) { >>>>>>>> + state = stateOpt.get(); >>>>>>>> + } else { >>>>>>>> + logger.fine("Creating new HTTP Server at >>>>>>>> "+inetAddress); >>>>>>>> + // Creates server with default socket >>>>>>>> backlog >>>>>>>> + server = HttpServer.create(inetAddress, 0); >>>>>>>> + >>>>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>>>> + String path = url.toURI().getPath(); >>>>>>>> + logger.fine("Creating HTTP Context at = >>>>>>>> "+path); >>>>>>>> + HttpContext context = >>>>>>>> server.createContext(path); >>>>>>>> + server.start(); >>>>>>>> >>>>>>>> - logger.fine("HTTP server started = >>>>>>>> "+inetAddress); >>>>>>>> - state = new ServerState(server, path); >>>>>>>> - servers.put(inetAddress, state); >>>>>>>> - return context; >>>>>>>> + // we have to get actual inetAddress from >>>>>>>> server, which can differ from the original in some cases. >>>>>>>> + // e.g. A port number of zero will let the >>>>>>>> system pick up an ephemeral port in a bind operation, >>>>>>>> + // or IP: 0.0.0.0 - which is used to >>>>>>>> monitor >>>>>>>> network traffic from any valid IP address >>>>>>>> + inetAddress = server.getAddress(); >>>>>>>> + >>>>>>>> + logger.fine("HTTP server started = >>>>>>>> "+inetAddress); >>>>>>>> + state = new ServerState(server, path); >>>>>>>> + servers.put(inetAddress, state); >>>>>>>> + return context; >>>>>>>> + } >>>>>>>> } >>>>>>>> } >>>>>>>> server = state.getServer(); >>>>>>>> --- >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Yuji >>>>>>> >>>>>>> >> >> > -- Best regards, Pango Chan From kubota.yuji at gmail.com Fri Dec 16 06:12:51 2016 From: kubota.yuji at gmail.com (KUBOTA Yuji) Date: Fri, 16 Dec 2016 15:12:51 +0900 Subject: Unexpected BindException in Endpoint.publish In-Reply-To: References: <8821bcd9-35aa-5a21-7a45-1fb6ed22c857@oracle.com> Message-ID: Hi Aleksej and Pango, Thank you for backport and pushing. Regards, Yuji 2016-12-16 14:32 GMT+09:00 Pango : > Hi Aleksej, > > Thank you. Really appreciate your prompt response. > Hope this fix could be included in the next release (8u122?). > > Best Regards, > Pango Chan > > 2016-12-15 20:04 GMT+09:00 Aleks Efimov : >> Hi Pango, >> The backport is done and I will send backport and review request for JDK8 >> later today (I'm pending testing results). >> >> Best Regards, >> Aleksej >> >> >> On 15/12/16 05:41, Pango wrote: >>> >>> Hi all, >>> >>> May I ask has there been any progress on this issue? >>> >>> Actually we are also struggling with this problem. The software that >>> we are working on do publish with 0.0.0.0 and we got this >>> BindException while migrating to JDK 8. We tried several workarounds >>> but it will be very inconvenient for the end users to follow. >>> >>> Now we are planning to release our product around next January, and >>> really hope that there will be some good news announced by then. >>> >>> It would be very appreciated if anyone can give some information >>> regarding the backport of this fix to JDK 8 update in advance. >>> >>> Thanks for all your hard work and contributions. >>> >>> Best regards, >>> Pango Chan >>> >>> >>> 2016-08-04 09:35 GMT+09:00 KUBOTA Yuji : >>>> >>>> Hi Aleksej, >>>> >>>> Thank you very much! >>>> If you need some help about the patch, please mention me :) >>>> >>>> Thanks, >>>> Yuji >>>> >>>> 2016-08-03 19:56 GMT+09:00 Aleks Efimov : >>>>> >>>>> Hi Yuji, >>>>> >>>>> I've created JDK8 backport [1] for this issue and will work on it in the >>>>> upcoming months. >>>>> >>>>> Best Regards, >>>>> >>>>> Aleksej >>>>> >>>>> [1] https://bugs.openjdk.java.net/browse/JDK-8162941 >>>>> >>>>> >>>>> >>>>> On 02/08/16 08:33, KUBOTA Yuji wrote: >>>>>> >>>>>> Hi all, >>>>>> >>>>>> Could you let me know when this fix will be backport to JDK 8? >>>>>> We need this backport to migrate our system from JDK 7 to JDK 8. >>>>>> >>>>>> Thanks, >>>>>> Yuji >>>>>> >>>>>> 2016-02-10 10:17 GMT+09:00 KUBOTA Yuji : >>>>>>> >>>>>>> Hi Miroslav, >>>>>>> >>>>>>> Thank you for your sponsor! : >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8146086 >>>>>>> >>>>>>> Can I ask the schedule when does this fix backport to JDK8 ? >>>>>>> >>>>>>> Thanks, >>>>>>> Yuji >>>>>>> >>>>>>> 2015-12-02 22:39 GMT+09:00 Miroslav Kos : >>>>>>>> >>>>>>>> Hi Yuji, >>>>>>>> thanks for the patch - it fixes the issue and looks ok to me. I'll >>>>>>>> integrate >>>>>>>> it to standalone JAX-WS repo and it will be integrated into openjdk >>>>>>>> during >>>>>>>> next syncup. >>>>>>>> >>>>>>>> Thanks >>>>>>>> Miran >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 01/12/15 11:11, KUBOTA Yuji wrote: >>>>>>>>> >>>>>>>>> Hi Miroslav and all, >>>>>>>>> >>>>>>>>> Could you please review the below issue and patch? >>>>>>>>> >>>>>>>>> I got the advice by Alan at net-dev. So I want to ask you. >>>>>>>>> >>>>>>>>> >>>>>>>>> http://mail.openjdk.java.net/pipermail/net-dev/2015-December/009361.html >>>>>>>>> >>>>>>>>> ---- >>>>>>>>> I'm at the HackerGarten @ JavaOne15, and write a patch for OpenJDK >>>>>>>>> community. This's second times from JavaOne14. :) >>>>>>>>> >>>>>>>>> We find an unexpected exception in JAX-WS, so I write a patch to fix >>>>>>>>> it. >>>>>>>>> We think that this issue may block the migration to JDK9 from JDK7. >>>>>>>>> >>>>>>>>> If we bind 0.0.0.0 ( using as wildcard ) to publish multiple as the >>>>>>>>> following test code, JDK9 (and JDK8) returns >>>>>>>>> "java.net.BindException: >>>>>>>>> Address already in use.? as the below. But JDK7 does NOT return the >>>>>>>>> exception. >>>>>>>>> >>>>>>>>> - Test code for reproduce >>>>>>>>> --- >>>>>>>>> import javax.jws.*; >>>>>>>>> import javax.xml.ws.*; >>>>>>>>> >>>>>>>>> public class WSTest{ >>>>>>>>> >>>>>>>>> @WebService >>>>>>>>> public static class Method1{ >>>>>>>>> @WebMethod >>>>>>>>> public String getMethod1Value(){ >>>>>>>>> return "from Method1"; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> @WebService >>>>>>>>> public static class Method2{ >>>>>>>>> @WebMethod >>>>>>>>> public String getMethod2Value(){ >>>>>>>>> return "from Method2"; >>>>>>>>> } >>>>>>>>> } >>>>>>>>> >>>>>>>>> public static void main(String[] args) throws Exception{ >>>>>>>>> Endpoint endPoint1 = >>>>>>>>> Endpoint.publish("http://0.0.0.0:8081/method1", >>>>>>>>> >>>>>>>>> new >>>>>>>>> Method1()); >>>>>>>>> Endpoint endPoint2 = >>>>>>>>> Endpoint.publish("http://0.0.0.0:8081/method2", >>>>>>>>> >>>>>>>>> new >>>>>>>>> Method2()); >>>>>>>>> >>>>>>>>> System.out.println("Sleep 3 secs..."); >>>>>>>>> >>>>>>>>> Thread.sleep(3000); >>>>>>>>> >>>>>>>>> endPoint2.stop(); >>>>>>>>> endPoint1.stop(); >>>>>>>>> } >>>>>>>>> >>>>>>>>> } >>>>>>>>> --- >>>>>>>>> >>>>>>>>> - StackTrace >>>>>>>>> --- >>>>>>>>> Exception in thread "main" >>>>>>>>> com.sun.xml.internal.ws.server.ServerRtException: Server Runtime >>>>>>>>> Error: java.net.BindException: Address already in use >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:117) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> com.sun.xml.internal.ws.transport.http.server.HttpEndpoint.publish(HttpEndpoint.java:64) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> com.sun.xml.internal.ws.transport.http.server.EndpointImpl.publish(EndpointImpl.java:232) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> com.sun.xml.internal.ws.spi.ProviderImpl.createAndPublishEndpoint(ProviderImpl.java:126) >>>>>>>>> at javax.xml.ws.Endpoint.publish(Endpoint.java:240) >>>>>>>>> at wstest.WSTest.main(WSTest.java:27) >>>>>>>>> Caused by: java.net.BindException: Address already in use >>>>>>>>> at sun.nio.ch.Net.bind0(Native Method) >>>>>>>>> at sun.nio.ch.Net.bind(Net.java:432) >>>>>>>>> at sun.nio.ch.Net.bind(Net.java:424) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> sun.nio.ch.ServerSocketChannelImpl.bind(ServerSocketChannelImpl.java:223) >>>>>>>>> at >>>>>>>>> sun.nio.ch.ServerSocketAdaptor.bind(ServerSocketAdaptor.java:74) >>>>>>>>> at >>>>>>>>> sun.net.httpserver.ServerImpl.(ServerImpl.java:102) >>>>>>>>> at >>>>>>>>> sun.net.httpserver.HttpServerImpl.(HttpServerImpl.java:50) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> sun.net.httpserver.DefaultHttpServerProvider.createHttpServer(DefaultHttpServerProvider.java:35) >>>>>>>>> at >>>>>>>>> com.sun.net.httpserver.HttpServer.create(HttpServer.java:130) >>>>>>>>> at >>>>>>>>> >>>>>>>>> >>>>>>>>> com.sun.xml.internal.ws.transport.http.server.ServerMgr.createContext(ServerMgr.java:86) >>>>>>>>> ... 5 more >>>>>>>>> ----- >>>>>>>>> >>>>>>>>> To publishes the Endpoint, JAX-WS checks whether the HttpContext has >>>>>>>>> been created by given address, then creates a HttpContext if do not >>>>>>>>> exist. >>>>>>>>> If we sets 0.0.0.0 as given address, JAX-WS checks by >>>>>>>>> ServerSocket#getLocalSocketAddress() (server local address), so >>>>>>>>> returns BindException when 0.0.0.0 has been blinded already. >>>>>>>>> >>>>>>>>> Why so? JAX_WS-941[1] fixes NPE in Endpoint.stop but do not think >>>>>>>>> about above situation. And JAX_WS-941 does not back port to JDK7. >>>>>>>>> >>>>>>>>> So I write a patch which is based jdk9/dev/jaxws >>>>>>>>> (changeset:637:2d84c6f4cbba) to fix the BindException with >>>>>>>>> JAX_WS-941. >>>>>>>>> >>>>>>>>> Please review this patch :) >>>>>>>>> >>>>>>>>> [1]: https://java.net/jira/browse/JAX_WS-941 >>>>>>>>> >>>>>>>>> - Patch >>>>>>>>> --- >>>>>>>>> diff -r 2d84c6f4cbba >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>>>> --- >>>>>>>>> >>>>>>>>> >>>>>>>>> a/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>>>> Thu Oct 22 08:47:47 2015 -0700 >>>>>>>>> +++ >>>>>>>>> >>>>>>>>> >>>>>>>>> b/src/java.xml.ws/share/classes/com/sun/xml/internal/ws/transport/http/server/ServerMgr.java >>>>>>>>> Tue Oct 27 19:48:35 2015 +0900 >>>>>>>>> @@ -38,6 +38,7 @@ >>>>>>>>> import java.util.concurrent.ExecutorService; >>>>>>>>> import java.util.concurrent.Executors; >>>>>>>>> import java.util.logging.Logger; >>>>>>>>> +import java.util.Optional; >>>>>>>>> >>>>>>>>> /** >>>>>>>>> * Manages all the WebService HTTP servers created by JAXWS >>>>>>>>> runtime. >>>>>>>>> @@ -81,24 +82,38 @@ >>>>>>>>> synchronized(servers) { >>>>>>>>> state = servers.get(inetAddress); >>>>>>>>> if (state == null) { >>>>>>>>> - logger.fine("Creating new HTTP Server at >>>>>>>>> "+inetAddress); >>>>>>>>> - // Creates server with default socket backlog >>>>>>>>> - server = HttpServer.create(inetAddress, 0); >>>>>>>>> - >>>>>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>>>>> - String path = url.toURI().getPath(); >>>>>>>>> - logger.fine("Creating HTTP Context at = >>>>>>>>> "+path); >>>>>>>>> - HttpContext context = >>>>>>>>> server.createContext(path); >>>>>>>>> - server.start(); >>>>>>>>> + final int finalPortNum = port; >>>>>>>>> + Optional stateOpt = >>>>>>>>> + servers.values() >>>>>>>>> + .stream() >>>>>>>>> + .filter(s -> s.getServer() >>>>>>>>> + .getAddress() >>>>>>>>> + .getPort() == >>>>>>>>> finalPortNum) >>>>>>>>> + .findAny(); >>>>>>>>> >>>>>>>>> - // we have to get actual inetAddress from >>>>>>>>> server, >>>>>>>>> which can differ from the original in some cases. >>>>>>>>> - // e.g. A port number of zero will let the >>>>>>>>> system >>>>>>>>> pick up an ephemeral port in a bind operation, >>>>>>>>> - // or IP: 0.0.0.0 - which is used to monitor >>>>>>>>> network traffic from any valid IP address >>>>>>>>> - inetAddress = server.getAddress(); >>>>>>>>> + if >>>>>>>>> (inetAddress.getAddress().isAnyLocalAddress() >>>>>>>>> && >>>>>>>>> + stateOpt.isPresent()) { >>>>>>>>> + state = stateOpt.get(); >>>>>>>>> + } else { >>>>>>>>> + logger.fine("Creating new HTTP Server at >>>>>>>>> "+inetAddress); >>>>>>>>> + // Creates server with default socket >>>>>>>>> backlog >>>>>>>>> + server = HttpServer.create(inetAddress, 0); >>>>>>>>> + >>>>>>>>> server.setExecutor(Executors.newCachedThreadPool()); >>>>>>>>> + String path = url.toURI().getPath(); >>>>>>>>> + logger.fine("Creating HTTP Context at = >>>>>>>>> "+path); >>>>>>>>> + HttpContext context = >>>>>>>>> server.createContext(path); >>>>>>>>> + server.start(); >>>>>>>>> >>>>>>>>> - logger.fine("HTTP server started = >>>>>>>>> "+inetAddress); >>>>>>>>> - state = new ServerState(server, path); >>>>>>>>> - servers.put(inetAddress, state); >>>>>>>>> - return context; >>>>>>>>> + // we have to get actual inetAddress from >>>>>>>>> server, which can differ from the original in some cases. >>>>>>>>> + // e.g. A port number of zero will let the >>>>>>>>> system pick up an ephemeral port in a bind operation, >>>>>>>>> + // or IP: 0.0.0.0 - which is used to >>>>>>>>> monitor >>>>>>>>> network traffic from any valid IP address >>>>>>>>> + inetAddress = server.getAddress(); >>>>>>>>> + >>>>>>>>> + logger.fine("HTTP server started = >>>>>>>>> "+inetAddress); >>>>>>>>> + state = new ServerState(server, path); >>>>>>>>> + servers.put(inetAddress, state); >>>>>>>>> + return context; >>>>>>>>> + } >>>>>>>>> } >>>>>>>>> } >>>>>>>>> server = state.getServer(); >>>>>>>>> --- >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Yuji >>>>>>>> >>>>>>>> >>> >>> >> > > > > -- > Best regards, > Pango Chan From chris.hegarty at oracle.com Fri Dec 16 09:49:54 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 16 Dec 2016 09:49:54 +0000 Subject: RFR 8171340: HttpNegotiateServer/java test should not use system proxy on Mac In-Reply-To: <40f9a2d2-d4af-f5c5-2770-ce84949d1c24@oracle.com> References: <40f9a2d2-d4af-f5c5-2770-ce84949d1c24@oracle.com> Message-ID: <680a8e3c-cc28-6d71-c5af-2d7e55068bcb@oracle.com> On 16/12/16 03:43, Wang Weijun wrote: > Please take a review at > > http://cr.openjdk.java.net/~weijun/8171340/webrev.00/ > > All "openConnection()" modified to "openConnection(Proxy.NO_PROXY)". Thank you Max. Reviewed. -Chris. From uschindler at apache.org Fri Dec 16 09:58:35 2016 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 16 Dec 2016 10:58:35 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <584BBB4A.9060603@gmx.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <584BBB4A.9060603@gmx.org> Message-ID: <00b501d25782$f997dd10$ecc79730$@apache.org> Hi Jochen, thank you for the information! Is there any plan about a release? I also found no JIRA issue about this issue to link it against our JIRA: https://issues.apache.org/jira/browse/LUCENE-7596 The problem makes our build system unusable, so it would be very important to have a fix quite soon! As our Ant/Ivy-based build relies on Maven Central, it would be good to have the bugfix release available there, which requires a release. I think the same applies for Gradle users (Elasticsearch). As a temporary workaround we might be able to use the Apache Snapshot repository, but this is not allowed if we do a release of Lucene. Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Jochen Theodorou [mailto:blackdrag at gmx.org] > Sent: Saturday, December 10, 2016 9:23 AM > To: Uwe Schindler ; jigsaw-dev at openjdk.java.net; > Core-Libs-Dev > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > On 09.12.2016 23:32, Uwe Schindler wrote: > > Hi, > > > > I updated our Jenkins server for the JDK 9 preview testing to use build 148. > Previously we had build 140 and build 147, which both worked without any > issues. But after the update the following stuff goes wrong: > > > > (1) Unmapping of direct buffers no longer works, although this API was > marked as critical because there is no replacement up to now, so code can > unmap memory mapped files, which is one of the most important things > Apache Lucene needs to use to access huge random access files while > reading the index. Without memory mapping, the slowdown for Lucene > users will be huge > > > > This is caused by the recent Jigsaw changes, published in build 148. > Unfortunately we did not test the Jigsaw builds, so we would have noticed > that earlier. Basically the following peace of code fails now (with or without > doPrivileged and with/without security manager): > > > > final Class directBufferClass = > Class.forName("java.nio.DirectByteBuffer"); > > > > final Method m = directBufferClass.getMethod("cleaner"); > > m.setAccessible(true); > > MethodHandle directBufferCleanerMethod = lookup.unreflect(m); > > Class cleanerClass = > directBufferCleanerMethod.type().returnType(); > > // build method handle for unmapping, full code is here: > https://goo.gl/TfQWl6 > > I guess that is the effect of #AwkwardStrongEncapsulation. I would > advise doing regular checks against the jigsaw builds to know about such > problems in the future earlier... but seeing your code break without an > obvious good solution sure is stressful. I feel with you. > > [...] > > (2) A second thing we noticed is that Groovy no longer works and dies with > strange error messages. > > That is because versions including Groovy 2.4.7 are using > setAccessible(AccessibleObject[] array, true), and the array will also > include private methods or fields. This worked till > #AwkwardStrongEncapsulation because will then a class was either > exported and its method can all be made accessible or not. For example > on GAE or earlier versions of the module system. Now an exported class > may break this, since its private methods can no longer be made > accessible using setAccessible. > > A fix for this is already committed, we are only waiting for release of > Groovy 2.4.8. Of course even with the fix Groovy code can possibly > break... for example if you did the direct buffer access in Groovy. > > Btw, do not hesitate to ask about such problems on groovy-user, please. > > bye Jochen From daniel.fuchs at oracle.com Fri Dec 16 10:46:48 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Fri, 16 Dec 2016 10:46:48 +0000 Subject: Review request - 8169465: Deadlock in com.sun.jndi.ldap.pool.Connections In-Reply-To: References: <20161214155913.GC2524@tecra> <058ced05-487e-5f0a-c4e8-4d0680811d57@oracle.com> <20161215145727.GA2475@vimes> Message-ID: <4e368403-e993-3db5-41cf-ed43fb20e236@oracle.com> Hi Rob, Looks good to me too now. -- daniel On 16/12/16 03:21, Vyom Tewari wrote: > Hi Rob, > > Code changes looks good to me. > > Thanks, > > Vyom > > > On Thursday 15 December 2016 08:27 PM, Rob McKenna wrote: >> Gah, thanks Daniel. I originally worked this fix on 8u and neglected to >> remove synchronized when forward porting. >> >> I've been having a few discussions on altering how we do locking in this >> code in general and CoWArrayList is a nice idea. I'd like to leave this >> change until I get to that work though. Thanks for the suggestion. >> >> Updated webrev at: http://cr.openjdk.java.net/~robm/8169465/webrev.02/ >> >> -Rob >> >> On 14/12/16 04:58, Daniel Fuchs wrote: >>> Hi Rob, >>> >>> The expire(long) method is already synchronized, so there's no >>> need to call synchronized(this) inside, unless you forgot to >>> to remove synchronized from the method declaration? >>> >>> I wonder if 'conns' could be created as a CopyOnWriteArrayList. >>> Then maybe no synchronization would be needed? It's the first time >>> I'm looking at this file - so please accept this as a suggestion >>> for a simpler (and possibly insufficient) alternative ... >>> >>> best regards, >>> >>> -- daniel >>> >>> On 14/12/16 15:59, Rob McKenna wrote: >>>> Hi folks, >>>> >>>> Looking for a review of this change: >>>> >>>> http://cr.openjdk.java.net/~robm/8169465/webrev.01/ >>>> >>>> This is necessary to fix a potential problem where recursive ldap calls >>>> can potentially cause a deadlock with the PoolCleaner thread. >>>> >>>> See: https://bugs.openjdk.java.net/browse/JDK-8169465 >>>> >>>> -Rob >>>> > From abhijit.r.roy at oracle.com Fri Dec 16 11:19:32 2016 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Fri, 16 Dec 2016 03:19:32 -0800 (PST) Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' Message-ID: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> Hi all, Please review the java doc fix for the below bug: Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 Description: Incorrect documentation for DateTimeFormatter letter 'k' Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ I have just rectified and modified those errors. And moving forward it for review. Regards, Abhijit P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, JDK-8169482, JDK-8170653 From blackdrag at gmx.org Fri Dec 16 13:11:25 2016 From: blackdrag at gmx.org (Jochen Theodorou) Date: Fri, 16 Dec 2016 14:11:25 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <00b501d25782$f997dd10$ecc79730$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <584BBB4A.9060603@gmx.org> <00b501d25782$f997dd10$ecc79730$@apache.org> Message-ID: <5ebb59c1-7ec3-6ae0-3851-361a40cab276@gmx.org> Hi, I strongly hope Paul and Cedric will be able to start the release process next week, if not we will have to do it the old way I think. what would help us a lot would be you testing the GROOVY_2_4_X branch with your build system to see if it really does solve your problem. Even if it is only locally on your computer bye Jochen On 16.12.2016 10:58, Uwe Schindler wrote: > Hi Jochen, > > thank you for the information! Is there any plan about a release? I also found no JIRA issue about this issue to link it against our JIRA: https://issues.apache.org/jira/browse/LUCENE-7596 > > The problem makes our build system unusable, so it would be very important to have a fix quite soon! As our Ant/Ivy-based build relies on Maven Central, it would be good to have the bugfix release available there, which requires a release. I think the same applies for Gradle users (Elasticsearch). > > As a temporary workaround we might be able to use the Apache Snapshot repository, but this is not allowed if we do a release of Lucene. > > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: Jochen Theodorou [mailto:blackdrag at gmx.org] >> Sent: Saturday, December 10, 2016 9:23 AM >> To: Uwe Schindler ; jigsaw-dev at openjdk.java.net; >> Core-Libs-Dev >> Subject: Re: Java 9 build 148 causes trouble in Apache >> Lucene/Solr/Elasticsearch >> >> On 09.12.2016 23:32, Uwe Schindler wrote: >>> Hi, >>> >>> I updated our Jenkins server for the JDK 9 preview testing to use build 148. >> Previously we had build 140 and build 147, which both worked without any >> issues. But after the update the following stuff goes wrong: >>> >>> (1) Unmapping of direct buffers no longer works, although this API was >> marked as critical because there is no replacement up to now, so code can >> unmap memory mapped files, which is one of the most important things >> Apache Lucene needs to use to access huge random access files while >> reading the index. Without memory mapping, the slowdown for Lucene >> users will be huge >>> >>> This is caused by the recent Jigsaw changes, published in build 148. >> Unfortunately we did not test the Jigsaw builds, so we would have noticed >> that earlier. Basically the following peace of code fails now (with or without >> doPrivileged and with/without security manager): >>> >>> final Class directBufferClass = >> Class.forName("java.nio.DirectByteBuffer"); >>> >>> final Method m = directBufferClass.getMethod("cleaner"); >>> m.setAccessible(true); >>> MethodHandle directBufferCleanerMethod = lookup.unreflect(m); >>> Class cleanerClass = >> directBufferCleanerMethod.type().returnType(); >>> // build method handle for unmapping, full code is here: >> https://goo.gl/TfQWl6 >> >> I guess that is the effect of #AwkwardStrongEncapsulation. I would >> advise doing regular checks against the jigsaw builds to know about such >> problems in the future earlier... but seeing your code break without an >> obvious good solution sure is stressful. I feel with you. >> >> [...] >>> (2) A second thing we noticed is that Groovy no longer works and dies with >> strange error messages. >> >> That is because versions including Groovy 2.4.7 are using >> setAccessible(AccessibleObject[] array, true), and the array will also >> include private methods or fields. This worked till >> #AwkwardStrongEncapsulation because will then a class was either >> exported and its method can all be made accessible or not. For example >> on GAE or earlier versions of the module system. Now an exported class >> may break this, since its private methods can no longer be made >> accessible using setAccessible. >> >> A fix for this is already committed, we are only waiting for release of >> Groovy 2.4.8. Of course even with the fix Groovy code can possibly >> break... for example if you did the direct buffer access in Groovy. >> >> Btw, do not hesitate to ask about such problems on groovy-user, please. >> >> bye Jochen > From dl at cs.oswego.edu Fri Dec 16 13:14:50 2016 From: dl at cs.oswego.edu (Doug Lea) Date: Fri, 16 Dec 2016 08:14:50 -0500 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: Message-ID: <0f1e0057-996f-a782-3197-10476ee5ed0a@cs.oswego.edu> On 12/15/2016 01:17 PM, Stefan Zobel wrote: > I recently noticed that javac creates a synthetic class and a bridge constructor > for SubmissionPublisher.ThreadPerTaskExecutor because its generated constructor > is private. I don't know if it really matters but that could be avoided by > declaring a package-private constructor that does nothing. Or, more simply remove the unnecessary "private" qualifier for the nested ThreadPerTaskExecutor class, as we did in the similar usage in CompletableFuture, and should have remembered to do here. Done; thanks. -Doug > >> /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */ >> private static final class ThreadPerTaskExecutor implements Executor { >> // avoid creation of synthetic class and bridge constructor >> ThreadPerTaskExecutor() {} >> public void execute(Runnable r) { new Thread(r).start(); } >> } > > > Regards, > Stefan > From Roger.Riggs at Oracle.com Fri Dec 16 14:10:50 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 16 Dec 2016 09:10:50 -0500 Subject: RFR of JDK-8171298: ProblemList java/rmi/registry/readTest/readTest.sh due to JDK-7146543 In-Reply-To: <5513e6bd-d1e3-5261-f5c2-729dc9456a9d@oracle.com> References: <5513e6bd-d1e3-5261-f5c2-729dc9456a9d@oracle.com> Message-ID: Hi Hamlin, Looks fine. (Using a subtask for this kind of problem listing works well too; then it is clearly related to the original bug. And isn't an independent issue. Yes, task bugid can be used for commits). Thanks, Roger On 12/16/2016 12:04 AM, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8171298 > > > diff -r 63e82d0eb4f6 test/ProblemList.txt > --- a/test/ProblemList.txt Wed Dec 14 19:23:08 2016 -0800 > +++ b/test/ProblemList.txt Thu Dec 15 21:01:34 2016 -0800 > @@ -205,6 +205,8 @@ > > java/rmi/transport/dgcDeadLock/DGCDeadLock.java 8029360 macosx-all > > +java/rmi/registry/readTest/readTest.sh 7146543 generic-all > + > ############################################################################ > > > # jdk_security > > > Thank you > -Hamlin From Roger.Riggs at Oracle.com Fri Dec 16 14:13:41 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 16 Dec 2016 09:13:41 -0500 Subject: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..) In-Reply-To: References: Message-ID: <645d57e8-7820-de52-dd6f-a7cd2f96982f@Oracle.com> Hi Hamlin, Yes, the logic would be clearer; and I would also remove the (now) redundant checking. Roger On 12/15/2016 9:42 PM, Hamlin Li wrote: > Hi Roger, Daniel, > > Thank you for reviewing. > > On 2016/12/15 22:45, Roger Riggs wrote: >> Hi Hamlin, >> >> If this is supposed to fix the call from line 68: then doesn't the >> test for reg != null >> at line 70 already have the same effect? > Please consider the situation: LocateRegistry.createRegistry(port) in > createReg(true, port) does not throw exception but just return null > when remoteOk is true. this case is missed by current test. Although > we know that should not happen by checking the product code, but the > test should not assume how it is implemented. > And I think the patch will make logic more clear, maybe we could > remove the check of reg != null at the same time after modify the code > in createReg(...). > > Thank you > -Hamlin >> >> Roger >> >> >> On 12/14/2016 10:19 PM, Hamlin Li wrote: >>> Would you please review the below patch? >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8171133 >>> webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/ >>> >>> java/rmi/registry/reexport/Reexport.java, there is a missing case >>> check in createReg(..): if LocateRegistry.createRegistry(port) >>> return null when port is in use. >>> >>> Thank you >>> -Hamlin >>> ------------------------------------------------------------------------ >>> >>> diff -r ddd192238fcb test/java/rmi/registry/reexport/Reexport.java >>> --- a/test/java/rmi/registry/reexport/Reexport.java Tue Dec 13 >>> 18:47:23 2016 -0800 >>> +++ b/test/java/rmi/registry/reexport/Reexport.java Wed Dec 14 >>> 19:06:40 2016 -0800 >>> @@ -105,6 +105,9 @@ >>> >>> try { >>> reg = LocateRegistry.createRegistry(port); >>> + if (remoteOk) { >>> + TestLibrary.bomb("Remote registry is up, an >>> Exception is expected!"); >>> + } >>> } catch (Throwable e) { >>> if (remoteOk) { >>> System.err.println("EXPECTING PORT IN USE >>> EXCEPTION:"); >>> >> > From Roger.Riggs at Oracle.com Fri Dec 16 14:28:15 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 16 Dec 2016 09:28:15 -0500 Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' In-Reply-To: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> References: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> Message-ID: <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> Hi Abhijit, Please also fix the same error in DateTimeFormatter; line 300. I would use '24' as the example of the hour of day. It would emphasize that the range is 1-24. Roger On 12/16/2016 6:19 AM, Abhijit Roy wrote: > Hi all, > > > > Please review the java doc fix for the below bug: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 > > Description: Incorrect documentation for DateTimeFormatter letter 'k' > > Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ > > > > I have just rectified and modified those errors. And moving forward it for review. > > > > Regards, > > Abhijit > > > > > > P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, JDK-8169482, JDK-8170653 From Roger.Riggs at Oracle.com Fri Dec 16 14:31:34 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 16 Dec 2016 09:31:34 -0500 Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' In-Reply-To: <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> References: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> Message-ID: <196d5a53-dc3b-0ba4-67b9-ce2fda1610fe@Oracle.com> Hi, Sorry, I meant DateTimeFormatterBuilder. Roger On 12/16/2016 9:28 AM, Roger Riggs wrote: > Hi Abhijit, > > Please also fix the same error in DateTimeFormatter; line 300. > > I would use '24' as the example of the hour of day. > It would emphasize that the range is 1-24. > > Roger > > > On 12/16/2016 6:19 AM, Abhijit Roy wrote: >> Hi all, >> >> >> Please review the java doc fix for the below bug: >> >> Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 >> >> Description: Incorrect documentation for DateTimeFormatter letter 'k' >> >> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ >> >> >> I have just rectified and modified those errors. And moving forward >> it for review. >> >> >> Regards, >> >> Abhijit >> >> >> >> P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, >> JDK-8169482, JDK-8170653 > From gunnar at hibernate.org Fri Dec 16 16:18:48 2016 From: gunnar at hibernate.org (Gunnar Morling) Date: Fri, 16 Dec 2016 17:18:48 +0100 Subject: Proposal: Add a type token class for representing generic types Message-ID: Hi, I'd like to suggest the addition of a type token class to the Java class library, to be used for representing generic types such as List. Actual class literals can only represent raw types. But often libraries have the need to apply some sort of configuration to specific generic types, link specific behaviour to them or expose (meta) data related to them. The suggested type token class would allow to implement such cases in a type-safe fashion. # Example use cases * The "type-safe heterogenous container" pattern from Joshua Bloch's book "Effective Java" introduces a container which allows to safely store and retrieve objects of different types. They are keyed by Class, which means that one cannot have a value for a List and another value for a List in such container. Also one cannot obtain a List without casting from such container. Type literals would allow this: void put(TypeLiteral type, T value); T get(TypeLiteral type); TypeLiteral> stringListType = ...; List stringList = container.get( stringListType ); * JAX-RS allows to read response message entities into parameterized types using its GenericType class: List customers = response.readEntity( new GenericType>() {} ); * CDI allows to dynamically obtain beans of specific parameterized types using its TypeLiteral class: @Inject @Any Instance anyPaymentProcessor; public PaymentProcessor getChequePaymentProcessor() { PaymentProcessor pp = anyPaymentProcessor .select( new TypeLiteral>() {} ).get(); } # Proposed solution Type literals would be represented by a new type java.lang.reflect.TypeLiteral. Instances would be created via sub-classing, capturing the parameter and baking it into the sub-class: TypeLiteral> stringListType = new TypeLiteral>(){}; That'd allow to provide type-safe APIs around generic types as shown in the examples above. The following methods should be defined on TypeLiteral in order to make it useful for implementers of such APIs: Type getType(); Class getRawType(); boolean equals(Object obj); int hashCode(); String toString(); # Prior art The idea of type tokens based on capturing a generic type in a sub-class has been around for a long time. The first reference I've found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1]. Examples in real-world APIs and libraries are TypeLiteral in CDI [2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4] and TypeToken in Guava [5]. # Alternatives and shortcomings The obvious alternative would be reified generics, but I think it's commonly agreed upon that these will not come to the Java language any time soon. Without native support in the language itself the proposed type literal class is the best way to support the mentioned use cases as far as I can say. Shortcomings are the creation of a sub-class per literal instantiation (probably more an aesthetic problem, though) and failure of the pattern when type variables are included anywhere in the represented type [6]. Unfortunately, this can only be detected at runtime when instantiating a literal but not by the compiler (although, I reckon it technically could, by handling this case specifically). # Conclusion Lacking reified generics, the Java platform would benefit from the addition of new type token class java.lang.reflect.TypeLiteral. The pattern's presence in common APIs and libraries shows that there is a wide-spread need for such mechanism and the community would benefit very much from a standardized solution in the JDK itself. This will allow for more unified API designs as well as foster integration of different libraries. I'm eager to learn about your feedback and the OpenJDK team's assessment of this proposal. --Gunnar [1] http://gafter.blogspot.de/2006/12/super-type-tokens.html [2] https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html [3] https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html [4] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html [5] https://google.github.io/guava/releases/20.0/api/docs/index.html?com/google/common/reflect/TypeToken.html [6] http://gafter.blogspot.de/2007/05/limitation-of-super-type-tokens.html From stevenschlansker at gmail.com Fri Dec 16 17:33:15 2016 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Fri, 16 Dec 2016 09:33:15 -0800 Subject: Proposal: Add a type token class for representing generic types In-Reply-To: References: Message-ID: > On Dec 16, 2016, at 8:18 AM, Gunnar Morling wrote: > > Hi, > > I'd like to suggest the addition of a type token class to the Java > class library, to be used for representing generic types such as > List. I don't have much clout on this list to throw around, but a huge +1 from me! I maintain a library that tries to be zero-dependency and we found that we also had to introduce a type token. If you try to avoid reusing existing names (as you mention, there are like 5 different implementations in very common libraries) it is hard to even come up with a unique class name at this point. And it just feels wrong to have so many unique implementations of a simple concept... Having this in the core libraries would be great for us. > > Actual class literals can only represent raw types. But often > libraries have the need to apply some sort of configuration to > specific generic types, link specific behaviour to them or expose > (meta) data related to them. The suggested type token class would > allow to implement such cases in a type-safe fashion. > > # Example use cases > > * The "type-safe heterogenous container" pattern from Joshua Bloch's > book "Effective Java" introduces a container which allows to safely > store and retrieve objects of different types. They are keyed by > Class, which means that one cannot have a value for a List > and another value for a List in such container. Also one > cannot obtain a List without casting from such container. Type > literals would allow this: > > void put(TypeLiteral type, T value); > T get(TypeLiteral type); > > TypeLiteral> stringListType = ...; > List stringList = container.get( stringListType ); > > * JAX-RS allows to read response message entities into parameterized > types using its GenericType class: > > List customers = response.readEntity( new > GenericType>() {} ); > > * CDI allows to dynamically obtain beans of specific parameterized > types using its TypeLiteral class: > > @Inject @Any Instance anyPaymentProcessor; > > public PaymentProcessor getChequePaymentProcessor() { > PaymentProcessor pp = anyPaymentProcessor > .select( new TypeLiteral>() {} ).get(); > } > > # Proposed solution > > Type literals would be represented by a new type > java.lang.reflect.TypeLiteral. Instances would be created via > sub-classing, capturing the parameter and baking it into the > sub-class: > > TypeLiteral> stringListType = new > TypeLiteral>(){}; > > That'd allow to provide type-safe APIs around generic types as shown > in the examples above. The following methods should be defined on > TypeLiteral in order to make it useful for implementers of such APIs: > > Type getType(); > Class getRawType(); > boolean equals(Object obj); > int hashCode(); > String toString(); > > # Prior art > > The idea of type tokens based on capturing a generic type in a > sub-class has been around for a long time. The first reference I've > found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1]. > Examples in real-world APIs and libraries are TypeLiteral in CDI > [2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4] > and TypeToken in Guava [5]. > > # Alternatives and shortcomings > > The obvious alternative would be reified generics, but I think it's > commonly agreed upon that these will not come to the Java language any > time soon. Without native support in the language itself the proposed > type literal class is the best way to support the mentioned use cases > as far as I can say. > > Shortcomings are the creation of a sub-class per literal instantiation > (probably more an aesthetic problem, though) and failure of the > pattern when type variables are included anywhere in the represented > type [6]. Unfortunately, this can only be detected at runtime when > instantiating a literal but not by the compiler (although, I reckon it > technically could, by handling this case specifically). > > # Conclusion > > Lacking reified generics, the Java platform would benefit from the > addition of new type token class java.lang.reflect.TypeLiteral. The > pattern's presence in common APIs and libraries shows that there is a > wide-spread need for such mechanism and the community would benefit > very much from a standardized solution in the JDK itself. This will > allow for more unified API designs as well as foster integration of > different libraries. > > I'm eager to learn about your feedback and the OpenJDK team's > assessment of this proposal. > > --Gunnar > > [1] http://gafter.blogspot.de/2006/12/super-type-tokens.html > [2] https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html > [3] https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html > [4] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html > [5] https://google.github.io/guava/releases/20.0/api/docs/index.html?com/google/common/reflect/TypeToken.html > [6] http://gafter.blogspot.de/2007/05/limitation-of-super-type-tokens.html From chris.hegarty at oracle.com Fri Dec 16 17:39:19 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Fri, 16 Dec 2016 17:39:19 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <66199530-cc41-b3a6-4276-89f2bc9773a8@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> <66199530-cc41-b3a6-4276-89f2bc9773a8@oracle.com> Message-ID: <9715ABEC-6964-4C44-8C9D-A16534A88C13@oracle.com> Pushed to jdk9/dev. Should make b150. https://bugs.openjdk.java.net/browse/JDK-8171377 -Chris. > On 14 Dec 2016, at 11:58, Chris Hegarty wrote: > > Webrev updated in-place. > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > -Chris. > > On 13/12/16 21:18, Peter Levart wrote: >> I think this is OK. >> >> Just a couple of nits in test: >> >> 1. You create a static Path bob = Paths.get("bob") field, but then you >> don't use it in: >> >> 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), >> CREATE, WRITE)) { >> >> 2. badBuffers could include a duplicate and a slice of a direct buffer >> allocated with ByteBuffer.allocateDirect() >> >> 3. The comment in the test is referencing the old method name: >> >> 26 * @summary Basic test for Unsafe::deallocate >> >> >> Regards, Peter >> >> On 12/13/2016 08:47 PM, Chris Hegarty wrote: >>> Taking into account the feedback so far, and changing the method name ( since >>> it is an attractive nuisance ), here is where I think we ended up. >>> >>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ >>> >>> If this is agreeable, I?ll file an issue in JIRA to track the code changes, and >>> update JEP 260. >>> >>> -Chris. >> From stevenschlansker at gmail.com Fri Dec 16 17:54:32 2016 From: stevenschlansker at gmail.com (Steven Schlansker) Date: Fri, 16 Dec 2016 09:54:32 -0800 Subject: Duration isPositive missing? Message-ID: <2D690A12-20A4-4CE0-882F-ECA3253E405B@gmail.com> Hi core-libs-dev, My coworker and I were just puzzling over the seemingly trivially missing java.time.Duration#isPositive There are already "isNegative" and "isZero" -- but for isPositive the best we came up with were awful things like !isZero() && !isNegative() !.negate().isNegative() .compareTo(Duration.ZERO) > 0 but all of these feel way worse than a simple isPositive method. Can you shed some light as to why this is missing? Thanks! Steven From Roger.Riggs at Oracle.com Fri Dec 16 18:26:34 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 16 Dec 2016 13:26:34 -0500 Subject: Duration isPositive missing? In-Reply-To: <2D690A12-20A4-4CE0-882F-ECA3253E405B@gmail.com> References: <2D690A12-20A4-4CE0-882F-ECA3253E405B@gmail.com> Message-ID: <0ffc2177-3be8-4fef-c8ce-b4dd6c85f9d9@Oracle.com> Hi Steven, Yes, it does seem like an oversight. There are some other alternatives that might be considered. .toMillis() > 0 // Might throw an exception for very large or small durations. I create an issue: 8171382 java.time.Duration missing isPositive method To look at it for the next release. Roger On 12/16/2016 12:54 PM, Steven Schlansker wrote: > Hi core-libs-dev, > > My coworker and I were just puzzling over the seemingly trivially missing > java.time.Duration#isPositive > > There are already "isNegative" and "isZero" -- but for isPositive the best > we came up with were awful things like > > !isZero() && !isNegative() > !.negate().isNegative() > .compareTo(Duration.ZERO) > 0 > > but all of these feel way worse than a simple isPositive method. > Can you shed some light as to why this is missing? > > Thanks! > Steven > From brian.burkhalter at oracle.com Fri Dec 16 18:43:02 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 16 Dec 2016 10:43:02 -0800 Subject: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java In-Reply-To: <213d5b02-a4d9-2171-73ef-44b5cdc46b17@oracle.com> References: <213d5b02-a4d9-2171-73ef-44b5cdc46b17@oracle.com> Message-ID: Hi Joe, This looks fine to me. I?ve just a few picayune items: 1. FdLibm Line 649: I assume the weird ?halF? (upper case F) is retained in order to match the original C code. 2. TEST.ROOT Line 30: The jtreg required version is reverted. 3. ExpTests Lines 65 and 69: The threshold values in comments could be static final constants as well as they are used at lines 66, 70, 109 and 112. Thanks, Brian On Dec 15, 2016, at 12:25 PM, joe darcy wrote: > Next up in porting fdlibm to Java after cbrt (JDK-8136799), pow (JDK-8134795) and hypot (JDK-7130085) earlier in JDK 9 is exp: > > JDK-8139688 Port fdlibm exp to Java > http://cr.openjdk.java.net/~darcy/8139688.5/ > > Same methodology followed as when porting the earlier functions. From martinrb at google.com Fri Dec 16 19:58:21 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 16 Dec 2016 11:58:21 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: <0f1e0057-996f-a782-3197-10476ee5ed0a@cs.oswego.edu> References: <0f1e0057-996f-a782-3197-10476ee5ed0a@cs.oswego.edu> Message-ID: Thanks, Stefan! The creation of these bridge classes seem like a misfeature/bug of javac. We should avoid them where possible. Every unnecessary class file makes every single java program a little slower to start up. We can discover such "bridge classes" heuristically by looking for "small" synthetic class files: find build/classes/java.base/ -name '*$[0-9].class' -size -800c I think adding the package-private constructor is slightly better software engineering than making the classes themselves package-private: Index: PriorityQueue.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/PriorityQueue.java,v retrieving revision 1.115 diff -u -r1.115 PriorityQueue.java --- PriorityQueue.java 2 Dec 2016 07:11:36 -0000 1.115 +++ PriorityQueue.java 16 Dec 2016 19:54:22 -0000 @@ -522,6 +522,8 @@ */ private int expectedModCount = modCount; + Itr() {} + public boolean hasNext() { return cursor < size || (forgetMeNot != null && !forgetMeNot.isEmpty()); Index: concurrent/ConcurrentLinkedDeque.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentLinkedDeque.java,v retrieving revision 1.79 diff -u -r1.79 ConcurrentLinkedDeque.java --- concurrent/ConcurrentLinkedDeque.java 8 Dec 2016 05:03:37 -0000 1.79 +++ concurrent/ConcurrentLinkedDeque.java 16 Dec 2016 19:54:23 -0000 @@ -1367,12 +1367,14 @@ /** Forward iterator */ private class Itr extends AbstractItr { + Itr() {} Node startNode() { return first(); } Node nextNode(Node p) { return succ(p); } } /** Descending iterator */ private class DescendingItr extends AbstractItr { + DescendingItr() {} Node startNode() { return last(); } Node nextNode(Node p) { return pred(p); } } Index: concurrent/CyclicBarrier.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CyclicBarrier.java,v retrieving revision 1.57 diff -u -r1.57 CyclicBarrier.java --- concurrent/CyclicBarrier.java 8 Oct 2016 20:37:20 -0000 1.57 +++ concurrent/CyclicBarrier.java 16 Dec 2016 19:54:23 -0000 @@ -120,6 +120,7 @@ * but no subsequent reset. */ private static class Generation { + Generation() {} boolean broken; // initially false } Index: concurrent/LinkedBlockingDeque.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/LinkedBlockingDeque.java,v retrieving revision 1.67 diff -u -r1.67 LinkedBlockingDeque.java --- concurrent/LinkedBlockingDeque.java 13 Dec 2016 18:55:57 -0000 1.67 +++ concurrent/LinkedBlockingDeque.java 16 Dec 2016 19:54:23 -0000 @@ -1145,12 +1145,14 @@ /** Forward iterator */ private class Itr extends AbstractItr { + Itr() {} Node firstNode() { return first; } Node nextNode(Node n) { return n.next; } } /** Descending iterator */ private class DescendingItr extends AbstractItr { + DescendingItr() {} Node firstNode() { return last; } Node nextNode(Node n) { return n.prev; } } Index: concurrent/SubmissionPublisher.java =================================================================== RCS file: /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/SubmissionPublisher.java,v retrieving revision 1.67 diff -u -r1.67 SubmissionPublisher.java --- concurrent/SubmissionPublisher.java 16 Dec 2016 13:11:50 -0000 1.67 +++ concurrent/SubmissionPublisher.java 16 Dec 2016 19:54:23 -0000 @@ -165,7 +165,8 @@ ForkJoinPool.commonPool() : new ThreadPerTaskExecutor(); /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */ - static final class ThreadPerTaskExecutor implements Executor { + private static final class ThreadPerTaskExecutor implements Executor { + ThreadPerTaskExecutor() {} public void execute(Runnable r) { new Thread(r).start(); } } On Fri, Dec 16, 2016 at 5:14 AM, Doug Lea
      wrote: > On 12/15/2016 01:17 PM, Stefan Zobel wrote: > > I recently noticed that javac creates a synthetic class and a bridge >> constructor >> for SubmissionPublisher.ThreadPerTaskExecutor because its generated >> constructor >> is private. I don't know if it really matters but that could be avoided by >> declaring a package-private constructor that does nothing. >> > > Or, more simply remove the unnecessary "private" qualifier for the > nested ThreadPerTaskExecutor class, as we did in the similar usage in > CompletableFuture, and should have remembered to do here. > Done; thanks. > > -Doug > > > > > >> /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */ >>> private static final class ThreadPerTaskExecutor implements Executor { >>> // avoid creation of synthetic class and bridge constructor >>> ThreadPerTaskExecutor() {} >>> public void execute(Runnable r) { new Thread(r).start(); } >>> } >>> >> >> >> Regards, >> Stefan >> >> > From spliterator at gmail.com Fri Dec 16 20:21:44 2016 From: spliterator at gmail.com (Stefan Zobel) Date: Fri, 16 Dec 2016 21:21:44 +0100 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: <0f1e0057-996f-a782-3197-10476ee5ed0a@cs.oswego.edu> Message-ID: 2016-12-16 20:58 GMT+01:00 Martin Buchholz : > Thanks, Stefan! > > The creation of these bridge classes seem like a misfeature/bug of javac. > We should avoid them where possible. Every unnecessary class file makes > every single java program a little slower to start up. We can discover such > "bridge classes" heuristically by looking for "small" synthetic class files: > > find build/classes/java.base/ -name '*$[0-9].class' -size -800c > > I think adding the package-private constructor is slightly better software > engineering than making the classes themselves package-private: > Hi Martin, yes, I agree. It may be better to add a comment like in ArrayList.Itr: // prevent creating a synthetic constructor Otherwise someone might be tempted to drop these empty constructors. See also http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-September/043803.html Regards, Stefan From martinrb at google.com Fri Dec 16 20:52:15 2016 From: martinrb at google.com (Martin Buchholz) Date: Fri, 16 Dec 2016 12:52:15 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: <0f1e0057-996f-a782-3197-10476ee5ed0a@cs.oswego.edu> Message-ID: ThreadPerTaskExecutor() {} // prevents bridge class creation On Fri, Dec 16, 2016 at 12:21 PM, Stefan Zobel wrote: > > yes, I agree. It may be better to add a comment like in ArrayList.Itr: > > // prevent creating a synthetic constructor > > Otherwise someone might be tempted to drop these empty constructors. > > See also > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016- > September/043803.html Yeah, no one Just Fixed The Problem Once And For All ! From paul.sandoz at oracle.com Fri Dec 16 20:59:18 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Fri, 16 Dec 2016 12:59:18 -0800 Subject: RFR: jsr166 jdk9 integration wave 13 In-Reply-To: References: <0f1e0057-996f-a782-3197-10476ee5ed0a@cs.oswego.edu> Message-ID: <8559A743-5C03-4AF2-943D-C155D3C3F5AC@oracle.com> > On 16 Dec 2016, at 11:58, Martin Buchholz wrote: > > Thanks, Stefan! > > The creation of these bridge classes seem like a misfeature/bug of javac. It?s to work around the current access control rules enforced by the VM. The Java source world and the bytecode/VM world have different opinions. IIUC we need a clearer notion of "nest mate" classes (something that Valhalla is looking into). Paul. > We should avoid them where possible. Every unnecessary class file makes > every single java program a little slower to start up. We can discover > such "bridge classes" heuristically by looking for "small" synthetic class > files: > > find build/classes/java.base/ -name '*$[0-9].class' -size -800c > > I think adding the package-private constructor is slightly better software > engineering than making the classes themselves package-private: > > Index: PriorityQueue.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/main/java/util/PriorityQueue.java,v > retrieving revision 1.115 > diff -u -r1.115 PriorityQueue.java > --- PriorityQueue.java 2 Dec 2016 07:11:36 -0000 1.115 > +++ PriorityQueue.java 16 Dec 2016 19:54:22 -0000 > @@ -522,6 +522,8 @@ > */ > private int expectedModCount = modCount; > > + Itr() {} > + > public boolean hasNext() { > return cursor < size || > (forgetMeNot != null && !forgetMeNot.isEmpty()); > Index: concurrent/ConcurrentLinkedDeque.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/ConcurrentLinkedDeque.java,v > retrieving revision 1.79 > diff -u -r1.79 ConcurrentLinkedDeque.java > --- concurrent/ConcurrentLinkedDeque.java 8 Dec 2016 05:03:37 -0000 1.79 > +++ concurrent/ConcurrentLinkedDeque.java 16 Dec 2016 19:54:23 -0000 > @@ -1367,12 +1367,14 @@ > > /** Forward iterator */ > private class Itr extends AbstractItr { > + Itr() {} > Node startNode() { return first(); } > Node nextNode(Node p) { return succ(p); } > } > > /** Descending iterator */ > private class DescendingItr extends AbstractItr { > + DescendingItr() {} > Node startNode() { return last(); } > Node nextNode(Node p) { return pred(p); } > } > Index: concurrent/CyclicBarrier.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/CyclicBarrier.java,v > retrieving revision 1.57 > diff -u -r1.57 CyclicBarrier.java > --- concurrent/CyclicBarrier.java 8 Oct 2016 20:37:20 -0000 1.57 > +++ concurrent/CyclicBarrier.java 16 Dec 2016 19:54:23 -0000 > @@ -120,6 +120,7 @@ > * but no subsequent reset. > */ > private static class Generation { > + Generation() {} > boolean broken; // initially false > } > > Index: concurrent/LinkedBlockingDeque.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/LinkedBlockingDeque.java,v > retrieving revision 1.67 > diff -u -r1.67 LinkedBlockingDeque.java > --- concurrent/LinkedBlockingDeque.java 13 Dec 2016 18:55:57 -0000 1.67 > +++ concurrent/LinkedBlockingDeque.java 16 Dec 2016 19:54:23 -0000 > @@ -1145,12 +1145,14 @@ > > /** Forward iterator */ > private class Itr extends AbstractItr { > + Itr() {} > Node firstNode() { return first; } > Node nextNode(Node n) { return n.next; } > } > > /** Descending iterator */ > private class DescendingItr extends AbstractItr { > + DescendingItr() {} > Node firstNode() { return last; } > Node nextNode(Node n) { return n.prev; } > } > Index: concurrent/SubmissionPublisher.java > =================================================================== > RCS file: > /export/home/jsr166/jsr166/jsr166/src/main/java/util/concurrent/SubmissionPublisher.java,v > retrieving revision 1.67 > diff -u -r1.67 SubmissionPublisher.java > --- concurrent/SubmissionPublisher.java 16 Dec 2016 13:11:50 -0000 1.67 > +++ concurrent/SubmissionPublisher.java 16 Dec 2016 19:54:23 -0000 > @@ -165,7 +165,8 @@ > ForkJoinPool.commonPool() : new ThreadPerTaskExecutor(); > > /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */ > - static final class ThreadPerTaskExecutor implements Executor { > + private static final class ThreadPerTaskExecutor implements Executor { > + ThreadPerTaskExecutor() {} > public void execute(Runnable r) { new Thread(r).start(); } > } > > > > On Fri, Dec 16, 2016 at 5:14 AM, Doug Lea
      wrote: > >> On 12/15/2016 01:17 PM, Stefan Zobel wrote: >> >> I recently noticed that javac creates a synthetic class and a bridge >>> constructor >>> for SubmissionPublisher.ThreadPerTaskExecutor because its generated >>> constructor >>> is private. I don't know if it really matters but that could be avoided by >>> declaring a package-private constructor that does nothing. >>> >> >> Or, more simply remove the unnecessary "private" qualifier for the >> nested ThreadPerTaskExecutor class, as we did in the similar usage in >> CompletableFuture, and should have remembered to do here. >> Done; thanks. >> >> -Doug >> >> >> >> >> >>> /** Fallback if ForkJoinPool.commonPool() cannot support parallelism */ >>>> private static final class ThreadPerTaskExecutor implements Executor { >>>> // avoid creation of synthetic class and bridge constructor >>>> ThreadPerTaskExecutor() {} >>>> public void execute(Runnable r) { new Thread(r).start(); } >>>> } >>>> >>> >>> >>> Regards, >>> Stefan >>> >>> >> From brian.burkhalter at oracle.com Fri Dec 16 21:31:57 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 16 Dec 2016 13:31:57 -0800 Subject: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths Message-ID: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8148023 Patch: http://cr.openjdk.java.net/~bpb/8148023/webrev.00/index.html The method was not adhering to the specification [1] and was creating long file names which caused failures on all platforms. The pertinent portion of the specification is: "To create the new file, the prefix and the suffix may first be adjusted to fit the limitations of the underlying platform. If the prefix is too long then it will be truncated, but its first three characters will always be preserved. If the suffix is too long then it too will be truncated, but if it begins with a period character ('.') then the period and the first three characters following it will always be preserved. Once these adjustments have been made the name of the new file will be generated by concatenating the prefix, five or more internally-generated characters, and the suffix." The code was updated to truncate the filename (leaf) portion of the path name to meet the platform file name component length constraints. The IO regression tests passed with this change on all platforms. Thanks, Brian [1] http://download.java.net/java/jdk9/docs/api/java/io/File.html#createTempFile-java.lang.String-java.lang.String-java.io.File- From uschindler at apache.org Fri Dec 16 21:44:05 2016 From: uschindler at apache.org (Uwe Schindler) Date: Fri, 16 Dec 2016 22:44:05 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <9715ABEC-6964-4C44-8C9D-A16534A88C13@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> <66199530-cc41-b3a6-4276-89f2bc9773a8@oracle.com> <9715ABEC-6964-4C44-8C9D-A16534A88C13@oracle.com> Message-ID: <000001d257e5$8e3ceb10$aab6c130$@apache.org> Hi Chris, thanks, works perfectly. I compiled a JDK with this commit and Lucene's unmapping works. Thanks. https://github.com/apache/lucene-solr/compare/LUCENE-6989-v2 Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Friday, December 16, 2016 6:39 PM > To: Peter Levart ; Core-Libs-Dev dev at openjdk.java.net>; jigsaw-dev ; Uwe > Schindler > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Pushed to jdk9/dev. Should make b150. > > https://bugs.openjdk.java.net/browse/JDK-8171377 > > -Chris. > > > On 14 Dec 2016, at 11:58, Chris Hegarty > wrote: > > > > Webrev updated in-place. > > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > > > -Chris. > > > > On 13/12/16 21:18, Peter Levart wrote: > >> I think this is OK. > >> > >> Just a couple of nits in test: > >> > >> 1. You create a static Path bob = Paths.get("bob") field, but then you > >> don't use it in: > >> > >> 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), > >> CREATE, WRITE)) { > >> > >> 2. badBuffers could include a duplicate and a slice of a direct buffer > >> allocated with ByteBuffer.allocateDirect() > >> > >> 3. The comment in the test is referencing the old method name: > >> > >> 26 * @summary Basic test for Unsafe::deallocate > >> > >> > >> Regards, Peter > >> > >> On 12/13/2016 08:47 PM, Chris Hegarty wrote: > >>> Taking into account the feedback so far, and changing the method name > ( since > >>> it is an attractive nuisance ), here is where I think we ended up. > >>> > >>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > >>> > >>> If this is agreeable, I?ll file an issue in JIRA to track the code changes, and > >>> update JEP 260. > >>> > >>> -Chris. > >> From david.holmes at oracle.com Fri Dec 16 22:09:24 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 17 Dec 2016 08:09:24 +1000 Subject: Proposal: Add a type token class for representing generic types In-Reply-To: References: Message-ID: <6acde717-ac6a-7165-9b24-2baf05a184c9@oracle.com> Hi Gunnar, On 17/12/2016 2:18 AM, Gunnar Morling wrote: > Hi, > > I'd like to suggest the addition of a type token class to the Java > class library, to be used for representing generic types such as > List. Sounds like something that falls within scope for the generic specialization work in Project Valhalla: http://openjdk.java.net/projects/valhalla/ David ----- > Actual class literals can only represent raw types. But often > libraries have the need to apply some sort of configuration to > specific generic types, link specific behaviour to them or expose > (meta) data related to them. The suggested type token class would > allow to implement such cases in a type-safe fashion. > > # Example use cases > > * The "type-safe heterogenous container" pattern from Joshua Bloch's > book "Effective Java" introduces a container which allows to safely > store and retrieve objects of different types. They are keyed by > Class, which means that one cannot have a value for a List > and another value for a List in such container. Also one > cannot obtain a List without casting from such container. Type > literals would allow this: > > void put(TypeLiteral type, T value); > T get(TypeLiteral type); > > TypeLiteral> stringListType = ...; > List stringList = container.get( stringListType ); > > * JAX-RS allows to read response message entities into parameterized > types using its GenericType class: > > List customers = response.readEntity( new > GenericType>() {} ); > > * CDI allows to dynamically obtain beans of specific parameterized > types using its TypeLiteral class: > > @Inject @Any Instance anyPaymentProcessor; > > public PaymentProcessor getChequePaymentProcessor() { > PaymentProcessor pp = anyPaymentProcessor > .select( new TypeLiteral>() {} ).get(); > } > > # Proposed solution > > Type literals would be represented by a new type > java.lang.reflect.TypeLiteral. Instances would be created via > sub-classing, capturing the parameter and baking it into the > sub-class: > > TypeLiteral> stringListType = new > TypeLiteral>(){}; > > That'd allow to provide type-safe APIs around generic types as shown > in the examples above. The following methods should be defined on > TypeLiteral in order to make it useful for implementers of such APIs: > > Type getType(); > Class getRawType(); > boolean equals(Object obj); > int hashCode(); > String toString(); > > # Prior art > > The idea of type tokens based on capturing a generic type in a > sub-class has been around for a long time. The first reference I've > found is Neal Gafter's blog post on "Super Type Tokens" from 2006 [1]. > Examples in real-world APIs and libraries are TypeLiteral in CDI > [2], GenericType in JAX-RS [3], TypeLiteral in commons-lang [4] > and TypeToken in Guava [5]. > > # Alternatives and shortcomings > > The obvious alternative would be reified generics, but I think it's > commonly agreed upon that these will not come to the Java language any > time soon. Without native support in the language itself the proposed > type literal class is the best way to support the mentioned use cases > as far as I can say. > > Shortcomings are the creation of a sub-class per literal instantiation > (probably more an aesthetic problem, though) and failure of the > pattern when type variables are included anywhere in the represented > type [6]. Unfortunately, this can only be detected at runtime when > instantiating a literal but not by the compiler (although, I reckon it > technically could, by handling this case specifically). > > # Conclusion > > Lacking reified generics, the Java platform would benefit from the > addition of new type token class java.lang.reflect.TypeLiteral. The > pattern's presence in common APIs and libraries shows that there is a > wide-spread need for such mechanism and the community would benefit > very much from a standardized solution in the JDK itself. This will > allow for more unified API designs as well as foster integration of > different libraries. > > I'm eager to learn about your feedback and the OpenJDK team's > assessment of this proposal. > > --Gunnar > > [1] http://gafter.blogspot.de/2006/12/super-type-tokens.html > [2] https://docs.oracle.com/javaee/7/api/index.html?javax/enterprise/util/TypeLiteral.html > [3] https://docs.oracle.com/javaee/7/api/index.html?javax/ws/rs/core/GenericType.html > [4] https://commons.apache.org/proper/commons-lang/apidocs/org/apache/commons/lang3/reflect/TypeLiteral.html > [5] https://google.github.io/guava/releases/20.0/api/docs/index.html?com/google/common/reflect/TypeToken.html > [6] http://gafter.blogspot.de/2007/05/limitation-of-super-type-tokens.html > From joe.darcy at oracle.com Sat Dec 17 05:44:23 2016 From: joe.darcy at oracle.com (joe darcy) Date: Fri, 16 Dec 2016 21:44:23 -0800 Subject: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java In-Reply-To: References: <213d5b02-a4d9-2171-73ef-44b5cdc46b17@oracle.com> Message-ID: <50b703f7-0f82-c36d-ae23-65e657d679ee@oracle.com> Hi Brian, On 12/16/2016 10:43 AM, Brian Burkhalter wrote: > Hi Joe, > > This looks fine to me. I?ve just a few picayune items: > > 1. FdLibm > > Line 649: I assume the weird ?halF? (upper case F) is retained in > order to match the original C code. Corrected. > > 2. TEST.ROOT > > Line 30: The jtreg required version is reverted. Oops; I'll fix that before pushing. > > 3. ExpTests > > Lines 65 and 69: The threshold values in comments could be static > final constants as well as they are used at lines > 66, 70, 109 and 112. Yeah, I went back and forth on that point a bit while write the test. I changed the later usages to double[] decisionPoints = { // Near overflow threshold EXP_OVERFLOW_THRESH - 512*Math.ulp(EXP_OVERFLOW_THRESH), // Near underflow threshold EXP_UNDERFLOW_THRESH - 512*Math.ulp(EXP_UNDERFLOW_THRESH), Thanks, -Joe From huaming.li at oracle.com Mon Dec 19 02:02:30 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 19 Dec 2016 10:02:30 +0800 Subject: RFR of JDK-8171133: java/rmi/registry/reexport/Reexport.java, there is a missing case check in createReg(..) In-Reply-To: <645d57e8-7820-de52-dd6f-a7cd2f96982f@Oracle.com> References: <645d57e8-7820-de52-dd6f-a7cd2f96982f@Oracle.com> Message-ID: <285479f4-3048-34bb-2807-92f070478f71@oracle.com> Hi Roger, Thank you for reviewing, removed the redundant checking and pushed the code. -Hamlin On 2016/12/16 22:13, Roger Riggs wrote: > Hi Hamlin, > > Yes, the logic would be clearer; and I would also remove the (now) > redundant checking. > > Roger > > > On 12/15/2016 9:42 PM, Hamlin Li wrote: >> Hi Roger, Daniel, >> >> Thank you for reviewing. >> >> On 2016/12/15 22:45, Roger Riggs wrote: >>> Hi Hamlin, >>> >>> If this is supposed to fix the call from line 68: then doesn't the >>> test for reg != null >>> at line 70 already have the same effect? >> Please consider the situation: LocateRegistry.createRegistry(port) in >> createReg(true, port) does not throw exception but just return null >> when remoteOk is true. this case is missed by current test. Although >> we know that should not happen by checking the product code, but the >> test should not assume how it is implemented. >> And I think the patch will make logic more clear, maybe we could >> remove the check of reg != null at the same time after modify the >> code in createReg(...). >> >> Thank you >> -Hamlin >>> >>> Roger >>> >>> >>> On 12/14/2016 10:19 PM, Hamlin Li wrote: >>>> Would you please review the below patch? >>>> >>>> bug: https://bugs.openjdk.java.net/browse/JDK-8171133 >>>> webrev: http://cr.openjdk.java.net/~mli/8171133/webrev.00/ >>>> >>>> java/rmi/registry/reexport/Reexport.java, there is a missing case >>>> check in createReg(..): if LocateRegistry.createRegistry(port) >>>> return null when port is in use. >>>> >>>> Thank you >>>> -Hamlin >>>> ------------------------------------------------------------------------ >>>> >>>> diff -r ddd192238fcb test/java/rmi/registry/reexport/Reexport.java >>>> --- a/test/java/rmi/registry/reexport/Reexport.java Tue Dec 13 >>>> 18:47:23 2016 -0800 >>>> +++ b/test/java/rmi/registry/reexport/Reexport.java Wed Dec 14 >>>> 19:06:40 2016 -0800 >>>> @@ -105,6 +105,9 @@ >>>> >>>> try { >>>> reg = LocateRegistry.createRegistry(port); >>>> + if (remoteOk) { >>>> + TestLibrary.bomb("Remote registry is up, an >>>> Exception is expected!"); >>>> + } >>>> } catch (Throwable e) { >>>> if (remoteOk) { >>>> System.err.println("EXPECTING PORT IN USE >>>> EXCEPTION:"); >>>> >>> >> > From frank.yuan at oracle.com Mon Dec 19 03:17:26 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Mon, 19 Dec 2016 11:17:26 +0800 Subject: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName; " even if "entities" property is false In-Reply-To: <58531F49.6030205@oracle.com> References: <059b01d256c1$4c8817f0$e59847d0$@oracle.com> <58531F49.6030205@oracle.com> Message-ID: <01bc01d259a6$6df06540$49d12fc0$@oracle.com> Thank you all! I have pushed the change with the license header update. Frank -----Original Message----- From: Joe Wang [mailto:huizhe.wang at oracle.com] Subject: Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always serializes an entity reference node to" &entityName;" even if "entities" property is false Hi Frank, Thanks for the update. It looks good. The license header for output_html.properties can be updated as the follows: ########################################################################### # Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved. ########################################################################### ## # Licensed to the Apache Software Foundation (ASF) under one # or more contributor license agreements. See the NOTICE file # distributed with this work for additional information # regarding copyright ownership. The ASF licenses this file # to you under the Apache License, Version 2.0 (the "License"); # you may not use this file except in compliance with the License. # You may obtain a copy of the License at # # http://www.apache.org/licenses/LICENSE-2.0 # # Unless required by applicable law or agreed to in writing, software # distributed under the License is distributed on an "AS IS" BASIS, # WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. # See the License for the specific language governing permissions and # limitations under the License. ## # # Specify defaults when method="html". These defaults use output_xml.properties # as a base. # Best, Joe On 12/15/16, 2:52 AM, Frank Yuan wrote: > Hi Christoph > > Thank you for the review! > > Please check http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.01/. > > I have updated the code as your comments except output_html.properties, I am not sure for the license of this file. > > To Joe > Could you confirm Christoph's comment for output_html.properties? > > > Thanks > Frank > >> -----Original Message----- >> From: Langer, Christoph [mailto:christoph.langer at sap.com] >> Subject: RE: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work anymore and JDK-8114834 LSSerializerImpl always > serializes an >> entity reference node to"&entityName;" even if "entities" property is false >> >> Hi Frank, >> >> this is awesome. >> >> Some minor things I saw while looking through the webrev: >> >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/runtime/AbstractTranslet.java >> Update copryright year >> Remove: >> 20 /* >> 21 * $Id: AbstractTranslet.java,v 1.6 2006/06/19 19:49:03 spericas Exp $ >> 22 */ >> >> src/java.xml/share/classes/com/sun/org/apache/xalan/internal/xsltc/trax/TransformerImpl.java >> Remove: >> 20 /* >> 21 * $Id: TransformerImpl.java,v 1.10 2007/06/13 01:57:09 joehw Exp $ >> 22 */ >> >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/SerializerBase.java >> 462 protected boolean isInEntityRef() >> 463 { >> Put the brace on line 462 as well >> >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToHTMLStream.java >> -> sort import statements >> Method >> 773 public void startElement( >> -> use SAXException without package name. It is imported on top. This can be done in various places throughout the file. >> 780 //will add extra one if having namespace but no matter >> -> space between // and will... >> 821 if ((null != elemContext.m_elementName) >> -> For me it reads better if it were if ((elemContext.m_elementName != null) >> >> 1971 private void initToHTMLStream() >> 1972 { >> 1973 // m_elementDesc = null; >> 1974 m_isprevblock = false; >> 1975 m_inDTD = false; >> 1976 // m_isRawStack.clear(); >> 1977 m_omitMetaTag = false; >> 1978 m_specialEscapeURLs = true; >> 1979 } >> -> I guess you could remove the commented statements >> >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/ToStream.java >> 116 protected boolean m_ispreserveSpace = false; >> 117 >> 118 >> -> remove one empty line (117) >> >> 1894 m_ispreserve = false; >> 1895 >> 1896 >> 1897 >> -> newly inserted lines 1896 and 1897 should be removed >> >> src/java.xml/share/classes/com/sun/org/apache/xml/internal/serializer/output_html.properties >> -> maybe the Oracle copyright header can be inserted and the "$Id: output_html.properties..." part can be removed? >> >> Best regards >> Christoph >> >>> -----Original Message----- >>> From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On Behalf >>> Of Joe Wang >>> Sent: Mittwoch, 14. Dezember 2016 04:09 >>> To: Frank Yuan >>> Cc: core-libs-dev at openjdk.java.net >>> Subject: Re: RFR (JAXP) JDK-8087303 LSSerializer pretty print does not work >>> anymore and JDK-8114834 LSSerializerImpl always serializes an entity >>> reference node to"&entityName;" even if "entities" property is false >>> >>> Hi Frank, >>> >>> Thanks for the diligent work! I think we've made a great improvement >>> over the PrettyPrint (tremendous ;-) ) >>> >>> Could you look into extracting the XML literal strings in the test into >>> plain files (similar to the other 'gold' files)? What I'm hoping to see >>> is that they'd look easily prettier in a text editor, and for that >>> matter, the original xml files were a mess. >>> >>> The tests set PrettyPrint, and by default for html. It would be good to >>> test the cases when it's turned off, that would help verify the >>> non-pretty format was not changed. >>> >>> Thanks, >>> Joe >>> >>> On 12/13/16, 6:55 AM, Frank Yuan wrote: >>>> Hi all >>>> >>>> Webrev http://cr.openjdk.java.net/~fyuan/8087303_8114834/webrev.00/ is >>> for JDK-8087303 and JDK-8114834, I have to combine the fix >>>> because there is some interaction between them. >>>> Bugs: https://bugs.openjdk.java.net/browse/JDK-8087303 >>> https://bugs.openjdk.java.net/browse/JDK-8114834 >>>> Besides fixed some issues in xml serializer, I made the following changes in >>> this patch: >>>> 1. refined the handling for whitespace text >>>> 2. added support for xml:space attribute >>>> 3. changed the default indentation to 4 >>>> 4. refined the handling for HTML block element and inline element >>>> >>>> Would you like to have a look at this review? >>>> >>>> Thanks, >>>> >>>> Frank >>>> >>>> From mandy.chung at oracle.com Mon Dec 19 05:42:22 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Sun, 18 Dec 2016 21:42:22 -0800 Subject: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option Message-ID: Webrev at: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.00 --include-system-modules option was a temporary option added in an early stage of developement. Time to remove it as a clean up. Mandy From huaming.li at oracle.com Mon Dec 19 07:22:14 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 19 Dec 2016 15:22:14 +0800 Subject: RFR of JDK-8025199: java/rmi/registry/reexport/Reexport.java failed with: Port already in use Message-ID: Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8025199 webrev: http://cr.openjdk.java.net/~mli/8025199/webrev.00 Root cause: running registry on TestLibrary.getUnusedRandomPort() will cause "port in use" exception, as there is a time window for a interloper to occupy the "free" port. Solution: in RegistryRunner print out the port running registry, add a class REGISTRY to control and monitor the registry sub-process, and get the running port. Thank you -Hamlin From peter.levart at gmail.com Mon Dec 19 09:41:32 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 19 Dec 2016 10:41:32 +0100 Subject: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more In-Reply-To: References: <9ddc7fc5-68fe-bb78-b54d-6ba55880c018@gmail.com> <34B4C0BE-A333-4865-9C24-C6A9DBBF3D35@oracle.com> <11cfb990-622d-10b1-5f85-7445f114073e@gmail.com> <60664B68-DAAE-4DB6-8B68-7884A2F0312D@oracle.com> <7E2092D9-ECB7-4003-B55D-0A1F017949CA@oracle.com> <9B1109B5-A8B8-456E-BB9A-BD0E22C80226@oracle.com> <24661900-d442-edd8-1c0b-435581f58a41@oracle.com> <9D77191E-0006-4A61-9D03-FD226C5290B7@oracle.com> <93a4cebd-79bb-aed4-d27a-4cad25b7ad97@oracle.com> <1ef1620a-f14c-ca3d-54e0-5f5f4b8a9551@oracle.com> Message-ID: <22b79993-4a51-b7f4-14a8-ad19e28873f4@gmail.com> Hi, This is the latest webrev of changes to Class.getMethod() and Class.getMethods(), rebased to current tip of jdk9-dev, incorporating comments from CCC review: http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.08/ Javadocs now include explicit text about Method(s) returned for interface and array types as well as description of general algorithm. Apart from javadocs, the following changed from webrev.07: - package-private Class.getMethdOrNull() (added by resent jigsaw changes) must copy the returned Method object itself since getMethod0() does not return a copy any more. - renamed PublicMethods[.MethodList].coalesce() -> merge(). I think this is a less confusing name. For those of you, watching the public list, changes from webrev.04 that was last presented there are as follows: - PublicMethods class changed to embed, rather than extend a HashMap. - Added a nearly-exhaustive test of Class.getMethods() and Class.getMethod(): PublicMethodsTest. This is actually a test generator. Given a Case template, it generates all variants of methods for each of the types in the case. Case1 contains 4 interface method variants ^ 3 interfaces * 4 class method variants ^ 3 classes = 4^6 = 4096 different sub-cases of which only 1379 compile. The results of those 1379 sub-cases are persisted in the Case1.results file. Running the test compares the persisted results with actual result of executing each sub-case. When running this test on plain JDK 9 (without patch), the test finds sub-cases where results differ: http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/PublicMethodsTest.jtr Regards, Peter On 12/18/2016 06:01 AM, joe darcy wrote: > > Hello Peter, > > Some comments on the spec changes proposed in this request. The new > algorithm looks, but I don't think it is appropriate to remove > explicit text like > >> If this |Class| object represents an array type, then the returned >> array has a |Method| object for each of the public methods inherited >> by the array type from |Object|. It does not contain a |Method| >> object for |clone()|. >> >> If this |Class| object represents an interface then the returned >> array does not contain any implicitly declared methods from |Object|. >> Therefore, if no methods are explicitly declared in this interface or >> any of its superinterfaces then the returned array has length 0. >> (Note that a |Class| object which represents a class always has >> public methods, inherited from |Object|.) >> > even if it is (non-obviously) implied by the rest of the text. > > I'm voting to approve the request on the condition that some explicit > discussion is added back to describe the handling of array types and > interface. > > Sorry for the delays, > > -Joe > > > On 12/12/2016 11:09 PM, joe darcy wrote: >> Hi Peter, >> >> Sorry for the delays on reviewing your request. I've been backed up >> on some ccc requests and I suspect the changes in your request are >> subtle enough to merit some time to examine. >> >> I'm trying to clear out my queue this week ahead of the next round of >> JDK 9 deadlines. >> >> Thanks, >> >> -Joe >> >> >> On 12/8/2016 12:42 AM, Alan Bateman wrote: >>> On 08/12/2016 08:34, Peter Levart wrote: >>> >>>> Hi Mandy, Alan, >>>> >>>> I know you're all very busy with finalization of jigsaw features >>>> before the freeze, but I would like to ask whether there has been >>>> any feedback on the CCC request for this issue. >>> Sorry for really really long delay on this. Joe Darcy is the chair >>> of the CCC and is in his queue to review/approve. He told me >>> yesterday that he wanted to get to it soon, I think he's just being >>> pulled into too many issues at the moment. Joe, do you have an ETA >>> for Peter? I think it's important that we get this into jdk9/dev by >>> Dec 16 in order to make the Dec 22 promotion. >>> >>> -Alan >> > From Roger.Riggs at Oracle.com Mon Dec 19 15:15:54 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 19 Dec 2016 10:15:54 -0500 Subject: RFR of JDK-8025199: java/rmi/registry/reexport/Reexport.java failed with: Port already in use In-Reply-To: References: Message-ID: <6267c23a-b8d4-52b2-652a-d4c2817dead5@Oracle.com> Look ok Thanks, Roger On 12/19/2016 2:22 AM, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8025199 > webrev: http://cr.openjdk.java.net/~mli/8025199/webrev.00 > > Root cause: running registry on TestLibrary.getUnusedRandomPort() will > cause "port in use" exception, as there is a time window for a > interloper to occupy the "free" port. > > Solution: in RegistryRunner print out the port running registry, add a > class REGISTRY to control and monitor the registry sub-process, and > get the running port. > > > Thank you > -Hamlin From aph at redhat.com Mon Dec 19 15:24:08 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 19 Dec 2016 15:24:08 +0000 Subject: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java In-Reply-To: <213d5b02-a4d9-2171-73ef-44b5cdc46b17@oracle.com> References: <213d5b02-a4d9-2171-73ef-44b5cdc46b17@oracle.com> Message-ID: <0ddf440e-8614-179b-916c-be93fe8d24de@redhat.com> On 15/12/16 20:25, joe darcy wrote: > Hello, > > Next up in porting fdlibm to Java after cbrt (JDK-8136799), pow > (JDK-8134795) and hypot (JDK-7130085) earlier in JDK 9 is exp: > > JDK-8139688 Port fdlibm exp to Java > http://cr.openjdk.java.net/~darcy/8139688.5/ > > Same methodology followed as when porting the earlier functions. As discussed, this test is pointless because it is always true: + if(huge+x>one) return one+x;/* trigger inexact */ I understand that we intend to leave the code untouched, but the inexact flag has no effect in Java code. Does it really make sense to translate the code to Java but include such cruft? Andrew. From joe.darcy at oracle.com Mon Dec 19 15:25:05 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 19 Dec 2016 07:25:05 -0800 Subject: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more In-Reply-To: <22b79993-4a51-b7f4-14a8-ad19e28873f4@gmail.com> References: <9ddc7fc5-68fe-bb78-b54d-6ba55880c018@gmail.com> <11cfb990-622d-10b1-5f85-7445f114073e@gmail.com> <60664B68-DAAE-4DB6-8B68-7884A2F0312D@oracle.com> <7E2092D9-ECB7-4003-B55D-0A1F017949CA@oracle.com> <9B1109B5-A8B8-456E-BB9A-BD0E22C80226@oracle.com> <24661900-d442-edd8-1c0b-435581f58a41@oracle.com> <9D77191E-0006-4A61-9D03-FD226C5290B7@oracle.com> <93a4cebd-79bb-aed4-d27a-4cad25b7ad97@oracle.com> <1ef1620a-f14c-ca3d-54e0-5f5f4b8a9551@oracle.com> <22b79993-4a51-b7f4-14a8-ad19e28873f4@gmail.com> Message-ID: Hi Peter, Revised specification looks good; thanks, -Joe On 12/19/2016 1:41 AM, Peter Levart wrote: > Hi, > > This is the latest webrev of changes to Class.getMethod() and > Class.getMethods(), rebased to current tip of jdk9-dev, incorporating > comments from CCC review: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.08/ > > Javadocs now include explicit text about Method(s) returned for > interface and array types as well as description of general algorithm. > Apart from javadocs, the following changed from webrev.07: > > - package-private Class.getMethdOrNull() (added by resent jigsaw > changes) must copy the returned Method object itself since > getMethod0() does not return a copy any more. > - renamed PublicMethods[.MethodList].coalesce() -> merge(). I think > this is a less confusing name. > > For those of you, watching the public list, changes from webrev.04 > that was last presented there are as follows: > > - PublicMethods class changed to embed, rather than extend a HashMap. > - Added a nearly-exhaustive test of Class.getMethods() and > Class.getMethod(): PublicMethodsTest. This is actually a test > generator. Given a Case template, it generates all variants of methods > for each of the types in the case. Case1 contains 4 interface method > variants ^ 3 interfaces * 4 class method variants ^ 3 classes = 4^6 = > 4096 different sub-cases of which only 1379 compile. The results of > those 1379 sub-cases are persisted in the Case1.results file. Running > the test compares the persisted results with actual result of > executing each sub-case. When running this test on plain JDK 9 > (without patch), the test finds sub-cases where results differ: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/PublicMethodsTest.jtr > > Regards, Peter > > > On 12/18/2016 06:01 AM, joe darcy wrote: >> >> Hello Peter, >> >> Some comments on the spec changes proposed in this request. The new >> algorithm looks, but I don't think it is appropriate to remove >> explicit text like >> >>> If this |Class| object represents an array type, then the returned >>> array has a |Method| object for each of the public methods inherited >>> by the array type from |Object|. It does not contain a |Method| >>> object for |clone()|. >>> >>> If this |Class| object represents an interface then the returned >>> array does not contain any implicitly declared methods from >>> |Object|. Therefore, if no methods are explicitly declared in this >>> interface or any of its superinterfaces then the returned array has >>> length 0. (Note that a |Class| object which represents a class >>> always has public methods, inherited from |Object|.) >>> >> even if it is (non-obviously) implied by the rest of the text. >> >> I'm voting to approve the request on the condition that some explicit >> discussion is added back to describe the handling of array types and >> interface. >> >> Sorry for the delays, >> >> -Joe >> >> >> On 12/12/2016 11:09 PM, joe darcy wrote: >>> Hi Peter, >>> >>> Sorry for the delays on reviewing your request. I've been backed up >>> on some ccc requests and I suspect the changes in your request are >>> subtle enough to merit some time to examine. >>> >>> I'm trying to clear out my queue this week ahead of the next round >>> of JDK 9 deadlines. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 12/8/2016 12:42 AM, Alan Bateman wrote: >>>> On 08/12/2016 08:34, Peter Levart wrote: >>>> >>>>> Hi Mandy, Alan, >>>>> >>>>> I know you're all very busy with finalization of jigsaw features >>>>> before the freeze, but I would like to ask whether there has been >>>>> any feedback on the CCC request for this issue. >>>> Sorry for really really long delay on this. Joe Darcy is the chair >>>> of the CCC and is in his queue to review/approve. He told me >>>> yesterday that he wanted to get to it soon, I think he's just being >>>> pulled into too many issues at the moment. Joe, do you have an ETA >>>> for Peter? I think it's important that we get this into jdk9/dev by >>>> Dec 16 in order to make the Dec 22 promotion. >>>> >>>> -Alan >>> >> > From pavel.rappo at oracle.com Mon Dec 19 15:26:52 2016 From: pavel.rappo at oracle.com (Pavel Rappo) Date: Mon, 19 Dec 2016 15:26:52 +0000 Subject: RFR 8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url Message-ID: <5EC3742A-A58A-4973-B598-24D47489ED90@oracle.com> Hello, Could you please review the following change for [1]? For convenience I split the otherwise monolithic change into 4 separate webrevs. The first webrev addresses the first part of the task. Which is elimination of undesirable inter-modular dependencies. There were dependencies on 3 symbols, 2 utility methods and 1 class: http://cr.openjdk.java.net/~prappo/8164907/webrev.00 The remaining 3 webrevs address the second part of the task. Which is coalescing the CORBA code in a single repo: http://cr.openjdk.java.net/~prappo/8164907/dev/ http://cr.openjdk.java.net/~prappo/8164907/corba/ http://cr.openjdk.java.net/~prappo/8164907/jdk/ As far as I can see all related tests are fine. Thanks, -Pavel -------------------------------------------------------------------------------- [1] https://bugs.openjdk.java.net/browse/JDK-8164907 From joe.darcy at oracle.com Mon Dec 19 15:44:13 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 19 Dec 2016 07:44:13 -0800 Subject: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java In-Reply-To: <0ddf440e-8614-179b-916c-be93fe8d24de@redhat.com> References: <213d5b02-a4d9-2171-73ef-44b5cdc46b17@oracle.com> <0ddf440e-8614-179b-916c-be93fe8d24de@redhat.com> Message-ID: <5d93ff7d-3338-4599-e638-c63c1d83d042@oracle.com> Hi Andrew, On 12/19/2016 7:24 AM, Andrew Haley wrote: > On 15/12/16 20:25, joe darcy wrote: >> Hello, >> >> Next up in porting fdlibm to Java after cbrt (JDK-8136799), pow >> (JDK-8134795) and hypot (JDK-7130085) earlier in JDK 9 is exp: >> >> JDK-8139688 Port fdlibm exp to Java >> http://cr.openjdk.java.net/~darcy/8139688.5/ >> >> Same methodology followed as when porting the earlier functions. > As discussed, this test is pointless because it is always true: > > + if(huge+x>one) return one+x;/* trigger inexact */ > > I understand that we intend to leave the code untouched, but the > inexact flag has no effect in Java code. Does it really make sense > to translate the code to Java but include such cruft? > It may not be clearly evident from the code reviews, but I take an iterative approach to porting the fdlibm C code to Java. The first iteration is the "transliteration" step where code as close to the C code is used and checked into the regression tests as a reference. I test the regression tests at this point by running them against JDK 8 which is still using the C version of fdlibm. Once that is done, I'll make a number of passes over a copy of the transliterated code in the core area to get it closer to idiomatic Java, sane whitespace and indenting, use of hex floating-point constants for specific values, preferring floating-point vs integer-based value checks, etc. One of those passes is removing "extraneous" computations which are present to set the IEEE floating-point flags, which as you point out, are outside of the Java and JVM model of computation. With deadlines looming, I didn't get to all the cruft removal passes for exp, but that can be done as future work. Cheers, -Joe From aph at redhat.com Mon Dec 19 15:47:33 2016 From: aph at redhat.com (Andrew Haley) Date: Mon, 19 Dec 2016 15:47:33 +0000 Subject: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java In-Reply-To: <5d93ff7d-3338-4599-e638-c63c1d83d042@oracle.com> References: <213d5b02-a4d9-2171-73ef-44b5cdc46b17@oracle.com> <0ddf440e-8614-179b-916c-be93fe8d24de@redhat.com> <5d93ff7d-3338-4599-e638-c63c1d83d042@oracle.com> Message-ID: Hi, On 19/12/16 15:44, joe darcy wrote: > With deadlines looming, I didn't get to all the cruft removal passes for > exp, but that can be done as future work. OK. My primary concern is how confusing it's going to be for the reader. We have already seen one example of a very experienced developer being confused by this. Perhaps a comment to that effect? Andrew. From aleksej.efimov at oracle.com Mon Dec 19 15:53:17 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Mon, 19 Dec 2016 18:53:17 +0300 Subject: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use" In-Reply-To: <82e0af2a-b250-a48f-75a3-34890755d6d3@oracle.com> References: <82e0af2a-b250-a48f-75a3-34890755d6d3@oracle.com> Message-ID: <7e4164c5-084d-fdee-acc2-2289aef677eb@oracle.com> Hi, Can I, please, ask JDK8 reviewer to look through the backported changes? Thanks, Aleksej On 15/12/16 17:06, Aleks Efimov wrote: > Hi, > Can I, please, have an approval to backport JDK-8146086 to 8u-dev. > The source fix was slightly modified to remove stream/lamdba usages, > therefore the fix is a subject to review. > Webrev with 8u-dev changes: > http://cr.openjdk.java.net/~aefimov/8146086/8/00/ > > The fix was tested with JPRT on all platforms - no failures observed. > > Best Regards, > Aleksej > > JBS: > https://bugs.openjdk.java.net/browse/JDK-8146086 > > JDK9 review thread: > http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037984.html > > > JDK9 changesets: > http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/daffd583eb35 > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/099e432fe59c > From chris.hegarty at oracle.com Mon Dec 19 15:54:05 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 19 Dec 2016 15:54:05 +0000 Subject: RFR 8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url In-Reply-To: <5EC3742A-A58A-4973-B598-24D47489ED90@oracle.com> References: <5EC3742A-A58A-4973-B598-24D47489ED90@oracle.com> Message-ID: <9a1f4b24-925b-d638-6493-9e4321938fa0@oracle.com> On 19/12/16 15:26, Pavel Rappo wrote: > Hello, > > Could you please review the following change for [1]? > > For convenience I split the otherwise monolithic change into 4 separate webrevs. > The first webrev addresses the first part of the task. Which is elimination of > undesirable inter-modular dependencies. There were dependencies on 3 symbols, > 2 utility methods and 1 class: > > http://cr.openjdk.java.net/~prappo/8164907/webrev.00 > > The remaining 3 webrevs address the second part of the task. Which is coalescing > the CORBA code in a single repo: > > http://cr.openjdk.java.net/~prappo/8164907/dev/ > http://cr.openjdk.java.net/~prappo/8164907/corba/ > http://cr.openjdk.java.net/~prappo/8164907/jdk/ These changes look good to me. Thanks for generating an easy-to-see version of the diffs too. Makes it easier to review. -Chris. > As far as I can see all related tests are fine. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1] https://bugs.openjdk.java.net/browse/JDK-8164907 > From Roger.Riggs at Oracle.com Mon Dec 19 15:55:36 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 19 Dec 2016 10:55:36 -0500 Subject: RFR 8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url In-Reply-To: <5EC3742A-A58A-4973-B598-24D47489ED90@oracle.com> References: <5EC3742A-A58A-4973-B598-24D47489ED90@oracle.com> Message-ID: <6362af57-fbb8-a685-1485-802079a75701@Oracle.com> Hi Pavel, Looks like a good consolidation and resolution. Roger On 12/19/2016 10:26 AM, Pavel Rappo wrote: > Hello, > > Could you please review the following change for [1]? > > For convenience I split the otherwise monolithic change into 4 separate webrevs. > The first webrev addresses the first part of the task. Which is elimination of > undesirable inter-modular dependencies. There were dependencies on 3 symbols, > 2 utility methods and 1 class: > > http://cr.openjdk.java.net/~prappo/8164907/webrev.00 > > The remaining 3 webrevs address the second part of the task. Which is coalescing > the CORBA code in a single repo: > > http://cr.openjdk.java.net/~prappo/8164907/dev/ > http://cr.openjdk.java.net/~prappo/8164907/corba/ > http://cr.openjdk.java.net/~prappo/8164907/jdk/ > > As far as I can see all related tests are fine. > > Thanks, > -Pavel > > -------------------------------------------------------------------------------- > [1]https://bugs.openjdk.java.net/browse/JDK-8164907 > From naoto.sato at oracle.com Mon Dec 19 16:28:13 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 19 Dec 2016 08:28:13 -0800 Subject: [9] RFR: 8171189: Deprecate ResourceBundleControlProvider for removal Message-ID: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com> Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8171189 The proposed fix is located at: http://cr.openjdk.java.net/~naoto/8171189/webrev.00/ The said SPI utilizes the Java extension mechanism which is now removed from JDK9. To our knowledge, no implementation has been made, including the original requester, so it's best to deprecate this in JDK9 and eventually remove in the future release. Naoto From naoto.sato at oracle.com Mon Dec 19 17:08:22 2016 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 19 Dec 2016 09:08:22 -0800 Subject: [9] RFR: 8171189: Deprecate ResourceBundleControlProvider for removal In-Reply-To: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com> References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com> Message-ID: <899d362a-1a43-1e9c-3e99-4445dff0b055@oracle.com> Small modification to the proposed fix: http://cr.openjdk.java.net/~naoto/8171189/webrev.01/ Modified test/ProblemList.txt to remove the line for the said SPI test. No other changes from 00. Naoto On 12/19/16 8:28 AM, Naoto Sato wrote: > Hello, > > Please review the fix to the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8171189 > > The proposed fix is located at: > > http://cr.openjdk.java.net/~naoto/8171189/webrev.00/ > > The said SPI utilizes the Java extension mechanism which is now removed > from JDK9. To our knowledge, no implementation has been made, including > the original requester, so it's best to deprecate this in JDK9 and > eventually remove in the future release. > > Naoto From mandy.chung at oracle.com Mon Dec 19 17:23:55 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Dec 2016 09:23:55 -0800 Subject: [9] RFR: 8171189: Deprecate ResourceBundleControlProvider for removal In-Reply-To: <899d362a-1a43-1e9c-3e99-4445dff0b055@oracle.com> References: <727b5e3b-50a5-d580-4308-4847795346ed@oracle.com> <899d362a-1a43-1e9c-3e99-4445dff0b055@oracle.com> Message-ID: <3DC257CD-49D7-47D4-B1AA-EA418FB4BC0C@oracle.com> Looks fine. To our knowledge, this ResourceBundleControlProvider SPI is rarely used, if any. The extension mechanism was removed in jdk-9+41 and there isn?t any issue filed related to this SPI. I agree to deprecate ResourceBundleControlProvider for removal. Mandy > On Dec 19, 2016, at 9:08 AM, Naoto Sato wrote: > > Small modification to the proposed fix: > > http://cr.openjdk.java.net/~naoto/8171189/webrev.01/ > > Modified test/ProblemList.txt to remove the line for the said SPI test. No other changes from 00. > > Naoto > > On 12/19/16 8:28 AM, Naoto Sato wrote: >> Hello, >> >> Please review the fix to the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8171189 >> >> The proposed fix is located at: >> >> http://cr.openjdk.java.net/~naoto/8171189/webrev.00/ >> >> The said SPI utilizes the Java extension mechanism which is now removed >> from JDK9. To our knowledge, no implementation has been made, including >> the original requester, so it's best to deprecate this in JDK9 and >> eventually remove in the future release. >> >> Naoto From daniel.fuchs at oracle.com Mon Dec 19 17:54:50 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Dec 2016 17:54:50 +0000 Subject: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option In-Reply-To: References: Message-ID: <7f85d9fa-8881-1bc4-78c8-c19c0433b16e@oracle.com> Hi Mandy, DepsAnalyzer.java: 232 Collection modules = configuration.getModules().values(); I don't see where modules is used in this method. Should this line be removed? 163 if (filter.requiresFilter().isEmpty()) { 164 return archives.stream() 165 .filter(this::include) ... 168 } else { 169 // use the archives that have dependences and not specified in --require 170 return archives.stream() 171 .filter(source -> !filter.requiresFilter().contains(source.getName())) 172 .filter(this::include) ... and later: 266 public boolean include(Archive source) { 267 Module module = source.getModule(); 268 // skip system module by default 269 return !module.isSystem() 270 || configuration.rootModules().contains(source) 271 || filter.requiresFilter().contains(module.name()); 272 } If I look at how JdepsFilter::includes was implemented, and given that filter.requiresFilter().contains(module.name()) will always be false if we come from line 165, or from line 172 then I would suggest to remove line 271: this would ensure that the call at line 95 does the same than before. best regards, -- daniel On 19/12/16 05:42, Mandy Chung wrote: > Webrev at: > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.00 > > --include-system-modules option was a temporary option added in an early stage of developement. Time to remove it as a clean up. > > Mandy > From mandy.chung at oracle.com Mon Dec 19 18:06:47 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Dec 2016 10:06:47 -0800 Subject: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option In-Reply-To: <7f85d9fa-8881-1bc4-78c8-c19c0433b16e@oracle.com> References: <7f85d9fa-8881-1bc4-78c8-c19c0433b16e@oracle.com> Message-ID: <31B4BA2E-5B37-4679-A63D-311183AE91B0@oracle.com> Updated webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.01 > On Dec 19, 2016, at 9:54 AM, Daniel Fuchs wrote: > > Hi Mandy, > > DepsAnalyzer.java: > > 232 Collection modules = configuration.getModules().values(); > > I don't see where modules is used in this method. > Should this line be removed? > Removed. Lance also caught that. > > 163 if (filter.requiresFilter().isEmpty()) { > 164 return archives.stream() > 165 .filter(this::include) > ... > 168 } else { > 169 // use the archives that have dependences and not specified in --require > 170 return archives.stream() > 171 .filter(source -> !filter.requiresFilter().contains(source.getName())) > 172 .filter(this::include) > ... > > and later: > > 266 public boolean include(Archive source) { > 267 Module module = source.getModule(); > 268 // skip system module by default > 269 return !module.isSystem() > 270 || configuration.rootModules().contains(source) > 271 || filter.requiresFilter().contains(module.name()); > 272 } > > > If I look at how JdepsFilter::includes was implemented, and given that > filter.requiresFilter().contains(module.name()) will always be false > if we come from line 165, or from line 172 then I would suggest to > remove line 271: this would ensure that the call at line 95 does > the same than before. > That?s a good suggestion. Mandy > > On 19/12/16 05:42, Mandy Chung wrote: >> Webrev at: >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.00 >> >> --include-system-modules option was a temporary option added in an early stage of developement. Time to remove it as a clean up. >> >> Mandy >> > From daniel.fuchs at oracle.com Mon Dec 19 18:26:05 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Dec 2016 18:26:05 +0000 Subject: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option In-Reply-To: <31B4BA2E-5B37-4679-A63D-311183AE91B0@oracle.com> References: <7f85d9fa-8881-1bc4-78c8-c19c0433b16e@oracle.com> <31B4BA2E-5B37-4679-A63D-311183AE91B0@oracle.com> Message-ID: On 19/12/16 18:06, Mandy Chung wrote: > Updated webrev: > > http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.01 Looks good to me. A related question is whether the tokens ALL-SYSTEM, ALL-DEFAULT, ALL-MODULE-PATH, should appear in the jdeps help message? best regards, -- daniel > >> On Dec 19, 2016, at 9:54 AM, Daniel Fuchs wrote: >> >> Hi Mandy, >> >> DepsAnalyzer.java: >> >> 232 Collection modules = configuration.getModules().values(); >> >> I don't see where modules is used in this method. >> Should this line be removed? >> > > Removed. Lance also caught that. > >> >> 163 if (filter.requiresFilter().isEmpty()) { >> 164 return archives.stream() >> 165 .filter(this::include) >> ... >> 168 } else { >> 169 // use the archives that have dependences and not specified in --require >> 170 return archives.stream() >> 171 .filter(source -> !filter.requiresFilter().contains(source.getName())) >> 172 .filter(this::include) >> ... >> >> and later: >> >> 266 public boolean include(Archive source) { >> 267 Module module = source.getModule(); >> 268 // skip system module by default >> 269 return !module.isSystem() >> 270 || configuration.rootModules().contains(source) >> 271 || filter.requiresFilter().contains(module.name()); >> 272 } >> >> >> If I look at how JdepsFilter::includes was implemented, and given that >> filter.requiresFilter().contains(module.name()) will always be false >> if we come from line 165, or from line 172 then I would suggest to >> remove line 271: this would ensure that the call at line 95 does >> the same than before. >> > > That?s a good suggestion. > > Mandy > >> >> On 19/12/16 05:42, Mandy Chung wrote: >>> Webrev at: >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.00 >>> >>> --include-system-modules option was a temporary option added in an early stage of developement. Time to remove it as a clean up. >>> >>> Mandy >>> >> > From mandy.chung at oracle.com Mon Dec 19 19:03:42 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Mon, 19 Dec 2016 11:03:42 -0800 Subject: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option In-Reply-To: References: <7f85d9fa-8881-1bc4-78c8-c19c0433b16e@oracle.com> <31B4BA2E-5B37-4679-A63D-311183AE91B0@oracle.com> Message-ID: <95FC2866-881A-4936-B236-355E71E341A5@oracle.com> > On Dec 19, 2016, at 10:26 AM, Daniel Fuchs wrote: > > On 19/12/16 18:06, Mandy Chung wrote: >> Updated webrev: >> >> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.01 > > Looks good to me. > A related question is whether the tokens ALL-SYSTEM, ALL-DEFAULT, > ALL-MODULE-PATH, should appear in the jdeps help message? > I?ll leave it as is. Clean it up when we do another pass on the help message. Mandy > best regards, > > -- daniel > >> >>> On Dec 19, 2016, at 9:54 AM, Daniel Fuchs wrote: >>> >>> Hi Mandy, >>> >>> DepsAnalyzer.java: >>> >>> 232 Collection modules = configuration.getModules().values(); >>> >>> I don't see where modules is used in this method. >>> Should this line be removed? >>> >> >> Removed. Lance also caught that. >> >>> >>> 163 if (filter.requiresFilter().isEmpty()) { >>> 164 return archives.stream() >>> 165 .filter(this::include) >>> ... >>> 168 } else { >>> 169 // use the archives that have dependences and not specified in --require >>> 170 return archives.stream() >>> 171 .filter(source -> !filter.requiresFilter().contains(source.getName())) >>> 172 .filter(this::include) >>> ... >>> >>> and later: >>> >>> 266 public boolean include(Archive source) { >>> 267 Module module = source.getModule(); >>> 268 // skip system module by default >>> 269 return !module.isSystem() >>> 270 || configuration.rootModules().contains(source) >>> 271 || filter.requiresFilter().contains(module.name()); >>> 272 } >>> >>> >>> If I look at how JdepsFilter::includes was implemented, and given that >>> filter.requiresFilter().contains(module.name()) will always be false >>> if we come from line 165, or from line 172 then I would suggest to >>> remove line 271: this would ensure that the call at line 95 does >>> the same than before. >>> >> >> That?s a good suggestion. >> >> Mandy >> >>> >>> On 19/12/16 05:42, Mandy Chung wrote: >>>> Webrev at: >>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.00 >>>> >>>> --include-system-modules option was a temporary option added in an early stage of developement. Time to remove it as a clean up. >>>> >>>> Mandy >>>> >>> >> > From Roger.Riggs at Oracle.com Mon Dec 19 19:04:31 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 19 Dec 2016 14:04:31 -0500 Subject: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths In-Reply-To: References: Message-ID: <842d435c-0d20-0da8-7625-799d95cf6a22@Oracle.com> Hi Brian, File.java: - 1906: shortenSubName might reasonably return the new length without creating the intermediate string and save on the allocation. - generateFile() line 1922 + -- I assume this slow path is infrequently used. Otherwise, the computations involving excess could be done arithmetically without actually creating the string and only create the name when the final length(s) are decided. - line 1952: appending the generated name to the exception is ok but it should omit the directory name; its not salient to the error and might expose a sensitive directory name. FileSystem.java - getNameMax; the length could reasonably be just an int. Long seems a bit excessive and raises suspicion that something clever is going on when its just a normal value. (Though I see the native code uses jlong) $.02, Roger On 12/16/2016 4:31 PM, Brian Burkhalter wrote: > Please review at your convenience. > > Issue: https://bugs.openjdk.java.net/browse/JDK-8148023 > Patch: http://cr.openjdk.java.net/~bpb/8148023/webrev.00/index.html > > The method was not adhering to the specification [1] and was creating long file names which caused failures on all platforms. The pertinent portion of the specification is: > > "To create the new file, the prefix and the suffix may first be adjusted to fit the limitations of the underlying platform. If the prefix is too long then it will be truncated, but its first three characters will always be preserved. If the suffix is too long then it too will be truncated, but if it begins with a period character ('.') then the period and the first three characters following it will always be preserved. Once these adjustments have been made the name of the new file will be generated by concatenating the prefix, five or more internally-generated characters, and the suffix." > > The code was updated to truncate the filename (leaf) portion of the path name to meet the platform file name component length constraints. The IO regression tests passed with this change on all platforms. > > Thanks, > > Brian > > [1] http://download.java.net/java/jdk9/docs/api/java/io/File.html#createTempFile-java.lang.String-java.lang.String-java.io.File- From daniel.fuchs at oracle.com Mon Dec 19 19:20:11 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Mon, 19 Dec 2016 19:20:11 +0000 Subject: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option In-Reply-To: <95FC2866-881A-4936-B236-355E71E341A5@oracle.com> References: <7f85d9fa-8881-1bc4-78c8-c19c0433b16e@oracle.com> <31B4BA2E-5B37-4679-A63D-311183AE91B0@oracle.com> <95FC2866-881A-4936-B236-355E71E341A5@oracle.com> Message-ID: On 19/12/16 19:03, Mandy Chung wrote: > >> On Dec 19, 2016, at 10:26 AM, Daniel Fuchs wrote: >> >> On 19/12/16 18:06, Mandy Chung wrote: >>> Updated webrev: >>> >>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.01 >> >> Looks good to me. >> A related question is whether the tokens ALL-SYSTEM, ALL-DEFAULT, >> ALL-MODULE-PATH, should appear in the jdeps help message? >> > > I?ll leave it as is. Clean it up when we do another pass on the help message. OK. Looks good then! -- daniel > > Mandy > >> best regards, >> >> -- daniel >> >>> >>>> On Dec 19, 2016, at 9:54 AM, Daniel Fuchs wrote: >>>> >>>> Hi Mandy, >>>> >>>> DepsAnalyzer.java: >>>> >>>> 232 Collection modules = configuration.getModules().values(); >>>> >>>> I don't see where modules is used in this method. >>>> Should this line be removed? >>>> >>> >>> Removed. Lance also caught that. >>> >>>> >>>> 163 if (filter.requiresFilter().isEmpty()) { >>>> 164 return archives.stream() >>>> 165 .filter(this::include) >>>> ... >>>> 168 } else { >>>> 169 // use the archives that have dependences and not specified in --require >>>> 170 return archives.stream() >>>> 171 .filter(source -> !filter.requiresFilter().contains(source.getName())) >>>> 172 .filter(this::include) >>>> ... >>>> >>>> and later: >>>> >>>> 266 public boolean include(Archive source) { >>>> 267 Module module = source.getModule(); >>>> 268 // skip system module by default >>>> 269 return !module.isSystem() >>>> 270 || configuration.rootModules().contains(source) >>>> 271 || filter.requiresFilter().contains(module.name()); >>>> 272 } >>>> >>>> >>>> If I look at how JdepsFilter::includes was implemented, and given that >>>> filter.requiresFilter().contains(module.name()) will always be false >>>> if we come from line 165, or from line 172 then I would suggest to >>>> remove line 271: this would ensure that the call at line 95 does >>>> the same than before. >>>> >>> >>> That?s a good suggestion. >>> >>> Mandy >>> >>>> >>>> On 19/12/16 05:42, Mandy Chung wrote: >>>>> Webrev at: >>>>> http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8171418/webrev.00 >>>>> >>>>> --include-system-modules option was a temporary option added in an early stage of developement. Time to remove it as a clean up. >>>>> >>>>> Mandy >>>>> >>>> >>> >> > From uschindler at apache.org Mon Dec 19 19:21:33 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 19 Dec 2016 20:21:33 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <9715ABEC-6964-4C44-8C9D-A16534A88C13@oracle.com> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> <66199530-cc41-b3a6-4276-89f2bc9773a8@oracle.com> <9715ABEC-6964-4C44-8C9D-A16534A88C13@oracle.com> Message-ID: <009a01d25a2d$1e715e20$5b541a60$@apache.org> Hi, will there be an update for JEP 260, so this is documented? Uwe ----- Uwe Schindler uschindler at apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -----Original Message----- > From: Chris Hegarty [mailto:chris.hegarty at oracle.com] > Sent: Friday, December 16, 2016 6:39 PM > To: Peter Levart ; Core-Libs-Dev dev at openjdk.java.net>; jigsaw-dev ; Uwe > Schindler > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Pushed to jdk9/dev. Should make b150. > > https://bugs.openjdk.java.net/browse/JDK-8171377 > > -Chris. > > > On 14 Dec 2016, at 11:58, Chris Hegarty > wrote: > > > > Webrev updated in-place. > > http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > > > > -Chris. > > > > On 13/12/16 21:18, Peter Levart wrote: > >> I think this is OK. > >> > >> Just a couple of nits in test: > >> > >> 1. You create a static Path bob = Paths.get("bob") field, but then you > >> don't use it in: > >> > >> 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), > >> CREATE, WRITE)) { > >> > >> 2. badBuffers could include a duplicate and a slice of a direct buffer > >> allocated with ByteBuffer.allocateDirect() > >> > >> 3. The comment in the test is referencing the old method name: > >> > >> 26 * @summary Basic test for Unsafe::deallocate > >> > >> > >> Regards, Peter > >> > >> On 12/13/2016 08:47 PM, Chris Hegarty wrote: > >>> Taking into account the feedback so far, and changing the method name > ( since > >>> it is an attractive nuisance ), here is where I think we ended up. > >>> > >>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ > >>> > >>> If this is agreeable, I?ll file an issue in JIRA to track the code changes, and > >>> update JEP 260. > >>> > >>> -Chris. > >> From chris.hegarty at oracle.com Mon Dec 19 19:22:26 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 19 Dec 2016 19:22:26 +0000 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <009a01d25a2d$1e715e20$5b541a60$@apache.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <26033a4d-7241-cee4-bd63-54bb99239977@gmail.com> <019b01d252e1$a70fb770$f52f2650$@apache.org> <0A212C12-63B0-40E5-B542-F350DB600D22@oracle.com> <284a59af-ddf6-4213-89ad-e62ae879ab1c@gmail.com> <90901cf8-f3a6-b922-8e2d-60047f9484d7@gmail.com> <006001d253ae$227fa010$677ee030$@apache.org> <66199530-cc41-b3a6-4276-89f2bc9773a8@oracle.com> <9715ABEC-6964-4C44-8C9D-A16534A88C13@oracle.com> <009a01d25a2d$1e715e20$5b541a60$@apache.org> Message-ID: <42D52551-FD9D-40CF-8296-4F4924E3FDCD@oracle.com> > On 19 Dec 2016, at 19:21, Uwe Schindler wrote: > > Hi, > > will there be an update for JEP 260, so this is documented? Yes, working on it. -Chris. > Uwe > > ----- > Uwe Schindler > uschindler at apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany > http://lucene.apache.org/ > >> -----Original Message----- >> From: Chris Hegarty [mailto:chris.hegarty at oracle.com] >> Sent: Friday, December 16, 2016 6:39 PM >> To: Peter Levart ; Core-Libs-Dev > dev at openjdk.java.net>; jigsaw-dev ; Uwe >> Schindler >> Subject: Re: Java 9 build 148 causes trouble in Apache >> Lucene/Solr/Elasticsearch >> >> Pushed to jdk9/dev. Should make b150. >> >> https://bugs.openjdk.java.net/browse/JDK-8171377 >> >> -Chris. >> >>> On 14 Dec 2016, at 11:58, Chris Hegarty >> wrote: >>> >>> Webrev updated in-place. >>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ >>> >>> -Chris. >>> >>> On 13/12/16 21:18, Peter Levart wrote: >>>> I think this is OK. >>>> >>>> Just a couple of nits in test: >>>> >>>> 1. You create a static Path bob = Paths.get("bob") field, but then you >>>> don't use it in: >>>> >>>> 56 try (FileChannel fc = FileChannel.open(Paths.get("bob"), >>>> CREATE, WRITE)) { >>>> >>>> 2. badBuffers could include a duplicate and a slice of a direct buffer >>>> allocated with ByteBuffer.allocateDirect() >>>> >>>> 3. The comment in the test is referencing the old method name: >>>> >>>> 26 * @summary Basic test for Unsafe::deallocate >>>> >>>> >>>> Regards, Peter >>>> >>>> On 12/13/2016 08:47 PM, Chris Hegarty wrote: >>>>> Taking into account the feedback so far, and changing the method name >> ( since >>>>> it is an attractive nuisance ), here is where I think we ended up. >>>>> >>>>> http://cr.openjdk.java.net/~chegar/Unsafe_invokeCleaner/ >>>>> >>>>> If this is agreeable, I?ll file an issue in JIRA to track the code changes, and >>>>> update JEP 260. >>>>> >>>>> -Chris. >>>> > From brian.burkhalter at oracle.com Mon Dec 19 20:54:59 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 19 Dec 2016 12:54:59 -0800 Subject: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths In-Reply-To: <842d435c-0d20-0da8-7625-799d95cf6a22@Oracle.com> References: <842d435c-0d20-0da8-7625-799d95cf6a22@Oracle.com> Message-ID: <8E5E7ADF-03DF-4CC6-91F1-D6A4E17F3D28@oracle.com> Hi Roger, Thanks for your suggestions. An updated version of the patch is here: http://cr.openjdk.java.net/~bpb/8148023/webrev.01/ On Dec 19, 2016, at 11:04 AM, Roger Riggs wrote: > File.java: > > - 1906: shortenSubName might reasonably return the new length without > creating the intermediate string and save on the allocation. So changed. > - generateFile() line 1922 + -- I assume this slow path is infrequently used. > Otherwise, the computations involving excess could be done arithmetically without actually creating the string > and only create the name when the final length(s) are decided. Modified. > - line 1952: appending the generated name to the exception is ok but it should omit the directory name; > its not salient to the error and might expose a sensitive directory name. Updated. > FileSystem.java > - getNameMax; the length could reasonably be just an int. Long seems a bit excessive > and raises suspicion that something clever is going on when its just a normal value. > (Though I see the native code uses jlong) Changed to an int except for the native Unix call. The invoking Java code clamps a highly unlikely out-of-range long to Integer.MAX_VALUE. Thanks, Brian From Roger.Riggs at Oracle.com Mon Dec 19 21:24:09 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Mon, 19 Dec 2016 16:24:09 -0500 Subject: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths In-Reply-To: <8E5E7ADF-03DF-4CC6-91F1-D6A4E17F3D28@oracle.com> References: <842d435c-0d20-0da8-7625-799d95cf6a22@Oracle.com> <8E5E7ADF-03DF-4CC6-91F1-D6A4E17F3D28@oracle.com> Message-ID: <842ec828-9d65-6a32-3d17-30787c39594c@Oracle.com> Hi Brian, Looks good Except for a typo in WinNTFileSystem_md.c:24 "compnent" Regards, Roger On 12/19/2016 3:54 PM, Brian Burkhalter wrote: > Hi Roger, > > Thanks for your suggestions. An updated version of the patch is here: > > http://cr.openjdk.java.net/~bpb/8148023/webrev.01/ > > > On Dec 19, 2016, at 11:04 AM, Roger Riggs > wrote: > >> File.java: >> >> - 1906: shortenSubName might reasonably return the new length without >> creating the intermediate string and save on the allocation. > > So changed. > >> - generateFile() line 1922 + -- I assume this slow path is >> infrequently used. >> Otherwise, the computations involving excess could be done >> arithmetically without actually creating the string >> and only create the name when the final length(s) are decided. > > Modified. > >> - line 1952: appending the generated name to the exception is ok but >> it should omit the directory name; >> its not salient to the error and might expose a sensitive directory >> name. > > Updated. > >> FileSystem.java >> - getNameMax; the length could reasonably be just an int. Long >> seems a bit excessive >> and raises suspicion that something clever is going on when its >> just a normal value. >> (Though I see the native code uses jlong) > > Changed to an int except for the native Unix call. The invoking Java > code clamps a highly unlikely out-of-range long to Integer.MAX_VALUE. > > Thanks, > > Brian From brian.burkhalter at oracle.com Mon Dec 19 21:35:03 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Mon, 19 Dec 2016 13:35:03 -0800 Subject: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths In-Reply-To: <842ec828-9d65-6a32-3d17-30787c39594c@Oracle.com> References: <842d435c-0d20-0da8-7625-799d95cf6a22@Oracle.com> <8E5E7ADF-03DF-4CC6-91F1-D6A4E17F3D28@oracle.com> <842ec828-9d65-6a32-3d17-30787c39594c@Oracle.com> Message-ID: <1C0B49BC-B80D-472A-8271-51557A25E439@oracle.com> Hi Roger, I updated the .01 version of the webrev in place. I?ll go ahead and push that. Thanks, Brian On Dec 19, 2016, at 1:24 PM, Roger Riggs wrote: > Looks good > > Except for a typo in WinNTFileSystem_md.c:24 "compnent" From paul.sandoz at oracle.com Tue Dec 20 01:51:10 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Dec 2016 17:51:10 -0800 Subject: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more In-Reply-To: <22b79993-4a51-b7f4-14a8-ad19e28873f4@gmail.com> References: <9ddc7fc5-68fe-bb78-b54d-6ba55880c018@gmail.com> <34B4C0BE-A333-4865-9C24-C6A9DBBF3D35@oracle.com> <11cfb990-622d-10b1-5f85-7445f114073e@gmail.com> <60664B68-DAAE-4DB6-8B68-7884A2F0312D@oracle.com> <7E2092D9-ECB7-4003-B55D-0A1F017949CA@oracle.com> <9B1109B5-A8B8-456E-BB9A-BD0E22C80226@oracle.com> <24661900-d442-edd8-1c0b-435581f58a41@oracle.com> <9D77191E-0006-4A61-9D03-FD226C5290B7@oracle.com> <93a4cebd-79bb-aed4-d27a-4cad25b7ad97@oracle.com> <1ef1620a-f14c-ca3d-54e0-5f5f4b8a9551@oracle.com> <22b79993-4a51-b7f4-14a8-ad19e2887! 3f4@gmail.com> Message-ID: Hi Peter, Very good work (that?s one heck of a test on steroids). Trivially on Class you could turn the ? Note that there may be ?? into @apiNote. In PublicMethodsTest can you merge Case and Case1? or did you intend the separation for future extensions? Paul. > On 19 Dec 2016, at 01:41, Peter Levart wrote: > > Hi, > > This is the latest webrev of changes to Class.getMethod() and Class.getMethods(), rebased to current tip of jdk9-dev, incorporating comments from CCC review: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.08/ > > Javadocs now include explicit text about Method(s) returned for interface and array types as well as description of general algorithm. Apart from javadocs, the following changed from webrev.07: > > - package-private Class.getMethdOrNull() (added by resent jigsaw changes) must copy the returned Method object itself since getMethod0() does not return a copy any more. > - renamed PublicMethods[.MethodList].coalesce() -> merge(). I think this is a less confusing name. > > For those of you, watching the public list, changes from webrev.04 that was last presented there are as follows: > > - PublicMethods class changed to embed, rather than extend a HashMap. > - Added a nearly-exhaustive test of Class.getMethods() and Class.getMethod(): PublicMethodsTest. This is actually a test generator. Given a Case template, it generates all variants of methods for each of the types in the case. Case1 contains 4 interface method variants ^ 3 interfaces * 4 class method variants ^ 3 classes = 4^6 = 4096 different sub-cases of which only 1379 compile. The results of those 1379 sub-cases are persisted in the Case1.results file. Running the test compares the persisted results with actual result of executing each sub-case. When running this test on plain JDK 9 (without patch), the test finds sub-cases where results differ: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/PublicMethodsTest.jtr > > Regards, Peter > > > On 12/18/2016 06:01 AM, joe darcy wrote: >> >> Hello Peter, >> >> Some comments on the spec changes proposed in this request. The new algorithm looks, but I don't think it is appropriate to remove explicit text like >> >>> If this |Class| object represents an array type, then the returned array has a |Method| object for each of the public methods inherited by the array type from |Object|. It does not contain a |Method| object for |clone()|. >>> >>> If this |Class| object represents an interface then the returned array does not contain any implicitly declared methods from |Object|. Therefore, if no methods are explicitly declared in this interface or any of its superinterfaces then the returned array has length 0. (Note that a |Class| object which represents a class always has public methods, inherited from |Object|.) >>> >> even if it is (non-obviously) implied by the rest of the text. >> >> I'm voting to approve the request on the condition that some explicit discussion is added back to describe the handling of array types and interface. >> >> Sorry for the delays, >> >> -Joe >> >> >> On 12/12/2016 11:09 PM, joe darcy wrote: >>> Hi Peter, >>> >>> Sorry for the delays on reviewing your request. I've been backed up on some ccc requests and I suspect the changes in your request are subtle enough to merit some time to examine. >>> >>> I'm trying to clear out my queue this week ahead of the next round of JDK 9 deadlines. >>> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 12/8/2016 12:42 AM, Alan Bateman wrote: >>>> On 08/12/2016 08:34, Peter Levart wrote: >>>> >>>>> Hi Mandy, Alan, >>>>> >>>>> I know you're all very busy with finalization of jigsaw features before the freeze, but I would like to ask whether there has been any feedback on the CCC request for this issue. >>>> Sorry for really really long delay on this. Joe Darcy is the chair of the CCC and is in his queue to review/approve. He told me yesterday that he wanted to get to it soon, I think he's just being pulled into too many issues at the moment. Joe, do you have an ETA for Peter? I think it's important that we get this into jdk9/dev by Dec 16 in order to make the Dec 22 promotion. >>>> >>>> -Alan >>> >> > From amy.lu at oracle.com Tue Dec 20 02:27:59 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 20 Dec 2016 10:27:59 +0800 Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64 In-Reply-To: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> Message-ID: <2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com> Please review. Thanks, Amy On 12/5/16 4:23 PM, Amy Lu wrote: > java/io/pathNames/GeneralWin32.java > > When tests run concurrently (-conc:N), it?s possible that this test > will walk into and does some testing on other test?s working dir, > other than it?s own. > > Please review the patch to avoid this unexpected behavior by > restricting the "checkNames" to test's own working directory. > > bug: https://bugs.openjdk.java.net/browse/JDK-8156595 > webrev: http://cr.openjdk.java.net/~amlu/8156595/webrev.00 > > Thanks, > Amy From paul.sandoz at oracle.com Tue Dec 20 05:47:51 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Mon, 19 Dec 2016 21:47:51 -0800 Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64 In-Reply-To: <2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com> References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> <2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com> Message-ID: <8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com> Hi Amy, I lack the context here so it feels like one is treating the symptoms rather than the cause. Perhaps it would be better to ensure this test never runs concurrently? is that possible? i believe we did something like that for the streams tests. Or perhaps the test should isolate it?s data via a temporary directory? Paul. > On 19 Dec 2016, at 18:27, Amy Lu wrote: > > Please review. > > Thanks, > Amy > > On 12/5/16 4:23 PM, Amy Lu wrote: >> java/io/pathNames/GeneralWin32.java >> >> When tests run concurrently (-conc:N), it?s possible that this test will walk into and does some testing on other test?s working dir, other than it?s own. >> >> Please review the patch to avoid this unexpected behavior by restricting the "checkNames" to test's own working directory. >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8156595 >> webrev: http://cr.openjdk.java.net/~amlu/8156595/webrev.00 >> >> Thanks, >> Amy > From huaming.li at oracle.com Tue Dec 20 07:10:50 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Tue, 20 Dec 2016 15:10:50 +0800 Subject: RFR of JDK-8029360: java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently Message-ID: <9f592cf2-9a46-0145-d6fc-f08f3402a71c@oracle.com> Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8029360 webrev: http://cr.openjdk.java.net/~mli/8029360/webrev.00/ * For the "connection refused" and "port in use" issue: Root Cause: consider reproducing scenario, 1. gets free port A (in main process). 2. interloper occupies port A. 3. starts registry subprocess and try to listen on port A (in subprocess). 4. registry fails with "port in use" (in subprocess). 5. interloper releases port A. 6. Naming.lookup on port A, it fails with "connection refused" Solution: To fix the issue, use REGISTRY to start registry process on ephemeral port and pass the port back to main process. * For another issue, log is short, can only guess that wait time is not long enough on busy machine, so fix the issue by scaling the wait time and using REGISTRY to synchronize. Thank you -Hamlin From weijun.wang at oracle.com Tue Dec 20 07:25:18 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 20 Dec 2016 15:25:18 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> Message-ID: <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> Ping again. > On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: > > An clarification is added to FilePermission::implies: > > * @implNote > .... > * a simple {@code npath} is recursively inside a wildcard {@code npath} > * if and only if {@code simple_npath.relativize(wildcard_npath)} > - * is a series of one or more "..". An invalid {@code FilePermission} does > + * is a series of one or more "..". Note that this means "/-" does not > + * imply "foo". An invalid {@code FilePermission} does > * not imply any object except for itself. > > The newly added sentence is > > Note that this means "/-" does not imply "foo". > > JCK has agreed to update their test. > > Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. > > Thanks > Max > From peter.levart at gmail.com Tue Dec 20 08:56:46 2016 From: peter.levart at gmail.com (Peter Levart) Date: Tue, 20 Dec 2016 09:56:46 +0100 Subject: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more In-Reply-To: References: <9ddc7fc5-68fe-bb78-b54d-6ba55880c018@gmail.com> <60664B68-DAAE-4DB6-8B68-7884A2F0312D@oracle.com> <7E2092D9-ECB7-4003-B55D-0A1F017949CA@oracle.com> <9B1109B5-A8B8-456E-BB9A-BD0E22C80226@oracle.com> <24661900-d442-edd8-1c0b-435581f58a41@oracle.com> <9D77191E-0006-4A61-9D03-FD226C5290B7@oracle.com> <93a4cebd-79bb-aed4-d27a-4cad25b7ad97@oracle.com> <1ef1620a-f14c-ca3d-54e0-5f5f4b8a9551@oracle.com> <22b79993-4a51-b7f4-14a8-ad19e2887! 3f4@gmail.com> Message-ID: <40e02f85-f992-bfe2-6aa1-6deae75b59c7@gmail.com> Hi Paul, On 12/20/2016 02:51 AM, Paul Sandoz wrote: > Hi Peter, > > Very good work (that?s one heck of a test on steroids). Which would not be possible without such nice APIs like Stream with lambdas and JavaCompiler... ;-) > > Trivially on Class you could turn the ? Note that there may be ?? into @apiNote. Like this? http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.09/ > > In PublicMethodsTest can you merge Case and Case1? or did you intend the separation for future extensions? Yes. While I can't currently imagine a situation that is not covered by the test, I also can't prove that this is an exhaustive test. So if someone discovers a situation that is important and not covered, it would be easy to create new Case implementation to cover just this situation and not have to touch Case1... Maybe, if the need arises, the templating, generation of combinations and compilation could even be factored out into a test utility and used in some other test? Regards, Peter > > Paul. > >> On 19 Dec 2016, at 01:41, Peter Levart wrote: >> >> Hi, >> >> This is the latest webrev of changes to Class.getMethod() and Class.getMethods(), rebased to current tip of jdk9-dev, incorporating comments from CCC review: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.08/ >> >> Javadocs now include explicit text about Method(s) returned for interface and array types as well as description of general algorithm. Apart from javadocs, the following changed from webrev.07: >> >> - package-private Class.getMethdOrNull() (added by resent jigsaw changes) must copy the returned Method object itself since getMethod0() does not return a copy any more. >> - renamed PublicMethods[.MethodList].coalesce() -> merge(). I think this is a less confusing name. >> >> For those of you, watching the public list, changes from webrev.04 that was last presented there are as follows: >> >> - PublicMethods class changed to embed, rather than extend a HashMap. >> - Added a nearly-exhaustive test of Class.getMethods() and Class.getMethod(): PublicMethodsTest. This is actually a test generator. Given a Case template, it generates all variants of methods for each of the types in the case. Case1 contains 4 interface method variants ^ 3 interfaces * 4 class method variants ^ 3 classes = 4^6 = 4096 different sub-cases of which only 1379 compile. The results of those 1379 sub-cases are persisted in the Case1.results file. Running the test compares the persisted results with actual result of executing each sub-case. When running this test on plain JDK 9 (without patch), the test finds sub-cases where results differ: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/PublicMethodsTest.jtr >> >> Regards, Peter >> >> >> On 12/18/2016 06:01 AM, joe darcy wrote: >>> Hello Peter, >>> >>> Some comments on the spec changes proposed in this request. The new algorithm looks, but I don't think it is appropriate to remove explicit text like >>> >>>> If this |Class| object represents an array type, then the returned array has a |Method| object for each of the public methods inherited by the array type from |Object|. It does not contain a |Method| object for |clone()|. >>>> >>>> If this |Class| object represents an interface then the returned array does not contain any implicitly declared methods from |Object|. Therefore, if no methods are explicitly declared in this interface or any of its superinterfaces then the returned array has length 0. (Note that a |Class| object which represents a class always has public methods, inherited from |Object|.) >>>> >>> even if it is (non-obviously) implied by the rest of the text. >>> >>> I'm voting to approve the request on the condition that some explicit discussion is added back to describe the handling of array types and interface. >>> >>> Sorry for the delays, >>> >>> -Joe >>> >>> >>> On 12/12/2016 11:09 PM, joe darcy wrote: >>>> Hi Peter, >>>> >>>> Sorry for the delays on reviewing your request. I've been backed up on some ccc requests and I suspect the changes in your request are subtle enough to merit some time to examine. >>>> >>>> I'm trying to clear out my queue this week ahead of the next round of JDK 9 deadlines. >>>> >>>> Thanks, >>>> >>>> -Joe >>>> >>>> >>>> On 12/8/2016 12:42 AM, Alan Bateman wrote: >>>>> On 08/12/2016 08:34, Peter Levart wrote: >>>>> >>>>>> Hi Mandy, Alan, >>>>>> >>>>>> I know you're all very busy with finalization of jigsaw features before the freeze, but I would like to ask whether there has been any feedback on the CCC request for this issue. >>>>> Sorry for really really long delay on this. Joe Darcy is the chair of the CCC and is in his queue to review/approve. He told me yesterday that he wanted to get to it soon, I think he's just being pulled into too many issues at the moment. Joe, do you have an ETA for Peter? I think it's important that we get this into jdk9/dev by Dec 16 in order to make the Dec 22 promotion. >>>>> >>>>> -Alan From amy.lu at oracle.com Tue Dec 20 09:20:45 2016 From: amy.lu at oracle.com (Amy Lu) Date: Tue, 20 Dec 2016 17:20:45 +0800 Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64 In-Reply-To: <8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com> References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> <2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com> <8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com> Message-ID: Thank you Paul for reviewing this. The failure is from testcase checkDrivePaths, in which it calls General.checkNames -> checkSlashes -> checkSlash -> checkNames public static void checkNames(int depth, boolean create, String ans, String ask) throws Exception { ... File f = new File(ans); ... if (f.exists()) { if (Files.isDirectory(f.toPath(), LinkOption.NOFOLLOW_LINKS) && f.list() != null) { 347: if ((n = findSomeFile(ans, create)) != null) 348: checkSlashes(d, create, ans + n, ask + n); ... 363: if ((n = f.getParent()) != null) { ... 371: checkSlashes(d, create, n, ask + ".."); } } For the failing case, the first time it calls checkNames, the "ans" (the 3rd arg) is "current working dir" (/path/scratch/1). Then changed to "parent" (/path/scratch) at line 363, and calls checkSlashes -> checkSlash -> checkNames checkNames now gets the "parent" (/path/scratch) and at line 347 it may reach files from other test's working dir (which is not expected to be tested) and then finally failed at using that file for InputStream in = new FileInputStream(path). Ensure test not runs concurrently can also avoid this issue. Please review the updated webrev: http://cr.openjdk.java.net/~amlu/8156595/webrev.01 Thanks, Amy On 12/20/16 1:47 PM, Paul Sandoz wrote: > Hi Amy, > > I lack the context here so it feels like one is treating the symptoms rather than the cause. > > Perhaps it would be better to ensure this test never runs concurrently? is that possible? i believe we did something like that for the streams tests. > > Or perhaps the test should isolate it?s data via a temporary directory? > > Paul. > >> On 19 Dec 2016, at 18:27, Amy Lu wrote: >> >> Please review. >> >> Thanks, >> Amy >> >> On 12/5/16 4:23 PM, Amy Lu wrote: >>> java/io/pathNames/GeneralWin32.java >>> >>> When tests run concurrently (-conc:N), it?s possible that this test will walk into and does some testing on other test?s working dir, other than it?s own. >>> >>> Please review the patch to avoid this unexpected behavior by restricting the "checkNames" to test's own working directory. >>> >>> bug: https://bugs.openjdk.java.net/browse/JDK-8156595 >>> webrev: http://cr.openjdk.java.net/~amlu/8156595/webrev.00 >>> >>> Thanks, >>> Amy From sean.coffey at oracle.com Tue Dec 20 09:40:03 2016 From: sean.coffey at oracle.com (=?UTF-8?Q?Se=c3=a1n_Coffey?=) Date: Tue, 20 Dec 2016 09:40:03 +0000 Subject: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use" In-Reply-To: <7e4164c5-084d-fdee-acc2-2289aef677eb@oracle.com> References: <82e0af2a-b250-a48f-75a3-34890755d6d3@oracle.com> <7e4164c5-084d-fdee-acc2-2289aef677eb@oracle.com> Message-ID: Looks fine Aleksej. Approved for jdk8u-dev. regards, Sean. On 19/12/2016 15:53, Aleks Efimov wrote: > Hi, > > Can I, please, ask JDK8 reviewer to look through the backported changes? > > Thanks, > Aleksej > > On 15/12/16 17:06, Aleks Efimov wrote: >> Hi, >> Can I, please, have an approval to backport JDK-8146086 to 8u-dev. >> The source fix was slightly modified to remove stream/lamdba usages, >> therefore the fix is a subject to review. >> Webrev with 8u-dev changes: >> http://cr.openjdk.java.net/~aefimov/8146086/8/00/ >> >> The fix was tested with JPRT on all platforms - no failures observed. >> >> Best Regards, >> Aleksej >> >> JBS: >> https://bugs.openjdk.java.net/browse/JDK-8146086 >> >> JDK9 review thread: >> http://mail.openjdk.java.net/pipermail/core-libs-dev/2016-January/037984.html >> >> >> JDK9 changesets: >> http://hg.openjdk.java.net/jdk9/dev/jaxws/rev/daffd583eb35 >> http://hg.openjdk.java.net/jdk9/dev/jdk/rev/099e432fe59c >> > From nadeesh.tv at oracle.com Tue Dec 20 09:55:14 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 20 Dec 2016 15:25:14 +0530 Subject: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns Message-ID: <58590002.5050902@oracle.com> Hi all, BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 Issue: Support adjacent value parsing for Localized Patterns Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ Pattern 'c' and 'W' were previously allowed to have 'zero padding' which was not explicitly mentioned in CLDR (http://unicode.org/reports/tr35/tr35-dates.html). To allow 'c' and 'W' to take part in adjacent value parsing ( at the same time, 2 digits are not required for these patterns), restricted the max width of these patterns to 1. Special thanks to Stephen for the help. -- Thanks and Regards, Nadeesh TV From daniel.fuchs at oracle.com Tue Dec 20 10:35:13 2016 From: daniel.fuchs at oracle.com (Daniel Fuchs) Date: Tue, 20 Dec 2016 10:35:13 +0000 Subject: RFR of JDK-8029360: java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently In-Reply-To: <9f592cf2-9a46-0145-d6fc-f08f3402a71c@oracle.com> References: <9f592cf2-9a46-0145-d6fc-f08f3402a71c@oracle.com> Message-ID: <0ed6f473-6bee-acf3-d659-545bac925190@oracle.com> Hi Hamlin, DGCDeadLock.java: 61 public static boolean finished = false; 62 static DGCDeadLock test = new DGCDeadLock(); 63 static int registryPort = -1; 1. 'finished' and 'registryPort' should be volatile since they are written and read by multiple threads. 2. 'test' should be final. The rest looks reasonable to me. -- daniel On 20/12/16 07:10, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8029360 > webrev: http://cr.openjdk.java.net/~mli/8029360/webrev.00/ > > * For the "connection refused" and "port in use" issue: > Root Cause: consider reproducing scenario, > 1. gets free port A (in main process). > 2. interloper occupies port A. > 3. starts registry subprocess and try to listen on port A (in > subprocess). > 4. registry fails with "port in use" (in subprocess). > 5. interloper releases port A. > 6. Naming.lookup on port A, it fails with "connection refused" > Solution: > To fix the issue, use REGISTRY to start registry process on > ephemeral port and pass the port back to main process. > > * For another issue, log is short, can only guess that wait time is not > long enough on busy machine, so fix the issue by scaling the wait time > and using REGISTRY to synchronize. > > > Thank you > -Hamlin From weijun.wang at oracle.com Tue Dec 20 12:04:26 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Tue, 20 Dec 2016 20:04:26 +0800 Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64 In-Reply-To: References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> <2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com> <8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com> Message-ID: > For the failing case, the first time it calls checkNames, the "ans" (the 3rd arg) is "current working dir" (/path/scratch/1). Is it possible to use ./tmp as "ans"? --Max From Roger.Riggs at Oracle.com Tue Dec 20 15:18:41 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 20 Dec 2016 10:18:41 -0500 Subject: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns In-Reply-To: <58590002.5050902@oracle.com> References: <58590002.5050902@oracle.com> Message-ID: <18f9b507-4d33-5057-648d-6dc2ea36aad5@Oracle.com> Hi Nadeesh, A nice bit of work. DateTimeFormatterBuilder: 4774: A note about the design to delay the choice of TemporalField and creating PrinterParser until the locale is known would be useful 4789: Please add the @param descriptions so the purpose of the new arguments is clear 4795: Documenting the 5 arg constructor may be useful too 4871: wrap this long line TCKLocalizedFieldParser.java: 85-87: Single character field names are too cryptic; and could be final and static? Thanks, Roger On 12/20/2016 4:55 AM, nadeesh tv wrote: > Hi all, > > BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 > > Issue: Support adjacent value parsing for Localized Patterns > > Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ > > Pattern 'c' and 'W' were previously allowed to have 'zero padding' > which was not explicitly mentioned in CLDR > (http://unicode.org/reports/tr35/tr35-dates.html). > To allow 'c' and 'W' to take part in adjacent value parsing ( at the > same time, 2 digits are not required for these patterns), restricted > the max width of these patterns to 1. > > Special thanks to Stephen for the help. > From Roger.Riggs at Oracle.com Tue Dec 20 15:49:44 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 20 Dec 2016 10:49:44 -0500 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> Message-ID: <4eb90509-4c28-a3d6-b0c1-f127973bd45a@Oracle.com> Hi Max, Comments: - Is there a better term/phrase to use other than "foo"; it does not appear elsewhere in the @implNote. The use of "cpath" and "npath" implies that someone is reading the source code. The description of the behavior of the implementation should use the same terminology as the spec. - The use of "Note" weakens the text as specification language. It can be omitted. - To make the source version more readable, I would keep each statement on its own line. Note that this means "/-" does not imply "foo". An invalid {@code FilePermission} does not imply any object except for itself. Thanks, Roger On 12/20/2016 2:25 AM, Wang Weijun wrote: > Ping again. > >> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >> >> An clarification is added to FilePermission::implies: >> >> * @implNote >> .... >> * a simple {@code npath} is recursively inside a wildcard {@code npath} >> * if and only if {@code simple_npath.relativize(wildcard_npath)} >> - * is a series of one or more "..". An invalid {@code FilePermission} does >> + * is a series of one or more "..". Note that this means "/-" does not >> + * imply "foo". An invalid {@code FilePermission} does >> * not imply any object except for itself. >> >> The newly added sentence is >> >> Note that this means "/-" does not imply "foo". >> >> JCK has agreed to update their test. >> >> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >> >> Thanks >> Max >> From scolebourne at joda.org Tue Dec 20 17:18:13 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Tue, 20 Dec 2016 17:18:13 +0000 Subject: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns In-Reply-To: <58590002.5050902@oracle.com> References: <58590002.5050902@oracle.com> Message-ID: In the test provider_adjacentValuePatterns2(), please add {"YYYYwwe", Y, w, c, "20161201", 2016, 12, 1}, This should succeed, because a single number is all that is needed to parse day-of-week. (So, it will need to be removed from the invalid patterns test). Line 1869 will need to change to "count, count, count" to make the tests pass. Otehrwise, looks fine, thanks. Stephen On 20 December 2016 at 09:55, nadeesh tv wrote: > Hi all, > > BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 > > Issue: Support adjacent value parsing for Localized Patterns > > Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ > > Pattern 'c' and 'W' were previously allowed to have 'zero padding' which > was not explicitly mentioned in CLDR > (http://unicode.org/reports/tr35/tr35-dates.html). > To allow 'c' and 'W' to take part in adjacent value parsing ( at the same > time, 2 digits are not required for these patterns), restricted the max > width of these patterns to 1. > > Special thanks to Stephen for the help. > > -- > Thanks and Regards, > Nadeesh TV > From nadeesh.tv at oracle.com Tue Dec 20 19:34:41 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 21 Dec 2016 01:04:41 +0530 Subject: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns In-Reply-To: References: <58590002.5050902@oracle.com> Message-ID: <585987D1.1020807@oracle.com> Hi Roger & Stephen , Thanks for the comments. Please see the updated webrev http://cr.openjdk.java.net/~ntv/8145633/webrev.12/ Changes included : 1. Doc changes and cosmetic changes suggested by Roger (except the note about delay..) 2. Changed the behavior of 'e' to parse only 1 digit as suggested by Stephen. Changed the existing test cases for this. Thanks and Regards, Nadeesh On 12/20/2016 10:48 PM, Stephen Colebourne wrote: > In the test provider_adjacentValuePatterns2(), please add > > {"YYYYwwe", Y, w, c, "20161201", 2016, 12, 1}, > > This should succeed, because a single number is all that is needed to > parse day-of-week. (So, it will need to be removed from the invalid > patterns test). > > Line 1869 will need to change to "count, count, count" to make the tests pass. > > Otehrwise, looks fine, thanks. > Stephen > > > On 20 December 2016 at 09:55, nadeesh tv wrote: >> Hi all, >> >> BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 >> >> Issue: Support adjacent value parsing for Localized Patterns >> >> Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ >> >> Pattern 'c' and 'W' were previously allowed to have 'zero padding' which >> was not explicitly mentioned in CLDR >> (http://unicode.org/reports/tr35/tr35-dates.html). >> To allow 'c' and 'W' to take part in adjacent value parsing ( at the same >> time, 2 digits are not required for these patterns), restricted the max >> width of these patterns to 1. >> >> Special thanks to Stephen for the help. >> >> -- >> Thanks and Regards, >> Nadeesh TV >> -- Thanks and Regards, Nadeesh TV From Roger.Riggs at Oracle.com Tue Dec 20 21:41:31 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Tue, 20 Dec 2016 16:41:31 -0500 Subject: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns In-Reply-To: <585987D1.1020807@oracle.com> References: <58590002.5050902@oracle.com> <585987D1.1020807@oracle.com> Message-ID: <84b30ddd-f5d7-e4d2-378e-441fb887498d@Oracle.com> Hi Nadeesh, On 12/20/2016 2:34 PM, nadeesh tv wrote: > > Hi Roger & Stephen , > Thanks for the comments. > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8145633/webrev.12/ > > Changes included : > > 1. Doc changes and cosmetic changes suggested by Roger (except the > note about delay..) The comments at 4776-4779 are fine. The issue came from passing null at line 4809 to the NumberPrinterParser constructor that expects the field argument to be non-null, and wanting some explanation of that disconnect. Other than that, I'm fine with the changes. Roger > > 2. Changed the behavior of 'e' to parse only 1 digit as suggested by > Stephen. Changed the existing test cases for this. > > Thanks and Regards, > Nadeesh > > On 12/20/2016 10:48 PM, Stephen Colebourne wrote: >> In the test provider_adjacentValuePatterns2(), please add >> >> {"YYYYwwe", Y, w, c, "20161201", 2016, 12, 1}, >> >> This should succeed, because a single number is all that is needed to >> parse day-of-week. (So, it will need to be removed from the invalid >> patterns test). >> >> Line 1869 will need to change to "count, count, count" to make the >> tests pass. >> >> Otehrwise, looks fine, thanks. >> Stephen >> >> >> On 20 December 2016 at 09:55, nadeesh tv wrote: >>> Hi all, >>> >>> BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 >>> >>> Issue: Support adjacent value parsing for Localized Patterns >>> >>> Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ >>> >>> Pattern 'c' and 'W' were previously allowed to have 'zero padding' >>> which >>> was not explicitly mentioned in CLDR >>> (http://unicode.org/reports/tr35/tr35-dates.html). >>> To allow 'c' and 'W' to take part in adjacent value parsing ( at >>> the same >>> time, 2 digits are not required for these patterns), restricted the >>> max >>> width of these patterns to 1. >>> >>> Special thanks to Stephen for the help. >>> >>> -- >>> Thanks and Regards, >>> Nadeesh TV >>> > From paul.sandoz at oracle.com Wed Dec 21 00:12:07 2016 From: paul.sandoz at oracle.com (Paul Sandoz) Date: Tue, 20 Dec 2016 16:12:07 -0800 Subject: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more In-Reply-To: <40e02f85-f992-bfe2-6aa1-6deae75b59c7@gmail.com> References: <9ddc7fc5-68fe-bb78-b54d-6ba55880c018@gmail.com> <60664B68-DAAE-4DB6-8B68-7884A2F0312D@oracle.com> <7E2092D9-ECB7-4003-B55D-0A1F017949CA@oracle.com> <9B1109B5-A8B8-456E-BB9A-BD0E22C80226@oracle.com> <24661900-d442-edd8-1c0b-435581f58a41@oracle.com> <9D77191E-0006-4A61-9D03-FD226C5290B7@oracle.com> <93a4cebd-79bb-aed4-d27a-4cad25b7ad97@oracle.com> <1ef1620a-f14c-ca3d-54e0-5f5f4b8a9551@oracle.com> <22b79993-4a51-b7f4-14a8-ad19e2887! 3f4@gmail.com> <40e02f85-f992-bfe2-6aa1-6deae75! b59c7@gmail.com> Message-ID: <4F86E1E0-5A61-4650-83DA-4AA3E0386795@oracle.com> > On 20 Dec 2016, at 00:56, Peter Levart wrote: > > Hi Paul, > > On 12/20/2016 02:51 AM, Paul Sandoz wrote: >> Hi Peter, >> >> Very good work (that?s one heck of a test on steroids). > > Which would not be possible without such nice APIs like Stream with lambdas and JavaCompiler... ;-) > :-) >> >> Trivially on Class you could turn the ? Note that there may be ?? into @apiNote. > > Like this? > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.09/ > Yes. >> >> In PublicMethodsTest can you merge Case and Case1? or did you intend the separation for future extensions? > > Yes. While I can't currently imagine a situation that is not covered by the test, I also can't prove that this is an exhaustive test. So if someone discovers a situation that is important and not covered, it would be easy to create new Case implementation to cover just this situation and not have to touch Case1? > Ok. > Maybe, if the need arises, the templating, generation of combinations and compilation could even be factored out into a test utility and used in some other test? > Yes. +1 Paul. From huaming.li at oracle.com Wed Dec 21 01:36:07 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 21 Dec 2016 09:36:07 +0800 Subject: RFR of JDK-8029360: java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently In-Reply-To: <0ed6f473-6bee-acf3-d659-545bac925190@oracle.com> References: <9f592cf2-9a46-0145-d6fc-f08f3402a71c@oracle.com> <0ed6f473-6bee-acf3-d659-545bac925190@oracle.com> Message-ID: <303c042f-31b2-8f94-a4d7-e30fe2c4be16@oracle.com> Hi Daniel, Thank you for reviewing, modified as you suggested and pushed the code. -Hamlin On 2016/12/20 18:35, Daniel Fuchs wrote: > Hi Hamlin, > > DGCDeadLock.java: > > 61 public static boolean finished = false; > 62 static DGCDeadLock test = new DGCDeadLock(); > 63 static int registryPort = -1; > > 1. 'finished' and 'registryPort' should be volatile since they are > written and read by multiple threads. > > 2. 'test' should be final. > > The rest looks reasonable to me. > > -- daniel > > On 20/12/16 07:10, Hamlin Li wrote: >> Would you please review the below patch? >> >> bug: https://bugs.openjdk.java.net/browse/JDK-8029360 >> webrev: http://cr.openjdk.java.net/~mli/8029360/webrev.00/ >> >> * For the "connection refused" and "port in use" issue: >> Root Cause: consider reproducing scenario, >> 1. gets free port A (in main process). >> 2. interloper occupies port A. >> 3. starts registry subprocess and try to listen on port A (in >> subprocess). >> 4. registry fails with "port in use" (in subprocess). >> 5. interloper releases port A. >> 6. Naming.lookup on port A, it fails with "connection refused" >> Solution: >> To fix the issue, use REGISTRY to start registry process on >> ephemeral port and pass the port back to main process. >> >> * For another issue, log is short, can only guess that wait time is not >> long enough on busy machine, so fix the issue by scaling the wait time >> and using REGISTRY to synchronize. >> >> >> Thank you >> -Hamlin > From mandy.chung at oracle.com Wed Dec 21 03:07:02 2016 From: mandy.chung at oracle.com (Mandy Chung) Date: Tue, 20 Dec 2016 19:07:02 -0800 Subject: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more In-Reply-To: <22b79993-4a51-b7f4-14a8-ad19e28873f4@gmail.com> References: <9ddc7fc5-68fe-bb78-b54d-6ba55880c018@gmail.com> <34B4C0BE-A333-4865-9C24-C6A9DBBF3D35@oracle.com> <11cfb990-622d-10b1-5f85-7445f114073e@gmail.com> <60664B68-DAAE-4DB6-8B68-7884A2F0312D@oracle.com> <7E2092D9-ECB7-4003-B55D-0A1F017949CA@oracle.com> <9B1109B5-A8B8-456E-BB9A-BD0E22C80226@oracle.com> <24661900-d442-edd8-1c0b-435581f58a41@oracle.com> <9D77191E-0006-4A61-9D03-FD226C5290B7@oracle.com> <93a4cebd-79bb-aed4-d27a-4cad25b7ad97@oracle.com> <1ef1620a-f14c-ca3d-54e0-5f5f4b8a9551@oracle.com> <22b79993-4a51-b7f4-14a8-ad19e2887! 3f4@gmail.com> Message-ID: <072F11A6-5BC3-469F-B3AD-3AE39348AE08@oracle.com> > On Dec 19, 2016, at 1:41 AM, Peter Levart wrote: > > Hi, > > This is the latest webrev of changes to Class.getMethod() and Class.getMethods(), rebased to current tip of jdk9-dev, incorporating comments from CCC review: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/webrev.08/ > > Javadocs now include explicit text about Method(s) returned for interface and array types as well as description of general algorithm. Apart from javadocs, the following changed from webrev.07: > > - package-private Class.getMethdOrNull() (added by resent jigsaw changes) must copy the returned Method object itself since getMethod0() does not return a copy any more. > - renamed PublicMethods[.MethodList].coalesce() -> merge(). I think this is a less confusing name. I reviewed webrev.09 on the delta change from webrev.07. Looks good. Mandy From amy.lu at oracle.com Wed Dec 21 03:50:40 2016 From: amy.lu at oracle.com (Amy Lu) Date: Wed, 21 Dec 2016 11:50:40 +0800 Subject: JDK 9 RFR of JDK-8171824: Remove OpenNonIntegralNumberOfSampleframes.java and ServerIdentityTest.java from ProblemList Message-ID: Please review the patch for taking back two tests. javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java This test was removed from ProblemList in JDK-8170581, but was wrongly added back to ProblemList by a merge: http://hg.openjdk.java.net/jdk9/hs/jdk/rev/16233 sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java This test was removed from ProblemList in JDK-8171043, but was wrongly added back to ProblemList by a merge: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9dde234ce1ef Thanks, Amy bug: https://bugs.openjdk.java.net/browse/JDK-8171824 webrev: --- old/test/ProblemList.txt 2016-12-21 11:44:07.000000000 +0800 +++ new/test/ProblemList.txt 2016-12-21 11:44:07.000000000 +0800 @@ -217,8 +217,6 @@ sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java 8161232 macosx-all -sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java 8171043 windows-all - javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 ############################################################################ @@ -232,8 +230,6 @@ javax/sound/sampled/Mixers/DisabledAssertionCrash.java 7067310 generic-all -javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java 8168881 generic-all - ############################################################################ # jdk_imageio From roger.riggs at oracle.com Wed Dec 21 04:04:20 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Tue, 20 Dec 2016 23:04:20 -0500 Subject: JDK 9 RFR of JDK-8171824: Remove OpenNonIntegralNumberOfSampleframes.java and ServerIdentityTest.java from ProblemList In-Reply-To: References: Message-ID: <76fc3576-48d4-6bfd-866c-b6bde8eac839@oracle.com> Hi Amy, Looks fine to remove those. Roger On 12/20/16 10:50 PM, Amy Lu wrote: > Please review the patch for taking back two tests. > > javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java > This test was removed from ProblemList in JDK-8170581, but was > wrongly added back to ProblemList by a merge: > http://hg.openjdk.java.net/jdk9/hs/jdk/rev/16233 > > sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java > This test was removed from ProblemList in JDK-8171043, but was > wrongly added back to ProblemList by a merge: > http://hg.openjdk.java.net/jdk9/dev/jdk/rev/9dde234ce1ef > > Thanks, > Amy > > bug: https://bugs.openjdk.java.net/browse/JDK-8171824 > > webrev: > > --- old/test/ProblemList.txt 2016-12-21 11:44:07.000000000 +0800 > +++ new/test/ProblemList.txt 2016-12-21 11:44:07.000000000 +0800 > @@ -217,8 +217,6 @@ > > sun/security/ssl/SSLSocketImpl/AsyncSSLSocketClose.java 8161232 > macosx-all > > -sun/net/www/protocol/https/HttpsClient/ServerIdentityTest.java > 8171043 windows-all > - > javax/net/ssl/DTLS/PacketLossRetransmission.java 8169086 macosx-x64 > > ############################################################################ > > @@ -232,8 +230,6 @@ > > javax/sound/sampled/Mixers/DisabledAssertionCrash.java 7067310 > generic-all > > -javax/sound/sampled/Clip/OpenNonIntegralNumberOfSampleframes.java > 8168881 generic-all > - > ############################################################################ > > > # jdk_imageio > From abhijit.r.roy at oracle.com Wed Dec 21 06:30:18 2016 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Wed, 21 Dec 2016 12:00:18 +0530 Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' In-Reply-To: <196d5a53-dc3b-0ba4-67b9-ce2fda1610fe@Oracle.com> References: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> <196d5a53-dc3b-0ba4-67b9-ce2fda1610fe@Oracle.com> Message-ID: <353a2b2d-032f-320e-6305-6248946fc32a@oracle.com> Hi Roger, I have fixed the same error in DateTimeFormatterBuiler. Please see the updated webrev below. Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.01/ Thanks Abhijit On 12/16/2016 8:01 PM, Roger Riggs wrote: > Hi, > > Sorry, I meant DateTimeFormatterBuilder. > > Roger > > > On 12/16/2016 9:28 AM, Roger Riggs wrote: >> Hi Abhijit, >> >> Please also fix the same error in DateTimeFormatter; line 300. >> >> I would use '24' as the example of the hour of day. >> It would emphasize that the range is 1-24. >> >> Roger >> >> >> On 12/16/2016 6:19 AM, Abhijit Roy wrote: >>> Hi all, >>> >>> >>> Please review the java doc fix for the below bug: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 >>> >>> Description: Incorrect documentation for DateTimeFormatter letter 'k' >>> >>> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ >>> >>> >>> I have just rectified and modified those errors. And moving forward >>> it for review. >>> >>> >>> Regards, >>> >>> Abhijit >>> >>> >>> >>> P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, >>> JDK-8169482, JDK-8170653 >> > From huaming.li at oracle.com Wed Dec 21 08:00:21 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Wed, 21 Dec 2016 16:00:21 +0800 Subject: RFR of JDK-8073080: TEST_BUG: sun/rmi/transport/tcp/DeadCachedConnection.java fails due to "ConnectException: Connection refused to host" Message-ID: <60fe275c-8c29-14e5-caf2-bf88f0bedaf8@oracle.com> Would you please review the below patch? bug: https://bugs.openjdk.java.net/browse/JDK-8073080 webrev: http://cr.openjdk.java.net/~mli/8073080/webrev.00/ Thank you -Hamlin From scolebourne at joda.org Wed Dec 21 09:54:55 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 21 Dec 2016 09:54:55 +0000 Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' In-Reply-To: <353a2b2d-032f-320e-6305-6248946fc32a@oracle.com> References: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> <196d5a53-dc3b-0ba4-67b9-ce2fda1610fe@Oracle.com> <353a2b2d-032f-320e-6305-6248946fc32a@oracle.com> Message-ID: Looks good Stephen On 21 Dec 2016 6:31 a.m., "Abhijit Roy" wrote: Hi Roger, I have fixed the same error in DateTimeFormatterBuiler. Please see the updated webrev below. Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.01/ Thanks Abhijit On 12/16/2016 8:01 PM, Roger Riggs wrote: > Hi, > > Sorry, I meant DateTimeFormatterBuilder. > > Roger > > > On 12/16/2016 9:28 AM, Roger Riggs wrote: > >> Hi Abhijit, >> >> Please also fix the same error in DateTimeFormatter; line 300. >> >> I would use '24' as the example of the hour of day. >> It would emphasize that the range is 1-24. >> >> Roger >> >> >> On 12/16/2016 6:19 AM, Abhijit Roy wrote: >> >>> Hi all, >>> >>> >>> Please review the java doc fix for the below bug: >>> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 >>> >>> Description: Incorrect documentation for DateTimeFormatter letter 'k' >>> >>> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ >>> >>> >>> I have just rectified and modified those errors. And moving forward it >>> for review. >>> >>> >>> Regards, >>> >>> Abhijit >>> >>> >>> >>> P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, JDK-8169482, >>> JDK-8170653 >>> >> >> > From ivan.gerasimov at oracle.com Wed Dec 21 12:16:04 2016 From: ivan.gerasimov at oracle.com (Ivan Gerasimov) Date: Wed, 21 Dec 2016 15:16:04 +0300 Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' In-Reply-To: <353a2b2d-032f-320e-6305-6248946fc32a@oracle.com> References: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> <196d5a53-dc3b-0ba4-67b9-ce2fda1610fe@Oracle.com> <353a2b2d-032f-320e-6305-6248946fc32a@oracle.com> Message-ID: Hi Abhijt! As you're changing the description of 'F' pattern in DateTimeFormatterBuilder, it makes sense to do the same in DateTimeFormatter. With kind regards, Ivan On 21.12.2016 9:30, Abhijit Roy wrote: > Hi Roger, > > I have fixed the same error in DateTimeFormatterBuiler. Please see the > updated webrev below. > > Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.01/ > > Thanks > Abhijit > > > On 12/16/2016 8:01 PM, Roger Riggs wrote: >> Hi, >> >> Sorry, I meant DateTimeFormatterBuilder. >> >> Roger >> >> >> On 12/16/2016 9:28 AM, Roger Riggs wrote: >>> Hi Abhijit, >>> >>> Please also fix the same error in DateTimeFormatter; line 300. >>> >>> I would use '24' as the example of the hour of day. >>> It would emphasize that the range is 1-24. >>> >>> Roger >>> >>> >>> On 12/16/2016 6:19 AM, Abhijit Roy wrote: >>>> Hi all, >>>> >>>> >>>> Please review the java doc fix for the below bug: >>>> >>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 >>>> >>>> Description: Incorrect documentation for DateTimeFormatter letter 'k' >>>> >>>> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ >>>> >>>> >>>> I have just rectified and modified those errors. And moving forward >>>> it for review. >>>> >>>> >>>> Regards, >>>> >>>> Abhijit >>>> >>>> >>>> >>>> P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, >>>> JDK-8169482, JDK-8170653 >>> >> > > From nadeesh.tv at oracle.com Wed Dec 21 13:24:27 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Wed, 21 Dec 2016 18:54:27 +0530 Subject: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns In-Reply-To: <84b30ddd-f5d7-e4d2-378e-441fb887498d@Oracle.com> References: <58590002.5050902@oracle.com> <585987D1.1020807@oracle.com> <84b30ddd-f5d7-e4d2-378e-441fb887498d@Oracle.com> Message-ID: <585A828B.6050604@oracle.com> Hi Roger & Stephen, Please see the updated webrev http://cr.openjdk.java.net/~ntv/8145633/webrev.13/ On 12/21/2016 3:11 AM, Roger Riggs wrote: > Hi Nadeesh, > > On 12/20/2016 2:34 PM, nadeesh tv wrote: >> >> Hi Roger & Stephen , >> Thanks for the comments. >> >> Please see the updated webrev >> http://cr.openjdk.java.net/~ntv/8145633/webrev.12/ >> >> Changes included : >> >> 1. Doc changes and cosmetic changes suggested by Roger (except the >> note about delay..) > The comments at 4776-4779 are fine. > The issue came from passing null at line 4809 to the > NumberPrinterParser constructor > that expects the field argument to be non-null, and wanting some > explanation of that disconnect. Changes included: Added the following clarification. 4775 * Prints or parses a localized pattern from a localized field. 4776 * The specific formatter and parameters is not selected until the 4777 * the field is to be printed or parsed. 4778 * The locale is needed to select the proper WeekFields from which 4779 * the field for day-of-week, week-of-month, or week-of-year is selected. *4780 * Since Locale is available only during parsing or formatting, the WeekBasedField 4781 * will be null during construction.* Is it OK? Thanks and Regards, Nadeesh > > Other than that, I'm fine with the changes. > > Roger > >> >> 2. Changed the behavior of 'e' to parse only 1 digit as suggested >> by Stephen. Changed the existing test cases for this. >> >> Thanks and Regards, >> Nadeesh >> >> On 12/20/2016 10:48 PM, Stephen Colebourne wrote: >>> In the test provider_adjacentValuePatterns2(), please add >>> >>> {"YYYYwwe", Y, w, c, "20161201", 2016, 12, 1}, >>> >>> This should succeed, because a single number is all that is needed to >>> parse day-of-week. (So, it will need to be removed from the invalid >>> patterns test). >>> >>> Line 1869 will need to change to "count, count, count" to make the >>> tests pass. >>> >>> Otehrwise, looks fine, thanks. >>> Stephen >>> >>> >>> On 20 December 2016 at 09:55, nadeesh tv wrote: >>>> Hi all, >>>> >>>> BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 >>>> >>>> Issue: Support adjacent value parsing for Localized Patterns >>>> >>>> Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ >>>> >>>> Pattern 'c' and 'W' were previously allowed to have 'zero padding' >>>> which >>>> was not explicitly mentioned in CLDR >>>> (http://unicode.org/reports/tr35/tr35-dates.html). >>>> To allow 'c' and 'W' to take part in adjacent value parsing ( at >>>> the same >>>> time, 2 digits are not required for these patterns), restricted >>>> the max >>>> width of these patterns to 1. >>>> >>>> Special thanks to Stephen for the help. >>>> >>>> -- >>>> Thanks and Regards, >>>> Nadeesh TV >>>> >> > -- Thanks and Regards, Nadeesh TV From scolebourne at joda.org Wed Dec 21 13:29:01 2016 From: scolebourne at joda.org (Stephen Colebourne) Date: Wed, 21 Dec 2016 13:29:01 +0000 Subject: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns In-Reply-To: <585A828B.6050604@oracle.com> References: <58590002.5050902@oracle.com> <585987D1.1020807@oracle.com> <84b30ddd-f5d7-e4d2-378e-441fb887498d@Oracle.com> <585A828B.6050604@oracle.com> Message-ID: Updated (13) webrev looks fine (link above is to webrev 12). Stephen On 21 December 2016 at 13:24, nadeesh tv wrote: > Hi Roger & Stephen, > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8145633/webrev.13/ > > > On 12/21/2016 3:11 AM, Roger Riggs wrote: > > Hi Nadeesh, > > On 12/20/2016 2:34 PM, nadeesh tv wrote: > > > Hi Roger & Stephen , > Thanks for the comments. > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8145633/webrev.12/ > > Changes included : > > 1. Doc changes and cosmetic changes suggested by Roger (except the note > about delay..) > > The comments at 4776-4779 are fine. > The issue came from passing null at line 4809 to the NumberPrinterParser > constructor > that expects the field argument to be non-null, and wanting some explanation > of that disconnect. > > > Changes included: Added the following clarification. > > 4775 * Prints or parses a localized pattern from a localized field. > 4776 * The specific formatter and parameters is not selected until the > 4777 * the field is to be printed or parsed. > 4778 * The locale is needed to select the proper WeekFields from which > 4779 * the field for day-of-week, week-of-month, or week-of-year is > selected. > 4780 * Since Locale is available only during parsing or formatting, the > WeekBasedField > 4781 * will be null during construction. > > Is it OK? > > Thanks and Regards, > Nadeesh > > > Other than that, I'm fine with the changes. > > Roger > > > 2. Changed the behavior of 'e' to parse only 1 digit as suggested by > Stephen. Changed the existing test cases for this. > > Thanks and Regards, > Nadeesh > > On 12/20/2016 10:48 PM, Stephen Colebourne wrote: > > In the test provider_adjacentValuePatterns2(), please add > > {"YYYYwwe", Y, w, c, "20161201", 2016, 12, 1}, > > This should succeed, because a single number is all that is needed to > parse day-of-week. (So, it will need to be removed from the invalid > patterns test). > > Line 1869 will need to change to "count, count, count" to make the tests > pass. > > Otehrwise, looks fine, thanks. > Stephen > > > On 20 December 2016 at 09:55, nadeesh tv wrote: > > Hi all, > > BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 > > Issue: Support adjacent value parsing for Localized Patterns > > Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ > > Pattern 'c' and 'W' were previously allowed to have 'zero padding' which > was not explicitly mentioned in CLDR > (http://unicode.org/reports/tr35/tr35-dates.html). > To allow 'c' and 'W' to take part in adjacent value parsing ( at the same > time, 2 digits are not required for these patterns), restricted the max > width of these patterns to 1. > > Special thanks to Stephen for the help. > > -- > Thanks and Regards, > Nadeesh TV > > > > > -- > Thanks and Regards, > Nadeesh TV > From dmitry.fazunenko at oracle.com Wed Dec 21 14:16:16 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko) Date: Wed, 21 Dec 2016 17:16:16 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks Message-ID: Hello, I'm looking for reviews of a relatively simple test change: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ https://bugs.openjdk.java.net/browse/JDK-8171441 The purpose of the change is to improve diagnostic. Thanks, Dima PS: After the fix the failures will be reported as: ----------System.err:(13/956)---------- java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; at VersionCheck.main(VersionCheck.java:295) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; PPS: The output of passed test now looks like: === testJVersionStrings === Testing servertool Testing jstat Testing jmod Testing jjs Testing jimage Testing jlink Testing jrunscript Testing jdeprscan Testing jconsole Testing rmiregistry Testing keytool Testing schemagen Testing javac Testing jar Testing jhsdb Testing jcmd Testing jstack Testing wsgen Testing jshell Testing serialver Testing jmap Testing javap Testing jps Testing jstatd Testing javadoc Testing tnameserv Testing jdb Testing jinfo Testing jdeps Testing xjc Testing rmid Testing jarsigner Testing idlj Testing rmic Testing appletviewer Testing pack200 Testing javah Testing policytool Testing orbd testJVersionStrings passed === testInternalStrings === testInternalStrings passed === testToolVersion === Testing java #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version java version "9-ea" Java(TM) SE Runtime Environment (build 9-ea+149) Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) #> echo $? 0 Testing javac #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version javac 9-ea #> echo $? 0 Testing jhsdb #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version clhsdb command line debugger debugd debug server hsdb ui debugger jstack --help to get more information jmap --help to get more information jinfo --help to get more information jsnap --help to get more information #> echo $? 0 Testing jshell #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version jshell 9-ea #> echo $? 0 Testing javap #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version 9-ea #> echo $? 0 Testing jdb #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version This is jdb version 9.0 (Java SE version 9-ea) #> echo $? 0 Testing idlj #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version IDL-to-Java compiler (portable), version "3.2" #> echo $? 0 Testing javah #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version Warning: The javah tool is planned to be removed in the next major JDK release. The tool has been superseded by the '-h' option added to javac in JDK 8. Users are recommended to migrate to using the javac '-h' option; see the javac man page for more information. javah version "9-ea" #> echo $? 0 testToolVersion passed === testInternalStrings === testDebugVersion passed All Version string comparisons: PASS ----------System.err:(1/15)---------- From roger.riggs at oracle.com Wed Dec 21 14:16:49 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 21 Dec 2016 09:16:49 -0500 Subject: RFR:JDK-8145633-Adjacent value parsing not supported for Localized Patterns In-Reply-To: <585A828B.6050604@oracle.com> References: <58590002.5050902@oracle.com> <585987D1.1020807@oracle.com> <84b30ddd-f5d7-e4d2-378e-441fb887498d@Oracle.com> <585A828B.6050604@oracle.com> Message-ID: <455a3708-c928-a418-11c0-0f7645d924f5@oracle.com> Hi Nadeesh, Looks fine. It would be more direct to add that "The inherited field NumberPrinterParser.field is unused." No need for another review cycle. Thanks, Roger On 12/21/16 8:24 AM, nadeesh tv wrote: > Hi Roger & Stephen, > > Please see the updated webrev > http://cr.openjdk.java.net/~ntv/8145633/webrev.13/ > > > On 12/21/2016 3:11 AM, Roger Riggs wrote: >> Hi Nadeesh, >> >> On 12/20/2016 2:34 PM, nadeesh tv wrote: >>> >>> Hi Roger & Stephen , >>> Thanks for the comments. >>> >>> Please see the updated webrev >>> http://cr.openjdk.java.net/~ntv/8145633/webrev.12/ >>> >>> Changes included : >>> >>> 1. Doc changes and cosmetic changes suggested by Roger (except the >>> note about delay..) >> The comments at 4776-4779 are fine. >> The issue came from passing null at line 4809 to the >> NumberPrinterParser constructor >> that expects the field argument to be non-null, and wanting some >> explanation of that disconnect. > > Changes included: Added the following clarification. > 4775 * Prints or parses a localized pattern from a localized field. > 4776 * The specific formatter and parameters is not selected until the > 4777 * the field is to be printed or parsed. > 4778 * The locale is needed to select the proper WeekFields from which > 4779 * the field for day-of-week, week-of-month, or week-of-year is selected. > *4780 * Since Locale is available only during parsing or formatting, > the WeekBasedField 4781 * will be null during construction.* > Is it OK? > > Thanks and Regards, > Nadeesh >> >> Other than that, I'm fine with the changes. >> >> Roger >> >>> >>> 2. Changed the behavior of 'e' to parse only 1 digit as suggested >>> by Stephen. Changed the existing test cases for this. >>> >>> Thanks and Regards, >>> Nadeesh >>> >>> On 12/20/2016 10:48 PM, Stephen Colebourne wrote: >>>> In the test provider_adjacentValuePatterns2(), please add >>>> >>>> {"YYYYwwe", Y, w, c, "20161201", 2016, 12, 1}, >>>> >>>> This should succeed, because a single number is all that is needed to >>>> parse day-of-week. (So, it will need to be removed from the invalid >>>> patterns test). >>>> >>>> Line 1869 will need to change to "count, count, count" to make the >>>> tests pass. >>>> >>>> Otehrwise, looks fine, thanks. >>>> Stephen >>>> >>>> >>>> On 20 December 2016 at 09:55, nadeesh tv >>>> wrote: >>>>> Hi all, >>>>> >>>>> BugId: https://bugs.openjdk.java.net/browse/JDK-8145633 >>>>> >>>>> Issue: Support adjacent value parsing for Localized Patterns >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~ntv/8145633/webrev.10/ >>>>> >>>>> Pattern 'c' and 'W' were previously allowed to have 'zero >>>>> padding' which >>>>> was not explicitly mentioned in CLDR >>>>> (http://unicode.org/reports/tr35/tr35-dates.html). >>>>> To allow 'c' and 'W' to take part in adjacent value parsing ( at >>>>> the same >>>>> time, 2 digits are not required for these patterns), restricted >>>>> the max >>>>> width of these patterns to 1. >>>>> >>>>> Special thanks to Stephen for the help. >>>>> >>>>> -- >>>>> Thanks and Regards, >>>>> Nadeesh TV >>>>> >>> >> > > -- > Thanks and Regards, > Nadeesh TV > From roger.riggs at oracle.com Wed Dec 21 14:23:13 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 21 Dec 2016 09:23:13 -0500 Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' In-Reply-To: References: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> <196d5a53-dc3b-0ba4-67b9-ce2fda1610fe@Oracle.com> <353a2b2d-032f-320e-6305-6248946fc32a@oracle.com> Message-ID: <407bb2be-5926-7732-e6fc-c4785dac7e2f@oracle.com> Hi Abhijit, Looks fine to push with this additional change to make the descriptions of 'F' match. Thanks, Roger On 12/21/16 7:16 AM, Ivan Gerasimov wrote: > Hi Abhijt! > > As you're changing the description of 'F' pattern in > DateTimeFormatterBuilder, it makes sense to do the same in > DateTimeFormatter. > > With kind regards, > Ivan > > > On 21.12.2016 9:30, Abhijit Roy wrote: >> Hi Roger, >> >> I have fixed the same error in DateTimeFormatterBuiler. Please see >> the updated webrev below. >> >> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.01/ >> >> Thanks >> Abhijit >> >> >> On 12/16/2016 8:01 PM, Roger Riggs wrote: >>> Hi, >>> >>> Sorry, I meant DateTimeFormatterBuilder. >>> >>> Roger >>> >>> >>> On 12/16/2016 9:28 AM, Roger Riggs wrote: >>>> Hi Abhijit, >>>> >>>> Please also fix the same error in DateTimeFormatter; line 300. >>>> >>>> I would use '24' as the example of the hour of day. >>>> It would emphasize that the range is 1-24. >>>> >>>> Roger >>>> >>>> >>>> On 12/16/2016 6:19 AM, Abhijit Roy wrote: >>>>> Hi all, >>>>> >>>>> >>>>> Please review the java doc fix for the below bug: >>>>> >>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 >>>>> >>>>> Description: Incorrect documentation for DateTimeFormatter letter 'k' >>>>> >>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ >>>>> >>>>> >>>>> I have just rectified and modified those errors. And moving >>>>> forward it for review. >>>>> >>>>> >>>>> Regards, >>>>> >>>>> Abhijit >>>>> >>>>> >>>>> >>>>> P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, >>>>> JDK-8169482, JDK-8170653 >>>> >>> >> >> > From roger.riggs at oracle.com Wed Dec 21 14:57:06 2016 From: roger.riggs at oracle.com (Roger Riggs) Date: Wed, 21 Dec 2016 09:57:06 -0500 Subject: RFR of JDK-8073080: TEST_BUG: sun/rmi/transport/tcp/DeadCachedConnection.java fails due to "ConnectException: Connection refused to host" In-Reply-To: <60fe275c-8c29-14e5-caf2-bf88f0bedaf8@oracle.com> References: <60fe275c-8c29-14e5-caf2-bf88f0bedaf8@oracle.com> Message-ID: Hi Hamlin, Looks fine. Roger On 12/21/16 3:00 AM, Hamlin Li wrote: > Would you please review the below patch? > > bug: https://bugs.openjdk.java.net/browse/JDK-8073080 > webrev: http://cr.openjdk.java.net/~mli/8073080/webrev.00/ > > Thank you > -Hamlin From xuelei.fan at oracle.com Wed Dec 21 20:39:28 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 21 Dec 2016 12:39:28 -0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> Message-ID: I'm trying to understand this update. Does "/-" imply "/foo"? Does the following spec can be used to explain the new added note? *
    • if the wildcard flag is "-", the simple pathname's path * must be recursively inside the wildcard pathname's path. Xuelei On 12/19/2016 11:25 PM, Wang Weijun wrote: > Ping again. > >> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >> >> An clarification is added to FilePermission::implies: >> >> * @implNote >> .... >> * a simple {@code npath} is recursively inside a wildcard {@code npath} >> * if and only if {@code simple_npath.relativize(wildcard_npath)} >> - * is a series of one or more "..". An invalid {@code FilePermission} does >> + * is a series of one or more "..". Note that this means "/-" does not >> + * imply "foo". An invalid {@code FilePermission} does >> * not imply any object except for itself. >> >> The newly added sentence is >> >> Note that this means "/-" does not imply "foo". >> >> JCK has agreed to update their test. >> >> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >> >> Thanks >> Max >> > From patrick at reini.net Wed Dec 21 21:08:13 2016 From: patrick at reini.net (Patrick Reinhart) Date: Wed, 21 Dec 2016 22:08:13 +0100 Subject: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net> <7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com> <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net> Message-ID: Hi Roger, I tried to put your suggested changes, into the following webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.01 >>>> - 375: Can this use the new private constructor that will handle psOut. >>> Here I can not get hold on the encoding at this point or have I missed something here? >> True, not easily, it is available as a String from OutputStreamWriter.getEncoding() but it would suffer from >> having to lookup it by name again. > > Right, even the Charset is actually available within the StreamEncoder implementation but not provided to the outside world. > > Also the OutputStreamWriter is in wrapped in a BufferedWriter and would be needed to be extracted from there again in the first place. Here I left the invocation as it was before? -Patrick From jason_mehrens at hotmail.com Wed Dec 21 21:40:53 2016 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Wed, 21 Dec 2016 21:40:53 +0000 Subject: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net> <7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com> <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net> , Message-ID: Patrick, How is 'withAutoFlush' expected to behave for subclasses of PrintWriter? Jason ________________________________________ From: core-libs-dev on behalf of Patrick Reinhart Sent: Wednesday, December 21, 2016 3:08 PM To: Roger Riggs Cc: core-libs-dev Subject: Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors Hi Roger, I tried to put your suggested changes, into the following webrev: http://cr.openjdk.java.net/~reinhapa/reviews/8167648/webrev.01 >>>> - 375: Can this use the new private constructor that will handle psOut. >>> Here I can not get hold on the encoding at this point or have I missed something here? >> True, not easily, it is available as a String from OutputStreamWriter.getEncoding() but it would suffer from >> having to lookup it by name again. > > Right, even the Charset is actually available within the StreamEncoder implementation but not provided to the outside world. > > Also the OutputStreamWriter is in wrapped in a BufferedWriter and would be needed to be extracted from there again in the first place. Here I left the invocation as it was before? -Patrick From weijun.wang at oracle.com Wed Dec 21 23:58:46 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Dec 2016 07:58:46 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> Message-ID: <7638C07B-F7A6-460B-AAC5-98F954624C9C@oracle.com> > On Dec 22, 2016, at 4:39 AM, Xuelei Fan wrote: > > I'm trying to understand this update. Does "/-" imply "/foo"? Yes. > > Does the following spec can be used to explain the new added note? > > *
    • if the wildcard flag is "-", the simple pathname's path > * must be recursively inside the wildcard pathname's path. Yes. But the precise meaning of "recursively inside" is different between the pre-jdk9 and jdk9 behaviors. The @implNote explains more. --Max > > Xuelei > > On 12/19/2016 11:25 PM, Wang Weijun wrote: >> Ping again. >> >>> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >>> >>> An clarification is added to FilePermission::implies: >>> >>> * @implNote >>> .... >>> * a simple {@code npath} is recursively inside a wildcard {@code npath} >>> * if and only if {@code simple_npath.relativize(wildcard_npath)} >>> - * is a series of one or more "..". An invalid {@code FilePermission} does >>> + * is a series of one or more "..". Note that this means "/-" does not >>> + * imply "foo". An invalid {@code FilePermission} does >>> * not imply any object except for itself. >>> >>> The newly added sentence is >>> >>> Note that this means "/-" does not imply "foo". >>> >>> JCK has agreed to update their test. >>> >>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >>> >>> Thanks >>> Max >>> >> From xuelei.fan at oracle.com Thu Dec 22 00:12:53 2016 From: xuelei.fan at oracle.com (Xuelei Fan) Date: Wed, 21 Dec 2016 16:12:53 -0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: <7638C07B-F7A6-460B-AAC5-98F954624C9C@oracle.com> References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> <7638C07B-F7A6-460B-AAC5-98F954624C9C@oracle.com> Message-ID: I think the note is an example, may not need an additional CCC. For easier reading, I may use a contrast example. For example, "Note that this means "/-" implies "/foo" but not "foo".". Use the one you like, I'm OK with the either. Xuelei On 12/21/2016 3:58 PM, Wang Weijun wrote: > >> On Dec 22, 2016, at 4:39 AM, Xuelei Fan wrote: >> >> I'm trying to understand this update. Does "/-" imply "/foo"? > > Yes. > >> >> Does the following spec can be used to explain the new added note? >> >> *
    • if the wildcard flag is "-", the simple pathname's path >> * must be recursively inside the wildcard pathname's path. > > Yes. > > But the precise meaning of "recursively inside" is different between the pre-jdk9 and jdk9 behaviors. The @implNote explains more. > > --Max > >> >> Xuelei >> >> On 12/19/2016 11:25 PM, Wang Weijun wrote: >>> Ping again. >>> >>>> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >>>> >>>> An clarification is added to FilePermission::implies: >>>> >>>> * @implNote >>>> .... >>>> * a simple {@code npath} is recursively inside a wildcard {@code npath} >>>> * if and only if {@code simple_npath.relativize(wildcard_npath)} >>>> - * is a series of one or more "..". An invalid {@code FilePermission} does >>>> + * is a series of one or more "..". Note that this means "/-" does not >>>> + * imply "foo". An invalid {@code FilePermission} does >>>> * not imply any object except for itself. >>>> >>>> The newly added sentence is >>>> >>>> Note that this means "/-" does not imply "foo". >>>> >>>> JCK has agreed to update their test. >>>> >>>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >>>> >>>> Thanks >>>> Max >>>> >>> > From weijun.wang at oracle.com Thu Dec 22 00:14:28 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Dec 2016 08:14:28 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> <7638C07B-F7A6-460B-AAC5-98F954624C9C@oracle.com> Message-ID: <279964A0-C943-48B7-86F0-210871A2723F@oracle.com> > On Dec 22, 2016, at 8:12 AM, Xuelei Fan wrote: > > I think the note is an example, may not need an additional CCC. That's always my understanding. > > For easier reading, I may use a contrast example. For example, "Note that this means "/-" implies "/foo" but not "foo".". Good advice. Thanks Max > > Use the one you like, I'm OK with the either. > > Xuelei > > On 12/21/2016 3:58 PM, Wang Weijun wrote: >> >>> On Dec 22, 2016, at 4:39 AM, Xuelei Fan wrote: >>> >>> I'm trying to understand this update. Does "/-" imply "/foo"? >> >> Yes. >> >>> >>> Does the following spec can be used to explain the new added note? >>> >>> *
    • if the wildcard flag is "-", the simple pathname's path >>> * must be recursively inside the wildcard pathname's path. >> >> Yes. >> >> But the precise meaning of "recursively inside" is different between the pre-jdk9 and jdk9 behaviors. The @implNote explains more. >> >> --Max >> >>> >>> Xuelei >>> >>> On 12/19/2016 11:25 PM, Wang Weijun wrote: >>>> Ping again. >>>> >>>>> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >>>>> >>>>> An clarification is added to FilePermission::implies: >>>>> >>>>> * @implNote >>>>> .... >>>>> * a simple {@code npath} is recursively inside a wildcard {@code npath} >>>>> * if and only if {@code simple_npath.relativize(wildcard_npath)} >>>>> - * is a series of one or more "..". An invalid {@code FilePermission} does >>>>> + * is a series of one or more "..". Note that this means "/-" does not >>>>> + * imply "foo". An invalid {@code FilePermission} does >>>>> * not imply any object except for itself. >>>>> >>>>> The newly added sentence is >>>>> >>>>> Note that this means "/-" does not imply "foo". >>>>> >>>>> JCK has agreed to update their test. >>>>> >>>>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >>>>> >>>>> Thanks >>>>> Max >>>>> >>>> >> From weijun.wang at oracle.com Thu Dec 22 00:23:11 2016 From: weijun.wang at oracle.com (Wang Weijun) Date: Thu, 22 Dec 2016 08:23:11 +0800 Subject: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-) In-Reply-To: <4eb90509-4c28-a3d6-b0c1-f127973bd45a@Oracle.com> References: <09921990-63EB-44D7-A6AB-5D858897C411@oracle.com> <171F8C29-90D0-4F8D-A59A-444F7732BECF@oracle.com> <4eb90509-4c28-a3d6-b0c1-f127973bd45a@Oracle.com> Message-ID: <934B4B33-22F8-49A7-BEEE-3CCFEEA4760E@oracle.com> Hi Roger > On Dec 20, 2016, at 11:49 PM, Roger Riggs wrote: > > Hi Max, > > Comments: > > - Is there a better term/phrase to use other than "foo"; it does not appear elsewhere in the @implNote. It appears in the spec of this method: *
    • p's pathname is implied by this object's * pathname. For example, "/tmp/*" implies "/tmp/foo", since * "/tmp/*" encompasses all files in the "/tmp" directory, * including the one named "foo". > The use of "cpath" and "npath" implies that someone is reading the source code. Not really. They also appears in the @implNote of the spec of FilePermission::(String,String): * If the value of the system property is set to {@code true}, {@code path} * is canonicalized and stored as a String object named {@code cpath}. * This means a relative path is converted to an absolute path, a Windows * DOS-style 8.3 path is expanded to a long path, and a symbolic link is * resolved to its target, etc. *

      * If the value of the system property is set to {@code false}, {@code path} * is converted to a {@link java.nio.file.Path} object named {@code npath} * after {@link Path#normalize() normalization}. No canonicalization is * performed which means the underlying file system is not accessed. * If an {@link InvalidPathException} is thrown during the conversion, * this {@code FilePermission} will be labeled as invalid. I think using the same name in all @implNote is more precise. > The description of the behavior of the implementation should use the same terminology as the spec. > > - The use of "Note" weakens the text as specification language. It can be omitted. OK. I'll use take Xuelei's advice to expand this line to This means "/-" implies "/foo" but not "foo". > > - To make the source version more readable, I would keep each statement on its own line. OK. Thanks Max > > Note that this means "/-" does not imply "foo". > An invalid {@code FilePermission} does not imply any object except for itself. > > Thanks, Roger > > On 12/20/2016 2:25 AM, Wang Weijun wrote: >> Ping again. >> >>> On Dec 14, 2016, at 1:53 PM, Wang Weijun wrote: >>> >>> An clarification is added to FilePermission::implies: >>> >>> * @implNote >>> .... >>> * a simple {@code npath} is recursively inside a wildcard {@code npath} >>> * if and only if {@code simple_npath.relativize(wildcard_npath)} >>> - * is a series of one or more "..". An invalid {@code FilePermission} does >>> + * is a series of one or more "..". Note that this means "/-" does not >>> + * imply "foo". An invalid {@code FilePermission} does >>> * not imply any object except for itself. >>> >>> The newly added sentence is >>> >>> Note that this means "/-" does not imply "foo". >>> >>> JCK has agreed to update their test. >>> >>> Since this is just a clarification inside an @implNote and no spec is updated, I suppose no CCC is needed. Please confirm. >>> >>> Thanks >>> Max >>> > From christoph.langer at sap.com Thu Dec 22 15:03:46 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 22 Dec 2016 15:03:46 +0000 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build Message-ID: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> Hi, after the fix for 8148023 was pushed, the AIX build is broken. Please review a fix for this: Bug: https://bugs.openjdk.java.net/browse/JDK-8171906 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8171906.0/ The build breaks because NAME_MAX is not defined on AIX (just like Solaris, I guess) and we have to define it in UnixFileSystem_md.c. When working on this fix, I spotted some compiler warnings indicating that if one is working with the APIs readdir64 and friends on AIX, one has to use the type DIR64 instead of DIR and to open/close with opendir64/closedir64. I guess that's specific to AIX, see IBM's documentation [1]. Furthermore, although fdopendir64 is not mentioned there but just fdopendir, both APIs exist from AIX 7.1 onwards (look at on an AIX 7.1). So I added some defines for AIX to redirect the API calls. Thanks and best regards Christoph [1] http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.basetrf1/opendir.htm From goetz.lindenmaier at sap.com Thu Dec 22 15:13:38 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Dec 2016 15:13:38 +0000 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> Message-ID: <945583fc3e434b34810f9d1149caa93e@DEROTE13DE08.global.corp.sap> Hi Christoph, good to get this fixed. As you move the solaris section in UnixFileSystem_md.c, you could move it behind BSD to sort it alphabetically as in other places. Why did you choose to define opendir to opendir64, but not so for fdopendir in UnixNativeDispatcher.c? Looks good otherwise. Best regards, Goetz. > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 22. Dezember 2016 16:04 > To: core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Cc: Brian Burkhalter ; Roger Riggs > ; Volker Simonis ; > Lindenmaier, Goetz > Subject: RFR(S): 8171906: Changes for 8148023 break AIX build > > Hi, > > > > after the fix for 8148023 was pushed, the AIX build is broken. Please review a > fix for this: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171906 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8171906.0/ > > > > The build breaks because NAME_MAX is not defined on AIX (just like Solaris, I > guess) and we have to define it in UnixFileSystem_md.c. > > > > When working on this fix, I spotted some compiler warnings indicating that if > one is working with the APIs readdir64 and friends on AIX, one has to use the > type DIR64 instead of DIR and to open/close with opendir64/closedir64. I guess > that's specific to AIX, see IBM's documentation [1]. > > Furthermore, although fdopendir64 is not mentioned there but just fdopendir, > both APIs exist from AIX 7.1 onwards (look at on an AIX 7.1). So I > added some defines for AIX to redirect the API calls. > > > > Thanks and best regards > > Christoph > > > > [1] > http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.baset > rf1/opendir.htm > > From christoph.langer at sap.com Thu Dec 22 15:19:36 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 22 Dec 2016 15:19:36 +0000 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: <945583fc3e434b34810f9d1149caa93e@DEROTE13DE08.global.corp.sap> References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> <945583fc3e434b34810f9d1149caa93e@DEROTE13DE08.global.corp.sap> Message-ID: Hi Goetz, thanks for your comments. The platform sorting I'm using usually (in libnet) is Linux, AIX, Solaris, BSD. As we are libnio, are there other wishes ore guidelines? As for fdopendir in UnixNativeDispatcher: This function is resolved via dlsym to a function pointer. So I thought it's ok to just load fdopendir64 at dlsym time to the fdopendir ptr and we don't have to have #ifdefs in the function where fdopendir is called. Best regards Christoph > -----Original Message----- > From: Lindenmaier, Goetz > Sent: Donnerstag, 22. Dezember 2016 16:14 > To: Langer, Christoph ; core-libs- > dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Cc: Brian Burkhalter ; Roger Riggs > ; Volker Simonis > Subject: RE: RFR(S): 8171906: Changes for 8148023 break AIX build > > Hi Christoph, > > good to get this fixed. > > As you move the solaris section in UnixFileSystem_md.c, you could move it > behind BSD > to sort it alphabetically as in other places. > > Why did you choose to define opendir to opendir64, but not so for fdopendir in > UnixNativeDispatcher.c? > > Looks good otherwise. > > Best regards, > Goetz. > > > -----Original Message----- > > From: Langer, Christoph > > Sent: Donnerstag, 22. Dezember 2016 16:04 > > To: core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix-port- > > dev at openjdk.java.net > > Cc: Brian Burkhalter ; Roger Riggs > > ; Volker Simonis ; > > Lindenmaier, Goetz > > Subject: RFR(S): 8171906: Changes for 8148023 break AIX build > > > > Hi, > > > > > > > > after the fix for 8148023 was pushed, the AIX build is broken. Please review a > > fix for this: > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171906 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8171906.0/ > > > > > > > > The build breaks because NAME_MAX is not defined on AIX (just like Solaris, I > > guess) and we have to define it in UnixFileSystem_md.c. > > > > > > > > When working on this fix, I spotted some compiler warnings indicating that if > > one is working with the APIs readdir64 and friends on AIX, one has to use the > > type DIR64 instead of DIR and to open/close with opendir64/closedir64. I > guess > > that's specific to AIX, see IBM's documentation [1]. > > > > Furthermore, although fdopendir64 is not mentioned there but just fdopendir, > > both APIs exist from AIX 7.1 onwards (look at on an AIX 7.1). So I > > added some defines for AIX to redirect the API calls. > > > > > > > > Thanks and best regards > > > > Christoph > > > > > > > > [1] > > > http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.baset > > rf1/opendir.htm > > > > From brian.burkhalter at oracle.com Thu Dec 22 15:56:13 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 22 Dec 2016 07:56:13 -0800 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> Message-ID: Sorry about that. There seems to a surprising lack of consistency for this across the platforms. Regards, Brian On Dec 22, 2016, at 7:03 AM, Langer, Christoph wrote: > The build breaks because NAME_MAX is not defined on AIX (just like Solaris, I guess) and we have to define it in UnixFileSystem_md.c. From christoph.langer at sap.com Thu Dec 22 15:58:13 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 22 Dec 2016 15:58:13 +0000 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> Message-ID: <705dabd55d97414696646eaf789c71f0@DEWDFE13DE03.global.corp.sap> Hi Brian, no problem. So, may I consider this reviewed? Thanks Christoph From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] Sent: Donnerstag, 22. Dezember 2016 16:56 To: Langer, Christoph Cc: core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; Roger Riggs ; Volker Simonis ; Lindenmaier, Goetz Subject: Re: RFR(S): 8171906: Changes for 8148023 break AIX build Sorry about that. There seems to a surprising lack of consistency for this across the platforms. Regards, Brian On Dec 22, 2016, at 7:03 AM, Langer, Christoph > wrote: The build breaks because NAME_MAX is not defined on AIX (just like Solaris, I guess) and we have to define it in UnixFileSystem_md.c. From goetz.lindenmaier at sap.com Thu Dec 22 16:03:19 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Thu, 22 Dec 2016 16:03:19 +0000 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> <945583fc3e434b34810f9d1149caa93e@DEROTE13DE08.global.corp.sap> Message-ID: <55ee6ed6a6fb47b491675c4dbe0654b3@DEROTE13DE08.global.corp.sap> Hi Christoph, > -----Original Message----- > From: Langer, Christoph > Sent: Donnerstag, 22. Dezember 2016 16:20 > To: Lindenmaier, Goetz > Cc: Brian Burkhalter ; Roger Riggs > ; Volker Simonis ; > core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net > Subject: RE: RFR(S): 8171906: Changes for 8148023 break AIX build > > Hi Goetz, > > thanks for your comments. > > The platform sorting I'm using usually (in libnet) is Linux, AIX, Solaris, BSD. As > we are libnio, are there other wishes ore guidelines? No, if it is consistent in that component it's fine. > As for fdopendir in UnixNativeDispatcher: This function is resolved via dlsym to > a function pointer. So I thought it's ok to just load fdopendir64 at dlsym time to > the fdopendir ptr and we don't have to have #ifdefs in the function where > fdopendir is called. Oh, right, it's a string anyways ... Looks good. Best, Goetz. > > Best regards > Christoph > > > -----Original Message----- > > From: Lindenmaier, Goetz > > Sent: Donnerstag, 22. Dezember 2016 16:14 > > To: Langer, Christoph ; core-libs- > > dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix-port- > > dev at openjdk.java.net > > Cc: Brian Burkhalter ; Roger Riggs > > ; Volker Simonis > > Subject: RE: RFR(S): 8171906: Changes for 8148023 break AIX build > > > > Hi Christoph, > > > > good to get this fixed. > > > > As you move the solaris section in UnixFileSystem_md.c, you could move it > > behind BSD > > to sort it alphabetically as in other places. > > > > Why did you choose to define opendir to opendir64, but not so for fdopendir > in > > UnixNativeDispatcher.c? > > > > Looks good otherwise. > > > > Best regards, > > Goetz. > > > > > -----Original Message----- > > > From: Langer, Christoph > > > Sent: Donnerstag, 22. Dezember 2016 16:04 > > > To: core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix- > port- > > > dev at openjdk.java.net > > > Cc: Brian Burkhalter ; Roger Riggs > > > ; Volker Simonis ; > > > Lindenmaier, Goetz > > > Subject: RFR(S): 8171906: Changes for 8148023 break AIX build > > > > > > Hi, > > > > > > > > > > > > after the fix for 8148023 was pushed, the AIX build is broken. Please review > a > > > fix for this: > > > > > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171906 > > > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8171906.0/ > > > > > > > > > > > > The build breaks because NAME_MAX is not defined on AIX (just like Solaris, > I > > > guess) and we have to define it in UnixFileSystem_md.c. > > > > > > > > > > > > When working on this fix, I spotted some compiler warnings indicating that > if > > > one is working with the APIs readdir64 and friends on AIX, one has to use > the > > > type DIR64 instead of DIR and to open/close with opendir64/closedir64. I > > guess > > > that's specific to AIX, see IBM's documentation [1]. > > > > > > Furthermore, although fdopendir64 is not mentioned there but just > fdopendir, > > > both APIs exist from AIX 7.1 onwards (look at on an AIX 7.1). So I > > > added some defines for AIX to redirect the API calls. > > > > > > > > > > > > Thanks and best regards > > > > > > Christoph > > > > > > > > > > > > [1] > > > > > > http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.baset > > > rf1/opendir.htm > > > > > > From brian.burkhalter at oracle.com Thu Dec 22 16:27:50 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 22 Dec 2016 08:27:50 -0800 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: <705dabd55d97414696646eaf789c71f0@DEWDFE13DE03.global.corp.sap> References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> <705dabd55d97414696646eaf789c71f0@DEWDFE13DE03.global.corp.sap> Message-ID: <6B2FA4CA-8019-48B2-903D-B523E820AF92@oracle.com> Hi Christoph, It looks OK, but have you built it on the other Unix platforms? If necessary I could run it through our regression suite first. Thanks, Brian On Dec 22, 2016, at 7:58 AM, Langer, Christoph wrote: > no problem. So, may I consider this reviewed? > > From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] > Sorry about that. There seems to a surprising lack of consistency for this across the platforms. From stanislav.smirnov at oracle.com Thu Dec 22 16:55:37 2016 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Thu, 22 Dec 2016 19:55:37 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: References: Message-ID: Hi Dima, changes look good, I will only suggest using lambda?s in couple of iterations + for (String s : tr.testOutput) { + System.out.println(s); + } tr.testOutput.forEach(System.out::println) for (String x : tr.testOutput) { alist.add(x.trim()); } tr.testOutput.stream.map(String::trim).forEach(aList:add) Best regards, Stanislav Smirnov > On 21 Dec 2016, at 17:16, Dmitry Fazunenenko wrote: > > Hello, > > I'm looking for reviews of a relatively simple test change: > http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ > https://bugs.openjdk.java.net/browse/JDK-8171441 > > The purpose of the change is to improve diagnostic. > > Thanks, > Dima > > PS: After the fix the failures will be reported as: > > ----------System.err:(13/956)---------- > java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; > at VersionCheck.main(VersionCheck.java:295) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) > at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) > at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) > at java.base/java.lang.reflect.Method.invoke(Method.java:538) > at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) > at java.base/java.lang.Thread.run(Thread.java:844) > > JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; > JavaTest Message: shutting down test > > STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; > > PPS: The output of passed test now looks like: > > === testJVersionStrings === > Testing servertool > Testing jstat > Testing jmod > Testing jjs > Testing jimage > Testing jlink > Testing jrunscript > Testing jdeprscan > Testing jconsole > Testing rmiregistry > Testing keytool > Testing schemagen > Testing javac > Testing jar > Testing jhsdb > Testing jcmd > Testing jstack > Testing wsgen > Testing jshell > Testing serialver > Testing jmap > Testing javap > Testing jps > Testing jstatd > Testing javadoc > Testing tnameserv > Testing jdb > Testing jinfo > Testing jdeps > Testing xjc > Testing rmid > Testing jarsigner > Testing idlj > Testing rmic > Testing appletviewer > Testing pack200 > Testing javah > Testing policytool > Testing orbd > testJVersionStrings passed > === testInternalStrings === > testInternalStrings passed > === testToolVersion === > Testing java > #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version > java version "9-ea" > Java(TM) SE Runtime Environment (build 9-ea+149) > Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) > #> echo $? > 0 > Testing javac > #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version > javac 9-ea > #> echo $? > 0 > Testing jhsdb > #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version > clhsdb command line debugger > debugd debug server > hsdb ui debugger > jstack --help to get more information > jmap --help to get more information > jinfo --help to get more information > jsnap --help to get more information > #> echo $? > 0 > Testing jshell > #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version > jshell 9-ea > #> echo $? > 0 > Testing javap > #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version > 9-ea > #> echo $? > 0 > Testing jdb > #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version > This is jdb version 9.0 (Java SE version 9-ea) > #> echo $? > 0 > Testing idlj > #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version > IDL-to-Java compiler (portable), version "3.2" > #> echo $? > 0 > Testing javah > #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version > > Warning: The javah tool is planned to be removed in the next major > JDK release. The tool has been superseded by the '-h' option added > to javac in JDK 8. Users are recommended to migrate to using the > javac '-h' option; see the javac man page for more information. > > javah version "9-ea" > #> echo $? > 0 > testToolVersion passed > === testInternalStrings === > testDebugVersion passed > All Version string comparisons: PASS > ----------System.err:(1/15)---------- > From brian.burkhalter at oracle.com Thu Dec 22 17:17:04 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 22 Dec 2016 09:17:04 -0800 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: <6B2FA4CA-8019-48B2-903D-B523E820AF92@oracle.com> References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> <705dabd55d97414696646eaf789c71f0@DEWDFE13DE03.global.corp.sap> <6B2FA4CA-8019-48B2-903D-B523E820AF92@oracle.com> Message-ID: Hi Christoph, I ran this patch through our regression test suite against the NIO tests and it built and passed the test on all platforms (Linux, OS X, Solaris, Windows). So it?s +1 on the review. Thanks, Brian On Dec 22, 2016, at 8:27 AM, Brian Burkhalter wrote: > Hi Christoph, > > It looks OK, but have you built it on the other Unix platforms? If necessary I could run it through our regression suite first. > > Thanks, > > Brian > > On Dec 22, 2016, at 7:58 AM, Langer, Christoph wrote: > >> no problem. So, may I consider this reviewed? >> >> From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] >> Sorry about that. There seems to a surprising lack of consistency for this across the platforms. From christoph.langer at sap.com Thu Dec 22 18:30:12 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Thu, 22 Dec 2016 18:30:12 +0000 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> <705dabd55d97414696646eaf789c71f0@DEWDFE13DE03.global.corp.sap> <6B2FA4CA-8019-48B2-903D-B523E820AF92@oracle.com> Message-ID: <938b0d18ca084c859f60d03c398e4e8d@DEWDFE13DE03.global.corp.sap> Thanks, Brian. I've also added it to our nightly verification run and if all goes well I'll push it tomorrow. Best regards Christoph > -----Original Message----- > From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] > Sent: Donnerstag, 22. Dezember 2016 18:17 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; ppc-aix-port-dev at openjdk.java.net; nio- > dev at openjdk.java.net > Subject: Re: RFR(S): 8171906: Changes for 8148023 break AIX build > > Hi Christoph, > > I ran this patch through our regression test suite against the NIO tests and it > built and passed the test on all platforms (Linux, OS X, Solaris, Windows). So it's > +1 on the review. > > Thanks, > > Brian > > On Dec 22, 2016, at 8:27 AM, Brian Burkhalter > wrote: > > > Hi Christoph, > > > > It looks OK, but have you built it on the other Unix platforms? If necessary I > could run it through our regression suite first. > > > > Thanks, > > > > Brian > > > > On Dec 22, 2016, at 7:58 AM, Langer, Christoph > wrote: > > > >> no problem. So, may I consider this reviewed? > >> > >> From: Brian Burkhalter [mailto:brian.burkhalter at oracle.com] > >> Sorry about that. There seems to a surprising lack of consistency for this > across the platforms. From brian.burkhalter at oracle.com Thu Dec 22 18:35:17 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Thu, 22 Dec 2016 10:35:17 -0800 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: <938b0d18ca084c859f60d03c398e4e8d@DEWDFE13DE03.global.corp.sap> References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> <705dabd55d97414696646eaf789c71f0@DEWDFE13DE03.global.corp.sap> <6B2FA4CA-8019-48B2-903D-B523E820AF92@oracle.com> <938b0d18ca084c859f60d03c398e4e8d@DEWDFE13DE03.global.corp.sap> Message-ID: <6A656790-74E5-4376-A3D8-4A9B2271E767@oracle.com> Hi Christoph, On Dec 22, 2016, at 10:30 AM, Langer, Christoph wrote: > Thanks, Brian. You?re welcome. > I've also added it to our nightly verification run and if all goes well I'll push it tomorrow. Sounds good. Best regards, Brian From abhijit.r.roy at oracle.com Thu Dec 22 19:26:39 2016 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Fri, 23 Dec 2016 00:56:39 +0530 Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' In-Reply-To: <407bb2be-5926-7732-e6fc-c4785dac7e2f@oracle.com> References: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> <196d5a53-dc3b-0ba4-67b9-ce2fda1610fe@Oracle.com> <353a2b2d-032f-320e-6305-6248946fc32a@oracle.com> <407bb2be-5926-7732-e6fc-c4785dac7e2f@oracle.com> Message-ID: Hi Roger, Ivan, Already done. Please see the JDK below. https://bugs.openjdk.java.net/browse/JDK-8169482 Thanks Abhijit On 12/21/2016 7:53 PM, Roger Riggs wrote: > Hi Abhijit, > > Looks fine to push with this additional change to make the > descriptions of 'F' match. > > Thanks, Roger > > > On 12/21/16 7:16 AM, Ivan Gerasimov wrote: >> Hi Abhijt! >> >> As you're changing the description of 'F' pattern in >> DateTimeFormatterBuilder, it makes sense to do the same in >> DateTimeFormatter. >> >> With kind regards, >> Ivan >> >> >> On 21.12.2016 9:30, Abhijit Roy wrote: >>> Hi Roger, >>> >>> I have fixed the same error in DateTimeFormatterBuiler. Please see >>> the updated webrev below. >>> >>> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.01/ >>> >>> Thanks >>> Abhijit >>> >>> >>> On 12/16/2016 8:01 PM, Roger Riggs wrote: >>>> Hi, >>>> >>>> Sorry, I meant DateTimeFormatterBuilder. >>>> >>>> Roger >>>> >>>> >>>> On 12/16/2016 9:28 AM, Roger Riggs wrote: >>>>> Hi Abhijit, >>>>> >>>>> Please also fix the same error in DateTimeFormatter; line 300. >>>>> >>>>> I would use '24' as the example of the hour of day. >>>>> It would emphasize that the range is 1-24. >>>>> >>>>> Roger >>>>> >>>>> >>>>> On 12/16/2016 6:19 AM, Abhijit Roy wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> Please review the java doc fix for the below bug: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 >>>>>> >>>>>> Description: Incorrect documentation for DateTimeFormatter letter >>>>>> 'k' >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ >>>>>> >>>>>> >>>>>> I have just rectified and modified those errors. And moving >>>>>> forward it for review. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Abhijit >>>>>> >>>>>> >>>>>> >>>>>> P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, >>>>>> JDK-8169482, JDK-8170653 >>>>> >>>> >>> >>> >> > From amy.lu at oracle.com Fri Dec 23 00:54:46 2016 From: amy.lu at oracle.com (Amy Lu) Date: Fri, 23 Dec 2016 08:54:46 +0800 Subject: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64 In-Reply-To: References: <20533121-1ea0-e372-7504-ae946ce522b5@oracle.com> <2e1b9908-dfa8-bfae-2c21-acb62efb85af@oracle.com> <8C39D6AB-BEBE-4EF9-8F49-5E5B71733B74@oracle.com> Message-ID: <6cac2594-9f40-bb1a-a8c0-7bccf8c57370@oracle.com> On 12/20/16 8:04 PM, Wang Weijun wrote: >> For the failing case, the first time it calls checkNames, the "ans" (the 3rd arg) is "current working dir" (/path/scratch/1). > Is it possible to use ./tmp as "ans"? > > --Max > Yes, good idea. Please review the updated webrev to make the data one level deeper: http://cr.openjdk.java.net/~amlu/8156595/webrev.02/ Thanks, Amy From dmitry.fazunenko at oracle.com Fri Dec 23 08:55:28 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenko) Date: Fri, 23 Dec 2016 11:55:28 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: References: Message-ID: Hi Stanislav, Thanks for looking. Updated webrev: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ -- Dima On 22.12.2016 19:55, Stanislav Smirnov wrote: > Hi Dima, > > changes look good, I will only suggest using lambda?s in couple of > iterations > + for (String s : tr.testOutput) { > + System.out.println(s); > + } > tr.testOutput.forEach(System.out::println) > > for (String x : tr.testOutput) { > alist.add(x.trim()); > } > tr.testOutput.stream.map(String::trim).forEach(aList:add) > > > Best regards, > Stanislav Smirnov > > > > > >> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko >> > wrote: >> >> Hello, >> >> I'm looking for reviews of a relatively simple test change: >> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >> >> https://bugs.openjdk.java.net/browse/JDK-8171441 >> >> The purpose of the change is to improve diagnostic. >> >> Thanks, >> Dima >> >> PS: After the fix the failures will be reported as: >> >> ----------System.err:(13/956)---------- >> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: >> [java]; testToolVersion: [jar]; >> at VersionCheck.main(VersionCheck.java:295) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >> Method) >> at >> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >> at >> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >> at >> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >> at java.base/java.lang.Thread.run(Thread.java:844) >> >> JavaTest Message: Test threw exception: java.lang.AssertionError: >> VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >> JavaTest Message: shutting down test >> >> STATUS:Failed.`main' threw exception: java.lang.AssertionError: >> VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >> >> PPS: The output of passed test now looks like: >> >> === testJVersionStrings === >> Testing servertool >> Testing jstat >> Testing jmod >> Testing jjs >> Testing jimage >> Testing jlink >> Testing jrunscript >> Testing jdeprscan >> Testing jconsole >> Testing rmiregistry >> Testing keytool >> Testing schemagen >> Testing javac >> Testing jar >> Testing jhsdb >> Testing jcmd >> Testing jstack >> Testing wsgen >> Testing jshell >> Testing serialver >> Testing jmap >> Testing javap >> Testing jps >> Testing jstatd >> Testing javadoc >> Testing tnameserv >> Testing jdb >> Testing jinfo >> Testing jdeps >> Testing xjc >> Testing rmid >> Testing jarsigner >> Testing idlj >> Testing rmic >> Testing appletviewer >> Testing pack200 >> Testing javah >> Testing policytool >> Testing orbd >> testJVersionStrings passed >> === testInternalStrings === >> testInternalStrings passed >> === testToolVersion === >> Testing java >> #> >> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java >> >> -version >> java version "9-ea" >> Java(TM) SE Runtime Environment (build 9-ea+149) >> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >> #> echo $? >> 0 >> Testing javac >> #> >> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac >> >> -version >> javac 9-ea >> #> echo $? >> 0 >> Testing jhsdb >> #> >> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb >> >> -version >> clhsdb command line debugger >> debugd debug server >> hsdb ui debugger >> jstack --help to get more information >> jmap --help to get more information >> jinfo --help to get more information >> jsnap --help to get more information >> #> echo $? >> 0 >> Testing jshell >> #> >> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell >> >> -version >> jshell 9-ea >> #> echo $? >> 0 >> Testing javap >> #> >> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap >> >> -version >> 9-ea >> #> echo $? >> 0 >> Testing jdb >> #> >> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb >> >> -version >> This is jdb version 9.0 (Java SE version 9-ea) >> #> echo $? >> 0 >> Testing idlj >> #> >> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj >> >> -version >> IDL-to-Java compiler (portable), version "3.2" >> #> echo $? >> 0 >> Testing javah >> #> >> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah >> >> -version >> >> Warning: The javah tool is planned to be removed in the next major >> JDK release. The tool has been superseded by the '-h' option added >> to javac in JDK 8. Users are recommended to migrate to using the >> javac '-h' option; see the javac man page for more information. >> >> javah version "9-ea" >> #> echo $? >> 0 >> testToolVersion passed >> === testInternalStrings === >> testDebugVersion passed >> All Version string comparisons: PASS >> ----------System.err:(1/15)---------- >> > From stanislav.smirnov at oracle.com Fri Dec 23 10:40:16 2016 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Fri, 23 Dec 2016 13:40:16 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: References: Message-ID: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> Hi, sorry, missed this strange comment during the first review. 152 /* 153 * this tests if the tool can take a version string and returns 154 * a 0 exit code, it is not possible to validate the contents 155 * of the -version output as they are inconsistent. 156 */ 157 static String testToolVersion() { It confuses me, can you please rephrase it? Best regards, Stanislav Smirnov > On 23 Dec 2016, at 11:55, Dmitry Fazunenko wrote: > > Hi Stanislav, > > Thanks for looking. > Updated webrev: > http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ > > -- Dima > > > On 22.12.2016 19:55, Stanislav Smirnov wrote: >> Hi Dima, >> >> changes look good, I will only suggest using lambda?s in couple of iterations >> + for (String s : tr.testOutput) { >> + System.out.println(s); >> + } >> tr.testOutput.forEach(System.out::println) >> >> for (String x : tr.testOutput) { >> alist.add(x.trim()); >> } >> tr.testOutput.stream.map(String::trim).forEach(aList:add) >> >> >> Best regards, >> Stanislav Smirnov >> >> >> >> >> >>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko > wrote: >>> >>> Hello, >>> >>> I'm looking for reviews of a relatively simple test change: >>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>> >>> The purpose of the change is to improve diagnostic. >>> >>> Thanks, >>> Dima >>> >>> PS: After the fix the failures will be reported as: >>> >>> ----------System.err:(13/956)---------- >>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>> at VersionCheck.main(VersionCheck.java:295) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>> at java.base/java.lang.Thread.run(Thread.java:844) >>> >>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>> JavaTest Message: shutting down test >>> >>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>> >>> PPS: The output of passed test now looks like: >>> >>> === testJVersionStrings === >>> Testing servertool >>> Testing jstat >>> Testing jmod >>> Testing jjs >>> Testing jimage >>> Testing jlink >>> Testing jrunscript >>> Testing jdeprscan >>> Testing jconsole >>> Testing rmiregistry >>> Testing keytool >>> Testing schemagen >>> Testing javac >>> Testing jar >>> Testing jhsdb >>> Testing jcmd >>> Testing jstack >>> Testing wsgen >>> Testing jshell >>> Testing serialver >>> Testing jmap >>> Testing javap >>> Testing jps >>> Testing jstatd >>> Testing javadoc >>> Testing tnameserv >>> Testing jdb >>> Testing jinfo >>> Testing jdeps >>> Testing xjc >>> Testing rmid >>> Testing jarsigner >>> Testing idlj >>> Testing rmic >>> Testing appletviewer >>> Testing pack200 >>> Testing javah >>> Testing policytool >>> Testing orbd >>> testJVersionStrings passed >>> === testInternalStrings === >>> testInternalStrings passed >>> === testToolVersion === >>> Testing java >>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version >>> java version "9-ea" >>> Java(TM) SE Runtime Environment (build 9-ea+149) >>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>> #> echo $? >>> 0 >>> Testing javac >>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version >>> javac 9-ea >>> #> echo $? >>> 0 >>> Testing jhsdb >>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version >>> clhsdb command line debugger >>> debugd debug server >>> hsdb ui debugger >>> jstack --help to get more information >>> jmap --help to get more information >>> jinfo --help to get more information >>> jsnap --help to get more information >>> #> echo $? >>> 0 >>> Testing jshell >>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version >>> jshell 9-ea >>> #> echo $? >>> 0 >>> Testing javap >>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version >>> 9-ea >>> #> echo $? >>> 0 >>> Testing jdb >>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version >>> This is jdb version 9.0 (Java SE version 9-ea) >>> #> echo $? >>> 0 >>> Testing idlj >>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version >>> IDL-to-Java compiler (portable), version "3.2" >>> #> echo $? >>> 0 >>> Testing javah >>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version >>> >>> Warning: The javah tool is planned to be removed in the next major >>> JDK release. The tool has been superseded by the '-h' option added >>> to javac in JDK 8. Users are recommended to migrate to using the >>> javac '-h' option; see the javac man page for more information. >>> >>> javah version "9-ea" >>> #> echo $? >>> 0 >>> testToolVersion passed >>> === testInternalStrings === >>> testDebugVersion passed >>> All Version string comparisons: PASS >>> ----------System.err:(1/15)---------- >>> >> > From volker.simonis at gmail.com Fri Dec 23 10:46:18 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Fri, 23 Dec 2016 11:46:18 +0100 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> Message-ID: On Thu, Dec 22, 2016 at 4:03 PM, Langer, Christoph wrote: > Hi, > > > > after the fix for 8148023 was pushed, the AIX build is broken. Please review > a fix for this: > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171906 > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8171906.0/ > > > > The build breaks because NAME_MAX is not defined on AIX (just like Solaris, > I guess) and we have to define it in UnixFileSystem_md.c. > > > > When working on this fix, I spotted some compiler warnings indicating that > if one is working with the APIs readdir64 and friends on AIX, one has to use > the type DIR64 instead of DIR and to open/close with opendir64/closedir64. I > guess that?s specific to AIX, see IBM?s documentation [1]. > > Furthermore, although fdopendir64 is not mentioned there but just fdopendir, > both APIs exist from AIX 7.1 onwards (look at on an AIX 7.1). So > I added some defines for AIX to redirect the API calls. > Not sure if we've already agreed to only support AIX 7.1 and higher with Java 9. If yes, the change is fine, otherwise we may check the result of dlsym(RTLD_DEFAULT, "fdopendir64") and fallback to dlsym(RTLD_DEFAULT, "fdopendir") if the former is NULL. Regards, Volker > > > Thanks and best regards > > Christoph > > > > [1] > http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.basetrf1/opendir.htm > > From christoph.langer at sap.com Fri Dec 23 11:11:04 2016 From: christoph.langer at sap.com (Langer, Christoph) Date: Fri, 23 Dec 2016 11:11:04 +0000 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> Message-ID: <3db6b0c8f0ca4f78bcb8b1d8a6fa182f@DEWDFE13DE03.global.corp.sap> Hi Volker, I think this is no concern. Either both, fdopendir and fdopendir64, exist (in AIX 7.1) or none (earlier AIX releases). And the code can live with both situations, as the functions are dynamically loaded and these capabilities are registered at runtime. Best regards Christoph > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Freitag, 23. Dezember 2016 11:46 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net; Brian Burkhalter ; > Roger Riggs ; Lindenmaier, Goetz > > Subject: Re: RFR(S): 8171906: Changes for 8148023 break AIX build > > On Thu, Dec 22, 2016 at 4:03 PM, Langer, Christoph > wrote: > > Hi, > > > > > > > > after the fix for 8148023 was pushed, the AIX build is broken. Please review > > a fix for this: > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171906 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8171906.0/ > > > > > > > > The build breaks because NAME_MAX is not defined on AIX (just like Solaris, > > I guess) and we have to define it in UnixFileSystem_md.c. > > > > > > > > When working on this fix, I spotted some compiler warnings indicating that > > if one is working with the APIs readdir64 and friends on AIX, one has to use > > the type DIR64 instead of DIR and to open/close with opendir64/closedir64. I > > guess that?s specific to AIX, see IBM?s documentation [1]. > > > > Furthermore, although fdopendir64 is not mentioned there but just fdopendir, > > both APIs exist from AIX 7.1 onwards (look at on an AIX 7.1). So > > I added some defines for AIX to redirect the API calls. > > > > Not sure if we've already agreed to only support AIX 7.1 and higher with Java 9. > If yes, the change is fine, otherwise we may check the result of > dlsym(RTLD_DEFAULT, "fdopendir64") and fallback to dlsym(RTLD_DEFAULT, > "fdopendir") if the former is NULL. > > Regards, > Volker > > > > > > > Thanks and best regards > > > > Christoph > > > > > > > > [1] > > > http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.baset > rf1/opendir.htm > > > > From goetz.lindenmaier at sap.com Fri Dec 23 11:58:07 2016 From: goetz.lindenmaier at sap.com (Lindenmaier, Goetz) Date: Fri, 23 Dec 2016 11:58:07 +0000 Subject: RFR(S): 8171906: Changes for 8148023 break AIX build In-Reply-To: References: <755e6067958e41feb8b06600d3f60fea@DEWDFE13DE03.global.corp.sap> Message-ID: <6f36a0b2e14b42058b4b7407a437895d@DEROTE13DE08.global.corp.sap> Hi, we support aix 6.1 / xlc12 with openjdk 9. Best regards, Goetz. > -----Original Message----- > From: Volker Simonis [mailto:volker.simonis at gmail.com] > Sent: Freitag, 23. Dezember 2016 11:46 > To: Langer, Christoph > Cc: core-libs-dev at openjdk.java.net; nio-dev at openjdk.java.net; ppc-aix-port- > dev at openjdk.java.net; Brian Burkhalter ; > Roger Riggs ; Lindenmaier, Goetz > > Subject: Re: RFR(S): 8171906: Changes for 8148023 break AIX build > > On Thu, Dec 22, 2016 at 4:03 PM, Langer, Christoph > wrote: > > Hi, > > > > > > > > after the fix for 8148023 was pushed, the AIX build is broken. Please review > > a fix for this: > > > > > > > > Bug: https://bugs.openjdk.java.net/browse/JDK-8171906 > > > > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8171906.0/ > > > > > > > > The build breaks because NAME_MAX is not defined on AIX (just like Solaris, > > I guess) and we have to define it in UnixFileSystem_md.c. > > > > > > > > When working on this fix, I spotted some compiler warnings indicating that > > if one is working with the APIs readdir64 and friends on AIX, one has to use > > the type DIR64 instead of DIR and to open/close with opendir64/closedir64. I > > guess that?s specific to AIX, see IBM?s documentation [1]. > > > > Furthermore, although fdopendir64 is not mentioned there but just fdopendir, > > both APIs exist from AIX 7.1 onwards (look at on an AIX 7.1). So > > I added some defines for AIX to redirect the API calls. > > > > Not sure if we've already agreed to only support AIX 7.1 and higher with Java 9. > If yes, the change is fine, otherwise we may check the result of > dlsym(RTLD_DEFAULT, "fdopendir64") and fallback to dlsym(RTLD_DEFAULT, > "fdopendir") if the former is NULL. > > Regards, > Volker > > > > > > > Thanks and best regards > > > > Christoph > > > > > > > > [1] > > > http://www.ibm.com/support/knowledgecenter/ssw_aix_71/com.ibm.aix.baset > rf1/opendir.htm > > > > From dmitry.fazunenko at oracle.com Fri Dec 23 16:13:35 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko) Date: Fri, 23 Dec 2016 19:13:35 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> Message-ID: <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> Hi, new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ This comment now looks like: 152 /* 153 * Checks if the tools accept "-version" option (exit code is zero). 154 * The output of the tools run with "-version" is not verified. 155 */ Thanks Dima On 23.12.2016 13:40, Stanislav Smirnov wrote: > Hi, > > sorry, missed this strange comment during the first review. > 152 /* > 153 * this tests if the tool can take a version string and returns > 154 * a 0 exit code, it is not possible to validate the contents > 155 * of the -version output as they are inconsistent. > 156 */ > 157 static String testToolVersion() { > It confuses me, can you please rephrase it? > > Best regards, > Stanislav Smirnov > > > > > >> On 23 Dec 2016, at 11:55, Dmitry Fazunenko >> > wrote: >> >> Hi Stanislav, >> >> Thanks for looking. >> Updated webrev: >> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >> >> -- Dima >> >> >> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>> Hi Dima, >>> >>> changes look good, I will only suggest using lambda?s in couple of >>> iterations >>> + for (String s : tr.testOutput) { >>> + System.out.println(s); >>> + } >>> tr.testOutput.forEach(System.out::println) >>> >>> for (String x : tr.testOutput) { >>> alist.add(x.trim()); >>> } >>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>> >>> >>> Best regards, >>> Stanislav Smirnov >>> >>> >>> >>> >>> >>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko >>>> > >>>> wrote: >>>> >>>> Hello, >>>> >>>> I'm looking for reviews of a relatively simple test change: >>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>> >>>> The purpose of the change is to improve diagnostic. >>>> >>>> Thanks, >>>> Dima >>>> >>>> PS: After the fix the failures will be reported as: >>>> >>>> ----------System.err:(13/956)---------- >>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: >>>> [java]; testToolVersion: [jar]; >>>> at VersionCheck.main(VersionCheck.java:295) >>>> at >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>> Method) >>>> at >>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>> at >>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>> at >>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>> >>>> JavaTest Message: Test threw exception: java.lang.AssertionError: >>>> VersionCheck failed: testJVersionStrings: [java]; testToolVersion: >>>> [jar]; >>>> JavaTest Message: shutting down test >>>> >>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: >>>> VersionCheck failed: testJVersionStrings: [java]; testToolVersion: >>>> [jar]; >>>> >>>> PPS: The output of passed test now looks like: >>>> >>>> === testJVersionStrings === >>>> Testing servertool >>>> Testing jstat >>>> Testing jmod >>>> Testing jjs >>>> Testing jimage >>>> Testing jlink >>>> Testing jrunscript >>>> Testing jdeprscan >>>> Testing jconsole >>>> Testing rmiregistry >>>> Testing keytool >>>> Testing schemagen >>>> Testing javac >>>> Testing jar >>>> Testing jhsdb >>>> Testing jcmd >>>> Testing jstack >>>> Testing wsgen >>>> Testing jshell >>>> Testing serialver >>>> Testing jmap >>>> Testing javap >>>> Testing jps >>>> Testing jstatd >>>> Testing javadoc >>>> Testing tnameserv >>>> Testing jdb >>>> Testing jinfo >>>> Testing jdeps >>>> Testing xjc >>>> Testing rmid >>>> Testing jarsigner >>>> Testing idlj >>>> Testing rmic >>>> Testing appletviewer >>>> Testing pack200 >>>> Testing javah >>>> Testing policytool >>>> Testing orbd >>>> testJVersionStrings passed >>>> === testInternalStrings === >>>> testInternalStrings passed >>>> === testToolVersion === >>>> Testing java >>>> #> >>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java >>>> >>>> -version >>>> java version "9-ea" >>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>> #> echo $? >>>> 0 >>>> Testing javac >>>> #> >>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac >>>> >>>> -version >>>> javac 9-ea >>>> #> echo $? >>>> 0 >>>> Testing jhsdb >>>> #> >>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb >>>> >>>> -version >>>> clhsdb command line debugger >>>> debugd debug server >>>> hsdb ui debugger >>>> jstack --help to get more information >>>> jmap --help to get more information >>>> jinfo --help to get more information >>>> jsnap --help to get more information >>>> #> echo $? >>>> 0 >>>> Testing jshell >>>> #> >>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell >>>> >>>> -version >>>> jshell 9-ea >>>> #> echo $? >>>> 0 >>>> Testing javap >>>> #> >>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap >>>> >>>> -version >>>> 9-ea >>>> #> echo $? >>>> 0 >>>> Testing jdb >>>> #> >>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb >>>> >>>> -version >>>> This is jdb version 9.0 (Java SE version 9-ea) >>>> #> echo $? >>>> 0 >>>> Testing idlj >>>> #> >>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj >>>> >>>> -version >>>> IDL-to-Java compiler (portable), version "3.2" >>>> #> echo $? >>>> 0 >>>> Testing javah >>>> #> >>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah >>>> >>>> -version >>>> >>>> Warning: The javah tool is planned to be removed in the next major >>>> JDK release. The tool has been superseded by the '-h' option added >>>> to javac in JDK 8. Users are recommended to migrate to using the >>>> javac '-h' option; see the javac man page for more information. >>>> >>>> javah version "9-ea" >>>> #> echo $? >>>> 0 >>>> testToolVersion passed >>>> === testInternalStrings === >>>> testDebugVersion passed >>>> All Version string comparisons: PASS >>>> ----------System.err:(1/15)---------- >>>> >>> >> > From Roger.Riggs at Oracle.com Fri Dec 23 18:10:03 2016 From: Roger.Riggs at Oracle.com (Roger Riggs) Date: Fri, 23 Dec 2016 13:10:03 -0500 Subject: RFR 9: 8171940 Incorrect statement about an absolute value of months unit after period's normalization Message-ID: <7c734498-4b9b-0f5e-57f5-60bb03190dd9@Oracle.com> Please review a simple javadoc fix for normalizing java.time.Period. Merry Christmas, Happy Hanukkah and a Happy New Year. Inline Patch: --- old/src/java.base/share/classes/java/time/Period.java 2016-12-23 13:06:04.345840617 -0500 +++ new/src/java.base/share/classes/java/time/Period.java 2016-12-23 13:06:04.081840617 -0500 @@ -1,5 +1,5 @@ /* - * Copyright (c) 2012, 2013, Oracle and/or its affiliates. All rights reserved. + * Copyright (c) 2012, 2016, Oracle and/or its affiliates. All rights reserved. * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. * * This code is free software; you can redistribute it and/or modify it @@ -818,7 +818,7 @@ * Returns a copy of this period with the years and months normalized. *

      * This normalizes the years and months units, leaving the days unit unchanged. - * The months unit is adjusted to have an absolute value less than 11, + * The months unit is adjusted to have an absolute value less than 12, * with the years unit being adjusted to compensate. For example, a period of * "1 Year and 15 months" will be normalized to "2 years and 3 months". *

      Thanks, Roger p.s. Webrev: http://cr.openjdk.java.net/~rriggs/webrev-period-doc-8171940/ From brian.burkhalter at oracle.com Fri Dec 23 18:39:51 2016 From: brian.burkhalter at oracle.com (Brian Burkhalter) Date: Fri, 23 Dec 2016 10:39:51 -0800 Subject: RFR 9: 8171940 Incorrect statement about an absolute value of months unit after period's normalization In-Reply-To: <7c734498-4b9b-0f5e-57f5-60bb03190dd9@Oracle.com> References: <7c734498-4b9b-0f5e-57f5-60bb03190dd9@Oracle.com> Message-ID: <1042A030-C024-4878-BECD-4F0CA6312CCD@oracle.com> Hi Roger, On Dec 23, 2016, at 10:10 AM, Roger Riggs wrote: > Please review a simple javadoc fix for normalizing java.time.Period. +1 > Merry Christmas, Happy Hanukkah and a Happy New Year. Happy Holidays! Brian From huaming.li at oracle.com Mon Dec 26 08:51:04 2016 From: huaming.li at oracle.com (Hamlin Li) Date: Mon, 26 Dec 2016 16:51:04 +0800 Subject: RFR of JDK-8030175: java/rmi/registry/altSecurityManager/AltSecurityManager.java fails due to timeout Message-ID: <3a343d7a-6c83-4cf4-592d-5c7d52ac3423@oracle.com> Would you please review the below patches? bug: https://bugs.openjdk.java.net/browse/JDK-8030175 webrev (version A): http://cr.openjdk.java.net/~mli/8030175/webrev.00/ webrev (version B): http://cr.openjdk.java.net/~mli/8030175/webrev.sun.rmi.registry.RegistryImpl.00/ There are 2 versions to be reviewed. In version A, just use RegistryRunner to replace rmiregistry. In version B, refactor sun.rmi.registry.RegistryImpl to improve the testability of RMI code, and create/use RMIRegistryRunner to simulate rmiregistry. Thank you -Hamlin From peter.levart at gmail.com Mon Dec 26 09:35:31 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 26 Dec 2016 10:35:31 +0100 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: References: Message-ID: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> Hi Jeff, I've been told that the latest change I pushed causes some tests to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ From the stacktrace of the bug report, it seems an early initialization issue with VarHandle(s) involved. Can you shed some light into what tests are failing? But first let us backout that change. Regards, Peter On 12/26/2016 10:09 AM, Peter Levart wrote: > Hi Jeff, > > I'm taking a look at this... > > Regards, Peter > > On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >> Hi Peter - >> >> I just received mail from out SQE manager, saying that your last changeset has caused our test harness to hiccup. I don?t have much more detail besides the below bug, but I?m wondering if you could do us a huge favor and roll your change back for now while it?s debugged (and so we can get our automated tests going again). >> >> https://bugs.openjdk.java.net/browse/JDK-8171988 >> >> thanks! >> >> -jeff >> > From chris.hegarty at oracle.com Mon Dec 26 09:58:49 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 26 Dec 2016 09:58:49 +0000 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> References: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> Message-ID: <98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com> > On 26 Dec 2016, at 09:35, Peter Levart wrote: > > Hi Jeff, > > I've been told that the latest change I pushed causes some tests to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ I just grabbed the webrev patch, applied it to a local repo, then compared that against a repo that had been updated to the change prior to your push. They are identical, so this appears to be an accurate anti-delta. Maybe file a new bug, or just make it clear in the synopsis of 8171988 that it is an anti-delta. > From the stacktrace of the bug report, it seems an early initialization issue with VarHandle(s) involved. Can you shed some light into what tests are failing? I?ll post a few comments in 8171988 with sample failures. -Chris. > But first let us backout that change. > > Regards, Peter > > On 12/26/2016 10:09 AM, Peter Levart wrote: >> Hi Jeff, >> >> I'm taking a look at this... >> >> Regards, Peter >> >> On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >>> Hi Peter - >>> >>> I just received mail from out SQE manager, saying that your last changeset has caused our test harness to hiccup. I don?t have much more detail besides the below bug, but I?m wondering if you could do us a huge favor and roll your change back for now while it?s debugged (and so we can get our automated tests going again). >>> >>> https://bugs.openjdk.java.net/browse/JDK-8171988 >>> >>> thanks! >>> >>> -jeff >>> >> > From matcdac at gmail.com Mon Dec 26 12:23:53 2016 From: matcdac at gmail.com (Prakhar Makhija) Date: Mon, 26 Dec 2016 17:53:53 +0530 Subject: Need info regarding Java Source Code Message-ID: Hi, Can anyone please tell me from where I can find and download/clone : 1) The source code of Java, of various releases. 2) The Java code of all JDK and it's various libraries. Looking forward to hear from you. From forax at univ-mlv.fr Mon Dec 26 12:46:25 2016 From: forax at univ-mlv.fr (Remi Forax) Date: Mon, 26 Dec 2016 12:46:25 +0000 Subject: Need info regarding Java Source Code In-Reply-To: References: Message-ID: Hi Prakhar, Java is the name of the spec but if you look for the source of the OpenJDK, everything is here http://hg.openjdk.java.net/ How to download the source http://openjdk.java.net/install/index.html Remi On December 26, 2016 1:23:53 PM GMT+01:00, Prakhar Makhija wrote: >Hi, > >Can anyone please tell me from where I can find and download/clone : > >1) The source code of Java, of various releases. > >2) The Java code of all JDK and it's various libraries. > >Looking forward to hear from you. -- Sent from my Android device with K-9 Mail. Please excuse my brevity. From stanislav.smirnov at oracle.com Mon Dec 26 14:40:58 2016 From: stanislav.smirnov at oracle.com (Stanislav Smirnov) Date: Mon, 26 Dec 2016 17:40:58 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> Message-ID: <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com> Hi, thanks, looks good Best regards, Stanislav Smirnov > On 23 Dec 2016, at 19:13, Dmitry Fazunenenko wrote: > > Hi, > > new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ > > This comment now looks like: > 152 /* > 153 * Checks if the tools accept "-version" option (exit code is zero). > 154 * The output of the tools run with "-version" is not verified. > 155 */ > > Thanks > Dima > > On 23.12.2016 13:40, Stanislav Smirnov wrote: >> Hi, >> >> sorry, missed this strange comment during the first review. >> 152 /* >> 153 * this tests if the tool can take a version string and returns >> 154 * a 0 exit code, it is not possible to validate the contents >> 155 * of the -version output as they are inconsistent. >> 156 */ >> 157 static String testToolVersion() { >> It confuses me, can you please rephrase it? >> >> Best regards, >> Stanislav Smirnov >> >> >> >> >> >>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko > wrote: >>> >>> Hi Stanislav, >>> >>> Thanks for looking. >>> Updated webrev: >>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >>> >>> -- Dima >>> >>> >>> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>>> Hi Dima, >>>> >>>> changes look good, I will only suggest using lambda?s in couple of iterations >>>> + for (String s : tr.testOutput) { >>>> + System.out.println(s); >>>> + } >>>> tr.testOutput.forEach(System.out::println) >>>> >>>> for (String x : tr.testOutput) { >>>> alist.add(x.trim()); >>>> } >>>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>>> >>>> >>>> Best regards, >>>> Stanislav Smirnov >>>> >>>> >>>> >>>> >>>> >>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko > wrote: >>>>> >>>>> Hello, >>>>> >>>>> I'm looking for reviews of a relatively simple test change: >>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>>> >>>>> The purpose of the change is to improve diagnostic. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> PS: After the fix the failures will be reported as: >>>>> >>>>> ----------System.err:(13/956)---------- >>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>> at VersionCheck.main(VersionCheck.java:295) >>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>> >>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>> JavaTest Message: shutting down test >>>>> >>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>> >>>>> PPS: The output of passed test now looks like: >>>>> >>>>> === testJVersionStrings === >>>>> Testing servertool >>>>> Testing jstat >>>>> Testing jmod >>>>> Testing jjs >>>>> Testing jimage >>>>> Testing jlink >>>>> Testing jrunscript >>>>> Testing jdeprscan >>>>> Testing jconsole >>>>> Testing rmiregistry >>>>> Testing keytool >>>>> Testing schemagen >>>>> Testing javac >>>>> Testing jar >>>>> Testing jhsdb >>>>> Testing jcmd >>>>> Testing jstack >>>>> Testing wsgen >>>>> Testing jshell >>>>> Testing serialver >>>>> Testing jmap >>>>> Testing javap >>>>> Testing jps >>>>> Testing jstatd >>>>> Testing javadoc >>>>> Testing tnameserv >>>>> Testing jdb >>>>> Testing jinfo >>>>> Testing jdeps >>>>> Testing xjc >>>>> Testing rmid >>>>> Testing jarsigner >>>>> Testing idlj >>>>> Testing rmic >>>>> Testing appletviewer >>>>> Testing pack200 >>>>> Testing javah >>>>> Testing policytool >>>>> Testing orbd >>>>> testJVersionStrings passed >>>>> === testInternalStrings === >>>>> testInternalStrings passed >>>>> === testToolVersion === >>>>> Testing java >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version >>>>> java version "9-ea" >>>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>>> #> echo $? >>>>> 0 >>>>> Testing javac >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version >>>>> javac 9-ea >>>>> #> echo $? >>>>> 0 >>>>> Testing jhsdb >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version >>>>> clhsdb command line debugger >>>>> debugd debug server >>>>> hsdb ui debugger >>>>> jstack --help to get more information >>>>> jmap --help to get more information >>>>> jinfo --help to get more information >>>>> jsnap --help to get more information >>>>> #> echo $? >>>>> 0 >>>>> Testing jshell >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version >>>>> jshell 9-ea >>>>> #> echo $? >>>>> 0 >>>>> Testing javap >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version >>>>> 9-ea >>>>> #> echo $? >>>>> 0 >>>>> Testing jdb >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version >>>>> This is jdb version 9.0 (Java SE version 9-ea) >>>>> #> echo $? >>>>> 0 >>>>> Testing idlj >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version >>>>> IDL-to-Java compiler (portable), version "3.2" >>>>> #> echo $? >>>>> 0 >>>>> Testing javah >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version >>>>> >>>>> Warning: The javah tool is planned to be removed in the next major >>>>> JDK release. The tool has been superseded by the '-h' option added >>>>> to javac in JDK 8. Users are recommended to migrate to using the >>>>> javac '-h' option; see the javac man page for more information. >>>>> >>>>> javah version "9-ea" >>>>> #> echo $? >>>>> 0 >>>>> testToolVersion passed >>>>> === testInternalStrings === >>>>> testDebugVersion passed >>>>> All Version string comparisons: PASS >>>>> ----------System.err:(1/15)---------- >>>>> >>>> >>> >> > From andrey.x.nazarov at oracle.com Mon Dec 26 14:53:26 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Mon, 26 Dec 2016 17:53:26 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com> Message-ID: <41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com> Hi, 2 minor comments. bug id has not been added ?@bug 8171441? javadoc should start with /** not 152 /* ?Andrey > On 26 Dec 2016, at 17:40, Stanislav Smirnov wrote: > > Hi, > > thanks, looks good > > Best regards, > Stanislav Smirnov > > > > > >> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko wrote: >> >> Hi, >> >> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ >> >> This comment now looks like: >> 152 /* >> 153 * Checks if the tools accept "-version" option (exit code is zero). >> 154 * The output of the tools run with "-version" is not verified. >> 155 */ >> >> Thanks >> Dima >> >> On 23.12.2016 13:40, Stanislav Smirnov wrote: >>> Hi, >>> >>> sorry, missed this strange comment during the first review. >>> 152 /* >>> 153 * this tests if the tool can take a version string and returns >>> 154 * a 0 exit code, it is not possible to validate the contents >>> 155 * of the -version output as they are inconsistent. >>> 156 */ >>> 157 static String testToolVersion() { >>> It confuses me, can you please rephrase it? >>> >>> Best regards, >>> Stanislav Smirnov >>> >>> >>> >>> >>> >>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko > wrote: >>>> >>>> Hi Stanislav, >>>> >>>> Thanks for looking. >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >>>> >>>> -- Dima >>>> >>>> >>>> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>>>> Hi Dima, >>>>> >>>>> changes look good, I will only suggest using lambda?s in couple of iterations >>>>> + for (String s : tr.testOutput) { >>>>> + System.out.println(s); >>>>> + } >>>>> tr.testOutput.forEach(System.out::println) >>>>> >>>>> for (String x : tr.testOutput) { >>>>> alist.add(x.trim()); >>>>> } >>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>>>> >>>>> >>>>> Best regards, >>>>> Stanislav Smirnov >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko > wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I'm looking for reviews of a relatively simple test change: >>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>>>> >>>>>> The purpose of the change is to improve diagnostic. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> PS: After the fix the failures will be reported as: >>>>>> >>>>>> ----------System.err:(13/956)---------- >>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>> at VersionCheck.main(VersionCheck.java:295) >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>> >>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>> JavaTest Message: shutting down test >>>>>> >>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>> >>>>>> PPS: The output of passed test now looks like: >>>>>> >>>>>> === testJVersionStrings === >>>>>> Testing servertool >>>>>> Testing jstat >>>>>> Testing jmod >>>>>> Testing jjs >>>>>> Testing jimage >>>>>> Testing jlink >>>>>> Testing jrunscript >>>>>> Testing jdeprscan >>>>>> Testing jconsole >>>>>> Testing rmiregistry >>>>>> Testing keytool >>>>>> Testing schemagen >>>>>> Testing javac >>>>>> Testing jar >>>>>> Testing jhsdb >>>>>> Testing jcmd >>>>>> Testing jstack >>>>>> Testing wsgen >>>>>> Testing jshell >>>>>> Testing serialver >>>>>> Testing jmap >>>>>> Testing javap >>>>>> Testing jps >>>>>> Testing jstatd >>>>>> Testing javadoc >>>>>> Testing tnameserv >>>>>> Testing jdb >>>>>> Testing jinfo >>>>>> Testing jdeps >>>>>> Testing xjc >>>>>> Testing rmid >>>>>> Testing jarsigner >>>>>> Testing idlj >>>>>> Testing rmic >>>>>> Testing appletviewer >>>>>> Testing pack200 >>>>>> Testing javah >>>>>> Testing policytool >>>>>> Testing orbd >>>>>> testJVersionStrings passed >>>>>> === testInternalStrings === >>>>>> testInternalStrings passed >>>>>> === testToolVersion === >>>>>> Testing java >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version >>>>>> java version "9-ea" >>>>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javac >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version >>>>>> javac 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jhsdb >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version >>>>>> clhsdb command line debugger >>>>>> debugd debug server >>>>>> hsdb ui debugger >>>>>> jstack --help to get more information >>>>>> jmap --help to get more information >>>>>> jinfo --help to get more information >>>>>> jsnap --help to get more information >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jshell >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version >>>>>> jshell 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javap >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version >>>>>> 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jdb >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version >>>>>> This is jdb version 9.0 (Java SE version 9-ea) >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing idlj >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version >>>>>> IDL-to-Java compiler (portable), version "3.2" >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javah >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version >>>>>> >>>>>> Warning: The javah tool is planned to be removed in the next major >>>>>> JDK release. The tool has been superseded by the '-h' option added >>>>>> to javac in JDK 8. Users are recommended to migrate to using the >>>>>> javac '-h' option; see the javac man page for more information. >>>>>> >>>>>> javah version "9-ea" >>>>>> #> echo $? >>>>>> 0 >>>>>> testToolVersion passed >>>>>> === testInternalStrings === >>>>>> testDebugVersion passed >>>>>> All Version string comparisons: PASS >>>>>> ----------System.err:(1/15)---------- >>>>>> >>>>> >>>> >>> >> > From sergei.kovalev at oracle.com Mon Dec 26 14:57:54 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Mon, 26 Dec 2016 17:57:54 +0300 Subject: RFR(s): 8171958: Several tests from java/time/test/java/time/format requiring jdk.localedata for execution Message-ID: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com> Hello Team, Please review below fix for tests. Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958 Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/ Issue: some tests fails in case of module limitation by '--limit-module java.base' command line option. Root cause: The tests uses locale data that stored in separate resource file "jdk.localedata". Solution: Add declaration of required module. In same cases a test file contains many test items, part of which could be executed with java.base module only. In this cases we can separate the items and extract that items which depend on locale data and run them individually. Therefore this proposal contains additional test files where added "WithLocale" suffix which demonstrate dependency on resources. Alternative solution could be add a required module declaration "jdk.localedata" to all files. However this will lead to unnecessary test coverage reduction. -- With best regards, Sergei From dmitry.fazunenko at oracle.com Mon Dec 26 15:36:07 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko) Date: Mon, 26 Dec 2016 18:36:07 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com> <41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com> Message-ID: <42793a53-c60c-0470-a1b7-83edf0761b0c@oracle.com> Hi Andrey, On 26.12.2016 17:53, Andrey Nazarov wrote: > Hi, > > 2 minor comments. > bug id has not been added ?@bug 8171441? I believe the purpose of the @bug tag is to list the issues the test verifies or the test is regression test for. And it's not need to mention all the problem with the test itself here. > javadoc should start with /** not 152 /* I intentionally kept "/*", because it's not a javadoc comment, but just a comment to a method. If we convert this to javadoc, we need to provide javadoc to other similar methods. Of course this would be good, but I'm afraid this activity is rather a separate RFE. Thanks, Dima > > > ?Andrey >> On 26 Dec 2016, at 17:40, Stanislav Smirnov wrote: >> >> Hi, >> >> thanks, looks good >> >> Best regards, >> Stanislav Smirnov >> >> >> >> >> >>> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko wrote: >>> >>> Hi, >>> >>> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ >>> >>> This comment now looks like: >>> 152 /* >>> 153 * Checks if the tools accept "-version" option (exit code is zero). >>> 154 * The output of the tools run with "-version" is not verified. >>> 155 */ >>> >>> Thanks >>> Dima >>> >>> On 23.12.2016 13:40, Stanislav Smirnov wrote: >>>> Hi, >>>> >>>> sorry, missed this strange comment during the first review. >>>> 152 /* >>>> 153 * this tests if the tool can take a version string and returns >>>> 154 * a 0 exit code, it is not possible to validate the contents >>>> 155 * of the -version output as they are inconsistent. >>>> 156 */ >>>> 157 static String testToolVersion() { >>>> It confuses me, can you please rephrase it? >>>> >>>> Best regards, >>>> Stanislav Smirnov >>>> >>>> >>>> >>>> >>>> >>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko > wrote: >>>>> >>>>> Hi Stanislav, >>>>> >>>>> Thanks for looking. >>>>> Updated webrev: >>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >>>>> >>>>> -- Dima >>>>> >>>>> >>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>>>>> Hi Dima, >>>>>> >>>>>> changes look good, I will only suggest using lambda?s in couple of iterations >>>>>> + for (String s : tr.testOutput) { >>>>>> + System.out.println(s); >>>>>> + } >>>>>> tr.testOutput.forEach(System.out::println) >>>>>> >>>>>> for (String x : tr.testOutput) { >>>>>> alist.add(x.trim()); >>>>>> } >>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>>>>> >>>>>> >>>>>> Best regards, >>>>>> Stanislav Smirnov >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko > wrote: >>>>>>> >>>>>>> Hello, >>>>>>> >>>>>>> I'm looking for reviews of a relatively simple test change: >>>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>>>>> >>>>>>> The purpose of the change is to improve diagnostic. >>>>>>> >>>>>>> Thanks, >>>>>>> Dima >>>>>>> >>>>>>> PS: After the fix the failures will be reported as: >>>>>>> >>>>>>> ----------System.err:(13/956)---------- >>>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>> at VersionCheck.main(VersionCheck.java:295) >>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>>>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>> >>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>> JavaTest Message: shutting down test >>>>>>> >>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>> >>>>>>> PPS: The output of passed test now looks like: >>>>>>> >>>>>>> === testJVersionStrings === >>>>>>> Testing servertool >>>>>>> Testing jstat >>>>>>> Testing jmod >>>>>>> Testing jjs >>>>>>> Testing jimage >>>>>>> Testing jlink >>>>>>> Testing jrunscript >>>>>>> Testing jdeprscan >>>>>>> Testing jconsole >>>>>>> Testing rmiregistry >>>>>>> Testing keytool >>>>>>> Testing schemagen >>>>>>> Testing javac >>>>>>> Testing jar >>>>>>> Testing jhsdb >>>>>>> Testing jcmd >>>>>>> Testing jstack >>>>>>> Testing wsgen >>>>>>> Testing jshell >>>>>>> Testing serialver >>>>>>> Testing jmap >>>>>>> Testing javap >>>>>>> Testing jps >>>>>>> Testing jstatd >>>>>>> Testing javadoc >>>>>>> Testing tnameserv >>>>>>> Testing jdb >>>>>>> Testing jinfo >>>>>>> Testing jdeps >>>>>>> Testing xjc >>>>>>> Testing rmid >>>>>>> Testing jarsigner >>>>>>> Testing idlj >>>>>>> Testing rmic >>>>>>> Testing appletviewer >>>>>>> Testing pack200 >>>>>>> Testing javah >>>>>>> Testing policytool >>>>>>> Testing orbd >>>>>>> testJVersionStrings passed >>>>>>> === testInternalStrings === >>>>>>> testInternalStrings passed >>>>>>> === testToolVersion === >>>>>>> Testing java >>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version >>>>>>> java version "9-ea" >>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>>>>> #> echo $? >>>>>>> 0 >>>>>>> Testing javac >>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version >>>>>>> javac 9-ea >>>>>>> #> echo $? >>>>>>> 0 >>>>>>> Testing jhsdb >>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version >>>>>>> clhsdb command line debugger >>>>>>> debugd debug server >>>>>>> hsdb ui debugger >>>>>>> jstack --help to get more information >>>>>>> jmap --help to get more information >>>>>>> jinfo --help to get more information >>>>>>> jsnap --help to get more information >>>>>>> #> echo $? >>>>>>> 0 >>>>>>> Testing jshell >>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version >>>>>>> jshell 9-ea >>>>>>> #> echo $? >>>>>>> 0 >>>>>>> Testing javap >>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version >>>>>>> 9-ea >>>>>>> #> echo $? >>>>>>> 0 >>>>>>> Testing jdb >>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version >>>>>>> This is jdb version 9.0 (Java SE version 9-ea) >>>>>>> #> echo $? >>>>>>> 0 >>>>>>> Testing idlj >>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version >>>>>>> IDL-to-Java compiler (portable), version "3.2" >>>>>>> #> echo $? >>>>>>> 0 >>>>>>> Testing javah >>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version >>>>>>> >>>>>>> Warning: The javah tool is planned to be removed in the next major >>>>>>> JDK release. The tool has been superseded by the '-h' option added >>>>>>> to javac in JDK 8. Users are recommended to migrate to using the >>>>>>> javac '-h' option; see the javac man page for more information. >>>>>>> >>>>>>> javah version "9-ea" >>>>>>> #> echo $? >>>>>>> 0 >>>>>>> testToolVersion passed >>>>>>> === testInternalStrings === >>>>>>> testDebugVersion passed >>>>>>> All Version string comparisons: PASS >>>>>>> ----------System.err:(1/15)---------- >>>>>>> From dmitry.fazunenko at oracle.com Mon Dec 26 15:40:52 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko) Date: Mon, 26 Dec 2016 18:40:52 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com> Message-ID: Thank you, Stanislav. -- Dima On 26.12.2016 17:40, Stanislav Smirnov wrote: > Hi, > > thanks, looks good > > Best regards, > Stanislav Smirnov > > > > > >> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko >> > wrote: >> >> Hi, >> >> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ >> >> This comment now looks like: >> 152 /* >> 153 * Checks if the tools accept "-version" option (exit code is zero). >> 154 * The output of the tools run with "-version" is not verified. >> 155 */ >> >> Thanks >> Dima >> >> On 23.12.2016 13:40, Stanislav Smirnov wrote: >>> Hi, >>> >>> sorry, missed this strange comment during the first review. >>> 152 /* >>> 153 * this tests if the tool can take a version string and returns >>> 154 * a 0 exit code, it is not possible to validate the contents >>> 155 * of the -version output as they are inconsistent. >>> 156 */ >>> 157 static String testToolVersion() { >>> It confuses me, can you please rephrase it? >>> >>> Best regards, >>> Stanislav Smirnov >>> >>> >>> >>> >>> >>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko >>>> > >>>> wrote: >>>> >>>> Hi Stanislav, >>>> >>>> Thanks for looking. >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >>>> >>>> -- Dima >>>> >>>> >>>> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>>>> Hi Dima, >>>>> >>>>> changes look good, I will only suggest using lambda?s in couple of >>>>> iterations >>>>> + for (String s : tr.testOutput) { >>>>> + System.out.println(s); >>>>> + } >>>>> tr.testOutput.forEach(System.out::println) >>>>> >>>>> for (String x : tr.testOutput) { >>>>> alist.add(x.trim()); >>>>> } >>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>>>> >>>>> >>>>> Best regards, >>>>> Stanislav Smirnov >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko >>>>>> >>>>> > wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I'm looking for reviews of a relatively simple test change: >>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>>>> >>>>>> The purpose of the change is to improve diagnostic. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> PS: After the fix the failures will be reported as: >>>>>> >>>>>> ----------System.err:(13/956)---------- >>>>>> java.lang.AssertionError: VersionCheck failed: >>>>>> testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>> at VersionCheck.main(VersionCheck.java:295) >>>>>> at >>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native >>>>>> Method) >>>>>> at >>>>>> java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>> at >>>>>> java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>>>> at >>>>>> com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>> >>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: >>>>>> VersionCheck failed: testJVersionStrings: [java]; >>>>>> testToolVersion: [jar]; >>>>>> JavaTest Message: shutting down test >>>>>> >>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: >>>>>> VersionCheck failed: testJVersionStrings: [java]; >>>>>> testToolVersion: [jar]; >>>>>> >>>>>> PPS: The output of passed test now looks like: >>>>>> >>>>>> === testJVersionStrings === >>>>>> Testing servertool >>>>>> Testing jstat >>>>>> Testing jmod >>>>>> Testing jjs >>>>>> Testing jimage >>>>>> Testing jlink >>>>>> Testing jrunscript >>>>>> Testing jdeprscan >>>>>> Testing jconsole >>>>>> Testing rmiregistry >>>>>> Testing keytool >>>>>> Testing schemagen >>>>>> Testing javac >>>>>> Testing jar >>>>>> Testing jhsdb >>>>>> Testing jcmd >>>>>> Testing jstack >>>>>> Testing wsgen >>>>>> Testing jshell >>>>>> Testing serialver >>>>>> Testing jmap >>>>>> Testing javap >>>>>> Testing jps >>>>>> Testing jstatd >>>>>> Testing javadoc >>>>>> Testing tnameserv >>>>>> Testing jdb >>>>>> Testing jinfo >>>>>> Testing jdeps >>>>>> Testing xjc >>>>>> Testing rmid >>>>>> Testing jarsigner >>>>>> Testing idlj >>>>>> Testing rmic >>>>>> Testing appletviewer >>>>>> Testing pack200 >>>>>> Testing javah >>>>>> Testing policytool >>>>>> Testing orbd >>>>>> testJVersionStrings passed >>>>>> === testInternalStrings === >>>>>> testInternalStrings passed >>>>>> === testToolVersion === >>>>>> Testing java >>>>>> #> >>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java >>>>>> >>>>>> -version >>>>>> java version "9-ea" >>>>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javac >>>>>> #> >>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac >>>>>> >>>>>> -version >>>>>> javac 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jhsdb >>>>>> #> >>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb >>>>>> >>>>>> -version >>>>>> clhsdb command line debugger >>>>>> debugd debug server >>>>>> hsdb ui debugger >>>>>> jstack --help to get more information >>>>>> jmap --help to get more information >>>>>> jinfo --help to get more information >>>>>> jsnap --help to get more information >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jshell >>>>>> #> >>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell >>>>>> >>>>>> -version >>>>>> jshell 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javap >>>>>> #> >>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap >>>>>> >>>>>> -version >>>>>> 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jdb >>>>>> #> >>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb >>>>>> >>>>>> -version >>>>>> This is jdb version 9.0 (Java SE version 9-ea) >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing idlj >>>>>> #> >>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj >>>>>> >>>>>> -version >>>>>> IDL-to-Java compiler (portable), version "3.2" >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javah >>>>>> #> >>>>>> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah >>>>>> >>>>>> -version >>>>>> >>>>>> Warning: The javah tool is planned to be removed in the next major >>>>>> JDK release. The tool has been superseded by the '-h' option added >>>>>> to javac in JDK 8. Users are recommended to migrate to using the >>>>>> javac '-h' option; see the javac man page for more information. >>>>>> >>>>>> javah version "9-ea" >>>>>> #> echo $? >>>>>> 0 >>>>>> testToolVersion passed >>>>>> === testInternalStrings === >>>>>> testDebugVersion passed >>>>>> All Version string comparisons: PASS >>>>>> ----------System.err:(1/15)---------- >>>>>> >>>>> >>>> >>> >> > From igor.ignatyev at oracle.com Mon Dec 26 15:42:24 2016 From: igor.ignatyev at oracle.com (Igor Ignatyev) Date: Mon, 26 Dec 2016 18:42:24 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> Message-ID: <9BD01FBA-2EF2-462A-8197-46D57B996499@oracle.com> Hi Dima, the fix looks good to me, Cheers, ? Igor > On Dec 23, 2016, at 7:13 PM, Dmitry Fazunenenko wrote: > > Hi, > > new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ > > This comment now looks like: > > 152 /* > 153 * Checks if the tools accept "-version" option (exit code is zero). > 154 * The output of the tools run with "-version" is not verified. > 155 */ > > > Thanks > Dima > > On 23.12.2016 13:40, Stanislav Smirnov wrote: >> Hi, >> >> sorry, missed this strange comment during the first review. >> 152 /* >> 153 * this tests if the tool can take a version string and returns >> 154 * a 0 exit code, it is not possible to validate the contents >> 155 * of the -version output as they are inconsistent. >> 156 */ >> 157 static String testToolVersion() { >> It confuses me, can you please rephrase it? >> >> Best regards, >> Stanislav Smirnov >> >> >> >> >> >>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko > wrote: >>> >>> Hi Stanislav, >>> >>> Thanks for looking. >>> Updated webrev: >>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >>> >>> -- Dima >>> >>> >>> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>>> Hi Dima, >>>> >>>> changes look good, I will only suggest using lambda?s in couple of iterations >>>> + for (String s : tr.testOutput) { >>>> + System.out.println(s); >>>> + } >>>> tr.testOutput.forEach(System.out::println) >>>> >>>> for (String x : tr.testOutput) { >>>> alist.add(x.trim()); >>>> } >>>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>>> >>>> >>>> Best regards, >>>> Stanislav Smirnov >>>> >>>> >>>> >>>> >>>> >>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko > wrote: >>>>> >>>>> Hello, >>>>> >>>>> I'm looking for reviews of a relatively simple test change: >>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>>> >>>>> The purpose of the change is to improve diagnostic. >>>>> >>>>> Thanks, >>>>> Dima >>>>> >>>>> PS: After the fix the failures will be reported as: >>>>> >>>>> ----------System.err:(13/956)---------- >>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>> at VersionCheck.main(VersionCheck.java:295) >>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>> >>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>> JavaTest Message: shutting down test >>>>> >>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>> >>>>> PPS: The output of passed test now looks like: >>>>> >>>>> === testJVersionStrings === >>>>> Testing servertool >>>>> Testing jstat >>>>> Testing jmod >>>>> Testing jjs >>>>> Testing jimage >>>>> Testing jlink >>>>> Testing jrunscript >>>>> Testing jdeprscan >>>>> Testing jconsole >>>>> Testing rmiregistry >>>>> Testing keytool >>>>> Testing schemagen >>>>> Testing javac >>>>> Testing jar >>>>> Testing jhsdb >>>>> Testing jcmd >>>>> Testing jstack >>>>> Testing wsgen >>>>> Testing jshell >>>>> Testing serialver >>>>> Testing jmap >>>>> Testing javap >>>>> Testing jps >>>>> Testing jstatd >>>>> Testing javadoc >>>>> Testing tnameserv >>>>> Testing jdb >>>>> Testing jinfo >>>>> Testing jdeps >>>>> Testing xjc >>>>> Testing rmid >>>>> Testing jarsigner >>>>> Testing idlj >>>>> Testing rmic >>>>> Testing appletviewer >>>>> Testing pack200 >>>>> Testing javah >>>>> Testing policytool >>>>> Testing orbd >>>>> testJVersionStrings passed >>>>> === testInternalStrings === >>>>> testInternalStrings passed >>>>> === testToolVersion === >>>>> Testing java >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version >>>>> java version "9-ea" >>>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>>> #> echo $? >>>>> 0 >>>>> Testing javac >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version >>>>> javac 9-ea >>>>> #> echo $? >>>>> 0 >>>>> Testing jhsdb >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version >>>>> clhsdb command line debugger >>>>> debugd debug server >>>>> hsdb ui debugger >>>>> jstack --help to get more information >>>>> jmap --help to get more information >>>>> jinfo --help to get more information >>>>> jsnap --help to get more information >>>>> #> echo $? >>>>> 0 >>>>> Testing jshell >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version >>>>> jshell 9-ea >>>>> #> echo $? >>>>> 0 >>>>> Testing javap >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version >>>>> 9-ea >>>>> #> echo $? >>>>> 0 >>>>> Testing jdb >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version >>>>> This is jdb version 9.0 (Java SE version 9-ea) >>>>> #> echo $? >>>>> 0 >>>>> Testing idlj >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version >>>>> IDL-to-Java compiler (portable), version "3.2" >>>>> #> echo $? >>>>> 0 >>>>> Testing javah >>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version >>>>> >>>>> Warning: The javah tool is planned to be removed in the next major >>>>> JDK release. The tool has been superseded by the '-h' option added >>>>> to javac in JDK 8. Users are recommended to migrate to using the >>>>> javac '-h' option; see the javac man page for more information. >>>>> >>>>> javah version "9-ea" >>>>> #> echo $? >>>>> 0 >>>>> testToolVersion passed >>>>> === testInternalStrings === >>>>> testDebugVersion passed >>>>> All Version string comparisons: PASS >>>>> ----------System.err:(1/15)---------- >>>>> >>>> >>> >> > From andrey.x.nazarov at oracle.com Mon Dec 26 15:45:38 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Mon, 26 Dec 2016 18:45:38 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <42793a53-c60c-0470-a1b7-83edf0761b0c@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com> <41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com> <42793a53-c60c-0470-a1b7-83edf0761b0c@oracle.com> Message-ID: <651385B8-25FC-4036-8E0B-1C015367F863@oracle.com> > On 26 Dec 2016, at 18:36, Dmitry Fazunenenko wrote: > > Hi Andrey, > > On 26.12.2016 17:53, Andrey Nazarov wrote: >> Hi, >> >> 2 minor comments. >> bug id has not been added ?@bug 8171441? > I believe the purpose of the @bug tag is to list the issues the test verifies or the test is regression test for. > And it's not need to mention all the problem with the test itself here. My understanding is that @bug tag is used to track the reasons for the test modifications and creation. But I haven?t seen any documentation for it. >> javadoc should start with /** not 152 /* > I intentionally kept "/*", because it's not a javadoc comment, but just a comment to a method. > If we convert this to javadoc, we need to provide javadoc to other similar methods. > Of course this would be good, but I'm afraid this activity is rather a separate RFE. Ok. > > Thanks, > Dima > >> >> >> ?Andrey >>> On 26 Dec 2016, at 17:40, Stanislav Smirnov wrote: >>> >>> Hi, >>> >>> thanks, looks good >>> >>> Best regards, >>> Stanislav Smirnov >>> >>> >>> >>> >>> >>>> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko wrote: >>>> >>>> Hi, >>>> >>>> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ >>>> >>>> This comment now looks like: >>>> 152 /* >>>> 153 * Checks if the tools accept "-version" option (exit code is zero). >>>> 154 * The output of the tools run with "-version" is not verified. >>>> 155 */ >>>> >>>> Thanks >>>> Dima >>>> >>>> On 23.12.2016 13:40, Stanislav Smirnov wrote: >>>>> Hi, >>>>> >>>>> sorry, missed this strange comment during the first review. >>>>> 152 /* >>>>> 153 * this tests if the tool can take a version string and returns >>>>> 154 * a 0 exit code, it is not possible to validate the contents >>>>> 155 * of the -version output as they are inconsistent. >>>>> 156 */ >>>>> 157 static String testToolVersion() { >>>>> It confuses me, can you please rephrase it? >>>>> >>>>> Best regards, >>>>> Stanislav Smirnov >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko > wrote: >>>>>> >>>>>> Hi Stanislav, >>>>>> >>>>>> Thanks for looking. >>>>>> Updated webrev: >>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >>>>>> >>>>>> -- Dima >>>>>> >>>>>> >>>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>>>>>> Hi Dima, >>>>>>> >>>>>>> changes look good, I will only suggest using lambda?s in couple of iterations >>>>>>> + for (String s : tr.testOutput) { >>>>>>> + System.out.println(s); >>>>>>> + } >>>>>>> tr.testOutput.forEach(System.out::println) >>>>>>> >>>>>>> for (String x : tr.testOutput) { >>>>>>> alist.add(x.trim()); >>>>>>> } >>>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>>>>>> >>>>>>> >>>>>>> Best regards, >>>>>>> Stanislav Smirnov >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko > wrote: >>>>>>>> >>>>>>>> Hello, >>>>>>>> >>>>>>>> I'm looking for reviews of a relatively simple test change: >>>>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>>>>>> >>>>>>>> The purpose of the change is to improve diagnostic. >>>>>>>> >>>>>>>> Thanks, >>>>>>>> Dima >>>>>>>> >>>>>>>> PS: After the fix the failures will be reported as: >>>>>>>> >>>>>>>> ----------System.err:(13/956)---------- >>>>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>>> at VersionCheck.main(VersionCheck.java:295) >>>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>>>>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>> >>>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>>> JavaTest Message: shutting down test >>>>>>>> >>>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>>> >>>>>>>> PPS: The output of passed test now looks like: >>>>>>>> >>>>>>>> === testJVersionStrings === >>>>>>>> Testing servertool >>>>>>>> Testing jstat >>>>>>>> Testing jmod >>>>>>>> Testing jjs >>>>>>>> Testing jimage >>>>>>>> Testing jlink >>>>>>>> Testing jrunscript >>>>>>>> Testing jdeprscan >>>>>>>> Testing jconsole >>>>>>>> Testing rmiregistry >>>>>>>> Testing keytool >>>>>>>> Testing schemagen >>>>>>>> Testing javac >>>>>>>> Testing jar >>>>>>>> Testing jhsdb >>>>>>>> Testing jcmd >>>>>>>> Testing jstack >>>>>>>> Testing wsgen >>>>>>>> Testing jshell >>>>>>>> Testing serialver >>>>>>>> Testing jmap >>>>>>>> Testing javap >>>>>>>> Testing jps >>>>>>>> Testing jstatd >>>>>>>> Testing javadoc >>>>>>>> Testing tnameserv >>>>>>>> Testing jdb >>>>>>>> Testing jinfo >>>>>>>> Testing jdeps >>>>>>>> Testing xjc >>>>>>>> Testing rmid >>>>>>>> Testing jarsigner >>>>>>>> Testing idlj >>>>>>>> Testing rmic >>>>>>>> Testing appletviewer >>>>>>>> Testing pack200 >>>>>>>> Testing javah >>>>>>>> Testing policytool >>>>>>>> Testing orbd >>>>>>>> testJVersionStrings passed >>>>>>>> === testInternalStrings === >>>>>>>> testInternalStrings passed >>>>>>>> === testToolVersion === >>>>>>>> Testing java >>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version >>>>>>>> java version "9-ea" >>>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>>>>>> #> echo $? >>>>>>>> 0 >>>>>>>> Testing javac >>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version >>>>>>>> javac 9-ea >>>>>>>> #> echo $? >>>>>>>> 0 >>>>>>>> Testing jhsdb >>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version >>>>>>>> clhsdb command line debugger >>>>>>>> debugd debug server >>>>>>>> hsdb ui debugger >>>>>>>> jstack --help to get more information >>>>>>>> jmap --help to get more information >>>>>>>> jinfo --help to get more information >>>>>>>> jsnap --help to get more information >>>>>>>> #> echo $? >>>>>>>> 0 >>>>>>>> Testing jshell >>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version >>>>>>>> jshell 9-ea >>>>>>>> #> echo $? >>>>>>>> 0 >>>>>>>> Testing javap >>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version >>>>>>>> 9-ea >>>>>>>> #> echo $? >>>>>>>> 0 >>>>>>>> Testing jdb >>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version >>>>>>>> This is jdb version 9.0 (Java SE version 9-ea) >>>>>>>> #> echo $? >>>>>>>> 0 >>>>>>>> Testing idlj >>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version >>>>>>>> IDL-to-Java compiler (portable), version "3.2" >>>>>>>> #> echo $? >>>>>>>> 0 >>>>>>>> Testing javah >>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version >>>>>>>> >>>>>>>> Warning: The javah tool is planned to be removed in the next major >>>>>>>> JDK release. The tool has been superseded by the '-h' option added >>>>>>>> to javac in JDK 8. Users are recommended to migrate to using the >>>>>>>> javac '-h' option; see the javac man page for more information. >>>>>>>> >>>>>>>> javah version "9-ea" >>>>>>>> #> echo $? >>>>>>>> 0 >>>>>>>> testToolVersion passed >>>>>>>> === testInternalStrings === >>>>>>>> testDebugVersion passed >>>>>>>> All Version string comparisons: PASS >>>>>>>> ----------System.err:(1/15)---------- >>>>>>>> > From dmitry.fazunenko at oracle.com Mon Dec 26 16:00:44 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko) Date: Mon, 26 Dec 2016 19:00:44 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <651385B8-25FC-4036-8E0B-1C015367F863@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> <6F646971-ABD1-4422-95AA-498AFE89F082@oracle.com> <41C5A56A-8555-4B3B-B3F4-5AF7E70E7F4A@oracle.com> <42793a53-c60c-0470-a1b7-83edf0761b0c@oracle.com> <651385B8-25FC-4036-8E0B-1C015367F863@oracle.com> Message-ID: <9d31fd1c-b60f-0afc-af32-4f4b5bae2ef2@oracle.com> On 26.12.2016 18:45, Andrey Nazarov wrote: >> On 26 Dec 2016, at 18:36, Dmitry Fazunenenko wrote: >> >> Hi Andrey, >> >> On 26.12.2016 17:53, Andrey Nazarov wrote: >>> Hi, >>> >>> 2 minor comments. >>> bug id has not been added ?@bug 8171441? >> I believe the purpose of the @bug tag is to list the issues the test verifies or the test is regression test for. >> And it's not need to mention all the problem with the test itself here. > My understanding is that @bug tag is used to track the reasons for the test modifications and creation. But I haven?t seen any documentation for it. It's not needed to list CRs related to the test modification, they could be extracted from the history. Much more useful is to list the regressions caught by the test. -- Dima >>> javadoc should start with /** not 152 /* >> I intentionally kept "/*", because it's not a javadoc comment, but just a comment to a method. >> If we convert this to javadoc, we need to provide javadoc to other similar methods. >> Of course this would be good, but I'm afraid this activity is rather a separate RFE. > Ok. >> Thanks, >> Dima >> >>> >>> ?Andrey >>>> On 26 Dec 2016, at 17:40, Stanislav Smirnov wrote: >>>> >>>> Hi, >>>> >>>> thanks, looks good >>>> >>>> Best regards, >>>> Stanislav Smirnov >>>> >>>> >>>> >>>> >>>> >>>>> On 23 Dec 2016, at 19:13, Dmitry Fazunenenko wrote: >>>>> >>>>> Hi, >>>>> >>>>> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ >>>>> >>>>> This comment now looks like: >>>>> 152 /* >>>>> 153 * Checks if the tools accept "-version" option (exit code is zero). >>>>> 154 * The output of the tools run with "-version" is not verified. >>>>> 155 */ >>>>> >>>>> Thanks >>>>> Dima >>>>> >>>>> On 23.12.2016 13:40, Stanislav Smirnov wrote: >>>>>> Hi, >>>>>> >>>>>> sorry, missed this strange comment during the first review. >>>>>> 152 /* >>>>>> 153 * this tests if the tool can take a version string and returns >>>>>> 154 * a 0 exit code, it is not possible to validate the contents >>>>>> 155 * of the -version output as they are inconsistent. >>>>>> 156 */ >>>>>> 157 static String testToolVersion() { >>>>>> It confuses me, can you please rephrase it? >>>>>> >>>>>> Best regards, >>>>>> Stanislav Smirnov >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko > wrote: >>>>>>> >>>>>>> Hi Stanislav, >>>>>>> >>>>>>> Thanks for looking. >>>>>>> Updated webrev: >>>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >>>>>>> >>>>>>> -- Dima >>>>>>> >>>>>>> >>>>>>> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>>>>>>> Hi Dima, >>>>>>>> >>>>>>>> changes look good, I will only suggest using lambda?s in couple of iterations >>>>>>>> + for (String s : tr.testOutput) { >>>>>>>> + System.out.println(s); >>>>>>>> + } >>>>>>>> tr.testOutput.forEach(System.out::println) >>>>>>>> >>>>>>>> for (String x : tr.testOutput) { >>>>>>>> alist.add(x.trim()); >>>>>>>> } >>>>>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>>>>>>> >>>>>>>> >>>>>>>> Best regards, >>>>>>>> Stanislav Smirnov >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko > wrote: >>>>>>>>> >>>>>>>>> Hello, >>>>>>>>> >>>>>>>>> I'm looking for reviews of a relatively simple test change: >>>>>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>>>>>>> >>>>>>>>> The purpose of the change is to improve diagnostic. >>>>>>>>> >>>>>>>>> Thanks, >>>>>>>>> Dima >>>>>>>>> >>>>>>>>> PS: After the fix the failures will be reported as: >>>>>>>>> >>>>>>>>> ----------System.err:(13/956)---------- >>>>>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>>>> at VersionCheck.main(VersionCheck.java:295) >>>>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>>>>>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>>>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>>>>> >>>>>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>>>> JavaTest Message: shutting down test >>>>>>>>> >>>>>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>>>>> >>>>>>>>> PPS: The output of passed test now looks like: >>>>>>>>> >>>>>>>>> === testJVersionStrings === >>>>>>>>> Testing servertool >>>>>>>>> Testing jstat >>>>>>>>> Testing jmod >>>>>>>>> Testing jjs >>>>>>>>> Testing jimage >>>>>>>>> Testing jlink >>>>>>>>> Testing jrunscript >>>>>>>>> Testing jdeprscan >>>>>>>>> Testing jconsole >>>>>>>>> Testing rmiregistry >>>>>>>>> Testing keytool >>>>>>>>> Testing schemagen >>>>>>>>> Testing javac >>>>>>>>> Testing jar >>>>>>>>> Testing jhsdb >>>>>>>>> Testing jcmd >>>>>>>>> Testing jstack >>>>>>>>> Testing wsgen >>>>>>>>> Testing jshell >>>>>>>>> Testing serialver >>>>>>>>> Testing jmap >>>>>>>>> Testing javap >>>>>>>>> Testing jps >>>>>>>>> Testing jstatd >>>>>>>>> Testing javadoc >>>>>>>>> Testing tnameserv >>>>>>>>> Testing jdb >>>>>>>>> Testing jinfo >>>>>>>>> Testing jdeps >>>>>>>>> Testing xjc >>>>>>>>> Testing rmid >>>>>>>>> Testing jarsigner >>>>>>>>> Testing idlj >>>>>>>>> Testing rmic >>>>>>>>> Testing appletviewer >>>>>>>>> Testing pack200 >>>>>>>>> Testing javah >>>>>>>>> Testing policytool >>>>>>>>> Testing orbd >>>>>>>>> testJVersionStrings passed >>>>>>>>> === testInternalStrings === >>>>>>>>> testInternalStrings passed >>>>>>>>> === testToolVersion === >>>>>>>>> Testing java >>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version >>>>>>>>> java version "9-ea" >>>>>>>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>>>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>>>>>>> #> echo $? >>>>>>>>> 0 >>>>>>>>> Testing javac >>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version >>>>>>>>> javac 9-ea >>>>>>>>> #> echo $? >>>>>>>>> 0 >>>>>>>>> Testing jhsdb >>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version >>>>>>>>> clhsdb command line debugger >>>>>>>>> debugd debug server >>>>>>>>> hsdb ui debugger >>>>>>>>> jstack --help to get more information >>>>>>>>> jmap --help to get more information >>>>>>>>> jinfo --help to get more information >>>>>>>>> jsnap --help to get more information >>>>>>>>> #> echo $? >>>>>>>>> 0 >>>>>>>>> Testing jshell >>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version >>>>>>>>> jshell 9-ea >>>>>>>>> #> echo $? >>>>>>>>> 0 >>>>>>>>> Testing javap >>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version >>>>>>>>> 9-ea >>>>>>>>> #> echo $? >>>>>>>>> 0 >>>>>>>>> Testing jdb >>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version >>>>>>>>> This is jdb version 9.0 (Java SE version 9-ea) >>>>>>>>> #> echo $? >>>>>>>>> 0 >>>>>>>>> Testing idlj >>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version >>>>>>>>> IDL-to-Java compiler (portable), version "3.2" >>>>>>>>> #> echo $? >>>>>>>>> 0 >>>>>>>>> Testing javah >>>>>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version >>>>>>>>> >>>>>>>>> Warning: The javah tool is planned to be removed in the next major >>>>>>>>> JDK release. The tool has been superseded by the '-h' option added >>>>>>>>> to javac in JDK 8. Users are recommended to migrate to using the >>>>>>>>> javac '-h' option; see the javac man page for more information. >>>>>>>>> >>>>>>>>> javah version "9-ea" >>>>>>>>> #> echo $? >>>>>>>>> 0 >>>>>>>>> testToolVersion passed >>>>>>>>> === testInternalStrings === >>>>>>>>> testDebugVersion passed >>>>>>>>> All Version string comparisons: PASS >>>>>>>>> ----------System.err:(1/15)---------- >>>>>>>>> From jeff.dinkins at oracle.com Mon Dec 26 16:05:54 2016 From: jeff.dinkins at oracle.com (Jeff Dinkins) Date: Mon, 26 Dec 2016 10:05:54 -0600 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> References: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> Message-ID: <5532B9EB-37D3-4A90-AE00-EEDBEF504D48@oracle.com> Thanks Peter! Can you give us an ETA of when you think you?ll be able to put back? thanks, -jeff > On Dec 26, 2016, at 3:35 AM, Peter Levart wrote: > > Hi Jeff, > > I've been told that the latest change I pushed causes some tests to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: > > http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ > > From the stacktrace of the bug report, it seems an early initialization issue with VarHandle(s) involved. Can you shed some light into what tests are failing? But first let us backout that change. > > Regards, Peter > > On 12/26/2016 10:09 AM, Peter Levart wrote: >> Hi Jeff, >> >> I'm taking a look at this... >> >> Regards, Peter >> >> On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >>> Hi Peter - >>> >>> I just received mail from out SQE manager, saying that your last changeset has caused our test harness to hiccup. I don?t have much more detail besides the below bug, but I?m wondering if you could do us a huge favor and roll your change back for now while it?s debugged (and so we can get our automated tests going again). >>> >>> https://bugs.openjdk.java.net/browse/JDK-8171988 >>> >>> thanks! >>> >>> -jeff >>> >> > From gustavo.galimberti at oracle.com Mon Dec 26 16:11:43 2016 From: gustavo.galimberti at oracle.com (Gustavo Galimberti) Date: Mon, 26 Dec 2016 11:11:43 -0500 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: <5532B9EB-37D3-4A90-AE00-EEDBEF504D48@oracle.com> References: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> <5532B9EB-37D3-4A90-AE00-EEDBEF504D48@oracle.com> Message-ID: <7e6f37d9-924f-9151-4e35-1b73c5bc254f@oracle.com> Hi Peter, Chris and Jeff. First of: thx u for your expeditious work! ... (I know... quite a Christmas activity ... :) ). Guys, please assure to run the roll back thru JPRT so we get back to normal as clean as possible. Cheers, GGG On 12/26/16 11:05 AM, Jeff Dinkins wrote: > > Thanks Peter! > > Can you give us an ETA of when you think you?ll be able to put back? > > thanks, > > -jeff > >> On Dec 26, 2016, at 3:35 AM, Peter Levart > > wrote: >> >> Hi Jeff, >> >> I've been told that the latest change I pushed causes some tests to >> fail, so I prepared a backout patch for 8062389, 8029459, 8061950: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ >> >> From the stacktrace of the bug report, it seems an early >> initialization issue with VarHandle(s) involved. Can you shed some >> light into what tests are failing? But first let us backout that change. >> >> Regards, Peter >> >> On 12/26/2016 10:09 AM, Peter Levart wrote: >>> Hi Jeff, >>> >>> I'm taking a look at this... >>> >>> Regards, Peter >>> >>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >>>> Hi Peter - >>>> >>>> I just received mail from out SQE manager, saying that your last changeset has caused our test harness to hiccup. I don?t have much more detail besides the below bug, but I?m wondering if you could do us a huge favor and roll your change back for now while it?s debugged (and so we can get our automated tests going again). >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8171988 >>>> >>>> thanks! >>>> >>>> -jeff >>>> >>> >> > From joe.darcy at oracle.com Mon Dec 26 16:26:39 2016 From: joe.darcy at oracle.com (joe darcy) Date: Mon, 26 Dec 2016 08:26:39 -0800 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: <98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com> References: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> <98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com> Message-ID: <47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com> Hello, Assuming we'll want to revisit this work at some point, there are some advantages to anti-delta-ing the code changes now, but just problem listing the tests in terms of making a less confusing history. Thanks, -Joe On 12/26/2016 1:58 AM, Chris Hegarty wrote: >> On 26 Dec 2016, at 09:35, Peter Levart wrote: >> >> Hi Jeff, >> >> I've been told that the latest change I pushed causes some tests to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: >> >> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ > I just grabbed the webrev patch, applied it to a local repo, then > compared that against a repo that had been updated to the > change prior to your push. They are identical, so this appears > to be an accurate anti-delta. > > Maybe file a new bug, or just make it clear in the synopsis of > 8171988 that it is an anti-delta. > > >> From the stacktrace of the bug report, it seems an early initialization issue with VarHandle(s) involved. Can you shed some light into what tests are failing? > I?ll post a few comments in 8171988 with sample failures. > > -Chris. > >> But first let us backout that change. >> >> Regards, Peter >> >> On 12/26/2016 10:09 AM, Peter Levart wrote: >>> Hi Jeff, >>> >>> I'm taking a look at this... >>> >>> Regards, Peter >>> >>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >>>> Hi Peter - >>>> >>>> I just received mail from out SQE manager, saying that your last changeset has caused our test harness to hiccup. I don?t have much more detail besides the below bug, but I?m wondering if you could do us a huge favor and roll your change back for now while it?s debugged (and so we can get our automated tests going again). >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8171988 >>>> >>>> thanks! >>>> >>>> -jeff >>>> From dmitry.fazunenko at oracle.com Mon Dec 26 17:25:54 2016 From: dmitry.fazunenko at oracle.com (Dmitry Fazunenenko) Date: Mon, 26 Dec 2016 20:25:54 +0300 Subject: RFR 8171441: tools/launcher/VersionCheck.java doesn't report names of tools which failed checks In-Reply-To: <9BD01FBA-2EF2-462A-8197-46D57B996499@oracle.com> References: <0877C414-4EB8-4CF0-89D9-F3F34AA2FF99@oracle.com> <03c0dc1b-b36b-8624-8315-ec1b20129ae2@oracle.com> <9BD01FBA-2EF2-462A-8197-46D57B996499@oracle.com> Message-ID: <35f4427f-e354-04e0-ef35-e102b4b9f8bf@oracle.com> Hi Igor, Thanks for the review! -- dima On 26.12.2016 18:42, Igor Ignatyev wrote: > Hi Dima, > > the fix looks good to me, > > Cheers, > ? Igor > >> On Dec 23, 2016, at 7:13 PM, Dmitry Fazunenenko wrote: >> >> Hi, >> >> new version: http://cr.openjdk.java.net/~dfazunen/8171441/webrev.02/ >> >> This comment now looks like: >> >> 152 /* >> 153 * Checks if the tools accept "-version" option (exit code is zero). >> 154 * The output of the tools run with "-version" is not verified. >> 155 */ >> >> >> Thanks >> Dima >> >> On 23.12.2016 13:40, Stanislav Smirnov wrote: >>> Hi, >>> >>> sorry, missed this strange comment during the first review. >>> 152 /* >>> 153 * this tests if the tool can take a version string and returns >>> 154 * a 0 exit code, it is not possible to validate the contents >>> 155 * of the -version output as they are inconsistent. >>> 156 */ >>> 157 static String testToolVersion() { >>> It confuses me, can you please rephrase it? >>> >>> Best regards, >>> Stanislav Smirnov >>> >>> >>> >>> >>> >>>> On 23 Dec 2016, at 11:55, Dmitry Fazunenko > wrote: >>>> >>>> Hi Stanislav, >>>> >>>> Thanks for looking. >>>> Updated webrev: >>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.01/ >>>> >>>> -- Dima >>>> >>>> >>>> On 22.12.2016 19:55, Stanislav Smirnov wrote: >>>>> Hi Dima, >>>>> >>>>> changes look good, I will only suggest using lambda?s in couple of iterations >>>>> + for (String s : tr.testOutput) { >>>>> + System.out.println(s); >>>>> + } >>>>> tr.testOutput.forEach(System.out::println) >>>>> >>>>> for (String x : tr.testOutput) { >>>>> alist.add(x.trim()); >>>>> } >>>>> tr.testOutput.stream.map(String::trim).forEach(aList:add) >>>>> >>>>> >>>>> Best regards, >>>>> Stanislav Smirnov >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> On 21 Dec 2016, at 17:16, Dmitry Fazunenenko > wrote: >>>>>> >>>>>> Hello, >>>>>> >>>>>> I'm looking for reviews of a relatively simple test change: >>>>>> http://cr.openjdk.java.net/~dfazunen/8171441/webrev.00/ >>>>>> https://bugs.openjdk.java.net/browse/JDK-8171441 >>>>>> >>>>>> The purpose of the change is to improve diagnostic. >>>>>> >>>>>> Thanks, >>>>>> Dima >>>>>> >>>>>> PS: After the fix the failures will be reported as: >>>>>> >>>>>> ----------System.err:(13/956)---------- >>>>>> java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>> at VersionCheck.main(VersionCheck.java:295) >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) >>>>>> at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) >>>>>> at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) >>>>>> at java.base/java.lang.reflect.Method.invoke(Method.java:538) >>>>>> at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) >>>>>> at java.base/java.lang.Thread.run(Thread.java:844) >>>>>> >>>>>> JavaTest Message: Test threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>> JavaTest Message: shutting down test >>>>>> >>>>>> STATUS:Failed.`main' threw exception: java.lang.AssertionError: VersionCheck failed: testJVersionStrings: [java]; testToolVersion: [jar]; >>>>>> >>>>>> PPS: The output of passed test now looks like: >>>>>> >>>>>> === testJVersionStrings === >>>>>> Testing servertool >>>>>> Testing jstat >>>>>> Testing jmod >>>>>> Testing jjs >>>>>> Testing jimage >>>>>> Testing jlink >>>>>> Testing jrunscript >>>>>> Testing jdeprscan >>>>>> Testing jconsole >>>>>> Testing rmiregistry >>>>>> Testing keytool >>>>>> Testing schemagen >>>>>> Testing javac >>>>>> Testing jar >>>>>> Testing jhsdb >>>>>> Testing jcmd >>>>>> Testing jstack >>>>>> Testing wsgen >>>>>> Testing jshell >>>>>> Testing serialver >>>>>> Testing jmap >>>>>> Testing javap >>>>>> Testing jps >>>>>> Testing jstatd >>>>>> Testing javadoc >>>>>> Testing tnameserv >>>>>> Testing jdb >>>>>> Testing jinfo >>>>>> Testing jdeps >>>>>> Testing xjc >>>>>> Testing rmid >>>>>> Testing jarsigner >>>>>> Testing idlj >>>>>> Testing rmic >>>>>> Testing appletviewer >>>>>> Testing pack200 >>>>>> Testing javah >>>>>> Testing policytool >>>>>> Testing orbd >>>>>> testJVersionStrings passed >>>>>> === testInternalStrings === >>>>>> testInternalStrings passed >>>>>> === testToolVersion === >>>>>> Testing java >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/java -version >>>>>> java version "9-ea" >>>>>> Java(TM) SE Runtime Environment (build 9-ea+149) >>>>>> Java HotSpot(TM) 64-Bit Server VM (build 9-ea+149, mixed mode) >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javac >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javac -version >>>>>> javac 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jhsdb >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jhsdb -version >>>>>> clhsdb command line debugger >>>>>> debugd debug server >>>>>> hsdb ui debugger >>>>>> jstack --help to get more information >>>>>> jmap --help to get more information >>>>>> jinfo --help to get more information >>>>>> jsnap --help to get more information >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jshell >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jshell -version >>>>>> jshell 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javap >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javap -version >>>>>> 9-ea >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing jdb >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/jdb -version >>>>>> This is jdb version 9.0 (Java SE version 9-ea) >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing idlj >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/idlj -version >>>>>> IDL-to-Java compiler (portable), version "3.2" >>>>>> #> echo $? >>>>>> 0 >>>>>> Testing javah >>>>>> #> /net/jse-st01.ru.oracle.com/export4/java/re/jdk/9/promoted/ea/149/binaries/solaris-x64/bin/javah -version >>>>>> >>>>>> Warning: The javah tool is planned to be removed in the next major >>>>>> JDK release. The tool has been superseded by the '-h' option added >>>>>> to javac in JDK 8. Users are recommended to migrate to using the >>>>>> javac '-h' option; see the javac man page for more information. >>>>>> >>>>>> javah version "9-ea" >>>>>> #> echo $? >>>>>> 0 >>>>>> testToolVersion passed >>>>>> === testInternalStrings === >>>>>> testDebugVersion passed >>>>>> All Version string comparisons: PASS >>>>>> ----------System.err:(1/15)---------- >>>>>> From chris.hegarty at oracle.com Mon Dec 26 17:30:29 2016 From: chris.hegarty at oracle.com (Chris Hegarty) Date: Mon, 26 Dec 2016 17:30:29 +0000 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: <47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com> References: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> <98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com> <47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com> Message-ID: <09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com> > On 26 Dec 2016, at 16:26, joe darcy wrote: > > Hello, > > Assuming we'll want to revisit this work at some point, there are some advantages to anti-delta-ing the code changes now, but just problem listing the tests in terms of making a less confusing history. My preference is to anti-delta. There are just too many tests failing, ~35 across all platforms and tiers. Peter, Let me know if you need any help pushing this. -Chris. > Thanks, > > -Joe > > > On 12/26/2016 1:58 AM, Chris Hegarty wrote: >>> On 26 Dec 2016, at 09:35, Peter Levart wrote: >>> >>> Hi Jeff, >>> >>> I've been told that the latest change I pushed causes some tests to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: >>> >>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ >> I just grabbed the webrev patch, applied it to a local repo, then >> compared that against a repo that had been updated to the >> change prior to your push. They are identical, so this appears >> to be an accurate anti-delta. >> >> Maybe file a new bug, or just make it clear in the synopsis of >> 8171988 that it is an anti-delta. >> >> >>> From the stacktrace of the bug report, it seems an early initialization issue with VarHandle(s) involved. Can you shed some light into what tests are failing? >> I?ll post a few comments in 8171988 with sample failures. >> >> -Chris. >> >>> But first let us backout that change. >>> >>> Regards, Peter >>> >>>> On 12/26/2016 10:09 AM, Peter Levart wrote: >>>> Hi Jeff, >>>> >>>> I'm taking a look at this... >>>> >>>> Regards, Peter >>>> >>>>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >>>>> Hi Peter - >>>>> >>>>> I just received mail from out SQE manager, saying that your last changeset has caused our test harness to hiccup. I don?t have much more detail besides the below bug, but I?m wondering if you could do us a huge favor and roll your change back for now while it?s debugged (and so we can get our automated tests going again). >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8171988 >>>>> >>>>> thanks! >>>>> >>>>> -jeff >>>>> > From peter.levart at gmail.com Mon Dec 26 17:54:41 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 26 Dec 2016 18:54:41 +0100 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: <09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com> References: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> <98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com> <47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com> <09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com> Message-ID: Hi, Just returned from a trip... So. No, there's no problem pushing this. But I can also just fix the real problem. If you give me a couple of minutes, I think I can diagnose what's going on... Regards, Peter On 12/26/2016 06:30 PM, Chris Hegarty wrote: >> On 26 Dec 2016, at 16:26, joe darcy wrote: >> >> Hello, >> >> Assuming we'll want to revisit this work at some point, there are some advantages to anti-delta-ing the code changes now, but just problem listing the tests in terms of making a less confusing history. > My preference is to anti-delta. There are just too many tests failing, ~35 across all platforms and tiers. > > Peter, > Let me know if you need any help pushing this. > > -Chris. > > >> Thanks, >> >> -Joe >> >> >> On 12/26/2016 1:58 AM, Chris Hegarty wrote: >>>> On 26 Dec 2016, at 09:35, Peter Levart wrote: >>>> >>>> Hi Jeff, >>>> >>>> I've been told that the latest change I pushed causes some tests to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ >>> I just grabbed the webrev patch, applied it to a local repo, then >>> compared that against a repo that had been updated to the >>> change prior to your push. They are identical, so this appears >>> to be an accurate anti-delta. >>> >>> Maybe file a new bug, or just make it clear in the synopsis of >>> 8171988 that it is an anti-delta. >>> >>> >>>> From the stacktrace of the bug report, it seems an early initialization issue with VarHandle(s) involved. Can you shed some light into what tests are failing? >>> I?ll post a few comments in 8171988 with sample failures. >>> >>> -Chris. >>> >>>> But first let us backout that change. >>>> >>>> Regards, Peter >>>> >>>>> On 12/26/2016 10:09 AM, Peter Levart wrote: >>>>> Hi Jeff, >>>>> >>>>> I'm taking a look at this... >>>>> >>>>> Regards, Peter >>>>> >>>>>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >>>>>> Hi Peter - >>>>>> >>>>>> I just received mail from out SQE manager, saying that your last changeset has caused our test harness to hiccup. I don?t have much more detail besides the below bug, but I?m wondering if you could do us a huge favor and roll your change back for now while it?s debugged (and so we can get our automated tests going again). >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8171988 >>>>>> >>>>>> thanks! >>>>>> >>>>>> -jeff >>>>>> From claes.redestad at oracle.com Mon Dec 26 17:55:58 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 26 Dec 2016 18:55:58 +0100 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: <09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com> References: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> <98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com> <47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com> <09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com> Message-ID: Hi, many of the tier 1 failures listed seems to fail due to a cyclic bootstrap dependency on the new PublicMethods -> Policy.isSet() -> ... -> PublicMethods that appears in all tests which install a security manager. It turns out the dependency is only there (Policy.isSet) to ensure the VM has booted to a state where System.getProperty will return actual values to feed into sun.security.util.Debug (the state of which does not in any way vary with Policy), and could be replaced by the new VM.isBooted() (or VM.initLevel() > 1): http://cr.openjdk.java.net/~redestad/scratch/8171988.01/ With this most test failures disappear, but there are still 5 tests in java/lang/Class which fail with a message more directly related to the changes: expected java.lang.NullPointerException for null -- FAILED Perhaps problem list these 5 together with the above change as a fix to this issue? Thanks! /Claes On 2016-12-26 18:30, Chris Hegarty wrote: > >> On 26 Dec 2016, at 16:26, joe darcy wrote: >> >> Hello, >> >> Assuming we'll want to revisit this work at some point, there are some advantages to anti-delta-ing the code changes now, but just problem listing the tests in terms of making a less confusing history. > > My preference is to anti-delta. There are just too many tests failing, ~35 across all platforms and tiers. > > Peter, > Let me know if you need any help pushing this. > > -Chris. > > >> Thanks, >> >> -Joe >> >> >> On 12/26/2016 1:58 AM, Chris Hegarty wrote: >>>> On 26 Dec 2016, at 09:35, Peter Levart wrote: >>>> >>>> Hi Jeff, >>>> >>>> I've been told that the latest change I pushed causes some tests to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: >>>> >>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ >>> I just grabbed the webrev patch, applied it to a local repo, then >>> compared that against a repo that had been updated to the >>> change prior to your push. They are identical, so this appears >>> to be an accurate anti-delta. >>> >>> Maybe file a new bug, or just make it clear in the synopsis of >>> 8171988 that it is an anti-delta. >>> >>> >>>> From the stacktrace of the bug report, it seems an early initialization issue with VarHandle(s) involved. Can you shed some light into what tests are failing? >>> I?ll post a few comments in 8171988 with sample failures. >>> >>> -Chris. >>> >>>> But first let us backout that change. >>>> >>>> Regards, Peter >>>> >>>>> On 12/26/2016 10:09 AM, Peter Levart wrote: >>>>> Hi Jeff, >>>>> >>>>> I'm taking a look at this... >>>>> >>>>> Regards, Peter >>>>> >>>>>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >>>>>> Hi Peter - >>>>>> >>>>>> I just received mail from out SQE manager, saying that your last changeset has caused our test harness to hiccup. I don?t have much more detail besides the below bug, but I?m wondering if you could do us a huge favor and roll your change back for now while it?s debugged (and so we can get our automated tests going again). >>>>>> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8171988 >>>>>> >>>>>> thanks! >>>>>> >>>>>> -jeff >>>>>> >> > From uschindler at apache.org Mon Dec 26 18:01:25 2016 From: uschindler at apache.org (Uwe Schindler) Date: Mon, 26 Dec 2016 19:01:25 +0100 Subject: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch In-Reply-To: <5ebb59c1-7ec3-6ae0-3851-361a40cab276@gmx.org> References: <013d01d2526c$321bbd30$96533790$@apache.org> <584BBB4A.9060603@gmx.org> <00b501d25782$f997dd10$ecc79730$@apache.org> <5ebb59c1-7ec3-6ae0-3851-361a40cab276@gmx.org> Message-ID: <000301d25fa2$1d9e73f0$58db5bd0$@apache.org> Hi, sorry for the delay! I updated Lucene's build system to use the JFrog snapshort artifacts and build succeeds with JDK 9 b148+: That's the one that was choosen by Apache Ant's Ivy downloader: groovy-all-2.4.8-20161220.101835-40.jar So we are waiting for a release! Uwe ----- Uwe Schindler Achterdiek 19, D-28357 Bremen http://www.thetaphi.de eMail: uwe at thetaphi.de > -----Original Message----- > From: core-libs-dev [mailto:core-libs-dev-bounces at openjdk.java.net] On > Behalf Of Jochen Theodorou > Sent: Friday, December 16, 2016 2:11 PM > To: dev at groovy.apache.org; jigsaw-dev at openjdk.java.net; 'Core-Libs-Dev' > > Subject: Re: Java 9 build 148 causes trouble in Apache > Lucene/Solr/Elasticsearch > > Hi, > > I strongly hope Paul and Cedric will be able to start the release > process next week, if not we will have to do it the old way I think. > > what would help us a lot would be you testing the GROOVY_2_4_X branch > with your build system to see if it really does solve your problem. Even > if it is only locally on your computer > > bye Jochen > > On 16.12.2016 10:58, Uwe Schindler wrote: > > Hi Jochen, > > > > thank you for the information! Is there any plan about a release? I also > found no JIRA issue about this issue to link it against our JIRA: > https://issues.apache.org/jira/browse/LUCENE-7596 > > > > The problem makes our build system unusable, so it would be very > important to have a fix quite soon! As our Ant/Ivy-based build relies on > Maven Central, it would be good to have the bugfix release available there, > which requires a release. I think the same applies for Gradle users > (Elasticsearch). > > > > As a temporary workaround we might be able to use the Apache Snapshot > repository, but this is not allowed if we do a release of Lucene. > > > > Uwe > > > > ----- > > Uwe Schindler > > uschindler at apache.org > > ASF Member, Apache Lucene PMC / Committer > > Bremen, Germany > > http://lucene.apache.org/ > > > >> -----Original Message----- > >> From: Jochen Theodorou [mailto:blackdrag at gmx.org] > >> Sent: Saturday, December 10, 2016 9:23 AM > >> To: Uwe Schindler ; jigsaw- > dev at openjdk.java.net; > >> Core-Libs-Dev > >> Subject: Re: Java 9 build 148 causes trouble in Apache > >> Lucene/Solr/Elasticsearch > >> > >> On 09.12.2016 23:32, Uwe Schindler wrote: > >>> Hi, > >>> > >>> I updated our Jenkins server for the JDK 9 preview testing to use build > 148. > >> Previously we had build 140 and build 147, which both worked without > any > >> issues. But after the update the following stuff goes wrong: > >>> > >>> (1) Unmapping of direct buffers no longer works, although this API was > >> marked as critical because there is no replacement up to now, so code can > >> unmap memory mapped files, which is one of the most important things > >> Apache Lucene needs to use to access huge random access files while > >> reading the index. Without memory mapping, the slowdown for Lucene > >> users will be huge > >>> > >>> This is caused by the recent Jigsaw changes, published in build 148. > >> Unfortunately we did not test the Jigsaw builds, so we would have noticed > >> that earlier. Basically the following peace of code fails now (with or > without > >> doPrivileged and with/without security manager): > >>> > >>> final Class directBufferClass = > >> Class.forName("java.nio.DirectByteBuffer"); > >>> > >>> final Method m = directBufferClass.getMethod("cleaner"); > >>> m.setAccessible(true); > >>> MethodHandle directBufferCleanerMethod = lookup.unreflect(m); > >>> Class cleanerClass = > >> directBufferCleanerMethod.type().returnType(); > >>> // build method handle for unmapping, full code is here: > >> https://goo.gl/TfQWl6 > >> > >> I guess that is the effect of #AwkwardStrongEncapsulation. I would > >> advise doing regular checks against the jigsaw builds to know about such > >> problems in the future earlier... but seeing your code break without an > >> obvious good solution sure is stressful. I feel with you. > >> > >> [...] > >>> (2) A second thing we noticed is that Groovy no longer works and dies > with > >> strange error messages. > >> > >> That is because versions including Groovy 2.4.7 are using > >> setAccessible(AccessibleObject[] array, true), and the array will also > >> include private methods or fields. This worked till > >> #AwkwardStrongEncapsulation because will then a class was either > >> exported and its method can all be made accessible or not. For example > >> on GAE or earlier versions of the module system. Now an exported class > >> may break this, since its private methods can no longer be made > >> accessible using setAccessible. > >> > >> A fix for this is already committed, we are only waiting for release of > >> Groovy 2.4.8. Of course even with the fix Groovy code can possibly > >> break... for example if you did the direct buffer access in Groovy. > >> > >> Btw, do not hesitate to ask about such problems on groovy-user, please. > >> > >> bye Jochen > > From peter.levart at gmail.com Mon Dec 26 18:31:22 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 26 Dec 2016 19:31:22 +0100 Subject: RFR 8171988: backout of 8062389, 8029459, 8061950 In-Reply-To: References: <221ca324-be41-9c74-89be-606e31ae93d3@gmail.com> <98DA94D5-F43B-491C-8DE7-EE2FF030920B@oracle.com> <47940b37-b09c-0888-d031-beefe9f5bcab@oracle.com> <09F19C0B-B0D8-4FF2-BD53-080EAAEA8974@oracle.com> Message-ID: <7a95546d-4b5b-190b-46db-3a6f3168eece@gmail.com> Hi, I see there remaining failures are not trivial to fix in a hurry. So I think it's better to just backout this change and than prepare new fix... I'm pushing this backout now. Regards, Peter On 12/26/2016 06:55 PM, Claes Redestad wrote: > Hi, > > many of the tier 1 failures listed seems to fail due to a cyclic > bootstrap dependency on the new PublicMethods -> Policy.isSet() -> > ... -> PublicMethods that appears in all tests which install a > security manager. > > It turns out the dependency is only there (Policy.isSet) to ensure the > VM has booted to a state where System.getProperty will return actual > values to feed into sun.security.util.Debug (the state of which does > not in any way vary with Policy), and could be replaced by the new > VM.isBooted() (or VM.initLevel() > 1): > > http://cr.openjdk.java.net/~redestad/scratch/8171988.01/ > > With this most test failures disappear, but there are still 5 tests > in java/lang/Class which fail with a message more directly related to > the changes: > > expected java.lang.NullPointerException for null -- FAILED > > Perhaps problem list these 5 together with the above change as a fix to > this issue? > > Thanks! > > /Claes > > On 2016-12-26 18:30, Chris Hegarty wrote: >> >>> On 26 Dec 2016, at 16:26, joe darcy wrote: >>> >>> Hello, >>> >>> Assuming we'll want to revisit this work at some point, there are >>> some advantages to anti-delta-ing the code changes now, but just >>> problem listing the tests in terms of making a less confusing history. >> >> My preference is to anti-delta. There are just too many tests >> failing, ~35 across all platforms and tiers. >> >> Peter, >> Let me know if you need any help pushing this. >> >> -Chris. >> >> >>> Thanks, >>> >>> -Joe >>> >>> >>> On 12/26/2016 1:58 AM, Chris Hegarty wrote: >>>>> On 26 Dec 2016, at 09:35, Peter Levart >>>>> wrote: >>>>> >>>>> Hi Jeff, >>>>> >>>>> I've been told that the latest change I pushed causes some tests >>>>> to fail, so I prepared a backout patch for 8062389, 8029459, 8061950: >>>>> >>>>> http://cr.openjdk.java.net/~plevart/jdk9-dev/Class.getMethods.new/backout.09/webrev.01/ >>>>> >>>>> >>>> I just grabbed the webrev patch, applied it to a local repo, then >>>> compared that against a repo that had been updated to the >>>> change prior to your push. They are identical, so this appears >>>> to be an accurate anti-delta. >>>> >>>> Maybe file a new bug, or just make it clear in the synopsis of >>>> 8171988 that it is an anti-delta. >>>> >>>> >>>>> From the stacktrace of the bug report, it seems an early >>>>> initialization issue with VarHandle(s) involved. Can you shed some >>>>> light into what tests are failing? >>>> I?ll post a few comments in 8171988 with sample failures. >>>> >>>> -Chris. >>>> >>>>> But first let us backout that change. >>>>> >>>>> Regards, Peter >>>>> >>>>>> On 12/26/2016 10:09 AM, Peter Levart wrote: >>>>>> Hi Jeff, >>>>>> >>>>>> I'm taking a look at this... >>>>>> >>>>>> Regards, Peter >>>>>> >>>>>>> On 12/26/2016 06:14 AM, Jeff Dinkins wrote: >>>>>>> Hi Peter - >>>>>>> >>>>>>> I just received mail from out SQE manager, saying that your last >>>>>>> changeset has caused our test harness to hiccup. I don?t have >>>>>>> much more detail besides the below bug, but I?m wondering if you >>>>>>> could do us a huge favor and roll your change back for now while >>>>>>> it?s debugged (and so we can get our automated tests going again). >>>>>>> >>>>>>> https://bugs.openjdk.java.net/browse/JDK-8171988 >>>>>>> >>>>>>> >>>>>>> thanks! >>>>>>> >>>>>>> -jeff >>>>>>> >>> >> From abhijit.r.roy at oracle.com Mon Dec 26 18:40:47 2016 From: abhijit.r.roy at oracle.com (Abhijit Roy) Date: Tue, 27 Dec 2016 00:10:47 +0530 Subject: RFR JDK-8171348: Incorrect documentation for DateTimeFormatter letter 'k' In-Reply-To: <407bb2be-5926-7732-e6fc-c4785dac7e2f@oracle.com> References: <39582be1-d2ad-4188-ab7f-0082258d1f0c@default> <1af7f582-f07c-1a71-521c-8d73bac68249@Oracle.com> <196d5a53-dc3b-0ba4-67b9-ce2fda1610fe@Oracle.com> <353a2b2d-032f-320e-6305-6248946fc32a@oracle.com> <407bb2be-5926-7732-e6fc-c4785dac7e2f@oracle.com> Message-ID: Hi Roger, Could you please push it for 9ea? If so, please find the attached changeset files. Regards Abhijit On 12/21/2016 7:53 PM, Roger Riggs wrote: > Hi Abhijit, > > Looks fine to push with this additional change to make the > descriptions of 'F' match. > > Thanks, Roger > > > On 12/21/16 7:16 AM, Ivan Gerasimov wrote: >> Hi Abhijt! >> >> As you're changing the description of 'F' pattern in >> DateTimeFormatterBuilder, it makes sense to do the same in >> DateTimeFormatter. >> >> With kind regards, >> Ivan >> >> >> On 21.12.2016 9:30, Abhijit Roy wrote: >>> Hi Roger, >>> >>> I have fixed the same error in DateTimeFormatterBuiler. Please see >>> the updated webrev below. >>> >>> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.01/ >>> >>> Thanks >>> Abhijit >>> >>> >>> On 12/16/2016 8:01 PM, Roger Riggs wrote: >>>> Hi, >>>> >>>> Sorry, I meant DateTimeFormatterBuilder. >>>> >>>> Roger >>>> >>>> >>>> On 12/16/2016 9:28 AM, Roger Riggs wrote: >>>>> Hi Abhijit, >>>>> >>>>> Please also fix the same error in DateTimeFormatter; line 300. >>>>> >>>>> I would use '24' as the example of the hour of day. >>>>> It would emphasize that the range is 1-24. >>>>> >>>>> Roger >>>>> >>>>> >>>>> On 12/16/2016 6:19 AM, Abhijit Roy wrote: >>>>>> Hi all, >>>>>> >>>>>> >>>>>> Please review the java doc fix for the below bug: >>>>>> >>>>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8171348 >>>>>> >>>>>> Description: Incorrect documentation for DateTimeFormatter letter >>>>>> 'k' >>>>>> >>>>>> Webrev: http://cr.openjdk.java.net/~rpatil/8171348/webrev.00/ >>>>>> >>>>>> >>>>>> I have just rectified and modified those errors. And moving >>>>>> forward it for review. >>>>>> >>>>>> >>>>>> Regards, >>>>>> >>>>>> Abhijit >>>>>> >>>>>> >>>>>> >>>>>> P.S. It will be merged with RFR: JDK-8164923, JDK-8170566, >>>>>> JDK-8169482, JDK-8170653 >>>>> >>>> >>> >>> >> > -------------- next part -------------- # HG changeset patch # User Abhijit Roy # Date 1482429952 -19800 # Thu Dec 22 23:35:52 2016 +0530 # Node ID d25f6a50496155bc519104863e8adbe6a25af330 # Parent c709e74ffcf65e82043ecd2370217e0df2805257 8164923: Error in the documentation for java.lang.Random Reviewed-by: rriggs Contributed-by: abhijit.r.roy at oracle.com diff -r c709e74ffcf6 -r d25f6a504961 src/java.base/share/classes/java/util/Random.java --- a/src/java.base/share/classes/java/util/Random.java Tue Sep 20 08:46:33 2016 +0200 +++ b/src/java.base/share/classes/java/util/Random.java Thu Dec 22 23:35:52 2016 +0530 @@ -187,7 +187,7 @@ * * This is a linear congruential pseudorandom number generator, as * defined by D. H. Lehmer and described by Donald E. Knuth in - * The Art of Computer Programming, Volume 3: + * The Art of Computer Programming, Volume 2: * Seminumerical Algorithms, section 3.2.1. * * @param bits random bits @@ -570,7 +570,7 @@ * }} * This uses the polar method of G. E. P. Box, M. E. Muller, and * G. Marsaglia, as described by Donald E. Knuth in The Art of - * Computer Programming, Volume 3: Seminumerical Algorithms, + * Computer Programming, Volume 2: Seminumerical Algorithms, * section 3.4.1, subsection C, algorithm P. Note that it generates two * independent values at the cost of only one call to {@code StrictMath.log} * and one call to {@code StrictMath.sqrt}. -------------- next part -------------- # HG changeset patch # User Abhijit Roy # Date 1482773246 -19800 # Mon Dec 26 22:57:26 2016 +0530 # Node ID 47a681cd74eec8c0b913e13a0dc85933d2d9ee95 # Parent ce85bfbe98b0471b4aa8ce504d078e8c1a5b4e0e 8169482: java.time.DateTimeFormatter javadoc: F is not week-of-month Reviewed-by: rriggs Contributed-by: abhijit.r.roy at oracle.com diff -r ce85bfbe98b0 -r 47a681cd74ee src/java.base/share/classes/java/time/format/DateTimeFormatter.java --- a/src/java.base/share/classes/java/time/format/DateTimeFormatter.java Sun Dec 25 19:29:06 2016 +0100 +++ b/src/java.base/share/classes/java/time/format/DateTimeFormatter.java Mon Dec 26 22:57:26 2016 +0530 @@ -292,7 +292,7 @@ * W week-of-month number 4 * E day-of-week text Tue; Tuesday; T * e/c localized day-of-week number/text 2; 02; Tue; Tuesday; T - * F week-of-month number 3 + * F day-of-week-in-month number 3 * * a am-pm-of-day text PM * h clock-hour-of-am-pm (1-12) number 12 -------------- next part -------------- # HG changeset patch # User Abhijit Roy # Date 1482773994 -19800 # Mon Dec 26 23:09:54 2016 +0530 # Node ID 45de439dcca920dad3ccfa4366f843a0285eb606 # Parent ce85bfbe98b0471b4aa8ce504d078e8c1a5b4e0e 8170566: Incorrect phrase usage in javadocs documentation Reviewed-by: rriggs Contributed-by: abhijit.r.roy at oracle.com diff -r ce85bfbe98b0 -r 45de439dcca9 src/java.base/share/classes/java/util/function/package-info.java --- a/src/java.base/share/classes/java/util/function/package-info.java Sun Dec 25 19:29:06 2016 +0100 +++ b/src/java.base/share/classes/java/util/function/package-info.java Mon Dec 26 23:09:54 2016 +0530 @@ -74,7 +74,7 @@ * {@link java.util.function.Function} (unary function from {@code T} to {@code R}), * {@link java.util.function.Consumer} (unary function from {@code T} to {@code void}), * {@link java.util.function.Predicate} (unary function from {@code T} to {@code boolean}), - * and {@link java.util.function.Supplier} (nilary function to {@code R}). + * and {@link java.util.function.Supplier} (nullary function to {@code R}). *

      • * *
    • Function shapes have a natural arity based on how they are most -------------- next part -------------- # HG changeset patch # User Abhijit Roy # Date 1482774306 -19800 # Mon Dec 26 23:15:06 2016 +0530 # Node ID 225b6ff18cda2c2a88a45784b4d0462246c1b1cc # Parent ce85bfbe98b0471b4aa8ce504d078e8c1a5b4e0e 8170653: The javadoc of ZoneRules.previousTransition() is wrong Reviewed-by: rriggs Contributed-by: abhijit.r.roy at oracle.com diff -r ce85bfbe98b0 -r 225b6ff18cda src/java.base/share/classes/java/time/zone/ZoneRules.java --- a/src/java.base/share/classes/java/time/zone/ZoneRules.java Sun Dec 25 19:29:06 2016 +0100 +++ b/src/java.base/share/classes/java/time/zone/ZoneRules.java Mon Dec 26 23:15:06 2016 +0530 @@ -871,13 +871,13 @@ /** * Gets the previous transition before the specified instant. *

      - * This returns details of the previous transition after the specified instant. + * This returns details of the previous transition before the specified instant. * For example, if the instant represents a point where "summer" daylight saving time * applies, then the method will return the transition from the previous "winter" time. * * @param instant the instant to get the previous transition after, not null, but null * may be ignored if the rules have a single offset for all instants - * @return the previous transition after the specified instant, null if this is before the first transition + * @return the previous transition before the specified instant, null if this is before the first transition */ public ZoneOffsetTransition previousTransition(Instant instant) { if (savingsInstantTransitions.length == 0) { -------------- next part -------------- # HG changeset patch # User Abhijit Roy # Date 1482774657 -19800 # Mon Dec 26 23:20:57 2016 +0530 # Node ID 94c26e762952f03c08f9d05c8c5ba1a897fcccf1 # Parent ce85bfbe98b0471b4aa8ce504d078e8c1a5b4e0e 8171348: Incorrect documentation for DateTimeFormatter letter 'k' Reviewed-by: rriggs Contributed-by: abhijit.r.roy at oracle.com diff -r ce85bfbe98b0 -r 94c26e762952 src/java.base/share/classes/java/time/format/DateTimeFormatter.java --- a/src/java.base/share/classes/java/time/format/DateTimeFormatter.java Sun Dec 25 19:29:06 2016 +0100 +++ b/src/java.base/share/classes/java/time/format/DateTimeFormatter.java Mon Dec 26 23:20:57 2016 +0530 @@ -297,7 +297,7 @@ * a am-pm-of-day text PM * h clock-hour-of-am-pm (1-12) number 12 * K hour-of-am-pm (0-11) number 0 - * k clock-hour-of-am-pm (1-24) number 0 + * k clock-hour-of-day (1-24) number 24 * * H hour-of-day (0-23) number 0 * m minute-of-hour number 30 diff -r ce85bfbe98b0 -r 94c26e762952 src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java --- a/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Sun Dec 25 19:29:06 2016 +0100 +++ b/src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java Mon Dec 26 23:20:57 2016 +0530 @@ -1486,12 +1486,12 @@ * W week-of-month number 4 * E day-of-week text Tue; Tuesday; T * e/c localized day-of-week number/text 2; 02; Tue; Tuesday; T - * F week-of-month number 3 + * F day-of-week-in-month number 3 * * a am-pm-of-day text PM * h clock-hour-of-am-pm (1-12) number 12 * K hour-of-am-pm (0-11) number 0 - * k clock-hour-of-am-pm (1-24) number 0 + * k clock-hour-of-day (1-24) number 24 * * H hour-of-day (0-23) number 0 * m minute-of-hour number 30 From peter.levart at gmail.com Mon Dec 26 19:29:36 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 26 Dec 2016 20:29:36 +0100 Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager Message-ID: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> Hi, There are 2 ReflectionFactory classes in JDK 9. The old one is sun.reflect.ReflectionFactory which ended in jdk.unsupported module and to which access is restricted with SecurityManager. There is also new jdk.internal.reflect.ReflectionFactory which is used internally by JDK, is exported to internal modules only but still uses SecurityManager to restrict access to itself. I checked all usages and they all use AccessControler.doPrivileged() for obtaining the instance of jdk.internal.reflect.ReflectionFactory, which somehow defeats the purpose of SecurityManager access checks in this API. I think this could be simplified by removing the SecurityManager check from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static method and change all usages to invoke this method directly without doPrivileged(). There are already two sensitive internal APIs exposed without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why wouldn't internal ReflectionFactory be exposed the same way? This would make obtaining the ReflectionFactory more robust and not sensitive to bootstrap issues that surfaced recently after my push of a fix for issues 8062389, 8029459, 8061950. So, what do you think? Is this a worthwhile cleanup and simplification? Regards, Peter From claes.redestad at oracle.com Mon Dec 26 20:11:55 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 26 Dec 2016 21:11:55 +0100 Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager In-Reply-To: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> Message-ID: <46028554-00d1-85ff-376b-095c5388703c@oracle.com> Hi, with strong encapsulation in place this seems perfectly fine to me. The only downside is that we will lose the extra reminder that the ReflectionFactory must not escape to untrusted code, but I think we can all help ensure that doesn't happen, right? :-) Thanks! /Claes On 2016-12-26 20:29, Peter Levart wrote: > Hi, > > There are 2 ReflectionFactory classes in JDK 9. The old one is > sun.reflect.ReflectionFactory which ended in jdk.unsupported module and > to which access is restricted with SecurityManager. There is also new > jdk.internal.reflect.ReflectionFactory which is used internally by JDK, > is exported to internal modules only but still uses SecurityManager to > restrict access to itself. I checked all usages and they all use > AccessControler.doPrivileged() for obtaining the instance of > jdk.internal.reflect.ReflectionFactory, which somehow defeats the > purpose of SecurityManager access checks in this API. > > I think this could be simplified by removing the SecurityManager check > from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static > method and change all usages to invoke this method directly without > doPrivileged(). There are already two sensitive internal APIs exposed > without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and > various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why > wouldn't internal ReflectionFactory be exposed the same way? > > This would make obtaining the ReflectionFactory more robust and not > sensitive to bootstrap issues that surfaced recently after my push of a > fix for issues 8062389, 8029459, 8061950. > > So, what do you think? Is this a worthwhile cleanup and simplification? > > Regards, Peter > From peter.levart at gmail.com Mon Dec 26 20:39:24 2016 From: peter.levart at gmail.com (Peter Levart) Date: Mon, 26 Dec 2016 21:39:24 +0100 Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager In-Reply-To: <46028554-00d1-85ff-376b-095c5388703c@oracle.com> References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> <46028554-00d1-85ff-376b-095c5388703c@oracle.com> Message-ID: Hi Claes, On 12/26/2016 09:11 PM, Claes Redestad wrote: > Hi, > > with strong encapsulation in place this seems perfectly fine to me. > > The only downside is that we will lose the extra reminder that the > ReflectionFactory must not escape to untrusted code, but I think we can > all help ensure that doesn't happen, right? :-) With strong encapsulation in place, if the ReflectionFactory escaped, it could only be used by the following modules: exports jdk.internal.reflect to java.corba, java.logging, java.sql, java.sql.rowset, jdk.dynalink, jdk.scripting.nashorn, jdk.unsupported; If SecurityManager check was removed, those modules could then also obtain ReflectionFactory (they currently don't use it except jdk.unsupported). Does this present any new danger? Changes needed to support removal of this SecurityManager check are as follows: http://cr.openjdk.java.net/~plevart/jdk9-dev/ReflectionFactory.withoutSM/webrev.01/ Changes mostly remove the need to store ReflectionFactory into a variable, therefore they encourage style where ReflectionFactory is less likely to escape. Regards, Peter > > Thanks! > > /Claes > > On 2016-12-26 20:29, Peter Levart wrote: >> Hi, >> >> There are 2 ReflectionFactory classes in JDK 9. The old one is >> sun.reflect.ReflectionFactory which ended in jdk.unsupported module and >> to which access is restricted with SecurityManager. There is also new >> jdk.internal.reflect.ReflectionFactory which is used internally by JDK, >> is exported to internal modules only but still uses SecurityManager to >> restrict access to itself. I checked all usages and they all use >> AccessControler.doPrivileged() for obtaining the instance of >> jdk.internal.reflect.ReflectionFactory, which somehow defeats the >> purpose of SecurityManager access checks in this API. >> >> I think this could be simplified by removing the SecurityManager check >> from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static >> method and change all usages to invoke this method directly without >> doPrivileged(). There are already two sensitive internal APIs exposed >> without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and >> various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why >> wouldn't internal ReflectionFactory be exposed the same way? >> >> This would make obtaining the ReflectionFactory more robust and not >> sensitive to bootstrap issues that surfaced recently after my push of a >> fix for issues 8062389, 8029459, 8061950. >> >> So, what do you think? Is this a worthwhile cleanup and simplification? >> >> Regards, Peter >> From claes.redestad at oracle.com Mon Dec 26 20:55:19 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Mon, 26 Dec 2016 21:55:19 +0100 Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager In-Reply-To: References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> <46028554-00d1-85ff-376b-095c5388703c@oracle.com> Message-ID: <93d4147f-f6ad-50c2-f34b-67c1f82a8c3e@oracle.com> On 2016-12-26 21:39, Peter Levart wrote: > Hi Claes, > > On 12/26/2016 09:11 PM, Claes Redestad wrote: >> Hi, >> >> with strong encapsulation in place this seems perfectly fine to me. >> >> The only downside is that we will lose the extra reminder that the >> ReflectionFactory must not escape to untrusted code, but I think we can >> all help ensure that doesn't happen, right? :-) > > With strong encapsulation in place, if the ReflectionFactory escaped, it > could only be used by the following modules: > > exports jdk.internal.reflect to > java.corba, > java.logging, > java.sql, > java.sql.rowset, > jdk.dynalink, > jdk.scripting.nashorn, > jdk.unsupported; > > > If SecurityManager check was removed, those modules could then also > obtain ReflectionFactory (they currently don't use it except > jdk.unsupported). Does this present any new danger? Right, it shouldn't be possible to do anything with a reference to an encapsulated object, but let's not challenge this assumption here and now. > > Changes needed to support removal of this SecurityManager check are as > follows: > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/ReflectionFactory.withoutSM/webrev.01/ > > Changes mostly remove the need to store ReflectionFactory into a > variable, therefore they encourage style where ReflectionFactory is less > likely to escape. That's a good point, and changes looks good to me. I think this could go as both a standalone cleanup and rolled into a redo of 8062389 etc. Thanks! /Claes > > Regards, Peter > > >> >> Thanks! >> >> /Claes >> >> On 2016-12-26 20:29, Peter Levart wrote: >>> Hi, >>> >>> There are 2 ReflectionFactory classes in JDK 9. The old one is >>> sun.reflect.ReflectionFactory which ended in jdk.unsupported module and >>> to which access is restricted with SecurityManager. There is also new >>> jdk.internal.reflect.ReflectionFactory which is used internally by JDK, >>> is exported to internal modules only but still uses SecurityManager to >>> restrict access to itself. I checked all usages and they all use >>> AccessControler.doPrivileged() for obtaining the instance of >>> jdk.internal.reflect.ReflectionFactory, which somehow defeats the >>> purpose of SecurityManager access checks in this API. >>> >>> I think this could be simplified by removing the SecurityManager check >>> from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static >>> method and change all usages to invoke this method directly without >>> doPrivileged(). There are already two sensitive internal APIs exposed >>> without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and >>> various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why >>> wouldn't internal ReflectionFactory be exposed the same way? >>> >>> This would make obtaining the ReflectionFactory more robust and not >>> sensitive to bootstrap issues that surfaced recently after my push of a >>> fix for issues 8062389, 8029459, 8061950. >>> >>> So, what do you think? Is this a worthwhile cleanup and simplification? >>> >>> Regards, Peter >>> > From david.holmes at oracle.com Mon Dec 26 21:16:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Dec 2016 07:16:15 +1000 Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager In-Reply-To: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> Message-ID: <2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com> Hi Peter, I know this is response to the problems with your other recent change, but this is an enhancement in my opinion, not a bug fix, and the time for enhancements is passed - though there is still a process to request them. I do not like to see last minutes changes like this where not enough due diligence may be done to identify all the ramifications. The Class.getMethod() fixes seem to have overstepped the line in that regard as well, in my opinion. Anything that potentially changes initialization order is fragile and risky and requires additional testing. That said, I am an admirer of your work on OpenJDK! :) Cheers, David On 27/12/2016 5:29 AM, Peter Levart wrote: > Hi, > > There are 2 ReflectionFactory classes in JDK 9. The old one is > sun.reflect.ReflectionFactory which ended in jdk.unsupported module and > to which access is restricted with SecurityManager. There is also new > jdk.internal.reflect.ReflectionFactory which is used internally by JDK, > is exported to internal modules only but still uses SecurityManager to > restrict access to itself. I checked all usages and they all use > AccessControler.doPrivileged() for obtaining the instance of > jdk.internal.reflect.ReflectionFactory, which somehow defeats the > purpose of SecurityManager access checks in this API. > > I think this could be simplified by removing the SecurityManager check > from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static > method and change all usages to invoke this method directly without > doPrivileged(). There are already two sensitive internal APIs exposed > without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and > various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why > wouldn't internal ReflectionFactory be exposed the same way? > > This would make obtaining the ReflectionFactory more robust and not > sensitive to bootstrap issues that surfaced recently after my push of a > fix for issues 8062389, 8029459, 8061950. > > So, what do you think? Is this a worthwhile cleanup and simplification? > > Regards, Peter > From claes.redestad at oracle.com Mon Dec 26 23:48:31 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Dec 2016 00:48:31 +0100 Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager In-Reply-To: <2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com> References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> <2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com> Message-ID: <6382cad1-a663-e049-b8cd-2a31d6dd33f9@oracle.com> Hi, while perhaps an enhancement in isolation, I'll argue this to be a blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that has been long in the making - thus I don't agree that the time for this has passed, and neither do I think this needs a critical approval request if it's pushed to enable a redo of JDK-8062389 et al. Thanks! /Claes On 2016-12-26 22:16, David Holmes wrote: > Hi Peter, > > I know this is response to the problems with your other recent change, > but this is an enhancement in my opinion, not a bug fix, and the time > for enhancements is passed - though there is still a process to request > them. I do not like to see last minutes changes like this where not > enough due diligence may be done to identify all the ramifications. > > The Class.getMethod() fixes seem to have overstepped the line in that > regard as well, in my opinion. Anything that potentially changes > initialization order is fragile and risky and requires additional testing. > > That said, I am an admirer of your work on OpenJDK! :) > > Cheers, > David > > > On 27/12/2016 5:29 AM, Peter Levart wrote: >> Hi, >> >> There are 2 ReflectionFactory classes in JDK 9. The old one is >> sun.reflect.ReflectionFactory which ended in jdk.unsupported module and >> to which access is restricted with SecurityManager. There is also new >> jdk.internal.reflect.ReflectionFactory which is used internally by JDK, >> is exported to internal modules only but still uses SecurityManager to >> restrict access to itself. I checked all usages and they all use >> AccessControler.doPrivileged() for obtaining the instance of >> jdk.internal.reflect.ReflectionFactory, which somehow defeats the >> purpose of SecurityManager access checks in this API. >> >> I think this could be simplified by removing the SecurityManager check >> from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static >> method and change all usages to invoke this method directly without >> doPrivileged(). There are already two sensitive internal APIs exposed >> without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and >> various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why >> wouldn't internal ReflectionFactory be exposed the same way? >> >> This would make obtaining the ReflectionFactory more robust and not >> sensitive to bootstrap issues that surfaced recently after my push of a >> fix for issues 8062389, 8029459, 8061950. >> >> So, what do you think? Is this a worthwhile cleanup and simplification? >> >> Regards, Peter >> From david.holmes at oracle.com Tue Dec 27 01:02:54 2016 From: david.holmes at oracle.com (David Holmes) Date: Tue, 27 Dec 2016 11:02:54 +1000 Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager In-Reply-To: <6382cad1-a663-e049-b8cd-2a31d6dd33f9@oracle.com> References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> <2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com> <6382cad1-a663-e049-b8cd-2a31d6dd33f9@oracle.com> Message-ID: <74f47972-493c-674d-cf87-5f56ea1fd475@oracle.com> Hi Claes, On 27/12/2016 9:48 AM, Claes Redestad wrote: > Hi, > > while perhaps an enhancement in isolation, I'll argue this to be a > blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that At this stage I would categorise it as one possible way to work around the issue that JDK-8062389 et al. ran into. The initialization sequence is fragile and is not a constant - different runtime options can affect the paths taken. So testing anything that introduces a change to initialization order is tricky, as there is no obvious set of tests that provide full coverage. Cheers, David > has been long in the making - thus I don't agree that the time for this > has passed, and neither do I think this needs a critical approval > request if it's pushed to enable a redo of JDK-8062389 et al. > > Thanks! > > /Claes > > > On 2016-12-26 22:16, David Holmes wrote: >> Hi Peter, >> >> I know this is response to the problems with your other recent change, >> but this is an enhancement in my opinion, not a bug fix, and the time >> for enhancements is passed - though there is still a process to request >> them. I do not like to see last minutes changes like this where not >> enough due diligence may be done to identify all the ramifications. >> >> The Class.getMethod() fixes seem to have overstepped the line in that >> regard as well, in my opinion. Anything that potentially changes >> initialization order is fragile and risky and requires additional >> testing. >> >> That said, I am an admirer of your work on OpenJDK! :) >> >> Cheers, >> David >> >> >> On 27/12/2016 5:29 AM, Peter Levart wrote: >>> Hi, >>> >>> There are 2 ReflectionFactory classes in JDK 9. The old one is >>> sun.reflect.ReflectionFactory which ended in jdk.unsupported module and >>> to which access is restricted with SecurityManager. There is also new >>> jdk.internal.reflect.ReflectionFactory which is used internally by JDK, >>> is exported to internal modules only but still uses SecurityManager to >>> restrict access to itself. I checked all usages and they all use >>> AccessControler.doPrivileged() for obtaining the instance of >>> jdk.internal.reflect.ReflectionFactory, which somehow defeats the >>> purpose of SecurityManager access checks in this API. >>> >>> I think this could be simplified by removing the SecurityManager check >>> from jdk.internal.reflect.ReflectionFactory#getReflectionFactory static >>> method and change all usages to invoke this method directly without >>> doPrivileged(). There are already two sensitive internal APIs exposed >>> without SecurityManager checks: jdk.internal.misc.Unsafe#getUnsafe and >>> various jdk.internal.misc.SharedSecrets#getXxxAccess methods. So why >>> wouldn't internal ReflectionFactory be exposed the same way? >>> >>> This would make obtaining the ReflectionFactory more robust and not >>> sensitive to bootstrap issues that surfaced recently after my push of a >>> fix for issues 8062389, 8029459, 8061950. >>> >>> So, what do you think? Is this a worthwhile cleanup and simplification? >>> >>> Regards, Peter >>> From claes.redestad at oracle.com Tue Dec 27 02:38:50 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Dec 2016 03:38:50 +0100 Subject: jdk.internal.reflect.ReflectionFactory and SecurityManager In-Reply-To: <74f47972-493c-674d-cf87-5f56ea1fd475@oracle.com> References: <2a6d2f85-b3c9-0658-6684-34c1a90aa22b@gmail.com> <2584fe72-ccf8-30d3-72bc-7cad0a6b7845@oracle.com> <6382cad1-a663-e049-b8cd-2a31d6dd33f9@oracle.com> <74f47972-493c-674d-cf87-5f56ea1fd475@oracle.com> Message-ID: <0c5be2a7-4091-dcb5-690a-f117c9d60032@oracle.com> On 2016-12-27 02:02, David Holmes wrote: > Hi Claes, > > On 27/12/2016 9:48 AM, Claes Redestad wrote: >> Hi, >> >> while perhaps an enhancement in isolation, I'll argue this to be a >> blocker of or a sub-task of the redo of JDK-8062389 - a P2 bug that > > At this stage I would categorise it as one possible way to work around > the issue that JDK-8062389 et al. ran into. Agreed that if a better/simpler fix comes around we should run with it and defer any further enhancemeents that's not critical, but I don't think we should block this on the premise that there might be such a fix around the corner. Some due diligence is of course in order. > > The initialization sequence is fragile and is not a constant - different > runtime options can affect the paths taken. So testing anything that > introduces a change to initialization order is tricky, as there is no > obvious set of tests that provide full coverage. > I agree that the initialization sequence is fragile and that we need to test anything we do in it thoroughly, but I'd also assert that by removing the need for doing SM.checkPermission calls (and the doPrivileged calls needed to subdue them) we are likely to reduce fragility, not increase it, ultimately decreasing the likelihood of issues. With more along the lines of what Peter is suggesting here we might even be able to support lambdas in security managers one day: https://bugs.openjdk.java.net/browse/JDK-8155659 Thanks! /Claes From nadeesh.tv at oracle.com Tue Dec 27 06:04:11 2016 From: nadeesh.tv at oracle.com (nadeesh tv) Date: Tue, 27 Dec 2016 11:34:11 +0530 Subject: RFR(s): 8171958: Several tests from java/time/test/java/time/format requiring jdk.localedata for execution In-Reply-To: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com> References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com> Message-ID: <5862045B.4080001@oracle.com> Hi Sergei, I could see you modified tests only in /test/java/time/*test*/java/time/format/ directory. Won't the tests from test/java/time/*tck*/java/time/format/ directory fail with same issue? Thanks and Regards, Nadeesh On 12/26/2016 8:27 PM, Sergei Kovalev wrote: > Hello Team, > > Please review below fix for tests. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958 > Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/ > > Issue: some tests fails in case of module limitation by > '--limit-module java.base' command line option. > Root cause: The tests uses locale data that stored in separate > resource file "jdk.localedata". > Solution: Add declaration of required module. In same cases a test > file contains many test items, part of which could be executed with > java.base module only. In this cases we can separate the items and > extract that items which depend on locale data and run them > individually. Therefore this proposal contains additional test files > where added "WithLocale" suffix which demonstrate dependency on > resources. Alternative solution could be add a required module > declaration "jdk.localedata" to all files. However this will lead to > unnecessary test coverage reduction. > -- Thanks and Regards, Nadeesh TV From sergei.kovalev at oracle.com Tue Dec 27 08:59:40 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Tue, 27 Dec 2016 11:59:40 +0300 Subject: RFR(s): 8171958: Several tests from java/time/test/java/time/format requiring jdk.localedata for execution In-Reply-To: <5862045B.4080001@oracle.com> References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com> <5862045B.4080001@oracle.com> Message-ID: <94955c17-acd7-6c05-9875-353aabc473b5@oracle.com> Hi Nadeesh, I cannot say for sure does tck tests have same issue or not because now they broken and failing as with limited JRE as well with full JDK. To make sure if we have same issue with tck tests we need to fix them first. I can take a look at the problem in separate CR. An example of failure you can find in attachment. 27.12.16 09:04, nadeesh tv wrote: > Hi Sergei, > > I could see you modified tests only in > /test/java/time/*test*/java/time/format/ directory. > > Won't the tests from test/java/time/*tck*/java/time/format/ directory > fail with same issue? > > Thanks and Regards, > Nadeesh > > On 12/26/2016 8:27 PM, Sergei Kovalev wrote: >> Hello Team, >> >> Please review below fix for tests. >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958 >> Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/ >> >> Issue: some tests fails in case of module limitation by >> '--limit-module java.base' command line option. >> Root cause: The tests uses locale data that stored in separate >> resource file "jdk.localedata". >> Solution: Add declaration of required module. In same cases a test >> file contains many test items, part of which could be executed with >> java.base module only. In this cases we can separate the items and >> extract that items which depend on locale data and run them >> individually. Therefore this proposal contains additional test files >> where added "WithLocale" suffix which demonstrate dependency on >> resources. Alternative solution could be add a required module >> declaration "jdk.localedata" to all files. However this will lead to >> unnecessary test coverage reduction. >> > > -- > Thanks and Regards, > Nadeesh TV > -- With best regards, Sergei -------------- next part -------------- #Test Results (version 2) #Thu Dec 22 20:55:18 MSK 2016 #-----testdescription----- $file=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java $root=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test keywords=testng library=/lib/testlibrary/ modules=java.base/java.time\:open java.base/java.time.chrono\:open java.base/java.time.zone\:open packageRoot=java/time/ run=ASSUMED_ACTION testng tck.java.time.format.TCKDateTimeParseResolver\n source=TCKDateTimeParseResolver.java testngClass=tck.java.time.format.TCKDateTimeParseResolver title=\ #-----environment----- #-----testresult----- description=file\:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java elapsed=33384 0\:00\:33.384 end=Thu Dec 22 20\:55\:18 MSK 2016 environment=regtest execStatus=Failed. Execution failed\: `main' threw exception\: java.lang.Exception\: failures\: 19 harnessLoaderMode=Classpath Loader harnessVariety=Full Bundle hostname=slowpoke.ru.oracle.com javatestOS=Linux 3.2.0-38-generic (amd64) javatestVersion=4.6 jtregVersion=jtreg 4.2 fcs b05 modules=java.base/java.time\:open java.base/java.time.chrono\:open java.base/java.time.zone\:open script=com.sun.javatest.regtest.exec.RegressionScript sections=script_messages build compile compile testng start=Thu Dec 22 20\:54\:45 MSK 2016 test=java/time/tck/java/time/format/TCKDateTimeParseResolver.java testJDK=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk totalTime=33389 user.name=hudson work=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/java/time/tck/java/time/format #section:script_messages ----------messages:(7/607)---------- JDK under test: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk java version "9-internal" Java(TM) SE Runtime Environment (build 9-internal+0-2016-12-21-165144.hudson.jake) Java HotSpot(TM) 64-Bit Server VM (build 9-internal+0-2016-12-21-165144.hudson.jake, mixed mode) Library /lib/testlibrary/; kind: packages source directory: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/lib/testlibrary class directory: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/lib/testlibrary #section:build ----------messages:(7/14072)---------- command: build jdk.testlibrary.RandomFactory tck.java.time.AbstractDateTimeTest tck.java.time.TCKZonedDateTime tck.java.time.TCKZoneId tck.java.time.TCKYear tck.java.time.format.TCKDateTimeFormatter tck.java.time.format.TCKLocalizedFieldParser tck.java.time.format.TCKChronoPrinterParser tck.java.time.format.TCKPadPrinterParser tck.java.time.format.TCKInstantPrinterParser tck.java.time.format.TCKDecimalStyle tck.java.time.format.TCKDateTimeFormatters tck.java.time.format.TCKDateTimeParseResolver tck.java.time.format.TCKDateTimeTextPrinting tck.java.time.format.TCKZoneIdPrinterParser tck.java.time.format.TCKOffsetPrinterParser tck.java.time.format.TCKLocalizedPrinterParser tck.java.time.format.TCKLocalizedOffsetIdPrinterParser tck.java.time.format.TCKDTFParsedInstant tck.java.time.format.TCKSignStyle tck.java.time.format.TCKFormatStyle tck.java.time.format.TCKResolverStyle tck.java.time.format.TCKLocalizedFieldPrinter tck.java.time.format.TCKTextStyle tck.java.time.format.TCKDateTimeFormatterBuilder tck.java.time.TestIsoChronology tck.java.time.TCKMonth tck.java.time.TCKLocalDateTime tck.java.time.temporal.TCKTemporalAdjusters tck.java.time.temporal.TCKJulianFields tck.java.time.temporal.TCKIsoFields tck.java.time.temporal.serial.TCKJulianFieldsSerialization tck.java.time.temporal.serial.TCKValueRangeSerialization tck.java.time.temporal.serial.TCKWeekFieldsSerialization tck.java.time.temporal.serial.TCKChronoFieldSerialization tck.java.time.temporal.serial.TCKChronoUnitSerialization tck.java.time.temporal.TCKChronoField tck.java.time.temporal.TCKChronoUnit tck.java.time.temporal.TCKWeekFields tck.java.time.TCKClock_Tick tck.java.time.TCKClock_Fixed tck.java.time.serial.TCKZoneOffsetSerialization tck.java.time.serial.TCKDurationSerialization tck.java.time.serial.TCKZoneIdSerialization tck.java.time.serial.TCKLocalDateSerialization tck.java.time.serial.TCKLocalDateTimeSerialization tck.java.time.serial.TCKClockSerialization tck.java.time.serial.TCKOffsetTimeSerialization tck.java.time.serial.TCKZonedDateTimeSerialization tck.java.time.serial.TCKYearMonthSerialization tck.java.time.serial.TCKOffsetDateTimeSerialization tck.java.time.serial.TCKInstantSerialization tck.java.time.serial.TCKLocalTimeSerialization tck.java.time.serial.TCKMonthDaySerialization tck.java.time.serial.TCKYearSerialization tck.java.time.serial.TCKPeriodSerialization tck.java.time.TCKYearMonth tck.java.time.TCKOffsetDateTime tck.java.time.TCKClock tck.java.time.TCKDayOfWeek tck.java.time.MockSimplePeriod tck.java.time.TCKPeriod tck.java.time.TCKOffsetTime tck.java.time.TCKDuration tck.java.time.chrono.TCKHijrahEra tck.java.time.chrono.CopticEra tck.java.time.chrono.TCKTestServiceLoader tck.java.time.chrono.CopticDate tck.java.time.chrono.TCKJapaneseChronology tck.java.time.chrono.TCKChronoPeriod tck.java.time.chrono.TCKThaiBuddhistChronology tck.java.time.chrono.TCKIsoChronology tck.java.time.chrono.serial.TCKChronoZonedDateTimeSerialization tck.java.time.chrono.serial.TCKChronoLocalDateTimeSerialization tck.java.time.chrono.serial.TCKEraSerialization tck.java.time.chrono.serial.TCKChronologySerialization tck.java.time.chrono.serial.TCKCopticSerialization tck.java.time.chrono.serial.TCKChronoLocalDateSerialization tck.java.time.chrono.TCKThaiBuddhistEra tck.java.time.chrono.CopticChronology tck.java.time.chrono.TCKChronology tck.java.time.chrono.TCKChronoLocalDate tck.java.time.chrono.TCKChronoZonedDateTime tck.java.time.chrono.TCKMinguoEra tck.java.time.chrono.TCKIsoEra tck.java.time.chrono.TCKMinguoChronology tck.java.time.chrono.TCKChronoLocalDateTime tck.java.time.chrono.TCKJapaneseEra tck.java.time.chrono.TCKHijrahChronology tck.java.time.TCKLocalDate tck.java.time.TCKLocalTime tck.java.time.TCKClock_Offset tck.java.time.TCKInstant tck.java.time.TCKZoneOffset tck.java.time.zone.TCKZoneOffsetTransitionRule tck.java.time.zone.TCKZoneRulesProvider tck.java.time.zone.TCKZoneRules tck.java.time.zone.serial.TCKFixedZoneRulesSerialization tck.java.time.zone.serial.TCKZoneOffsetTransitionRuleSerialization tck.java.time.zone.serial.TCKZoneOffsetTransitionSerialization tck.java.time.zone.serial.TCKZoneRulesSerialization tck.java.time.zone.TCKFixedZoneRules tck.java.time.zone.TCKZoneOffsetTransition tck.java.time.AbstractTCKTest tck.java.time.TCKMonthDay tck.java.time.TCKClock_System test.java.util.TestFormatter test.java.time.format.TestZoneTextPrinterParser test.java.time.format.TestNarrowMonthNamesAndDayNames test.java.time.format.TestTextParser test.java.time.format.MockIOExceptionAppendable test.java.time.format.TestStringLiteralPrinter test.java.time.format.AbstractTestPrinterParser test.java.time.format.TestNonIsoFormatter test.java.time.format.TestNumberParser test.java.time.format.TestZoneOffsetPrinter test.java.time.format.TestCharLiteralPrinter test.java.time.format.TestSettingsParser test.java.time.format.TestDateTimeTextProvider test.java.time.format.TestNumberPrinter test.java.time.format.ZoneName test.java.time.format.TestReducedParser test.java.time.format.TestCharLiteralParser test.java.time.format.TestFractionPrinterParser test.java.time.format.TestStringLiteralParser test.java.time.format.TestPadPrinterDecorator test.java.time.format.TestReducedPrinter test.java.time.format.TestTextPrinter test.java.time.format.TestDateTimeFormatterBuilder test.java.time.format.TestDateTimeParsing test.java.time.format.TestDateTimeFormatter test.java.time.format.TestDecimalStyle test.java.time.format.TestZoneOffsetParser test.java.time.TestMonthDay test.java.time.TestZonedDateTime test.java.time.TestLocalTime test.java.time.temporal.MockFieldValue test.java.time.temporal.TestDateTimeBuilderCombinations test.java.time.temporal.TestDateTimeValueRange test.java.time.temporal.TestChronoField test.java.time.temporal.TestChronoUnit test.java.time.temporal.MockFieldNoValue test.java.time.temporal.TestJulianFields test.java.time.temporal.TestIsoWeekFields test.java.time.TestYearMonth test.java.time.TestYear test.java.time.TestLocalDateTime test.java.time.TestClock_Fixed test.java.time.TestPeriod test.java.time.TestLocalDate test.java.time.TestZoneOffset test.java.time.AbstractTest test.java.time.MockSimplePeriod test.java.time.chrono.TestIsoChronoImpl test.java.time.chrono.TestChronoLocalDate test.java.time.chrono.TestUmmAlQuraChronology test.java.time.chrono.TestJapaneseChronology test.java.time.chrono.TestServiceLoader test.java.time.chrono.TestJapaneseChronoImpl test.java.time.chrono.TestChronologyPerf test.java.time.chrono.TestThaiBuddhistChronoImpl test.java.time.chrono.TestExampleCode test.java.time.TestDuration test.java.time.TestZoneId test.java.time.TestOffsetDateTime_instants test.java.time.TestOffsetTime test.java.time.zone.TestFixedZoneRules test.java.time.TestClock_Offset test.java.time.TestOffsetDateTime test.java.time.TestClock_Tick test.java.time.TestClock_System test.java.time.TestInstant reason: Named class compiled on demand Library /lib/testlibrary/: compile: jdk.testlibrary.RandomFactory Test directory: compile: tck.java.time.AbstractDateTimeTest, tck.java.time.TCKZonedDateTime, tck.java.time.TCKZoneId, tck.java.time.TCKYear, tck.java.time.format.TCKDateTimeFormatter, tck.java.time.format.TCKLocalizedFieldParser, tck.java.time.format.TCKChronoPrinterParser, tck.java.time.format.TCKPadPrinterParser, tck.java.time.format.TCKInstantPrinterParser, tck.java.time.format.TCKDecimalStyle, tck.java.time.format.TCKDateTimeFormatters, tck.java.time.format.TCKDateTimeParseResolver, tck.java.time.format.TCKDateTimeTextPrinting, tck.java.time.format.TCKZoneIdPrinterParser, tck.java.time.format.TCKOffsetPrinterParser, tck.java.time.format.TCKLocalizedPrinterParser, tck.java.time.format.TCKLocalizedOffsetIdPrinterParser, tck.java.time.format.TCKDTFParsedInstant, tck.java.time.format.TCKSignStyle, tck.java.time.format.TCKFormatStyle, tck.java.time.format.TCKResolverStyle, tck.java.time.format.TCKLocalizedFieldPrinter, tck.java.time.format.TCKTextStyle, tck.java.time.format.TCKDateTimeFormatterBuilder, tck.java.time.TestIsoChronology, tck.java.time.TCKMonth, tck.java.time.TCKLocalDateTime, tck.java.time.temporal.TCKTemporalAdjusters, tck.java.time.temporal.TCKJulianFields, tck.java.time.temporal.TCKIsoFields, tck.java.time.temporal.serial.TCKJulianFieldsSerialization, tck.java.time.temporal.serial.TCKValueRangeSerialization, tck.java.time.temporal.serial.TCKWeekFieldsSerialization, tck.java.time.temporal.serial.TCKChronoFieldSerialization, tck.java.time.temporal.serial.TCKChronoUnitSerialization, tck.java.time.temporal.TCKChronoField, tck.java.time.temporal.TCKChronoUnit, tck.java.time.temporal.TCKWeekFields, tck.java.time.TCKClock_Tick, tck.java.time.TCKClock_Fixed, tck.java.time.serial.TCKZoneOffsetSerialization, tck.java.time.serial.TCKDurationSerialization, tck.java.time.serial.TCKZoneIdSerialization, tck.java.time.serial.TCKLocalDateSerialization, tck.java.time.serial.TCKLocalDateTimeSerialization, tck.java.time.serial.TCKClockSerialization, tck.java.time.serial.TCKOffsetTimeSerialization, tck.java.time.serial.TCKZonedDateTimeSerialization, tck.java.time.serial.TCKYearMonthSerialization, tck.java.time.serial.TCKOffsetDateTimeSerialization, tck.java.time.serial.TCKInstantSerialization, tck.java.time.serial.TCKLocalTimeSerialization, tck.java.time.serial.TCKMonthDaySerialization, tck.java.time.serial.TCKYearSerialization, tck.java.time.serial.TCKPeriodSerialization, tck.java.time.TCKYearMonth, tck.java.time.TCKOffsetDateTime, tck.java.time.TCKClock, tck.java.time.TCKDayOfWeek, tck.java.time.MockSimplePeriod, tck.java.time.TCKPeriod, tck.java.time.TCKOffsetTime, tck.java.time.TCKDuration, tck.java.time.chrono.TCKHijrahEra, tck.java.time.chrono.CopticEra, tck.java.time.chrono.TCKTestServiceLoader, tck.java.time.chrono.CopticDate, tck.java.time.chrono.TCKJapaneseChronology, tck.java.time.chrono.TCKChronoPeriod, tck.java.time.chrono.TCKThaiBuddhistChronology, tck.java.time.chrono.TCKIsoChronology, tck.java.time.chrono.serial.TCKChronoZonedDateTimeSerialization, tck.java.time.chrono.serial.TCKChronoLocalDateTimeSerialization, tck.java.time.chrono.serial.TCKEraSerialization, tck.java.time.chrono.serial.TCKChronologySerialization, tck.java.time.chrono.serial.TCKCopticSerialization, tck.java.time.chrono.serial.TCKChronoLocalDateSerialization, tck.java.time.chrono.TCKThaiBuddhistEra, tck.java.time.chrono.CopticChronology, tck.java.time.chrono.TCKChronology, tck.java.time.chrono.TCKChronoLocalDate, tck.java.time.chrono.TCKChronoZonedDateTime, tck.java.time.chrono.TCKMinguoEra, tck.java.time.chrono.TCKIsoEra, tck.java.time.chrono.TCKMinguoChronology, tck.java.time.chrono.TCKChronoLocalDateTime, tck.java.time.chrono.TCKJapaneseEra, tck.java.time.chrono.TCKHijrahChronology, tck.java.time.TCKLocalDate, tck.java.time.TCKLocalTime, tck.java.time.TCKClock_Offset, tck.java.time.TCKInstant, tck.java.time.TCKZoneOffset, tck.java.time.zone.TCKZoneOffsetTransitionRule, tck.java.time.zone.TCKZoneRulesProvider, tck.java.time.zone.TCKZoneRules, tck.java.time.zone.serial.TCKFixedZoneRulesSerialization, tck.java.time.zone.serial.TCKZoneOffsetTransitionRuleSerialization, tck.java.time.zone.serial.TCKZoneOffsetTransitionSerialization, tck.java.time.zone.serial.TCKZoneRulesSerialization, tck.java.time.zone.TCKFixedZoneRules, tck.java.time.zone.TCKZoneOffsetTransition, tck.java.time.AbstractTCKTest, tck.java.time.TCKMonthDay, tck.java.time.TCKClock_System, test.java.util.TestFormatter, test.java.time.format.TestZoneTextPrinterParser, test.java.time.format.TestNarrowMonthNamesAndDayNames, test.java.time.format.TestTextParser, test.java.time.format.MockIOExceptionAppendable, test.java.time.format.TestStringLiteralPrinter, test.java.time.format.AbstractTestPrinterParser, test.java.time.format.TestNonIsoFormatter, test.java.time.format.TestNumberParser, test.java.time.format.TestZoneOffsetPrinter, test.java.time.format.TestCharLiteralPrinter, test.java.time.format.TestSettingsParser, test.java.time.format.TestDateTimeTextProvider, test.java.time.format.TestNumberPrinter, test.java.time.format.ZoneName, test.java.time.format.TestReducedParser, test.java.time.format.TestCharLiteralParser, test.java.time.format.TestFractionPrinterParser, test.java.time.format.TestStringLiteralParser, test.java.time.format.TestPadPrinterDecorator, test.java.time.format.TestReducedPrinter, test.java.time.format.TestTextPrinter, test.java.time.format.TestDateTimeFormatterBuilder, test.java.time.format.TestDateTimeParsing, test.java.time.format.TestDateTimeFormatter, test.java.time.format.TestDecimalStyle, test.java.time.format.TestZoneOffsetParser, test.java.time.TestMonthDay, test.java.time.TestZonedDateTime, test.java.time.TestLocalTime, test.java.time.temporal.MockFieldValue, test.java.time.temporal.TestDateTimeBuilderCombinations, test.java.time.temporal.TestDateTimeValueRange, test.java.time.temporal.TestChronoField, test.java.time.temporal.TestChronoUnit, test.java.time.temporal.MockFieldNoValue, test.java.time.temporal.TestJulianFields, test.java.time.temporal.TestIsoWeekFields, test.java.time.TestYearMonth, test.java.time.TestYear, test.java.time.TestLocalDateTime, test.java.time.TestClock_Fixed, test.java.time.TestPeriod, test.java.time.TestLocalDate, test.java.time.TestZoneOffset, test.java.time.AbstractTest, test.java.time.MockSimplePeriod, test.java.time.chrono.TestIsoChronoImpl, test.java.time.chrono.TestChronoLocalDate, test.java.time.chrono.TestUmmAlQuraChronology, test.java.time.chrono.TestJapaneseChronology, test.java.time.chrono.TestServiceLoader, test.java.time.chrono.TestJapaneseChronoImpl, test.java.time.chrono.TestChronologyPerf, test.java.time.chrono.TestThaiBuddhistChronoImpl, test.java.time.chrono.TestExampleCode, test.java.time.TestDuration, test.java.time.TestZoneId, test.java.time.TestOffsetDateTime_instants, test.java.time.TestOffsetTime, test.java.time.zone.TestFixedZoneRules, test.java.time.TestClock_Offset, test.java.time.TestOffsetDateTime, test.java.time.TestClock_Tick, test.java.time.TestClock_System, test.java.time.TestInstant elapsed time (seconds): 30.265 result: Passed. Build successful #section:compile ----------messages:(5/293)---------- command: compile -implicit:none /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/lib/testlibrary/jdk/testlibrary/RandomFactory.java reason: .class file out of date or does not exist Additional options from @modules: --add-modules java.base Mode: othervm elapsed time (seconds): 3.276 ----------configuration:(6/336)---------- javac compilation environment add modules: java.base limit modules: java.base class path: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/lib/testlibrary /var/www/hudson/ws/workspace/MinimalDepsRun/jtreg/lib/testng.jar ----------rerun:(18/1740)*---------- HOME=/var/lib/hudson \\ JTREG_HOME=/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ /var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk/bin/javac \\ -J-Dtest.src=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time \\ -J-Dtest.src.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/lib/testlibrary \\ -J-Dtest.classes=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/java/time \\ -J-Dtest.class.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/java/time:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/lib/testlibrary \\ -J-Dtest.vm.opts= \\ -J-Dtest.tool.vm.opts= \\ -J-Dtest.compiler.opts='--limit-modules java.base' \\ -J-Dtest.java.opts='--limit-modules java.base' \\ -J-Dtest.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\ -J-Dcompile.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\ -J-Dtest.timeout.factor=1.0 \\ -J-Dtest.modules='java.base/java.time:open java.base/java.time.chrono:open java.base/java.time.zone:open' \\ @/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/java/time/tck/java/time/format/TCKDateTimeParseResolver.d/compile.0.jta ----------System.out:(0/0)---------- ----------System.err:(0/0)---------- result: Passed. Compilation successful #section:compile ----------messages:(5/19514)---------- command: compile -implicit:none /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/AbstractDateTimeTest.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKZonedDateTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKZoneId.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKYear.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDateTimeFormatter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKLocalizedFieldParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKChronoPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKPadPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKInstantPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDecimalStyle.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDateTimeFormatters.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDateTimeParseResolver.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDateTimeTextPrinting.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKZoneIdPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKOffsetPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKLocalizedPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKLocalizedOffsetIdPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDTFParsedInstant.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKSignStyle.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKFormatStyle.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKResolverStyle.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKLocalizedFieldPrinter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKTextStyle.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/format/TCKDateTimeFormatterBuilder.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TestIsoChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKMonth.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKLocalDateTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/TCKTemporalAdjusters.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/TCKJulianFields.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/TCKIsoFields.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/serial/TCKJulianFieldsSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/serial/TCKValueRangeSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/serial/TCKWeekFieldsSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/serial/TCKChronoFieldSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/serial/TCKChronoUnitSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/TCKChronoField.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/TCKChronoUnit.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/temporal/TCKWeekFields.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKClock_Tick.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKClock_Fixed.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKZoneOffsetSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKDurationSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKZoneIdSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKLocalDateSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKLocalDateTimeSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKClockSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKOffsetTimeSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKZonedDateTimeSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKYearMonthSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKOffsetDateTimeSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKInstantSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKLocalTimeSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKMonthDaySerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKYearSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/serial/TCKPeriodSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKYearMonth.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKOffsetDateTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKClock.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKDayOfWeek.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/MockSimplePeriod.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKPeriod.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKOffsetTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKDuration.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKHijrahEra.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/CopticEra.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKTestServiceLoader.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/CopticDate.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKJapaneseChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKChronoPeriod.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKThaiBuddhistChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKIsoChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/serial/TCKChronoZonedDateTimeSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateTimeSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/serial/TCKEraSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/serial/TCKChronologySerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/serial/TCKCopticSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/serial/TCKChronoLocalDateSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKThaiBuddhistEra.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/CopticChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKChronoLocalDate.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKChronoZonedDateTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKMinguoEra.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKIsoEra.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKMinguoChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKChronoLocalDateTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKJapaneseEra.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/chrono/TCKHijrahChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKLocalDate.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKLocalTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKClock_Offset.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKInstant.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKZoneOffset.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/TCKZoneOffsetTransitionRule.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/TCKZoneRulesProvider.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/TCKZoneRules.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/serial/TCKFixedZoneRulesSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionRuleSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/serial/TCKZoneOffsetTransitionSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/serial/TCKZoneRulesSerialization.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/TCKFixedZoneRules.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/zone/TCKZoneOffsetTransition.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/AbstractTCKTest.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKMonthDay.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/tck/java/time/TCKClock_System.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/util/TestFormatter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestZoneTextPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestNarrowMonthNamesAndDayNames.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestTextParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/MockIOExceptionAppendable.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestStringLiteralPrinter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/AbstractTestPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestNonIsoFormatter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestNumberParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestZoneOffsetPrinter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestCharLiteralPrinter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestSettingsParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestDateTimeTextProvider.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestNumberPrinter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/ZoneName.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestReducedParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestCharLiteralParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestFractionPrinterParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestStringLiteralParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestPadPrinterDecorator.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestReducedPrinter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestTextPrinter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestDateTimeFormatterBuilder.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestDateTimeParsing.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestDateTimeFormatter.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestDecimalStyle.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/format/TestZoneOffsetParser.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestMonthDay.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestZonedDateTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestLocalTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/temporal/MockFieldValue.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/temporal/TestDateTimeBuilderCombinations.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/temporal/TestDateTimeValueRange.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/temporal/TestChronoField.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/temporal/TestChronoUnit.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/temporal/MockFieldNoValue.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/temporal/TestJulianFields.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/temporal/TestIsoWeekFields.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestYearMonth.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestYear.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestLocalDateTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestClock_Fixed.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestPeriod.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestLocalDate.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestZoneOffset.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/AbstractTest.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/MockSimplePeriod.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestIsoChronoImpl.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestChronoLocalDate.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestUmmAlQuraChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestJapaneseChronology.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestServiceLoader.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestJapaneseChronoImpl.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestChronologyPerf.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestThaiBuddhistChronoImpl.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/chrono/TestExampleCode.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestDuration.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestZoneId.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestOffsetDateTime_instants.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestOffsetTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/zone/TestFixedZoneRules.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestClock_Offset.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestOffsetDateTime.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestClock_Tick.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestClock_System.java /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time/test/java/time/TestInstant.java reason: .class file out of date or does not exist Additional options from @modules: --add-modules java.base Mode: othervm elapsed time (seconds): 26.942 ----------configuration:(8/584)---------- javac compilation environment add modules: java.base limit modules: java.base class path: /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/java/time /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/lib/testlibrary /var/www/hudson/ws/workspace/MinimalDepsRun/jtreg/lib/testng.jar ----------rerun:(18/1740)*---------- HOME=/var/lib/hudson \\ JTREG_HOME=/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ /var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk/bin/javac \\ -J-Dtest.src=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time \\ -J-Dtest.src.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/lib/testlibrary \\ -J-Dtest.classes=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/java/time \\ -J-Dtest.class.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/java/time:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/lib/testlibrary \\ -J-Dtest.vm.opts= \\ -J-Dtest.tool.vm.opts= \\ -J-Dtest.compiler.opts='--limit-modules java.base' \\ -J-Dtest.java.opts='--limit-modules java.base' \\ -J-Dtest.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\ -J-Dcompile.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\ -J-Dtest.timeout.factor=1.0 \\ -J-Dtest.modules='java.base/java.time:open java.base/java.time.chrono:open java.base/java.time.zone:open' \\ @/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/java/time/tck/java/time/format/TCKDateTimeParseResolver.d/compile.1.jta ----------System.out:(0/0)---------- ----------System.err:(0/0)---------- result: Passed. Compilation successful #section:testng ----------messages:(5/409)---------- command: testng tck.java.time.format.TCKDateTimeParseResolver reason: Assumed action based on file name: run testng tck.java.time.format.TCKDateTimeParseResolver Mode: othervm Additional options from @modules: --add-modules java.base --add-opens java.base/java.time=ALL-UNNAMED --add-opens java.base/java.time.chrono=ALL-UNNAMED --add-opens java.base/java.time.zone=ALL-UNNAMED elapsed time (seconds): 2.305 ----------configuration:(7/270)---------- Boot Layer add modules: java.base limit modules: java.base add opens: java.base/java.time ALL-UNNAMED java.base/java.time.chrono ALL-UNNAMED java.base/java.time.zone ALL-UNNAMED ----------System.out:(608/49821)---------- [TestNG] Running: java/time/tck/java/time/format/TCKDateTimeParseResolver.java test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoLocalDateTime_noOverrideChrono_matches(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoLocalDateTime_noOverrideChrono_wrongChrono(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoLocalDateTime_overrideChrono_matches(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoLocalDateTime_overrideChrono_wrongChrono(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoLocalDate_noOverrideChrono_matches(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoLocalDate_noOverrideChrono_wrongChrono(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoLocalDate_overrideChrono_matches(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoLocalDate_overrideChrono_wrongChrono(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoZonedDateTime_noOverrideChrono_matches(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoZonedDateTime_noOverrideChrono_wrongChrono(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoZonedDateTime_overrideChrono_matches(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoZonedDateTime_overrideChrono_wrongChrono(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoZonedDateTime_overrideZone_matches(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToChronoZonedDateTime_overrideZone_wrongZone(): success test tck.java.time.format.TCKDateTimeParseResolver.test_fieldResolvesToLocalTime(): success test tck.java.time.format.TCKDateTimeParseResolver.test_parse_fromField_InstantSeconds(): success test tck.java.time.format.TCKDateTimeParseResolver.test_parse_fromField_InstantSeconds_NanoOfSecond(): success test tck.java.time.format.TCKDateTimeParseResolver.test_parse_fromField_SecondOfDay(): success test tck.java.time.format.TCKDateTimeParseResolver.test_parse_fromField_SecondOfDay_NanoOfSecond(): success test tck.java.time.format.TCKDateTimeParseResolver.test_parse_fromField_SecondOfMinute(): success test tck.java.time.format.TCKDateTimeParseResolver.test_parse_fromField_SecondOfMinute_NanoOfSecond(): success test tck.java.time.format.TCKDateTimeParseResolver.test_resolveAmPm(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveAmPm([Parameter{index=0, type=java.time.format.ResolverStyle, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.lang.Integer, declaredAnnotations=[]}]) Arguments: [(java.time.format.ResolverStyle)STRICT,(java.lang.Integer)0,(java.lang.Integer)0] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveClockHourOfAmPm(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveClockHourOfAmPm([Parameter{index=0, type=java.time.format.ResolverStyle, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.lang.Integer, declaredAnnotations=[]}]) Arguments: [(java.time.format.ResolverStyle)STRICT,(java.lang.Integer)1,(java.lang.Integer)1] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveClockHourOfDay(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveClockHourOfDay([Parameter{index=0, type=java.time.format.ResolverStyle, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.lang.Integer, declaredAnnotations=[]}, Parameter{index=3, type=int, declaredAnnotations=[]}]) Arguments: [(java.time.format.ResolverStyle)STRICT,(java.lang.Integer)1,(java.lang.Integer)1,(java.lang.Integer)0] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveFourToDate(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveFourToDate([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=5, type=long, declaredAnnotations=[]}, Parameter{index=6, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=7, type=long, declaredAnnotations=[]}, Parameter{index=8, type=java.time.LocalDate, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)Year,(java.lang.Integer)2012,(java.time.temporal.ChronoField)MonthOfYear,(java.lang.Integer)2,(java.time.temporal.ChronoField)AlignedWeekOfMonth,(java.lang.Integer)1,(java.time.temporal.ChronoField)AlignedDayOfWeekInMonth,(java.lang.Integer)1,(java.time.LocalDate)2012-02-01] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveFourToDateTime(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveFourToDateTime([Parameter{index=0, type=java.time.format.ResolverStyle, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=long, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=long, declaredAnnotations=[]}, Parameter{index=5, type=java.time.LocalTime, declaredAnnotations=[]}, Parameter{index=6, type=java.time.Period, declaredAnnotations=[]}]) Arguments: [null,(java.lang.Integer)0,(java.lang.Integer)0,(java.lang.Integer)0,(java.lang.Integer)0,(java.time.LocalTime)00:00,(java.time.Period)P0D] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveFourToTime(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveFourToTime([Parameter{index=0, type=java.time.format.ResolverStyle, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=long, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=long, declaredAnnotations=[]}, Parameter{index=5, type=java.time.LocalTime, declaredAnnotations=[]}, Parameter{index=6, type=java.time.Period, declaredAnnotations=[]}]) Arguments: [null,(java.lang.Integer)0,(java.lang.Integer)0,(java.lang.Integer)0,(java.lang.Integer)0,(java.time.LocalTime)00:00,(java.time.Period)P0D] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveMinuteOfDay(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveMinuteOfDay([Parameter{index=0, type=java.time.format.ResolverStyle, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.lang.Integer, declaredAnnotations=[]}, Parameter{index=3, type=int, declaredAnnotations=[]}]) Arguments: [(java.time.format.ResolverStyle)STRICT,(java.lang.Integer)0,(java.lang.Integer)0,(java.lang.Integer)0] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveOneNoChange(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveOneNoChange([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)Year,(java.lang.Integer)2012] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveOneToDate(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveOneToDate([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.LocalDate, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)EpochDay,(java.lang.Integer)32,(java.time.LocalDate)1970-02-02] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveOneToField(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveOneToField([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=3, type=java.lang.Long, declaredAnnotations=[]}, Parameter{index=4, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=5, type=java.lang.Long, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)YearOfEra,(java.lang.Integer)2012,(java.time.temporal.ChronoField)Year,(java.lang.Long)2012,null,null] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveOneToTime(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveOneToTime([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.LocalTime, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)HourOfDay,(java.lang.Integer)8,(java.time.LocalTime)08:00] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveSecondOfDay(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveSecondOfDay([Parameter{index=0, type=java.time.format.ResolverStyle, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.lang.Integer, declaredAnnotations=[]}, Parameter{index=3, type=int, declaredAnnotations=[]}]) Arguments: [(java.time.format.ResolverStyle)STRICT,(java.lang.Integer)0,(java.lang.Integer)0,(java.lang.Integer)0] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveThreeNoChange(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveThreeNoChange([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=5, type=long, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)Year,(java.lang.Integer)2012,(java.time.temporal.ChronoField)MonthOfYear,(java.lang.Integer)5,(java.time.temporal.ChronoField)DayOfWeek,(java.lang.Integer)5] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveThreeToDate(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveThreeToDate([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=5, type=long, declaredAnnotations=[]}, Parameter{index=6, type=java.time.LocalDate, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)Year,(java.lang.Integer)2012,(java.time.temporal.ChronoField)MonthOfYear,(java.lang.Integer)2,(java.time.temporal.ChronoField)DayOfMonth,(java.lang.Integer)1,(java.time.LocalDate)2012-02-01] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveThreeToTime(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveThreeToTime([Parameter{index=0, type=java.time.format.ResolverStyle, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=long, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=long, declaredAnnotations=[]}, Parameter{index=5, type=java.time.LocalTime, declaredAnnotations=[]}, Parameter{index=6, type=java.time.Period, declaredAnnotations=[]}]) Arguments: [null,(java.lang.Integer)0,(java.lang.Integer)0,(java.lang.Integer)0,(java.lang.Integer)0,(java.time.LocalTime)00:00,(java.time.Period)P0D] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveTwoNoChange(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveTwoNoChange([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)Year,(java.lang.Integer)2012,(java.time.temporal.ChronoField)MonthOfYear,(java.lang.Integer)5] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveTwoToDate(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveTwoToDate([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=java.time.LocalDate, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)Year,(java.lang.Integer)2012,(java.time.temporal.ChronoField)DayOfYear,(java.lang.Integer)32,(java.time.LocalDate)2012-02-01] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveTwoToField(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveTwoToField([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=5, type=java.lang.Long, declaredAnnotations=[]}, Parameter{index=6, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=7, type=java.lang.Long, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)ProlepticMonth,(java.lang.Long)24146,(java.time.temporal.ChronoField)Year,(java.lang.Integer)2012,(java.time.temporal.ChronoField)Year,(java.lang.Long)2012,(java.time.temporal.ChronoField)MonthOfYear,(java.lang.Long)3] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_resolveTwoToTime(): failure org.testng.internal.reflect.MethodMatcherException: Data provider mismatch Method: test_resolveTwoToTime([Parameter{index=0, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=1, type=long, declaredAnnotations=[]}, Parameter{index=2, type=java.time.temporal.TemporalField, declaredAnnotations=[]}, Parameter{index=3, type=long, declaredAnnotations=[]}, Parameter{index=4, type=java.time.LocalTime, declaredAnnotations=[]}]) Arguments: [(java.time.temporal.ChronoField)HourOfDay,(java.lang.Integer)8,(java.time.temporal.ChronoField)MinuteOfHour,(java.lang.Integer)6,(java.time.LocalTime)08:06] at org.testng.internal.reflect.DataProviderMethodMatcher.getConformingArguments(DataProviderMethodMatcher.java:52) at org.testng.internal.Invoker.injectParameters(Invoker.java:1228) at org.testng.internal.Invoker.invokeTestMethods(Invoker.java:1125) at org.testng.internal.TestMethodWorker.invokeTestMethods(TestMethodWorker.java:129) at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:112) at org.testng.TestRunner.privateRun(TestRunner.java:778) at org.testng.TestRunner.run(TestRunner.java:632) at org.testng.SuiteRunner.runTest(SuiteRunner.java:366) at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:361) at org.testng.SuiteRunner.privateRun(SuiteRunner.java:319) at org.testng.SuiteRunner.run(SuiteRunner.java:268) at org.testng.SuiteRunnerWorker.runSuite(SuiteRunnerWorker.java:52) at org.testng.SuiteRunnerWorker.run(SuiteRunnerWorker.java:86) at org.testng.TestNG.runSuitesSequentially(TestNG.java:1222) at org.testng.TestNG.runSuitesLocally(TestNG.java:1147) at org.testng.TestNG.runSuites(TestNG.java:1072) at org.testng.TestNG.run(TestNG.java:1044) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:87) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) test tck.java.time.format.TCKDateTimeParseResolver.test_withChronology_noOverride(): success test tck.java.time.format.TCKDateTimeParseResolver.test_withChronology_override(): success test tck.java.time.format.TCKDateTimeParseResolver.test_withChronology_parsedChronology_noOverride(): success test tck.java.time.format.TCKDateTimeParseResolver.test_withChronology_parsedChronology_override(): success test tck.java.time.format.TCKDateTimeParseResolver.test_withZone_noOverride(): success test tck.java.time.format.TCKDateTimeParseResolver.test_withZone_override(): success test tck.java.time.format.TCKDateTimeParseResolver.test_withZone_parsedZone_noOverride(): success test tck.java.time.format.TCKDateTimeParseResolver.test_withZone_parsedZone_override(): success =============================================== java/time/tck/java/time/format/TCKDateTimeParseResolver.java Total tests run: 48, Failures: 19, Skips: 0 =============================================== ----------System.err:(14/861)---------- java.lang.Exception: failures: 19 at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:89) at com.sun.javatest.regtest.agent.TestNGRunner.main(TestNGRunner.java:54) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.base/java.lang.reflect.Method.invoke(Method.java:538) at com.sun.javatest.regtest.agent.MainWrapper$MainThread.run(MainWrapper.java:110) at java.base/java.lang.Thread.run(Thread.java:844) JavaTest Message: Test threw exception: java.lang.Exception: failures: 19 JavaTest Message: shutting down test STATUS:Failed.`main' threw exception: java.lang.Exception: failures: 19 ----------rerun:(24/2761)*---------- HOME=/var/lib/hudson \\ JTREG_HOME=/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg \\ LANG=en_US.UTF-8 \\ PATH=/bin:/usr/bin \\ CLASSPATH=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/java/time:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/lib/testlibrary:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/lib/testlibrary:/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg/lib/testng.jar:/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg/lib/javatest.jar:/var/www/hudson/ws/workspace/MinimalDepsRun/jtreg/lib/jtreg.jar \\ /var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk/bin/java \\ -Dtest.src=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time \\ -Dtest.src.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/java/time:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/lib/testlibrary \\ -Dtest.classes=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/java/time \\ -Dtest.class.path=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/java/time:/var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/classes/lib/testlibrary \\ -Dtest.vm.opts= \\ -Dtest.tool.vm.opts= \\ -Dtest.compiler.opts='--limit-modules java.base' \\ -Dtest.java.opts='--limit-modules java.base' \\ -Dtest.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\ -Dcompile.jdk=/var/www/hudson/ws/workspace/MinimalDepsRun/jake/build/linux-x64/images/jdk \\ -Dtest.timeout.factor=1.0 \\ -Dtest.modules='java.base/java.time:open java.base/java.time.chrono:open java.base/java.time.zone:open' \\ --add-modules java.base \\ --add-opens java.base/java.time=ALL-UNNAMED \\ --add-opens java.base/java.time.chrono=ALL-UNNAMED \\ --add-opens java.base/java.time.zone=ALL-UNNAMED \\ --limit-modules java.base \\ com.sun.javatest.regtest.agent.MainWrapper /var/www/hudson/ws/workspace/MinimalDepsRun/jake/jdk/test/JTwork-java-time-tck-java-time-format-TCKDateTimeParseResolver-java_0/java/time/tck/java/time/format/TCKDateTimeParseResolver.d/testng.2.jta java/time/tck/java/time/format/TCKDateTimeParseResolver.java tck.java.time.format.TCKDateTimeParseResolver result: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 19 test result: Failed. Execution failed: `main' threw exception: java.lang.Exception: failures: 19 From rachna.goel at oracle.com Tue Dec 27 10:55:36 2016 From: rachna.goel at oracle.com (Rachna Goel) Date: Tue, 27 Dec 2016 16:25:36 +0530 Subject: RFR(s): 8171958: Several tests from java/time/test/java/time/format requiring jdk.localedata for execution In-Reply-To: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com> References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com> Message-ID: <5dbbbb52-26fd-bd59-fdc8-ebb94585c7df@oracle.com> Hi Sergei, Though I am not a reviewer, But I have one comment on this fix. test/java/time/TEST.properties declares "modules = jdk.localedata" , so that all tests for java.time can have access to "jdk.localedata" module. If we are restricting usage of jdk.localedata module for different tests, then TEST.properties need to be updated as well. Thanks, Rachna On 26/12/16 8:27 PM, Sergei Kovalev wrote: > Hello Team, > > Please review below fix for tests. > > Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958 > Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/ > > Issue: some tests fails in case of module limitation by > '--limit-module java.base' command line option. > Root cause: The tests uses locale data that stored in separate > resource file "jdk.localedata". > Solution: Add declaration of required module. In same cases a test > file contains many test items, part of which could be executed with > java.base module only. In this cases we can separate the items and > extract that items which depend on locale data and run them > individually. Therefore this proposal contains additional test files > where added "WithLocale" suffix which demonstrate dependency on > resources. Alternative solution could be add a required module > declaration "jdk.localedata" to all files. However this will lead to > unnecessary test coverage reduction. > From claes.redestad at oracle.com Tue Dec 27 14:04:45 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Tue, 27 Dec 2016 15:04:45 +0100 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy Message-ID: Hi, since java.util.concurrent.AtomicReference was changed to use a VarHandle internally, using it from within the security libraries can lead to hard to diagnose bootstrap cycles (since VarHandles has to do doPrivileged calls during setup). The need to initialize VarHandles is also cause for a small startup regression for any application run with a security manager. The use of AtomicReference in java.security.Policy is not really motivated, though, since only the .get/.set methods are used, thus a rather straight-forward fix is to convert the code to use a volatile reference instead with identical semantics: Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ While a rather insignificant startup improvement in and off itself, this would help to unblock the attempted fix to resolve https://bugs.openjdk.java.net/browse/JDK-8062389 Thanks! /Claes From patrick at reini.net Tue Dec 27 14:46:44 2016 From: patrick at reini.net (Patrick Reinhart) Date: Tue, 27 Dec 2016 15:46:44 +0100 Subject: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net> <7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com> <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net> , Message-ID: <64ebf6b5c9ce31310daff8f2f13c96d2@reini.net> Hi Jason, At the moment, a subclass would need to overwrite this method with the same behaviour. The other solution would be to make the internal state auto-flush to no longer be final. -Patrick On 2016-12-21 22:40, Jason Mehrens wrote: > Patrick, > > How is 'withAutoFlush' expected to behave for subclasses of > PrintWriter? > > Jason From jason_mehrens at hotmail.com Tue Dec 27 15:14:23 2016 From: jason_mehrens at hotmail.com (Jason Mehrens) Date: Tue, 27 Dec 2016 15:14:23 +0000 Subject: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors In-Reply-To: <64ebf6b5c9ce31310daff8f2f13c96d2@reini.net> References: <6D1ED283-28C4-4787-B33E-9EF5B8AB9F50@reini.net> <7983a3c2-5943-d32a-b0e8-755958700ba8@Oracle.com> <11EFA41B-9978-4CC6-B941-1EE6B4F313E6@reini.net> , , <64ebf6b5c9ce31310daff8f2f13c96d2@reini.net> Message-ID: You should add a subclass test to prove that it works in practice. If the subclasses are required to override the method then shouldn't the 'withAutoFlush' method check that getClass() == PrintWriter.class otherwise throw something like UnsupportedOperationException? Jason ________________________________________ From: Patrick Reinhart Sent: Tuesday, December 27, 2016 8:46 AM To: Jason Mehrens Cc: core-libs-dev Subject: Re: Request for Review and Sponsor needed: JDK-8167648: java.io.PrintWriter should have PrintWriter((String|File), Charset) constructors Hi Jason, At the moment, a subclass would need to overwrite this method with the same behaviour. The other solution would be to make the internal state auto-flush to no longer be final. -Patrick On 2016-12-21 22:40, Jason Mehrens wrote: > Patrick, > > How is 'withAutoFlush' expected to behave for subclasses of > PrintWriter? > > Jason From volker.simonis at gmail.com Tue Dec 27 17:17:44 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Tue, 27 Dec 2016 18:17:44 +0100 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) Message-ID: Hi, can I please have a review and approval for pushing the following small, ppc64-only fix to jdk8u-dev: http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ https://bugs.openjdk.java.net/browse/JDK-8172053 The problem is that the recent downport of "8170153: PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized compilation" breaks the build of jdk8u with the original gcc 4.3 on linux/ppc64. We should however ensure, that an update-release will not break the original tool chain used for a released version of Java. Notice, that this change won't go to jdk9 because it only fixes an issue caused by the downport of another fix to jdk8u which doesn't exist in jdk9. JDK-8170153 increased the optimization level for the compilation of fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by using the option '-ffp-contract=off' which guaranteed correct IEEE floating point behavior. Unfortunately, '-ffp-contract' is only available since gcc 4.6. For ppc64le that's no problem since ppc64le support only appeared in gcc 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc 4.3 which only knows '-mno-fused-madd'. However, that's still not enough to get the float computations right - we additionally have to supply '-fno-strict-aliasing'. I've tested the new configuration (i.e. '-mno-fused-madd -fno-strict-aliasing') with the corresponding jtreg and JCK tests and couldn't find any issue. Thank you and best regards, Volker From david.holmes at oracle.com Tue Dec 27 22:30:38 2016 From: david.holmes at oracle.com (David Holmes) Date: Wed, 28 Dec 2016 08:30:38 +1000 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) In-Reply-To: References: Message-ID: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> Hi Volker, As this is a build change I have added build-dev. The change looks fine to me. Aside: More generally it would be nice if there was a simple way to record minimum compiler versions necessary for a given flag/option. Thanks, David On 28/12/2016 3:17 AM, Volker Simonis wrote: > Hi, > > can I please have a review and approval for pushing the following > small, ppc64-only fix to jdk8u-dev: > > http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ > https://bugs.openjdk.java.net/browse/JDK-8172053 > > The problem is that the recent downport of "8170153: > PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized > compilation" breaks the build of jdk8u with the original gcc 4.3 on > linux/ppc64. We should however ensure, that an update-release will not > break the original tool chain used for a released version of Java. > Notice, that this change won't go to jdk9 because it only fixes an > issue caused by the downport of another fix to jdk8u which doesn't > exist in jdk9. > > JDK-8170153 increased the optimization level for the compilation of > fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by > using the option '-ffp-contract=off' which guaranteed correct IEEE > floating point behavior. > > Unfortunately, '-ffp-contract' is only available since gcc 4.6. For > ppc64le that's no problem since ppc64le support only appeared in gcc > 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc > 4.3 which only knows '-mno-fused-madd'. However, that's still not > enough to get the float computations right - we additionally have to > supply '-fno-strict-aliasing'. > > I've tested the new configuration (i.e. '-mno-fused-madd > -fno-strict-aliasing') with the corresponding jtreg and JCK tests and > couldn't find any issue. > > Thank you and best regards, > Volker > From peter.levart at gmail.com Wed Dec 28 00:07:05 2016 From: peter.levart at gmail.com (Peter Levart) Date: Wed, 28 Dec 2016 01:07:05 +0100 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: References: Message-ID: <978ff508-a07f-9778-efde-52d19d1f31d2@gmail.com> Hi Claes, A nice find! This is certainly a straightforward and low-risk fix for breaking the initialization cycle problem with JDK-8062389. Related to VarHandles, the call trace of the initialization cycle also includes the following part of code in VarHandle: AccessMode(final String methodName, AccessType at) { this.methodName = methodName; this.at = at; // Assert that return type is correct // Otherwise, when disabled avoid using reflection assert at.returnType == getReturnType(methodName); } ... private static Class getReturnType(String name) { try { Method m = VarHandle.class.getMethod(name, Object[].class); return m.getReturnType(); } catch (Exception e) { throw newInternalError(e); } } ... where enabling assertions (tests enable assertions) causes the initialization of VarHandle(s) to involve reflection. This is also a place that could be made more robust, perhaps by devising a special test that verifies method return types, instead of embedding the check into the AccessMode constructor... Regards, Peter On 12/27/2016 03:04 PM, Claes Redestad wrote: > Hi, > > since java.util.concurrent.AtomicReference was changed to use a > VarHandle internally, using it from within the security libraries can > lead to hard to diagnose bootstrap cycles (since VarHandles has to do > doPrivileged calls during setup). The need to initialize VarHandles is > also cause for a small startup regression for any application run with > a security manager. > > The use of AtomicReference in java.security.Policy is not really > motivated, though, since only the .get/.set methods are used, thus a > rather straight-forward fix is to convert the code to use a volatile > reference instead with identical semantics: > > Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 > Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ > > While a rather insignificant startup improvement in and off itself, > this would help to unblock the attempted fix to resolve > https://bugs.openjdk.java.net/browse/JDK-8062389 > > Thanks! > > /Claes From frank.yuan at oracle.com Wed Dec 28 04:47:31 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Wed, 28 Dec 2016 12:47:31 +0800 Subject: Does jvisualvm work in JDK 9? Message-ID: <003001d260c5$816772f0$843658d0$@oracle.com> Hi all I tried to run jvisualvm in Linux with both b147 and b150(by adding add-opens option), it always quit quietly after showing a splash screen. Does it still work? Thanks Frank From erik.joelsson at oracle.com Wed Dec 28 08:08:23 2016 From: erik.joelsson at oracle.com (Erik Joelsson) Date: Wed, 28 Dec 2016 09:08:23 +0100 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) In-Reply-To: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> References: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> Message-ID: Change looks ok. /Erik On 2016-12-27 23:30, David Holmes wrote: > Hi Volker, > > As this is a build change I have added build-dev. > > The change looks fine to me. > > Aside: More generally it would be nice if there was a simple way to > record minimum compiler versions necessary for a given flag/option. > > Thanks, > David > > On 28/12/2016 3:17 AM, Volker Simonis wrote: >> Hi, >> >> can I please have a review and approval for pushing the following >> small, ppc64-only fix to jdk8u-dev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ >> https://bugs.openjdk.java.net/browse/JDK-8172053 >> >> The problem is that the recent downport of "8170153: >> PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized >> compilation" breaks the build of jdk8u with the original gcc 4.3 on >> linux/ppc64. We should however ensure, that an update-release will not >> break the original tool chain used for a released version of Java. >> Notice, that this change won't go to jdk9 because it only fixes an >> issue caused by the downport of another fix to jdk8u which doesn't >> exist in jdk9. >> >> JDK-8170153 increased the optimization level for the compilation of >> fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by >> using the option '-ffp-contract=off' which guaranteed correct IEEE >> floating point behavior. >> >> Unfortunately, '-ffp-contract' is only available since gcc 4.6. For >> ppc64le that's no problem since ppc64le support only appeared in gcc >> 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc >> 4.3 which only knows '-mno-fused-madd'. However, that's still not >> enough to get the float computations right - we additionally have to >> supply '-fno-strict-aliasing'. >> >> I've tested the new configuration (i.e. '-mno-fused-madd >> -fno-strict-aliasing') with the corresponding jtreg and JCK tests and >> couldn't find any issue. >> >> Thank you and best regards, >> Volker >> From volker.simonis at gmail.com Wed Dec 28 08:32:25 2016 From: volker.simonis at gmail.com (Volker Simonis) Date: Wed, 28 Dec 2016 09:32:25 +0100 Subject: [8u] Request for approval for 8172053: (ppc64) Downport of 8170153 breaks build on linux/ppc64 (big endian) In-Reply-To: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> References: <93dddd7b-f922-6721-0877-fd906e70d353@oracle.com> Message-ID: On Tue, Dec 27, 2016 at 11:30 PM, David Holmes wrote: > Hi Volker, > > As this is a build change I have added build-dev. > > The change looks fine to me. > Thanks for reviewing! > Aside: More generally it would be nice if there was a simple way to record > minimum compiler versions necessary for a given flag/option. > Yes, I first wanted to do this compiler-version dependent. Unfortunately that would have been much more complex because I don't have access to the compiler version in CoreLibraries.gmk and I didn't wanted to start it for legacy code which is not needed in jdk9 anyway. Regards, Volker > Thanks, > David > > > On 28/12/2016 3:17 AM, Volker Simonis wrote: >> >> Hi, >> >> can I please have a review and approval for pushing the following >> small, ppc64-only fix to jdk8u-dev: >> >> http://cr.openjdk.java.net/~simonis/webrevs/2016/8172053/ >> https://bugs.openjdk.java.net/browse/JDK-8172053 >> >> The problem is that the recent downport of "8170153: >> PPC64/s390x/aarch64: Poor StrictMath performance due to non-optimized >> compilation" breaks the build of jdk8u with the original gcc 4.3 on >> linux/ppc64. We should however ensure, that an update-release will not >> break the original tool chain used for a released version of Java. >> Notice, that this change won't go to jdk9 because it only fixes an >> issue caused by the downport of another fix to jdk8u which doesn't >> exist in jdk9. >> >> JDK-8170153 increased the optimization level for the compilation of >> fdlibm on both linux/ppc64 and linux/ppc64le. This only worked by >> using the option '-ffp-contract=off' which guaranteed correct IEEE >> floating point behavior. >> >> Unfortunately, '-ffp-contract' is only available since gcc 4.6. For >> ppc64le that's no problem since ppc64le support only appeared in gcc >> 4.8.3. But on ppc64 (big endian) we traditionally compiled with gcc >> 4.3 which only knows '-mno-fused-madd'. However, that's still not >> enough to get the float computations right - we additionally have to >> supply '-fno-strict-aliasing'. >> >> I've tested the new configuration (i.e. '-mno-fused-madd >> -fno-strict-aliasing') with the corresponding jtreg and JCK tests and >> couldn't find any issue. >> >> Thank you and best regards, >> Volker >> > From sergei.kovalev at oracle.com Wed Dec 28 14:20:09 2016 From: sergei.kovalev at oracle.com (Sergei Kovalev) Date: Wed, 28 Dec 2016 17:20:09 +0300 Subject: RFR(s): 8171958: Several tests from java/time/test/java/time/format requiring jdk.localedata for execution In-Reply-To: <5dbbbb52-26fd-bd59-fdc8-ebb94585c7df@oracle.com> References: <39bd0f19-5dbd-9790-2d5f-d3cae2a7cf08@oracle.com> <5dbbbb52-26fd-bd59-fdc8-ebb94585c7df@oracle.com> Message-ID: <3e978d60-2fed-4106-6d8f-fb64f32dff63@oracle.com> Hi Rachna, Thank you for the comment. I've reviewed usage of module declaration in TEST.properties file and find that it could be removed without any impact. In both cases (with original and modified TEST.properties file) I get same result. Test results: passed: 142; failed: 27 The reason of this behavior is the lack of jtreg header in test sources. In case test source has no "@test" tag jtreg ignores all properties that exists in TEST.properties file. I recreated the review by adding TEST.properties modification: http://cr.openjdk.java.net/~skovalev/8171958/webrev.01/ 27.12.16 13:55, Rachna Goel wrote: > > Hi Sergei, > > Though I am not a reviewer, But I have one comment on this fix. > > test/java/time/TEST.properties declares "modules = jdk.localedata" , > so that all tests for java.time can have access to "jdk.localedata" > module. > > If we are restricting usage of jdk.localedata module for different > tests, then TEST.properties need to be updated as well. > > Thanks, > Rachna > > > > On 26/12/16 8:27 PM, Sergei Kovalev wrote: >> Hello Team, >> >> Please review below fix for tests. >> >> Bug ID: https://bugs.openjdk.java.net/browse/JDK-8171958 >> Web review: http://cr.openjdk.java.net/~skovalev/8171958/webrev.00/ >> >> Issue: some tests fails in case of module limitation by >> '--limit-module java.base' command line option. >> Root cause: The tests uses locale data that stored in separate >> resource file "jdk.localedata". >> Solution: Add declaration of required module. In same cases a test >> file contains many test items, part of which could be executed with >> java.base module only. In this cases we can separate the items and >> extract that items which depend on locale data and run them >> individually. Therefore this proposal contains additional test files >> where added "WithLocale" suffix which demonstrate dependency on >> resources. Alternative solution could be add a required module >> declaration "jdk.localedata" to all files. However this will lead to >> unnecessary test coverage reduction. >> > -- With best regards, Sergei From aleksej.efimov at oracle.com Wed Dec 28 15:03:38 2016 From: aleksej.efimov at oracle.com (Aleks Efimov) Date: Wed, 28 Dec 2016 18:03:38 +0300 Subject: RFR(XS): 8067237: [TESTBUG] javax/xml/ws/xsanymixed/Test.java failed on compilation Message-ID: <8db32933-34aa-3a0d-5b5d-13e70ac3d9b6@oracle.com> Hello, Please, help to review javax/xml/ws/xsanymixed/Test.java test fix that addresses test failure [1] with JDK9 JRE runtime due to missing wsimport tool. The fix is to use the tool from compile JDK: http://cr.openjdk.java.net/~aefimov/8067237/9/00/ The modification was tested with JTREG both with jre and jdk set as java under test (-jdk jtreg option). Best Regards, Aleksej [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8067237 From lance.andersen at oracle.com Wed Dec 28 19:11:35 2016 From: lance.andersen at oracle.com (Lance Andersen) Date: Wed, 28 Dec 2016 14:11:35 -0500 Subject: RFR(XS): 8067237: [TESTBUG] javax/xml/ws/xsanymixed/Test.java failed on compilation In-Reply-To: <8db32933-34aa-3a0d-5b5d-13e70ac3d9b6@oracle.com> References: <8db32933-34aa-3a0d-5b5d-13e70ac3d9b6@oracle.com> Message-ID: +1 > On Dec 28, 2016, at 10:03 AM, Aleks Efimov wrote: > > Hello, > > Please, help to review javax/xml/ws/xsanymixed/Test.java test fix that addresses test failure [1] with JDK9 JRE runtime due to missing wsimport tool. The fix is to use the tool from compile JDK: > http://cr.openjdk.java.net/~aefimov/8067237/9/00/ > > The modification was tested with JTREG both with jre and jdk set as java under test (-jdk jtreg option). > > Best Regards, > Aleksej > > [1] JBS: https://bugs.openjdk.java.net/browse/JDK-8067237 > > > > Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 Lance.Andersen at oracle.com From frank.yuan at oracle.com Thu Dec 29 02:39:24 2016 From: frank.yuan at oracle.com (Frank Yuan) Date: Thu, 29 Dec 2016 10:39:24 +0800 Subject: Does jvisualvm work in JDK 9? In-Reply-To: <6d658448-6d59-4e44-d0d3-c84a2734fcdf@gmail.com> References: <003001d260c5$816772f0$843658d0$@oracle.com> <6d658448-6d59-4e44-d0d3-c84a2734fcdf@gmail.com> Message-ID: <005601d2617c$c62a8500$527f8f00$@oracle.com> Hi Dmitry Thank you very much for your help! Unluckily visualvm doesn't work for 147 and 150 as well, I have to give up using this tool in current stage... Frank > -----Original Message----- > From: Dmitry Buzdin [mailto:buzdin at gmail.com] > Sent: Wednesday, December 28, 2016 4:57 PM > To: Frank Yuan; code-tools-dev at openjdk.java.net; core-libs-dev at openjdk.java.net > Subject: Re: Does jvisualvm work in JDK 9? > > Hi, > > I had a similar problem on Mac. Downloaded the latest version of > VisualVM (https://visualvm.github.io/) and it did work. > > It seems that the version bundled with JDK 9 is out of date. > > Dmitry > > > On 28/12/16 06:47, Frank Yuan wrote: > > Hi all > > > > > > > > I tried to run jvisualvm in Linux with both b147 and b150(by adding add-opens option), it always quit quietly after showing a splash > > screen. Does it still work? > > > > > > > > > > > > Thanks > > > > Frank > > From david.holmes at oracle.com Fri Dec 30 01:10:15 2016 From: david.holmes at oracle.com (David Holmes) Date: Fri, 30 Dec 2016 11:10:15 +1000 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: References: Message-ID: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> Hi Claes, On 28/12/2016 12:04 AM, Claes Redestad wrote: > Hi, > > since java.util.concurrent.AtomicReference was changed to use a > VarHandle internally, using it from within the security libraries can > lead to hard to diagnose bootstrap cycles (since VarHandles has to do > doPrivileged calls during setup). The need to initialize VarHandles is > also cause for a small startup regression for any application run with > a security manager. > > The use of AtomicReference in java.security.Policy is not really > motivated, though, since only the .get/.set methods are used, thus a > rather straight-forward fix is to convert the code to use a volatile > reference instead with identical semantics: I agree, this was a good find! - AtomicReference use was unnecessary in this class and certainly not worth the additional initialization complexity. Not sure about the "// volatile read" commentary when there is no corresponding volatile-write commentary, and when not applied in all locations. Thanks, David > Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 > Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ > > While a rather insignificant startup improvement in and off itself, > this would help to unblock the attempted fix to resolve > https://bugs.openjdk.java.net/browse/JDK-8062389 > > Thanks! > > /Claes From andrey.x.nazarov at oracle.com Fri Dec 30 14:11:48 2016 From: andrey.x.nazarov at oracle.com (Andrey Nazarov) Date: Fri, 30 Dec 2016 17:11:48 +0300 Subject: RFR: 8071566 Improve testing for multi-version JAR file maker tool Message-ID: <12CA06E6-0BCE-4A10-90CD-4968ED1B6FC5@oracle.com> Hi, Following tests for Jar tool were added: Tests for API validator. Jar tool should detect API changes between releases. Test for custom manifest file. Test for version format in --release option Also refactoring of existing tests was made: 1. Common base class ?MRTestBase.java? was extracted. 2. Result and process builders were substituted by existing library classes jdk/test/lib/process/* Please review. Review: http://cr.openjdk.java.net/~anazarov/8071566/webrev.00/ Issue: https://bugs.openjdk.java.net/browse/JDK-8071566 ?Andrey From claes.redestad at oracle.com Fri Dec 30 14:50:58 2016 From: claes.redestad at oracle.com (Claes Redestad) Date: Fri, 30 Dec 2016 15:50:58 +0100 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> References: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> Message-ID: Hi David, On 2016-12-30 02:10, David Holmes wrote: > Hi Claes, > > On 28/12/2016 12:04 AM, Claes Redestad wrote: >> Hi, >> >> since java.util.concurrent.AtomicReference was changed to use a >> VarHandle internally, using it from within the security libraries can >> lead to hard to diagnose bootstrap cycles (since VarHandles has to do >> doPrivileged calls during setup). The need to initialize VarHandles is >> also cause for a small startup regression for any application run with >> a security manager. >> >> The use of AtomicReference in java.security.Policy is not really >> motivated, though, since only the .get/.set methods are used, thus a >> rather straight-forward fix is to convert the code to use a volatile >> reference instead with identical semantics: > > I agree, this was a good find! - AtomicReference use was unnecessary in > this class and certainly not worth the additional initialization > complexity. thanks for reviewing! > > Not sure about the "// volatile read" commentary when there is no > corresponding volatile-write commentary, and when not applied in all > locations. yes, it seems I was lacking in dedication to this idea. It seems customary to point out that one is intentionally doing a read into a local variable as to avoid both performance and correctness issues that'd result if someone tried to "simplify" things. As we're safely publishing an object with only final fields a comment on the writes isn't strictly necessary, but I don't mind adding comments there too for consistency. Or do we prefer no comments at all? :-) /Claes > > Thanks, > David > >> Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 >> Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ >> >> While a rather insignificant startup improvement in and off itself, >> this would help to unblock the attempted fix to resolve >> https://bugs.openjdk.java.net/browse/JDK-8062389 >> >> Thanks! >> >> /Claes From david.holmes at oracle.com Fri Dec 30 23:45:08 2016 From: david.holmes at oracle.com (David Holmes) Date: Sat, 31 Dec 2016 09:45:08 +1000 Subject: RFR: 8172048: Re-examine use of AtomicReference in java.security.Policy In-Reply-To: References: <016ae37a-4d28-fcfc-f309-fbaf2c8beedc@oracle.com> Message-ID: On 31/12/2016 12:50 AM, Claes Redestad wrote: > Hi David, > > On 2016-12-30 02:10, David Holmes wrote: >> Hi Claes, >> >> On 28/12/2016 12:04 AM, Claes Redestad wrote: >>> Hi, >>> >>> since java.util.concurrent.AtomicReference was changed to use a >>> VarHandle internally, using it from within the security libraries can >>> lead to hard to diagnose bootstrap cycles (since VarHandles has to do >>> doPrivileged calls during setup). The need to initialize VarHandles is >>> also cause for a small startup regression for any application run with >>> a security manager. >>> >>> The use of AtomicReference in java.security.Policy is not really >>> motivated, though, since only the .get/.set methods are used, thus a >>> rather straight-forward fix is to convert the code to use a volatile >>> reference instead with identical semantics: >> >> I agree, this was a good find! - AtomicReference use was unnecessary in >> this class and certainly not worth the additional initialization >> complexity. > > thanks for reviewing! > >> >> Not sure about the "// volatile read" commentary when there is no >> corresponding volatile-write commentary, and when not applied in all >> locations. > > yes, it seems I was lacking in dedication to this idea. > > It seems customary to point out that one is intentionally doing a read > into a local variable as to avoid both performance and correctness > issues that'd result if someone tried to "simplify" things. As we're > safely publishing an object with only final fields a comment on the > writes isn't strictly necessary, but I don't mind adding comments > there too for consistency. Not sure how others have done this but the read-into-a-local should be documented more clearly as it isn't just the volatile aspect that is critical (for memory ordering) but the read-once aspect! The volatile write must also come after all other initialization actions - even when done inside a sync block. (It does, but it isn't obvious that it does, or that it has to.) > Or do we prefer no comments at all? :-) Not sure. I'll let you think about it so more. I'll be back in the office on Tuesday :) Cheers, David > /Claes > >> >> Thanks, >> David >> >>> Bug: https://bugs.openjdk.java.net/browse/JDK-8172048 >>> Webrev: http://cr.openjdk.java.net/~redestad/8172048/webrev.01/ >>> >>> While a rather insignificant startup improvement in and off itself, >>> this would help to unblock the attempted fix to resolve >>> https://bugs.openjdk.java.net/browse/JDK-8062389 >>> >>> Thanks! >>> >>> /Claes From buzdin at gmail.com Wed Dec 28 08:57:26 2016 From: buzdin at gmail.com (Dmitry Buzdin) Date: Wed, 28 Dec 2016 10:57:26 +0200 Subject: Does jvisualvm work in JDK 9? In-Reply-To: <003001d260c5$816772f0$843658d0$@oracle.com> References: <003001d260c5$816772f0$843658d0$@oracle.com> Message-ID: <6d658448-6d59-4e44-d0d3-c84a2734fcdf@gmail.com> Hi, I had a similar problem on Mac. Downloaded the latest version of VisualVM (https://visualvm.github.io/) and it did work. It seems that the version bundled with JDK 9 is out of date. Dmitry On 28/12/16 06:47, Frank Yuan wrote: > Hi all > > > > I tried to run jvisualvm in Linux with both b147 and b150(by adding add-opens option), it always quit quietly after showing a splash > screen. Does it still work? > > > > > > Thanks > > Frank >