Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

John Rose wrote: Can anyone point out a reason why the value based lists of List.of() should serialize while the value based lists of List.of().subList() should not? Or is there some reason we should not allow subList to produce value based lists? I think one can interpret the @implSpec in

Re: Adding SocketChannel toString to connection exception messages

cc'ing net-dev as that might be the more appropriate list. On 22/12/2017 10:59 AM, Steven Schlansker wrote: On Dec 21, 2017, at 4:35 PM, David Holmes wrote: On 22/12/2017 10:29 AM, Steven Schlansker wrote: On Dec 21, 2017, at 11:11 AM, Steven Schlansker

Re: RFR (JDK10/JAXP Doc-only) 8184431: References to @sun.com

Thanks Lance! On 12/21/17, 4:12 PM, Lance @ Oracle wrote: Hi joe Looks fine Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington,

Re: [10?] RFR: 8193128: Reduce number of implementation classes returned by List/Set/Map.of()

Finally catching up with this thread Yes, there should be some additional test cases added. When I added the immutable collection classes in JDK 9, I did modify MOAT.java so that its test cases would apply to the new implementations. A few more cases could be added that apply not only to

Re: Adding SocketChannel toString to connection exception messages

> On Dec 21, 2017, at 4:35 PM, David Holmes wrote: > > On 22/12/2017 10:29 AM, Steven Schlansker wrote: >>> On Dec 21, 2017, at 11:11 AM, Steven Schlansker >>> wrote: >>> >>> What if ConnectException included the attempted hostname / IP /

Re: [10] RFR 8075939: Stream.flatMap() causes breaking of short-circuiting of terminal operations

> On 21 Dec 2017, at 15:46, Remi Forax wrote: > > Hi Paul, > three things: > - I think you should add a comment to explain why you have chosen to create a > the field downstream* in the primitive implementations, > I suppose it's to avoid to allocate a lambda proxy at each

Re: Adding SocketChannel toString to connection exception messages

On 22/12/2017 10:29 AM, Steven Schlansker wrote: On Dec 21, 2017, at 11:11 AM, Steven Schlansker wrote: What if ConnectException included the attempted hostname / IP / port SocketAddress? java.net.ConnectException: Connection to 'foo.mycorp.com[10.x.x.x]:12345'

Re: Adding SocketChannel toString to connection exception messages

> On Dec 21, 2017, at 11:11 AM, Steven Schlansker > wrote: > > What if ConnectException included the attempted hostname / IP / port > SocketAddress? > java.net.ConnectException: Connection to 'foo.mycorp.com[10.x.x.x]:12345' > refused > Much more useful! This

Re: RFR (JDK10/JAXP Doc-only) 8184431: References to @sun.com

Hi joe Looks fine Best Lance Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037 Oracle Java Engineering 1 Network Drive Burlington, MA 01803 lance.ander...@oracle.com Sent from my iPad > On Dec 21, 2017, at 6:48 PM, Joe Wang wrote: > > Hi Lance, >

Re: RFR (JDK10/JAXP Doc-only) 8184431: References to @sun.com

Hi Lance, Thanks for the review! As you suggested, the names in comments, and "Sun Microsystems" in a few cases in the following classes are removed. Updated webrevs: http://cr.openjdk.java.net/~joehw/jdk10/8184431/webrev/index.html Happy Holidays! Best, Joe +++

Re: [10] RFR 8075939: Stream.flatMap() causes breaking of short-circuiting of terminal operations

Hi Paul, three things: - I think you should add a comment to explain why you have chosen to create a the field downstream* in the primitive implementations, I suppose it's to avoid to allocate a lambda proxy at each call. - the fields in the inner classes cancellationRequested and downstream*

[10] RFR 8075939: Stream.flatMap() causes breaking of short-circuiting of terminal operations

Hi, Please review the following webrev that makes flatMap non-aggressive when pushing elements downstream if any downstream operation is short-circuiting. http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8075939-flatMap-aggressive-push/webrev/index.html

Re: RFR (JDK10/JAXP Doc-only) 8184431: References to @sun.com

