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

Hi Naoto, Thank you for the feedback, I'll send an updated patch shortly. Best regards, Naufal On 21 December 2017 at 05:19, Naoto Sato wrote: > Hi Naufal, > > Thank you for the patch. It does seem to be a bug. However, TimeZone class > defines CustomID as "GMT+(offset)", so I'd rather fix it

Re: RFR(s): 8140281 add no-arg Optional.orElseThrow() as preferred alternative to get()

On 12/18/17 2:31 AM, Tagir Valeev wrote: I think that both methods could co-exist with slightly different semantics (even though they implementation is identical): ... Think of get() as an assertion-like method: if get() throws, then it's a bug in the code (most likely right in this method). ..

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

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? On 21/12/2017 9:45 AM, Chris Hegarty wrote: On 20 Dec 2017, at 19:21, mandy chung wrote: The native side and hotspot side should also be cleaned up

Re: [10] RFR 8193856 takeWhile produces incorrect result with elements produced by flatMap

On 12/20/17 1:28 PM, Paul Sandoz wrote: Please review this fix for a bug in the stream takeWhile operation: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8193856-takeWhile-incorrect-results/webrev/

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

On 12/20/17 3:45 PM, Chris Hegarty wrote: On 20 Dec 2017, at 19:21, mandy chung > wrote: The native side and hotspot side should also be cleaned up. Good call. I think the following is probably as far as we want to go. Maybe a follow-on issue could be filed i

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

