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 A

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 wrote: What if ConnectException in

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, MA 01803 lance.ander

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 / port >>> SocketAddress? >>> java.net.ConnectException

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 call. Yes, i inclu

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' refused Much more useful! T

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 could also be extended to variou

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, > > Thanks for the review

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 +++ new/src/java.xml/share/c

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* s

[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 2017-1

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 different internal API that also

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 me, i think keeping the

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 >> arguably over spent. > > I concur that this horse is

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 which eliminates intermediat

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 1/3

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 everythi

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 size >while ((n = re

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 writte

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 > filled. The inner reading l

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 init

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 into buffers of DEFAULT

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 'exception

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 has a replacement, and add

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] http://openjdk.ja

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 script

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 them to an ArrayList, >

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 <= >> DEFAULT_BUFFER_SIZE; >> * us

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 langtools test. Is it just tryi

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 then okay. Jdeps prints he

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 langtools test. Is it just tr

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 initi

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 trying to >> reference so

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 sure the various code pat

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 webrev

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 probably makes sense to push

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 changes in the hotspot area, t