Re: [10] RFR 8194666: ProblemList update for bugid associated with PreferredKey.java, ConcurrentHashMapTest and SSLSocketParametersTest.sh

I'm not very sure of the fix problems of JDK-8176354. But this changeset Looks fine to me. Thanks, Xuelei On 1/4/2018 7:55 PM, Amy Lu wrote: Please review this minor cleanup for test/jdk/ProblemList.txt on bugid that associated with tests. bug: https://bugs.openjdk.java.net/browse/JDK-81946

[10] RFR 8194666: ProblemList update for bugid associated with PreferredKey.java, ConcurrentHashMapTest and SSLSocketParametersTest.sh

Please review this minor cleanup for test/jdk/ProblemList.txt on bugid that associated with tests. bug: https://bugs.openjdk.java.net/browse/JDK-8194666 webrev: http://cr.openjdk.java.net/~amlu/8194666/webrev.00/ Thanks, Amy --- old/test/jdk/ProblemList.txt2018-01-05 11:41:00.0

Re: Fix typo in InetSocketAddress.getAddress() documentation

> On 4 Jan 2018, at 21:29, Brian Burkhalter wrote: > > Hi Chris, > > Sure, no problem: http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html Reviewed. Thank you. -Chris.

Re: RFR 4358774: Add null InputStream and OutputStream

On Dec 11, 2017, at 12:52 PM, Brian Burkhalter wrote: > On Dec 8, 2017, at 3:12 PM, Brian Burkhalter > wrote: > >> All previous suggested changes have been made in >> >> http://cr.openjdk.java.net/~bpb/4358774/webrev.03/ >> >> except for the possible change of name for the IS and OS nullStr

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On 1/4/18 12:03 AM, Alan Bateman wrote: On 04/01/2018 01:35, David Holmes wrote: You're not missing anything. It's a class initialization related "deadlock". Thread A has called FileSystems.getDefault() which is doing of DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrar

Re: RFR 8193861: Typo in API documentation of File.toPath()

+1 > On Jan 4, 2018, at 4:39 PM, Brian Burkhalter > wrote: > > Updated to include a fix for a typo in InetSocketAddress.getAddress() [1]: > > http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html > > Thanks, > > Brian > > [1] > http://mail.openjdk.java.net/pipermail/core-libs-dev/201

Re: Fix typo in InetSocketAddress.getAddress() documentation

Hi Chris, Sure, no problem: http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html Brian On Jan 4, 2018, at 1:13 PM, Chris Hegarty wrote: > Would you mind adding the below typo to another you are fixing under > JDK-8193861 ( to reduce the overhead ).

Re: RFR 8193861: Typo in API documentation of File.toPath()

Updated to include a fix for a typo in InetSocketAddress.getAddress() [1]: http://cr.openjdk.java.net/~bpb/8193861/webrev.01/index.html Thanks, Brian [1] http://mail.openjdk.java.net/pipermail/core-libs-dev/2018-January/050814.html On Jan 4, 2018, at 1:05 PM, Brian Burkhalter wrote: > http

Re: RFR 8193861: Typo in API documentation of File.toPath()

+1 On 1/4/18 4:05 PM, Brian Burkhalter wrote: https://bugs.openjdk.java.net/browse/JDK-8193861 http://cr.openjdk.java.net/~bpb/8193861/webrev.00/ Thanks, Brian

RFR 8193861: Typo in API documentation of File.toPath()

https://bugs.openjdk.java.net/browse/JDK-8193861 http://cr.openjdk.java.net/~bpb/8193861/webrev.00/ Thanks, Brian

Re: RFR 8194649: Minor cleanup of parameter checking in ByteArrayOutputStream and ObjectInputStream

+1, (There has been some variation in opinion about use of requireNonNull even where the VM would check a reference for null; but it does seem redundant on the face of it, even if hotspot would optimize it) On 1/4/18 1:14 PM, Brian Burkhalter wrote: https://bugs.openjdk.java.net/browse/JDK-8

RFR 8194649: Minor cleanup of parameter checking in ByteArrayOutputStream and ObjectInputStream

https://bugs.openjdk.java.net/browse/JDK-8194649 Please see the proposed change included below. In the OIS case the requireNonNull() call is not needed as a NPE would be thrown at the next line anyway if arrayType were null. Thanks, Brian --- a/src/java.base/share/classes/java/io/ByteArrayOut

Re: RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method

On Jan 4, 2018, at 12:06 AM, Alan Bateman wrote: > So not clear to me that Files.copy methods needs to use this. So you are suggesting leaving the call to InputStream.transferTo() in preference to IOSupport.copy()? >>> Yes, I think these two should use transferTo. >> >> I do

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On Thu, Jan 4, 2018 at 3:03 AM, Alan Bateman wrote: > On 04/01/2018 01:35, David Holmes wrote: > >> >> You're not missing anything. It's a class initialization related >> "deadlock". >> >> Thread A has called FileSystems.getDefault() which is doing of >> DefaultFileSystemHolder, which in turn le

Re: RFR 8193842: Refactor InputStream-to-OutputStream copy into a utility method

On 04/01/2018 01:48, Brian Burkhalter wrote: On Jan 3, 2018, at 3:23 AM, Alan Bateman > wrote: On 02/01/2018 23:43, Brian Burkhalter wrote: : So not clear to me that Files.copy methods needs to use this. So you are suggesting leaving the call to InputStrea

Re: Possible VM deadlock due to FileSystems.getDefault and System.loadLibrary interplay

On 04/01/2018 01:35, David Holmes wrote: You're not missing anything. It's a class initialization related "deadlock". Thread A has called FileSystems.getDefault() which is doing of DefaultFileSystemHolder, which in turn leads to Runtime.loadLibrary0 which needs to lock the Runtime instance