RFR (XXS) 8233658 : Escape + in the expression describing Runtime.Version string

Hello! Here's yet another javadoc-only fix. Format of the Runtime.Version string is described as a list of regular expressions [1]: $VNUM(-$PRE)?\+$BUILD(-$OPT)? $VNUM-$PRE(-$OPT)? $VNUM(+-$OPT)? The character + in the last line should be escaped to be consistent with the

Re: RFR (S) 8233650 : Javadoc for Math.floorMod(int, int) gives wrong example

Thank you Brian! Pushed. On 11/5/19 4:05 PM, Brian Burkhalter wrote: Hi Ivan, I think this looks good. Brian On Nov 5, 2019, at 3:35 PM, Ivan Gerasimov wrote: The javadoc for the method Math.floorMod(int, int) [1] contains an inaccuracy. There are two sets of examples given: One for

RFR of JDK-8232446: logging enhancement for rmi when socket closed

Would you please review the patch? bug: https://bugs.openjdk.java.net/browse/JDK-8232446 webrev: http://cr.openjdk.java.net/~mli/8232446/webrev.00/ We have some intermittent failures in rmi related to socket closing, this is to add more logging to help diagnose the issues. Thanks you

JDK 14 RFR of JDK-8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR results in incorrect result

Hello, Please review the changes to fix     JDK-8233452: java.math.BigDecimal.sqrt() with RoundingMode.FLOOR results in incorrect result     http://cr.openjdk.java.net/~darcy/8233452.0/ Some background on the problem and fix. The core of the BigDecimal.sqrt method is a Newton-Raphson loop.

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

Hi Andy, http://cr.openjdk.java.net/~herrick/8233594/webrev.01/src/jdk.jpackage/share/classes/jdk/jpackage/internal/resources/HelpResources.properties.frames.html  106 \  Pass on --bind-seervices option to jlink (which will link in \n\ Spelling: --bind-seervices -> --bind-services

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

I noticed this problem when creating various demo scenarios so +1 to the change, but +\ Pass on --bind-seervices option to jlink (which will link in \n\ typo here -phil On 11/5/19, 3:36 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for

Re: RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

Looks good. - Alexey On 11/5/2019 6:36 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This changes adds the --bind-services option and removes the previous behavior of

Re: RFR (S) 8233650 : Javadoc for Math.floorMod(int, int) gives wrong example

Hi Ivan, I think this looks good. Brian > On Nov 5, 2019, at 3:35 PM, Ivan Gerasimov wrote: > > The javadoc for the method Math.floorMod(int, int) [1] contains an inaccuracy. > > There are two sets of examples given: One for the case when signs of the > arguments are the same and the other

RFR: JDK-8233594: create a new option --bind-servces to pass on to jlink

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This changes adds the --bind-services option and removes the previous behavior of always including --bind-services in the jlink options except when

RFR (S) 8233650 : Javadoc for Math.floorMod(int, int) gives wrong example

Hello! The javadoc for the method Math.floorMod(int, int) [1] contains an inaccuracy. There are two sets of examples given:  One for the case when signs of the arguments are the same and the other for the case when signs of the arguments are different. The second set of examples wrongly

Re: RFR: JDK-8233592: change --package-type option name to --type and allow -t short form

Looks good. On 11/5/2019 12:39 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This changes the --package-type option to just --type , and adds the -t short form. [1]

[14] RFR: 8232871: Host Locale Provider on Mac does not return translated values of Japanese calendar

Hello, Please review the fix to the following issue: https://bugs.openjdk.java.net/browse/JDK-8232871 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8232871/webrev.00/ Implementation for getting calendar display names was missing in macOS's host adapter. Naoto

Re: RFR: JDK-8233592: change --package-type option name to --type and allow -t short form

+1 On 11/5/2019 9:47 PM, Alexey Semenyuk wrote: Looks good. - Alexey On 11/5/2019 3:39 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This changes the --package-type

Re: RFR: JDK-8233592: change --package-type option name to --type and allow -t short form

Looks good. - Alexey On 11/5/2019 3:39 PM, Andy Herrick wrote: Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This changes the --package-type option to just --type , and adds the -t short form.

RFR: JDK-8233592: change --package-type option name to --type and allow -t short form

Please review the jpackage fix for bug [1] at [2]. This is a fix for the JDK-8200758-branch branch of the open sandbox repository (jpackage). This changes the --package-type option to just --type , and adds the -t short form. [1] https://bugs.openjdk.java.net/browse/JDK-8233592 [2]

Re: RFR: CSR Core-libs support for records

I have updated the CSR after some feedback, please take a look at it. I have added some comments to the bug entry describing the last changes Thanks, Vicente On 11/4/19 3:54 PM, Vicente Romero wrote: Hi, Please review the draft of the CSR for Core-libs support for records at [1] Thanks,

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

I attached text-blocks-jls.html which contains the current unified text blocks + new escape sequences spec. Edited the CSR's Specification section refer specifically to section 3.10.7 of the attachment rather than reproducing some of that section. Made some small edits elsewhere related to

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

> De: "John Rose" > À: "Remi Forax" > Cc: "Jim Laskey" , "compiler-dev" > , "core-libs-dev" > > Envoyé: Mardi 5 Novembre 2019 19:35:45 > Objet: Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and > White > Space (Preview) > On Nov 5, 2019, at 10:17 AM, Remi Forax < [

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

On Nov 5, 2019, at 10:17 AM, Remi Forax wrote: > > the rationale to add \ is well explain but why do you want to > introduce \s given we already have \u0020 ? Remi, you are an expert in the field and you got fooled! This is *exactly* why we need \s. The \u syntax is expanded *before*

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

Whereas \u0020 is just another way of expressing space, it also gets consumed by trailing space stripping. Maybe you meant to say we already have \040, which I would reply that you might have the ASCII table memorized but many do not. \s also has brevity on its side. String colors = """

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

This should be answered in JEP 368, which currently introduces \s with its definition rather than a connecting line back to the final line of the Motivation. JEP 355 had text about the octal escape sequence \040 and now Remi has raised \u0020 -- both should be positioned in 368 as less-clear

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

Hi Jim, the rationale to add \ is well explain but why do you want to introduce \s given we already have \u0020 ? Rémi - Mail original - > De: "Jim Laskey" > À: "core-libs-dev" , "compiler-dev" > > Envoyé: Mardi 5 Novembre 2019 19:00:32 > Objet: Re: RFR: CSR JDK-8233117 Escape

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

Re-proposed. > On Nov 5, 2019, at 11:40 AM, Jim Laskey wrote: > > I'm withdrawing until it is the correct format. Apologies. > > >> On Nov 5, 2019, at 9:58 AM, Jim Laskey wrote: >> >> Please review the following CSR. Provides for the introduction of two new >> escape sequences \ and \s. \

Re: Further comments on jpackage (JEP 343)

The three suggestions below are captured in the 3 enhancements: JDK-8233594 , JDK-8233592 , and JDK-8233591 I should be able to have these

Re: RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

I'm withdrawing until it is the correct format. Apologies. > On Nov 5, 2019, at 9:58 AM, Jim Laskey wrote: > > Please review the following CSR. Provides for the introduction of two new > escape sequences \ and \s. \ allows > developers to express unwieldy string literals in a text block as

Re: Return value of DateFormatSymbols.getWeekdays()

Hi, Please create an issue in the Jira (https://bugs.openjdk.java.net). The appropriate email alias  is:    core-libs-dev@openjdk.java.net Thanks, Roger On 11/5/19 1:31 AM, Wang Zhuo(Zhuoren) wrote: Hi, I am an engineer from Alibaba, and I have a question for return value of

RFR: CSR JDK-8233117 Escape Sequences For Line Continuation and White Space (Preview)

Please review the following CSR. Provides for the introduction of two new escape sequences \ and \s. \ allows developers to express unwieldy string literals in a text block as a cluster of short single line segments. The second is to allow developers to express ASCII space, much like \t for

Re: RFR: CSR Core-libs support for records

> On 4 Nov 2019, at 23:22, Joe Darcy wrote: > ... > It isn't unreasonable for java.lang.Record to make some mention of the > special treatment by serialization. (As a point of reference, java.lang.Enum > does *not* reference the special handling of enums of serialization.) > > I think a

Re: RFR: JDK-8232684: Make switch expressions final

I've missed updates to some hotspot and jdk tests in the first patch. The problem are unqualified invocations of Thread.yield(), which are no longer allowed (from the spec: JLS 3.9 Keywords: "All invocations of a method called yield must be qualified so as to be distinguished from a yield

Re: RFR: CSR Core-libs support for records

> On 4 Nov 2019, at 21:27, Florian Weimer wrote: > > ... > Right now, it appears to be possible to have a record implement > java.io.Serializable, and serialization will appear to work, but > because the names of the implicitly generated private fields are not > specified, it is not portable