RE: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for definitions of system properties

Hi Roger, Thanks for review. Please find below updated version of webrev:- http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.01/ Regards, Deepak -Original Message- From: Roger Riggs Sent: Friday, May 17, 2019 8:35 PM To: core-libs-dev@openjdk.java.net Subject: Re: [13] RFR:

Re: RFR - JDK-8203444 String::formatted (Preview)

* Jim Laskey: > Good point. To make sure I fully understand what you are stating, > > - The argument for having an instance method is reasonable to achieve > "flowiness". Right. > - However, only one version is necessary or desired, that is, "public > String formatted(Object... args)". Yes, thi

Re: RFR - JDK-8223780 String::translateEscapes (Preview)

Thank you. Will integrate your suggested changes. > On May 21, 2019, at 8:15 PM, Brent Christian > wrote: > > Hi, Jim > > I have some comments on the CSR and the Webrev. > > > CSR: > > > "This method takes the receiver String a replaces escape sequences with > character equivalents."

Re: [13] RFR: 8214565 and 8214563: Use {@systemProperty} for definitions of system properties

Looks good. On 05/22/2019 03:18 AM, Deepak Kejriwal wrote: Hi Roger, Thanks for review. Please find below updated version of webrev:- http://cr.openjdk.java.net/~dkejriwal/8214565_8214563/webrev.01/ Regards, Deepak -Original Message- From: Roger Riggs Sent: Friday, May 17, 2019 8:35

Re: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

No problems in tier 1 tests (jdk-submit). ..Thomas On Wed, May 22, 2019 at 8:16 AM Thomas Stüfe wrote: > Ping... > > Guys, I need some feedback on this. If we do not fix this issue, we may > want to roll back the use of posix_spawn() as a default and return to vfork > for JDK13. > > The fix has

Re: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

I'm in favor of what the change is meant to accomplish. I haven't had time to analyze the change in detail, and I may not get time to do so. But I'm not a reviewer in any case, so maybe that doesn't matter too much. On Wed, May 22, 2019 at 1:16 AM Thomas Stüfe wrote: > > Ping... > > Guys, I need

Re: RFR(s): (new approach) 8223777: In posix_spawn mode, failing to exec() jspawnhelper does not result in an error

Any technical input is welcome, Reviewer or not. If a non-Reviewer sees valid reasons for or against a patch, that is good to know. Cheers, Thomas On Wed, May 22, 2019 at 4:41 PM David Lloyd wrote: > I'm in favor of what the change is meant to accomplish. I haven't had > time to analyze the ch

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

Hi Stuart, It seems we have one major disagreement. You believe the collections framework specification is inconsistent. I believe it is consistent. (We agree that there is room for improvement.) That disagreement is making communication more difficult. Based on your reply, I assume the disagr

Re: RFR (M): JDK-6394757: rev1: AbstractSet.removeAll semantics are surprisingly dependent on relative sizes

For the record, the performance change that concerns me involves the removal of a small number of elements from a large HashSet. Let’s say I want to remove three elements from a large HashSet. I could write target.remove(e1); target.remove(e2); target.remove(e3); or, if the elements were in a

Re: RFR: 8224202: Speed up Properties.load

Reworked after further analysis: - swapping out char[] for StringBuilder was only a win for the outgoing buffer - using locals for oft-accessed variables in readLine is a substantial interpreter-only optimization[1] - the skipLF logic can safely be folded into the end-of-line logic, thus re

Re: RFR(XS): 8220072: GCC 8.3 reports errors in java.base

Hi Dmitry, Looks ok. Roger On 05/21/2019 04:24 PM, Dmitry Chuyko wrote: Hello, Please review a small fix for compilation error reported by recent compiler in canonicalize() from canonicalize_md.c. PATH_MAX may be passed as num argument to strncpy() and ‘\0’ is added to resulting string. Th

Re: RFR: JDK-8223914: specification of j.l.c.MethodTypeDesc::of should document better the exceptions thrown

Hi Vicente, Looks ok. Roger On 05/20/2019 03:29 PM, Vicente Romero wrote: Hi Roger, On 5/20/19 2:00 PM, Roger Riggs wrote: Hi Vicente, In the CSR, the Summary should be about the change... "...MethodTypeDesc::of should document all exceptions. Avoid duplication between Summary and Proble

Re: RFR - JDK-8223775 String::stripIndent (Preview)

On 5/21/2019 4:19 PM, Alex Buckley wrote: On 5/21/2019 2:10 PM, Jim Laskey wrote: Updated version http://cr.openjdk.java.net/~jlaskey/8223775/webrev-02 API spec looks good, but it was a surprise to learn that stripIndent performs normalization of line terminators: "@return string with margins

How to identify prioritized bugs/enhancements needing working on?

Hi, I'm currently looking through the "bugs" database to see what issues/enhancements I can help out with.. but struggling a bit to find a clear list of what looks like a suitably prioritized bug/enhancement to work on. How best could I view what should be looked at for the upcoming releases? o

Re: RFR: 8224202: Speed up Properties.load

Hi Claes, Properties.java: 542-547, 636-639 you might find the function Ivan added useful:     newlen =  ArraySupport.newLength(oldlength, min, preferred); Can it be refactored differently to read the bytes into a char array and then process that to avoid the processing code duplication.