Hi Joe, Overall, this is fine, a few things to consider if you want to address Happy Holidays Best Lance Do we really need to keep the name in comments such as these: final class TestSeq { --- old/src/java.xml/share/classes/com/sun/org/apache/xerces/internal/dom/ElementImpl.java

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

On 12/21/17 9:18 AM, Chris Hegarty wrote: On 21 Dec 2017, at 16:09, mandy chung wrote: ... The test is about identifying StackWalker as the replacement supported API for getCallerClass, which is continues to do. I could add yet another scenario to test for a

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

On Dec 21, 2017, at 11:44 AM, Paul Sandoz wrote: >> I concur that this horse is almost dead from the beatings but since I >> already hacked up Peter’s suggestion which eliminates intermediate copies I >> might as well hang it out there (see below). > > That looks ok to

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

> On 21 Dec 2017, at 11:05, Brian Burkhalter > wrote: > > Hi Paul, > > On Dec 21, 2017, at 10:28 AM, Paul Sandoz > wrote: > >> This looks ok, i think it’s definitely reached it’s complexity budget, and

RFR (JDK10/JAXP Doc-only) 8184431: References to @sun.com

Hi, This change uses a process to strip off the @sun.com email addresses and links, and keep just the name of the authors. Please review: JBS: https://bugs.openjdk.java.net/browse/JDK-8184431 webrev: http://cr.openjdk.java.net/~joehw/jdk10/8184431/webrev/index.html Thanks, Joe

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

Hi Paul, On Dec 21, 2017, at 10:28 AM, Paul Sandoz wrote: > This looks ok, i think it’s definitely reached it’s complexity budget, and > arguably over spent. I concur that this horse is almost dead from the beatings but since I already hacked up Peter’s suggestion

Adding SocketChannel toString to connection exception messages

Hi core-libs-dev, While tracking down a connectivity issue, we identified that two of our hosts are unable to talk to each other due to a misconfiguration of the network. This manifested as: 2017-12-21T11:00:34.840Z DEBUG <> [default-pool-34] o.e.j.client.AbstractConnectionPool - Connection

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

Aleksei, You have to override all of the constructors to always disable initCause. Actually a similar issue was covered in: http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-May/016908.html http://mail.openjdk.java.net/pipermail/core-libs-dev/2013-June/017594.html Pretty much

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

Hi Peter, On Dec 21, 2017, at 10:26 AM, Brian Burkhalter wrote: > What about the case where read() returns 0, e.g., when reading from a socket, > but subsequent reads return positive values? > >// read to EOF which may read more or less than buffer

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

Hi, This looks ok, i think it’s definitely reached it’s complexity budget, and arguably over spent. — I do have one follow on investigation we discussed off list that is worth measuring. At the end use the Unsafe array allocation with no zeroing, since the resulting array will be fully

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

On Dec 21, 2017, at 10:23 AM, Peter Levart wrote: >> Or I suppose a single List containing an object containing both the bytes >> and the length would work. One could for example us > > I don't think this would be necessary. All buffers but the last one are fully >

Re: RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

Hi Aleksei, In the case of creating SAXException and then calling initCause() it looks like the value returned by getException() and getCause() may differ. The past behavior and the descriptions of those two methods are the same. Is the change intentional? If not, you may need to override

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

On 12/21/2017 05:38 PM, Brian Burkhalter wrote: Hi Peter, On Dec 21, 2017, at 2:03 AM, Peter Levart wrote: This is OK as is, but I see another possible improvement to the logic. You decide whether it is worth trying to implement it. Currently the logic reads stream

Re: RFR (JDK10/JAXP Doc-only) 8193568 : @LastModified tag in license header

Thanks Roger! On 12/21/17, 9:02 AM, Roger Riggs wrote: Hi Joe, Looks fine Thanks, Roger On 12/20/2017 5:35 PM, Joe Wang wrote: Hi, Refer to the previous change for JDK-8191938[1], the @LastModified tag needs to be moved to the class description section. This change affects 341 files and

RFR [11] (JAXP): 6857903: SAXException.initCause() does not correctly set Exception

Hello, Please, help to review the fix for jaxp bug that fixes SAXException to correctly set exception cause with 'setCause' method: http://cr.openjdk.java.net/~aefimov/6857903/dev/00/ I've tried to keep the fix miminal with respect to serial form of this API class, i.e. kept private

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

> On 21 Dec 2017, at 16:09, mandy chung wrote: > >>> ... >> The test is about identifying StackWalker as the replacement >> supported API for getCallerClass, which is continues to do. >> I could add yet another scenario to test for a different internal >> API that also

Re: [PATCH] Support for UTC Zones with TimeZone.getTimeZone()

Hi Naufal, I can sponsor your fix. Here is the issue created for this: https://bugs.openjdk.java.net/browse/JDK-8193938 If haven't already, would you take a look at the OpenJDK contribute page? [1] Also, I will need a regression test for the fix as well. Thanks! Naoto [1]

Re: RFR (JDK10/JAXP Doc-only) 8193568 : @LastModified tag in license header

Hi Joe, Looks fine Thanks, Roger On 12/20/2017 5:35 PM, Joe Wang wrote: Hi, Refer to the previous change for JDK-8191938[1], the @LastModified tag needs to be moved to the class description section. This change affects 341 files and may be hard to look through. But it's done with a

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

Hi Peter, On Dec 21, 2017, at 2:03 AM, Peter Levart wrote: > This is OK as is, but I see another possible improvement to the logic. You > decide whether it is worth trying to implement it. Currently the logic reads > stream into buffers of DEFAULT_BUFFER_SIZE and adds

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

On Dec 21, 2017, at 3:05 AM, Alan Bateman wrote: > On 20/12/2017 22:30, Brian Burkhalter wrote: >> : >> http://cr.openjdk.java.net/~bpb/8193832/webrev.03/ >> >> The patch is updated to: >> >> * use Peter’s approach to avoid allocating an ArrayList when length <= >>

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

On 12/21/17 2:20 AM, Chris Hegarty wrote: David, Alan, On 21 Dec 2017, at 09:54, Alan Bateman wrote: On 21/12/2017 09:29, David Holmes wrote: : Updated webrev: http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ I don't quite follow the change to the

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

> On 21 Dec 2017, at 12:33, David Holmes wrote: > ... >> The test is about identifying StackWalker as the replacement >> supported API for getCallerClass, which is continues to do. > > Won't pretend I actually understand that, but as long as the test works > reliably

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

On 21/12/2017 8:20 PM, Chris Hegarty wrote: David, Alan, On 21 Dec 2017, at 09:54, Alan Bateman wrote: On 21/12/2017 09:29, David Holmes wrote: : Updated webrev: http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ I don't quite follow the change to the

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

On 20/12/2017 22:30, Brian Burkhalter wrote: : http://cr.openjdk.java.net/~bpb/8193832/webrev.03/ The patch is updated to: * use Peter’s approach to avoid allocating an ArrayList when length <= DEFAULT_BUFFER_SIZE; * use the default ArrayList constructor instead of that with a specific

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

David, Alan, > On 21 Dec 2017, at 09:54, Alan Bateman wrote: > > On 21/12/2017 09:29, David Holmes wrote: >> : >>> >>> Updated webrev: >>>http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ >> >> I don't quite follow the change to the langtools test. Is it just

Re: RFR 8193832: Performance of InputStream.readAllBytes() could be improved

Hi Brian, On 12/20/2017 11:30 PM, Brian Burkhalter wrote: On Dec 20, 2017, at 11:52 AM, Paul Sandoz wrote: I was a little lassiaz-faire given that 8K bytes were anyway being allocated upfront. Peter’s changes look good. Brian, i would double check the tests to make

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

On 21/12/2017 09:29, David Holmes wrote: : Updated webrev:    http://cr.openjdk.java.net/~chegar/8179424/webrev.02/ I don't quite follow the change to the langtools test. Is it just trying to reference something in jdk.unsupported? I don't know what the "patch" does. I looked through

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

David, > On 21 Dec 2017, at 00:42, David Holmes wrote: > > Hi Chris, > > Adding in hotspot-runtime-dev now that you have included the VM side of the > cleanup. What repo are you planning on pushing this to? Since there are now changes in the hotspot area, then it

Re: RFR [11] JDK-8179424: Remove terminally deprecated sun.reflect.Reflection.getCallerClass

On 21/12/2017 7:20 PM, Chris Hegarty wrote: David, On 21 Dec 2017, at 00:42, David Holmes wrote: Hi Chris, Adding in hotspot-runtime-dev now that you have included the VM side of the cleanup. What repo are you planning on pushing this to? Since there are now