Hi Brian, Brian Burkhalter je 20. 12. 2017 ob 22:54 napisal: Hi Peter, On Dec 20, 2017, at 3:45 AM, Peter Levart > wrote:     if (result == null) { result = copy;     } else { bufs = new ArrayList<>(8); // <— ? bufs.add(result); bufs.add

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

> On 20 Dec 2017, at 19:21, mandy chung wrote: > > The native side and hotspot side should also be cleaned up. Good call. I think the following is probably as far as we want to go. Maybe a follow-on issue could be filed if deeper VM clean up is needed? http://cr.openjdk.java.net/~chegar/81794

Re: [10] RFR 8193856 takeWhile produces incorrect result with elements produced by flatMap

Hi Jonathan, > On 20 Dec 2017, at 14:47, Jonathan Bluett-Duncan > wrote: > > Hi Paul, > > It seems that some clever Googler managed to find a workaround for aggressive > `flatMap` operations in the form of a so-called `MoreStreams.flatten` > operation, implemented in a side project called g

Re: [10] RFR 8193856 takeWhile produces incorrect result with elements produced by flatMap

Hi Paul, It seems that some clever Googler managed to find a workaround for aggressive `flatMap` operations in the form of a so-called `MoreStreams.flatten` operation, implemented in a side project called google/mug. I'm sharing the javadoc

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

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 that simply moves the tag from the top header to the class description sect

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

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 paths are > tested. http://cr.openjdk.java.net/~bpb/81

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

Hi Peter, On Dec 20, 2017, at 3:45 AM, Peter Levart wrote: > if (result == null) { > result = copy; > } else { > bufs = new ArrayList<>(8); // <— ? > bufs.add(result); > bufs.add(copy)

[10] RFR 8193856 takeWhile produces incorrect result with elements produced by flatMap

Hi, Please review this fix for a bug in the stream takeWhile operation: http://cr.openjdk.java.net/~psandoz/jdk10/JDK-8193856-takeWhile-incorrect-results/webrev/ The flatMap operation is currently ag

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

> On 20 Dec 2017, at 11:04, John Rose wrote: > > On Dec 20, 2017, at 3:45 AM, Peter Levart > wrote: >> >> allocation of ArrayList could be avoided. Imagine a use case where lots of >> small files are read into byte[] arrays > > +1 I was going to write a simila

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

Looks good Chris! -- daniel On 20/12/2017 18:42, Chris Hegarty wrote: In JDK 9 sun.reflect.Reflection.getCallerClass, and its jdk.internal counterpart, where both deprecated-for-removal ( to give prior warning of the unsupported private API's intended removal ). The supported replacement, since

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

The native side and hotspot side should also be cleaned up. Mandy On 12/20/17 11:20 AM, mandy chung wrote: On 12/20/17 10:42 AM, Chris Hegarty wrote: In JDK 9 sun.reflect.Reflection.getCallerClass, and its jdk.internal counterpart, where both deprecated-for-removal ( to give prior warning of

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

On 12/20/17 10:42 AM, Chris Hegarty wrote: In JDK 9 sun.reflect.Reflection.getCallerClass, and its jdk.internal counterpart, where both deprecated-for-removal ( to give prior warning of the unsupported private API's intended removal ). The supported replacement, since Java SE 9, is java.lang.St

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

+1 On 12/20/2017 1:53 PM, Lance Andersen wrote: looks fine Chris Best Lance On Dec 20, 2017, at 1:42 PM, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8179424/webrev/

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

On Dec 20, 2017, at 3:45 AM, Peter Levart wrote: > > allocation of ArrayList could be avoided. Imagine a use case where lots of > small files are read into byte[] arrays +1 I was going to write a similar suggestion; thanks for sending it out. These sorts of things often need to be designed to

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

looks fine Chris Best Lance > On Dec 20, 2017, at 1:42 PM, Chris Hegarty wrote: > > http://cr.openjdk.java.net/~chegar/8179424/webrev/ >

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

In JDK 9 sun.reflect.Reflection.getCallerClass, and its jdk.internal counterpart, where both deprecated-for-removal ( to give prior warning of the unsupported private API's intended removal ). The supported replacement, since Java SE 9, is java.lang.StackWalker. http://cr.openjdk.java.net/~chegar

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

Hi Naufal, Thank you for the patch. It does seem to be a bug. However, TimeZone class defines CustomID as "GMT+(offset)", so I'd rather fix it in GregorianCalendar.from() to recognize those "UTC+offset" zones. Naoto On 12/16/17 2:27 AM, Mohamed Naufal wrote: Hi, I noticed that with the fol

Re: [11] RFR of 8146656: Wrong Months Array for DateFormatSymbols

Hi Rachna, I think the revised version with the @implSpec tag switch is acceptable, but also think providing more text to describe this situation would be helpful to programmers unaware of a 13 month possibility. Cheers, -Joe On 12/19/2017 2:08 AM, Rachna Goel wrote: Hi Joe, Thanks for

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

Hi Peter, On Dec 20, 2017, at 8:04 AM, Peter Levart wrote: >>> found another improvement. If you are reading from files, there's no >>> difference. But if you read from say socket(s), there may be short reads >>> (read() returning 0). >> InputStreams are blocking so if someone creates an Inpu

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

On 12/20/2017 03:09 PM, Alan Bateman wrote: On 20/12/2017 12:40, Peter Levart wrote: Hi Brian, I found another improvement. If you are reading from files, there's no difference. But if you read from say socket(s), there may be short reads (read() returning 0). InputStreams are blocking so

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

On 19/12/17 23:22, Brian Burkhalter wrote: .. Updated version here: http://cr.openjdk.java.net/~bpb/8193832/webrev.02/ Looks good to me. This is a nice improvement on the original implementation that I added in 9. Thanks. -Chris.

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

On 20/12/2017 12:40, Peter Levart wrote: Hi Brian, I found another improvement. If you are reading from files, there's no difference. But if you read from say socket(s), there may be short reads (read() returning 0). InputStreams are blocking so if someone creates an InputStream over a sock

RE: RFR: JDK8u Backport of 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit

Thank you Daniel and Sean for your reviews. Regards, Ramanand. > -Original Message- > From: Daniel Fuchs > Sent: Wednesday, December 20, 2017 2:43 PM > To: Ramanand Patil ; core-libs-dev d...@openjdk.java.net> > Subject: Re: RFR: JDK8u Backport of 8153955: increase > java.util.logging.Fi

Re: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11 for JDK 11 and 12 support

Thanks Serguei! David On 20/12/2017 8:41 PM, serguei.spit...@oracle.com wrote: David, It looks good. Thanks, Serguei On 12/20/17 02:22, David Holmes wrote: Before we can update to JDK version 11, jtreg needs to be updated to recognize that release value - which is happening in jtreg 4.2 b1

Re: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11 for JDK 11 and 12 support

Thanks Alan. David On 20/12/2017 8:32 PM, Alan Bateman wrote: On 20/12/2017 10:22, David Holmes wrote: Before we can update to JDK version 11, jtreg needs to be updated to recognize that release value - which is happening in jtreg 4.2 b11. So we then need to ensure that jtreg 4.2 b11 is use

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

Hi Brian, I found another improvement. If you are reading from files, there's no difference. But if you read from say socket(s), there may be short reads (read() returning 0). Your current code bails out from inner loop when this happens and consequently does not fill the buf up to the top whe

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

Hi Brian, There's also a variation of copy-ing fragment possible, that replaces copying with allocation:     byte[] copy;     if (nread == DEFAULT_BUFFER_SIZE) {     copy = buf;     if (n >= 0) {     buf = new byte[DEF

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

Hi Brian, On 12/20/2017 12:22 AM, Brian Burkhalter wrote: On Dec 19, 2017, at 2:36 PM, Brian Burkhalter wrote: You can also simplify the “for(;;) + break" into a do while loop: do { int nread = 0; ... } while (n > 0); Good suggestion but I think that this needs to be "while (n >= 0)."

Re: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11 for JDK 11 and 12 support

David, It looks good. Thanks, Serguei On 12/20/17 02:22, David Holmes wrote: Before we can update to JDK version 11, jtreg needs to be updated to recognize that release value - which is happening in jtreg 4.2 b11. So we then need to ensure that jtreg 4.2 b11 is used by updating the required

Re: [11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11 for JDK 11 and 12 support

On 20/12/2017 10:22, David Holmes wrote: Before we can update to JDK version 11, jtreg needs to be updated to recognize that release value - which is happening in jtreg 4.2 b11. So we then need to ensure that jtreg 4.2 b11 is used by updating the requiredVersion in each of the TEST.ROOT files

Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

Looks ok to me. /Erik On 2017-12-20 10:32, Volker Simonis wrote: Hi Matthias, the change looks good! I can sponsor it once we get the approval. Also forwarded to buil-dev for the minimal build change. Thank you and best regards, Volker On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias w

[11] RFR (XS) 8193838: Update jtreg requiredVersion to 4.2 b11 for JDK 11 and 12 support

Before we can update to JDK version 11, jtreg needs to be updated to recognize that release value - which is happening in jtreg 4.2 b11. So we then need to ensure that jtreg 4.2 b11 is used by updating the requiredVersion in each of the TEST.ROOT files, and in the jib configuiration. bug: htt

Re: RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

Hi Matthias, the change looks good! I can sponsor it once we get the approval. Also forwarded to buil-dev for the minimal build change. Thank you and best regards, Volker On Wed, Dec 20, 2017 at 9:50 AM, Baesken, Matthias wrote: > Hello , Mark reported this issue on AIX with OpenJDK8 : > >

Re: RFR: JDK8u Backport of 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit

Hi Ramanand, On 18/12/2017 11:41, Ramanand Patil wrote: Hi all, Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8153955 Backport Bug: https://bugs.openjdk.java.net/browse/JDK-8161266 Webrev: http://cr.openjdk.java.net/~rpatil/8161266/webrev.00/ Looks good

RFR [jdk8] : 8193807 : AIX: avoid UnsatisfiedLinkError by providing empty basic implementations of getSystemCpuLoad and getProcessCpuLoad

Hello , Mark reported this issue on AIX with OpenJDK8 : > >I'm getting an unsatisfied link error when using logstash on AIX but I suspect >the issue is with AIX or the JRE, the exception is: > > java.lang.UnsatisfiedLinkError: > sun.management.OperatingSystemImpl.getProcessCpuLoad()D >

Re: RFR: JDK8u Backport of 8153955: increase java.util.logging.FileHandler MAX_LOCKS limit

Looks fine to me. regards, Sean. On 18/12/2017 11:41, Ramanand Patil wrote: Hi all, Please review the fix for JDK8u Backport of https://bugs.openjdk.java.net/browse/JDK-8153955 Backport Bug: https://bugs.openjdk.java.net/browse/JDK-8161266 Webrev: http://cr.openjdk.java.net/~rpatil/8161266/we