Re: RFR(XS): 8220072: GCC 8.3 reports errors in java.base

Thanks for the review, pushed with copyright update. -Dmitry On 5/22/19 8:36 PM, Roger Riggs wrote: Hi Dmitry, Looks ok. Roger On 05/21/2019 04:24 PM, Dmitry Chuyko wrote: Hello, Please review a small fix for compilation error reported by recent compiler in canonicalize() from canonicali

Re: RFR: 8224202: Speed up Properties.load

Hi Roger, On 2019-05-22 20:09, Roger Riggs wrote: Hi Claes, Properties.java: 542-547, 636-639 you might find the function Ivan added useful:     newlen =  ArraySupport.newLength(oldlength, min, preferred); good suggestion - this is a slow path that we don't hit in any of the startup te

[13] RFR: 8221431: Support for Unicode 12.1

Hi, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8221431 The proposed CSR and changeset are located at: https://bugs.openjdk.java.net/browse/JDK-8222771 https://cr.openjdk.java.net/~naoto/8221431/webrev.03/ This enhancement incorporates support fo

Re: [13] RFR: 8221431: Support for Unicode 12.1

Adding build-dev, as the change adds a small build tool to parse emoji-data. Naoto On 5/22/19 3:26 PM, naoto.s...@oracle.com wrote: Hi, Please review the changes to the following issue: https://bugs.openjdk.java.net/browse/JDK-8221431 The proposed CSR and changeset are located at: https://b

Re: [13] RFR: 8221431: Support for Unicode 12.1

Hello Naoto, In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double $$. I would recommend calling the newer MakeTargetDir macro instead. It doesn't take an argument. Otherwise build changes look good. /Erik On 2019-05-22 15:56, naoto.s...@oracle.com wrote: Adding build-dev

Re: RFR: 8224202: Speed up Properties.load

Hi Claes! A few comments: 1) 571 if (len == lineBuf.length) { 572 int newLength = ArraysSupport.newLength(lineBuf.length, 1, lineBuf.length); could be written slightly shorter as 571 if (len == lineBuf.length) { 572

Re: RFR: 8224629: Unnecessary indirection in LambdaToMethod

Hi Alan, This javac change should be reviewed on compiler-dev not core-libs-dev. Thanks, David On 23/05/2019 10:42 am, Alan Malloy wrote: Hello. Please review this patch to eliminate an unnecessary upcast and method call in LambdaToMethod. bug: https://bugs.openjdk.java.net/browse/JDK-8224629

RFR: 8215156: Deprecate the -Xfuture option

Hi, Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2]. Cheers, Henry [1] https://cr.openjdk.java.net/~henryjen/jdk13/8215156/open/webrev/ [2] https://bugs.openjdk.java.net/browse/JDK-8224524

Re: RFR: 8215156: Deprecate the -Xfuture option

Hi Henry, On 23/05/2019 11:07 am, Henry Jen wrote: Hi, Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2]. src/hotspot/share/Xusage.txt Ignoring the usefulness, or otherwise of this file, the entry for Xfuture should not be deleted (that happens when an option is

Re: [13] RFR: 8221431: Support for Unicode 12.1

Hi Erik, Thank you for your comments. Updated the webrev accordingly: https://cr.openjdk.java.net/~naoto/8221431/webrev.04/ Naoto On 5/22/19 4:13 PM, Erik Joelsson wrote: Hello Naoto, In GensrcEmojiData.gmk: The MakeDir doesn't look correct with the double $$. I would recommend calling the

Re: RFR: 8215156: Deprecate the -Xfuture option

Thanks for the quick review, > On May 22, 2019, at 6:34 PM, David Holmes wrote: > > Hi Henry, > > On 23/05/2019 11:07 am, Henry Jen wrote: >> Hi, >> Please review a webrev[1] to deprecate the -Xfuture option per >> CSR-8224524[2]. > > src/hotspot/share/Xusage.txt > > Ignoring the usefulness,

Re: RFR: 8215156: Deprecate the -Xfuture option

On 23/05/2019 11:56 am, Henry Jen wrote: Thanks for the quick review, On May 22, 2019, at 6:34 PM, David Holmes wrote: Hi Henry, On 23/05/2019 11:07 am, Henry Jen wrote: Hi, Please review a webrev[1] to deprecate the -Xfuture option per CSR-8224524[2]. src/hotspot/share/Xusage.txt Ignori

Re: RFR: 8215156: Deprecate the -Xfuture option

> On May 22, 2019, at 7:04 PM, David Holmes wrote: > > On 23/05/2019 11:56 am, Henry Jen wrote: >> Thanks for the quick review, >>> On May 22, 2019, at 6:34 PM, David Holmes wrote: >>> >>> Hi Henry, >>> >>> On 23/05/2019 11:07 am, Henry Jen wrote: Hi, Please review a webrev[1] to d

Re: RFR: 8215156: Deprecate the -Xfuture option

Looks good. Thanks, David On 23/05/2019 12:44 pm, Henry Jen wrote: On May 22, 2019, at 7:04 PM, David Holmes wrote: On 23/05/2019 11:56 am, Henry Jen wrote: Thanks for the quick review, On May 22, 2019, at 6:34 PM, David Holmes wrote: Hi Henry, On 23/05/2019 11:07 am, Henry Jen wrote: