Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

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,

Re: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64

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

Re: RFR 8170900: Issue with FilePermission::implies for wildcard flag(-)

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

Re: JDK 9 RFR of JDK-8156595: java/io/pathNames/GeneralWin32.java fail intermittently on windows-x64

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

RFR of JDK-8029360: java/rmi/transport/dgcDeadLock/DGCDeadLock.java failing intermittently

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

Re: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java

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

[9] RFR: 8171189: Deprecate ResourceBundleControlProvider for removal

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

Re: RFR 8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url

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

Re: RFR of JDK-8025199: java/rmi/registry/reexport/Reexport.java failed with: Port already in use

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

Re: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java

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

Re: JDK 9 RFR of JDK-8139688 Port fdlibm exp to Java

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

RFR 8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url

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

Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

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:

Re: [8u-dev] Request for review and approval: 8146086: Publishing two webservices on same port fails with "java.net.BindException: Address already in use"

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

Re: RFR 8164907: Eliminate dependency on java.naming/com.sun.jndi.toolkit.url

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

Re: [9] RFR: 8171189: Deprecate ResourceBundleControlProvider for removal

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:

Re: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option

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

Re: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option

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

Re: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option

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

Re: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option

> 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,

Re: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths

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

Re: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths

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 >

Re: [9] RFR: 8171189: Deprecate ResourceBundleControlProvider for removal

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

Re: Review Request: JDK-8171418: Remove jdeps internal --include-system-modules option

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

RE: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

Hi, will there be an update for JEP 260, so this is documented? Uwe - Uwe Schindler uschind...@apache.org ASF Member, Apache Lucene PMC / Committer Bremen, Germany http://lucene.apache.org/ > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent:

Re: Java 9 build 148 causes trouble in Apache Lucene/Solr/Elasticsearch

> 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 > uschind...@apache.org > ASF Member, Apache Lucene PMC / Committer > Bremen, Germany

Re: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths

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/

Re: JDK 9 RFR of 8148023: File.createTempFile is not adhering to the contract regarding file name lengths

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"

Re: RFR: 8062389, 8029459, 8061950: Class.getMethod() is inconsistent with Class.getMethods() results + more

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)