From naoto.sato at oracle.com Fri Aug 14 22:20:08 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Fri, 14 Aug 2020 15:20:08 -0700 Subject: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException Message-ID: <5b81c727-b1e0-0614-c68e-5568f98d9d6f@oracle.com> Hello, Please review the fix for the following issue: https://bugs.openjdk.java.net/browse/JDK-8251499 The proposed changeset is located at: https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ The current implementation of CompactNumberFormat assumes that there is always the number placeholder part in compact patterns. This is not always true. In fact, upcoming CLDR 38 resurrects such patterns, so this fix is a precursor to support CLDR 38. Naoto From huizhe.wang at oracle.com Sat Aug 15 01:21:15 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Fri, 14 Aug 2020 18:21:15 -0700 Subject: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException In-Reply-To: <5b81c727-b1e0-0614-c68e-5568f98d9d6f@oracle.com> References: <5b81c727-b1e0-0614-c68e-5568f98d9d6f@oracle.com> Message-ID: Hi Naoto, Looks good to me. While a negative divisor representing no zeros is newly introduced, the "divisor > 0" checks seem to have always been beneficial.? I had to count the number of ""s in COMPACT_PATTERN13 :-) Have a great weekend! Joe On 8/14/2020 3:20 PM, naoto.sato at oracle.com wrote: > Hello, > > Please review the fix for the following issue: > > https://bugs.openjdk.java.net/browse/JDK-8251499 > > The proposed changeset is located at: > > https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ > > The current implementation of CompactNumberFormat assumes that there > is always the number placeholder part in compact patterns. This is not > always true. In fact, upcoming CLDR 38 resurrects such patterns, so > this fix is a precursor to support CLDR 38. > > Naoto From naoto.sato at oracle.com Mon Aug 17 23:42:52 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Mon, 17 Aug 2020 16:42:52 -0700 Subject: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException In-Reply-To: References: <5b81c727-b1e0-0614-c68e-5568f98d9d6f@oracle.com> Message-ID: <217ef621-2293-3a1b-827c-06d067ea8b36@oracle.com> Hi Joe, It turned out that the previous fix did not address plural format cases. That means that just making the divisor negative to indicate non-placeholder cannot distinguish multiple plural cases with the same divisor. Instead, I created a list of placeholders (minimum digits) for each index and count. Here is the updated webrev: http://cr.openjdk.java.net/~naoto/8251499/webrev.01/ I added a new test case (COMPACT_PATTERN14), which actually is extracted from CLDR 38 Somali locale that demonstrates the issue. I'd appreciate your further review. Naoto On 8/14/20 6:21 PM, Joe Wang wrote: > Hi Naoto, > > Looks good to me. > > While a negative divisor representing no zeros is newly introduced, the > "divisor > 0" checks seem to have always been beneficial.? I had to > count the number of ""s in COMPACT_PATTERN13 :-) > > Have a great weekend! > Joe > > On 8/14/2020 3:20 PM, naoto.sato at oracle.com wrote: >> Hello, >> >> Please review the fix for the following issue: >> >> https://bugs.openjdk.java.net/browse/JDK-8251499 >> >> The proposed changeset is located at: >> >> https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ >> >> The current implementation of CompactNumberFormat assumes that there >> is always the number placeholder part in compact patterns. This is not >> always true. In fact, upcoming CLDR 38 resurrects such patterns, so >> this fix is a precursor to support CLDR 38. >> >> Naoto > From huizhe.wang at oracle.com Tue Aug 18 06:52:31 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Mon, 17 Aug 2020 23:52:31 -0700 Subject: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException In-Reply-To: <217ef621-2293-3a1b-827c-06d067ea8b36@oracle.com> References: <5b81c727-b1e0-0614-c68e-5568f98d9d6f@oracle.com> <217ef621-2293-3a1b-827c-06d067ea8b36@oracle.com> Message-ID: <9ee7bb2e-8030-b3a5-c5f6-6aa1517deb5c@oracle.com> Hi Naoto, Looks good overall. One nit, blocks 1633-1639 and 1642-1649 may share a common private method with a parameter that takes either matchedPosIndex or matchedNegIndex, if you want. Best, Joe On 8/17/20 4:42 PM, naoto.sato at oracle.com wrote: > Hi Joe, > > It turned out that the previous fix did not address plural format > cases. That means that just making the divisor negative to indicate > non-placeholder cannot distinguish multiple plural cases with the same > divisor. Instead, I created a list of placeholders (minimum digits) > for each index and count. Here is the updated webrev: > > http://cr.openjdk.java.net/~naoto/8251499/webrev.01/ > > I added a new test case (COMPACT_PATTERN14), which actually is > extracted from CLDR 38 Somali locale that demonstrates the issue. I'd > appreciate your further review. > > Naoto > > On 8/14/20 6:21 PM, Joe Wang wrote: >> Hi Naoto, >> >> Looks good to me. >> >> While a negative divisor representing no zeros is newly introduced, >> the "divisor > 0" checks seem to have always been beneficial.? I had >> to count the number of ""s in COMPACT_PATTERN13 :-) >> >> Have a great weekend! >> Joe >> >> On 8/14/2020 3:20 PM, naoto.sato at oracle.com wrote: >>> Hello, >>> >>> Please review the fix for the following issue: >>> >>> https://bugs.openjdk.java.net/browse/JDK-8251499 >>> >>> The proposed changeset is located at: >>> >>> https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ >>> >>> The current implementation of CompactNumberFormat assumes that there >>> is always the number placeholder part in compact patterns. This is >>> not always true. In fact, upcoming CLDR 38 resurrects such patterns, >>> so this fix is a precursor to support CLDR 38. >>> >>> Naoto >> From naoto.sato at oracle.com Tue Aug 18 18:37:26 2020 From: naoto.sato at oracle.com (naoto.sato at oracle.com) Date: Tue, 18 Aug 2020 11:37:26 -0700 Subject: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException In-Reply-To: <9ee7bb2e-8030-b3a5-c5f6-6aa1517deb5c@oracle.com> References: <5b81c727-b1e0-0614-c68e-5568f98d9d6f@oracle.com> <217ef621-2293-3a1b-827c-06d067ea8b36@oracle.com> <9ee7bb2e-8030-b3a5-c5f6-6aa1517deb5c@oracle.com> Message-ID: Hi Joe, Thank you for your comment. I consolidated those duplicated pieces into one piece. Did not make it a private method, though, as it would need to return two results from the method (cnfMultiplier and whether to return immediately for no-placeholder cases). https://cr.openjdk.java.net/~naoto/8251499/webrev.02/ Naoto On 8/17/20 11:52 PM, Joe Wang wrote: > Hi Naoto, > > Looks good overall. One nit, blocks 1633-1639 and 1642-1649 may share a > common private method with a parameter that takes either matchedPosIndex > or matchedNegIndex, if you want. > > Best, > Joe > > On 8/17/20 4:42 PM, naoto.sato at oracle.com wrote: >> Hi Joe, >> >> It turned out that the previous fix did not address plural format >> cases. That means that just making the divisor negative to indicate >> non-placeholder cannot distinguish multiple plural cases with the same >> divisor. Instead, I created a list of placeholders (minimum digits) >> for each index and count. Here is the updated webrev: >> >> http://cr.openjdk.java.net/~naoto/8251499/webrev.01/ >> >> I added a new test case (COMPACT_PATTERN14), which actually is >> extracted from CLDR 38 Somali locale that demonstrates the issue. I'd >> appreciate your further review. >> >> Naoto >> >> On 8/14/20 6:21 PM, Joe Wang wrote: >>> Hi Naoto, >>> >>> Looks good to me. >>> >>> While a negative divisor representing no zeros is newly introduced, >>> the "divisor > 0" checks seem to have always been beneficial.? I had >>> to count the number of ""s in COMPACT_PATTERN13 :-) >>> >>> Have a great weekend! >>> Joe >>> >>> On 8/14/2020 3:20 PM, naoto.sato at oracle.com wrote: >>>> Hello, >>>> >>>> Please review the fix for the following issue: >>>> >>>> https://bugs.openjdk.java.net/browse/JDK-8251499 >>>> >>>> The proposed changeset is located at: >>>> >>>> https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ >>>> >>>> The current implementation of CompactNumberFormat assumes that there >>>> is always the number placeholder part in compact patterns. This is >>>> not always true. In fact, upcoming CLDR 38 resurrects such patterns, >>>> so this fix is a precursor to support CLDR 38. >>>> >>>> Naoto >>> > From huizhe.wang at oracle.com Tue Aug 18 21:13:13 2020 From: huizhe.wang at oracle.com (Joe Wang) Date: Tue, 18 Aug 2020 14:13:13 -0700 Subject: RFR: 8251499: no-placeholder compact number patterns throw IllegalArgumentException In-Reply-To: References: <5b81c727-b1e0-0614-c68e-5568f98d9d6f@oracle.com> <217ef621-2293-3a1b-827c-06d067ea8b36@oracle.com> <9ee7bb2e-8030-b3a5-c5f6-6aa1517deb5c@oracle.com> Message-ID: <18130879-d9ad-a5a7-611f-138a3b3f27bd@oracle.com> Hi Naoto, That's nice!? The change looks good to me. Regards, Joe On 8/18/20 11:37 AM, naoto.sato at oracle.com wrote: > Hi Joe, > > Thank you for your comment. I consolidated those duplicated pieces > into one piece. Did not make it a private method, though, as it would > need to return two results from the method (cnfMultiplier and whether > to return immediately for no-placeholder cases). > > https://cr.openjdk.java.net/~naoto/8251499/webrev.02/ > > Naoto > > On 8/17/20 11:52 PM, Joe Wang wrote: >> Hi Naoto, >> >> Looks good overall. One nit, blocks 1633-1639 and 1642-1649 may share >> a common private method with a parameter that takes either >> matchedPosIndex or matchedNegIndex, if you want. >> >> Best, >> Joe >> >> On 8/17/20 4:42 PM, naoto.sato at oracle.com wrote: >>> Hi Joe, >>> >>> It turned out that the previous fix did not address plural format >>> cases. That means that just making the divisor negative to indicate >>> non-placeholder cannot distinguish multiple plural cases with the >>> same divisor. Instead, I created a list of placeholders (minimum >>> digits) for each index and count. Here is the updated webrev: >>> >>> http://cr.openjdk.java.net/~naoto/8251499/webrev.01/ >>> >>> I added a new test case (COMPACT_PATTERN14), which actually is >>> extracted from CLDR 38 Somali locale that demonstrates the issue. >>> I'd appreciate your further review. >>> >>> Naoto >>> >>> On 8/14/20 6:21 PM, Joe Wang wrote: >>>> Hi Naoto, >>>> >>>> Looks good to me. >>>> >>>> While a negative divisor representing no zeros is newly introduced, >>>> the "divisor > 0" checks seem to have always been beneficial.? I >>>> had to count the number of ""s in COMPACT_PATTERN13 :-) >>>> >>>> Have a great weekend! >>>> Joe >>>> >>>> On 8/14/2020 3:20 PM, naoto.sato at oracle.com wrote: >>>>> Hello, >>>>> >>>>> Please review the fix for the following issue: >>>>> >>>>> https://bugs.openjdk.java.net/browse/JDK-8251499 >>>>> >>>>> The proposed changeset is located at: >>>>> >>>>> https://cr.openjdk.java.net/~naoto/8251499/webrev.00/ >>>>> >>>>> The current implementation of CompactNumberFormat assumes that >>>>> there is always the number placeholder part in compact patterns. >>>>> This is not always true. In fact, upcoming CLDR 38 resurrects such >>>>> patterns, so this fix is a precursor to support CLDR 38. >>>>> >>>>> Naoto >>>> >> From yan at azul.com Fri Aug 28 10:32:43 2020 From: yan at azul.com (Yuri Nesterenko) Date: Fri, 28 Aug 2020 13:32:43 +0300 Subject: RFR: 8252497: Incorrect numeric currency code for ROL Message-ID: Hi, I have a customer requiring an obsolete currency ROL for something. They pointed that numeric code for it should be 642, and they cannot change that value using java.util.currency.data file. Bug is: https://bugs.openjdk.java.net/browse/JDK-8252497 The trivial fix is in CurrencyData.properties: http://cr.openjdk.java.net/~yan/8252497/webrev.0/ I'll put there noreg-trivial label. Thanks, --yan From naoto.sato at oracle.com Fri Aug 28 16:30:08 2020 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 28 Aug 2020 09:30:08 -0700 Subject: RFR: 8252497: Incorrect numeric currency code for ROL In-Reply-To: References: Message-ID: <25b29b52-03b0-b4cb-51cd-812d8d22811d@oracle.com> Hi Yuri, Thanks for the catch! Looks good to me. Please update the copyright year to 2020 before the push. Naoto On 8/28/20 3:32 AM, Yuri Nesterenko wrote: > Hi, > > I have a customer requiring an obsolete currency ROL for something. > They pointed that numeric code for it should be 642, and they cannot > change that value using java.util.currency.data file. > > Bug is: https://bugs.openjdk.java.net/browse/JDK-8252497 > The trivial fix is in CurrencyData.properties: > http://cr.openjdk.java.net/~yan/8252497/webrev.0/ > > I'll put there noreg-trivial label. > > Thanks, > --yan > From naoto.sato at oracle.com Fri Aug 28 16:41:38 2020 From: naoto.sato at oracle.com (Naoto Sato) Date: Fri, 28 Aug 2020 09:41:38 -0700 Subject: RFR: 8252497: Incorrect numeric currency code for ROL In-Reply-To: <25b29b52-03b0-b4cb-51cd-812d8d22811d@oracle.com> References: <25b29b52-03b0-b4cb-51cd-812d8d22811d@oracle.com> Message-ID: Sorry, another comment here. The ROL currency seemed to have no minor unit (minor digit is zero). So it should be listed in "minor0" property. Naoto On 8/28/20 9:30 AM, Naoto Sato wrote: > Hi Yuri, > > Thanks for the catch! Looks good to me. Please update the copyright year > to 2020 before the push. > > Naoto > > On 8/28/20 3:32 AM, Yuri Nesterenko wrote: >> Hi, >> >> I have a customer requiring an obsolete currency ROL for something. >> They pointed that numeric code for it should be 642, and they cannot >> change that value using java.util.currency.data file. >> >> Bug is: https://bugs.openjdk.java.net/browse/JDK-8252497 >> The trivial fix is in CurrencyData.properties: >> http://cr.openjdk.java.net/~yan/8252497/webrev.0/ >> >> I'll put there noreg-trivial label. >> >> Thanks, >> --yan >> From yan at azul.com Sat Aug 29 07:55:48 2020 From: yan at azul.com (Yuri Nesterenko) Date: Sat, 29 Aug 2020 10:55:48 +0300 Subject: RFR: 8252497: Incorrect numeric currency code for ROL In-Reply-To: References: <25b29b52-03b0-b4cb-51cd-812d8d22811d@oracle.com> Message-ID: <3cccafae-53e6-2e1e-7f7d-b94bb3cab71c@azul.com> Thank you, Naoto! Yes, you are right, while some sites insist on 2: for instance, https://help.sap.com/saphelp_pos22/helpdata/en/4f/efa63a9bb04d94a0ae4c32fd6cd827/content.htm?no_cache=true -- so I have been confused -- the official amendment fax on www.currency-iso.org https://www.currency-iso.org/dam/downloads/dl_currency_iso_amendment_126.pdf states minor unit 0 (no wonder with denomination 10000 to 1). Updated webrev is http://cr.openjdk.java.net/~yan/8252497/webrev.1/ Thank you again! --yan On 28.08.2020 19:41, Naoto Sato wrote: > Sorry, another comment here. The ROL currency seemed to have no minor unit (minor digit is zero). So > it should be listed in "minor0" property. > > Naoto > > On 8/28/20 9:30 AM, Naoto Sato wrote: >> Hi Yuri, >> >> Thanks for the catch! Looks good to me. Please update the copyright year to 2020 before the push. >> >> Naoto >> >> On 8/28/20 3:32 AM, Yuri Nesterenko wrote: >>> Hi, >>> >>> I have a customer requiring an obsolete currency ROL for something. >>> They pointed that numeric code for it should be 642, and they cannot >>> change that value using java.util.currency.data file. >>> >>> Bug is: https://bugs.openjdk.java.net/browse/JDK-8252497 >>> The trivial fix is in CurrencyData.properties: >>> http://cr.openjdk.java.net/~yan/8252497/webrev.0/ >>> >>> I'll put there noreg-trivial label. >>> >>> Thanks, >>> --yan >>> From yan at azul.com Sat Aug 29 08:07:25 2020 From: yan at azul.com (Yuri Nesterenko) Date: Sat, 29 Aug 2020 11:07:25 +0300 Subject: RFR: 8252497: Incorrect numeric currency code for ROL In-Reply-To: <3cccafae-53e6-2e1e-7f7d-b94bb3cab71c@azul.com> References: <25b29b52-03b0-b4cb-51cd-812d8d22811d@oracle.com> <3cccafae-53e6-2e1e-7f7d-b94bb3cab71c@azul.com> Message-ID: <1e4871c9-c2a2-7541-0794-d13c648c72ff@azul.com> And, how about push? Would it be possible to push to Mercurial repo of jdk 16 on or before Sep 1 or will it be the new Git repo soon after Sep 5, or is it a matter of later decision? --yan On 29.08.2020 10:55, Yuri Nesterenko wrote: > Thank you, Naoto! > > Yes, you are right, while some sites insist on 2: for instance, > https://help.sap.com/saphelp_pos22/helpdata/en/4f/efa63a9bb04d94a0ae4c32fd6cd827/content.htm?no_cache=true > -- so I have been confused -- the official amendment fax on www.currency-iso.org > https://www.currency-iso.org/dam/downloads/dl_currency_iso_amendment_126.pdf > states minor unit 0 (no wonder with denomination 10000 to 1). > > Updated webrev is > http://cr.openjdk.java.net/~yan/8252497/webrev.1/ > > Thank you again! > --yan > > On 28.08.2020 19:41, Naoto Sato wrote: >> Sorry, another comment here. The ROL currency seemed to have no minor unit (minor digit is zero). So >> it should be listed in "minor0" property. >> >> Naoto >> >> On 8/28/20 9:30 AM, Naoto Sato wrote: >>> Hi Yuri, >>> >>> Thanks for the catch! Looks good to me. Please update the copyright year to 2020 before the push. >>> >>> Naoto >>> >>> On 8/28/20 3:32 AM, Yuri Nesterenko wrote: >>>> Hi, >>>> >>>> I have a customer requiring an obsolete currency ROL for something. >>>> They pointed that numeric code for it should be 642, and they cannot >>>> change that value using java.util.currency.data file. >>>> >>>> Bug is: https://bugs.openjdk.java.net/browse/JDK-8252497 >>>> The trivial fix is in CurrencyData.properties: >>>> http://cr.openjdk.java.net/~yan/8252497/webrev.0/ >>>> >>>> I'll put there noreg-trivial label. >>>> >>>> Thanks, >>>> --yan >>>> From naoto.sato at oracle.com Sat Aug 29 21:26:40 2020 From: naoto.sato at oracle.com (Naoto Sato) Date: Sat, 29 Aug 2020 14:26:40 -0700 Subject: RFR: 8252497: Incorrect numeric currency code for ROL In-Reply-To: <1e4871c9-c2a2-7541-0794-d13c648c72ff@azul.com> References: <25b29b52-03b0-b4cb-51cd-812d8d22811d@oracle.com> <3cccafae-53e6-2e1e-7f7d-b94bb3cab71c@azul.com> <1e4871c9-c2a2-7541-0794-d13c648c72ff@azul.com> Message-ID: Looks good. I believe you can push the fix through hg till Sep. 3 COB (hg repository becomes read only on Sep. 4) [0] Naoto [0] https://mail.openjdk.java.net/pipermail/jdk-dev/2020-August/004588.html On 8/29/20 1:07 AM, Yuri Nesterenko wrote: > And, how about push? Would it be possible to push to Mercurial repo of jdk 16 on or before Sep 1 > or will it be the new Git repo soon after Sep 5, or is it a matter of later decision? > > --yan > > On 29.08.2020 10:55, Yuri Nesterenko wrote: >> Thank you, Naoto! >> >> Yes, you are right, while some sites insist on 2: for instance, >> https://help.sap.com/saphelp_pos22/helpdata/en/4f/efa63a9bb04d94a0ae4c32fd6cd827/content.htm?no_cache=true >> -- so I have been confused -- the official amendment fax on www.currency-iso.org >> https://www.currency-iso.org/dam/downloads/dl_currency_iso_amendment_126.pdf >> states minor unit 0 (no wonder with denomination 10000 to 1). >> >> Updated webrev is >> http://cr.openjdk.java.net/~yan/8252497/webrev.1/ >> >> Thank you again! >> --yan >> >> On 28.08.2020 19:41, Naoto Sato wrote: >>> Sorry, another comment here. The ROL currency seemed to have no minor unit (minor digit is zero). So >>> it should be listed in "minor0" property. >>> >>> Naoto >>> >>> On 8/28/20 9:30 AM, Naoto Sato wrote: >>>> Hi Yuri, >>>> >>>> Thanks for the catch! Looks good to me. Please update the copyright year to 2020 before the push. >>>> >>>> Naoto >>>> >>>> On 8/28/20 3:32 AM, Yuri Nesterenko wrote: >>>>> Hi, >>>>> >>>>> I have a customer requiring an obsolete currency ROL for something. >>>>> They pointed that numeric code for it should be 642, and they cannot >>>>> change that value using java.util.currency.data file. >>>>> >>>>> Bug is: https://bugs.openjdk.java.net/browse/JDK-8252497 >>>>> The trivial fix is in CurrencyData.properties: >>>>> http://cr.openjdk.java.net/~yan/8252497/webrev.0/ >>>>> >>>>> I'll put there noreg-trivial label. >>>>> >>>>> Thanks, >>>>> --yan >>>>> > From naoto.sato at oracle.com Mon Aug 31 16:22:20 2020 From: naoto.sato at oracle.com (Naoto Sato) Date: Mon, 31 Aug 2020 09:22:20 -0700 Subject: RFR: 8252552: DecimalFormat javadoc contains HTML tags in example code Message-ID: <4219fa9a-f90f-8e75-30b0-eb0f084c1ffa@oracle.com> Hello, Please review this simple javadoc fix to: https://bugs.openjdk.java.net/browse/JDK-8252552 The proposed diff is inserted here: --- --- old/src/java.base/share/classes/java/text/DecimalFormat.java 2020-08-31 09:07:22.000000000 -0700 +++ new/src/java.base/share/classes/java/text/DecimalFormat.java 2020-08-31 09:07:22.000000000 -0700 @@ -338,9 +338,9 @@ * *

Example

* - * 
{@code
- * // Print out a number using the localized number, integer, 
currency,
- * // and percent format for each locale
+ * 
{@code
+ * // Print out a number using the localized number, integer, currency,
+ * // and percent format for each locale}{@code
   * Locale[] locales = NumberFormat.getAvailableLocales();
   * double myNumber = -1234.56;
   * NumberFormat form;
---

It is simply to take those  HTML tags out of {@code} snippet.

Naoto

From LANCE.ANDERSEN at ORACLE.COM  Mon Aug 31 17:14:44 2020
From: LANCE.ANDERSEN at ORACLE.COM (Lance Andersen)
Date: Mon, 31 Aug 2020 13:14:44 -0400
Subject:  RFR: 8252552: DecimalFormat javadoc contains HTML
 tags in example code
In-Reply-To: <4219fa9a-f90f-8e75-30b0-eb0f084c1ffa@oracle.com>
References: <4219fa9a-f90f-8e75-30b0-eb0f084c1ffa@oracle.com>
Message-ID: <14AD1FE8-F496-4EA9-8EB6-E8618D98B0E1@ORACLE.COM>

Hi Naoto,

Looks OK to me.  

Best
Lance

> On Aug 31, 2020, at 12:22 PM, Naoto Sato  wrote:
> 
> Hello,
> 
> Please review this simple javadoc fix to:
> 
> https://bugs.openjdk.java.net/browse/JDK-8252552
> 
> The proposed diff is inserted here:
> 
> ---
> --- old/src/java.base/share/classes/java/text/DecimalFormat.java 2020-08-31 09:07:22.000000000 -0700
> +++ new/src/java.base/share/classes/java/text/DecimalFormat.java 2020-08-31 09:07:22.000000000 -0700
> @@ -338,9 +338,9 @@
>  *
>  * 
Example

>  *
> - * 
{@code
> - * // Print out a number using the localized number, integer, currency,
> - * // and percent format for each locale
> + * 
{@code
> + * // Print out a number using the localized number, integer, currency,
> + * // and percent format for each locale}{@code
>  * Locale[] locales = NumberFormat.getAvailableLocales();
>  * double myNumber = -1234.56;
>  * NumberFormat form;
> ---
> 
> It is simply to take those  HTML tags out of {@code} snippet.
> 
> Naoto


Best
Lance
------------------




Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
Oracle Java Engineering 
1 Network Drive 
Burlington, MA 01803
Lance.Andersen at oracle.com





From huizhe.wang at oracle.com  Mon Aug 31 19:55:19 2020
From: huizhe.wang at oracle.com (Joe Wang)
Date: Mon, 31 Aug 2020 12:55:19 -0700
Subject:  RFR: 8252552: DecimalFormat javadoc contains HTML
 tags in example code
In-Reply-To: <14AD1FE8-F496-4EA9-8EB6-E8618D98B0E1@ORACLE.COM>
References: <4219fa9a-f90f-8e75-30b0-eb0f084c1ffa@oracle.com>
 <14AD1FE8-F496-4EA9-8EB6-E8618D98B0E1@ORACLE.COM>
Message-ID: <15e08b3a-fcc2-5151-4e28-e9b2b611dfbf@oracle.com>

+1

Or, maybe  is not needed for code comments

-Joe

On 8/31/20 10:14 AM, Lance Andersen wrote:
> Hi Naoto,
>
> Looks OK to me.
>
> Best
> Lance
>
>> On Aug 31, 2020, at 12:22 PM, Naoto Sato  wrote:
>>
>> Hello,
>>
>> Please review this simple javadoc fix to:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8252552
>>
>> The proposed diff is inserted here:
>>
>> ---
>> --- old/src/java.base/share/classes/java/text/DecimalFormat.java 2020-08-31 09:07:22.000000000 -0700
>> +++ new/src/java.base/share/classes/java/text/DecimalFormat.java 2020-08-31 09:07:22.000000000 -0700
>> @@ -338,9 +338,9 @@
>>   *
>>   * 
Example

>>   *
>> - * 
{@code
>> - * // Print out a number using the localized number, integer, currency,
>> - * // and percent format for each locale
>> + * 
{@code
>> + * // Print out a number using the localized number, integer, currency,
>> + * // and percent format for each locale}{@code
>>   * Locale[] locales = NumberFormat.getAvailableLocales();
>>   * double myNumber = -1234.56;
>>   * NumberFormat form;
>> ---
>>
>> It is simply to take those  HTML tags out of {@code} snippet.
>>
>> Naoto
>
> Best
> Lance
> ------------------
>
>
>
>
> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
> Oracle Java Engineering
> 1 Network Drive
> Burlington, MA 01803
> Lance.Andersen at oracle.com
>
>
>
>


From naoto.sato at oracle.com  Mon Aug 31 21:12:56 2020
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 31 Aug 2020 14:12:56 -0700
Subject:  RFR: 8252552: DecimalFormat javadoc contains HTML
 tags in example code
In-Reply-To: <15e08b3a-fcc2-5151-4e28-e9b2b611dfbf@oracle.com>
References: <4219fa9a-f90f-8e75-30b0-eb0f084c1ffa@oracle.com>
 <14AD1FE8-F496-4EA9-8EB6-E8618D98B0E1@ORACLE.COM>
 <15e08b3a-fcc2-5151-4e28-e9b2b611dfbf@oracle.com>
Message-ID: <46e95fff-3f12-1813-8037-b1584d81156e@oracle.com>

Thanks, Joe!

On 8/31/20 12:55 PM, Joe Wang wrote:
> +1
> 
> Or, maybe  is not needed for code comments

Yes. I just kept it as is, as it seems the comment summarizes what the 
examples do.

Naoto

> 
> -Joe
> 
> On 8/31/20 10:14 AM, Lance Andersen wrote:
>> Hi Naoto,
>>
>> Looks OK to me.
>>
>> Best
>> Lance
>>
>>> On Aug 31, 2020, at 12:22 PM, Naoto Sato  wrote:
>>>
>>> Hello,
>>>
>>> Please review this simple javadoc fix to:
>>>
>>> https://bugs.openjdk.java.net/browse/JDK-8252552
>>>
>>> The proposed diff is inserted here:
>>>
>>> ---
>>> --- old/src/java.base/share/classes/java/text/DecimalFormat.java 
>>> 2020-08-31 09:07:22.000000000 -0700
>>> +++ new/src/java.base/share/classes/java/text/DecimalFormat.java 
>>> 2020-08-31 09:07:22.000000000 -0700
>>> @@ -338,9 +338,9 @@
>>> ? *
>>> ? * 
Example

>>> ? *
>>> - * 
{@code
>>> - * // Print out a number using the localized number, 
>>> integer, currency,
>>> - * // and percent format for each locale
>>> + * 
{@code
>>> + * // Print out a number using the localized number, integer, currency,
>>> + * // and percent format for each locale}{@code
>>> ? * Locale[] locales = NumberFormat.getAvailableLocales();
>>> ? * double myNumber = -1234.56;
>>> ? * NumberFormat form;
>>> ---
>>>
>>> It is simply to take those  HTML tags out of {@code} snippet.
>>>
>>> Naoto
>>
>> Best
>> Lance
>> ------------------
>>
>>
>>
>>
>> Lance Andersen| Principal Member of Technical Staff | +1.781.442.2037
>> Oracle Java Engineering
>> 1 Network Drive
>> Burlington, MA 01803
>> Lance.Andersen at oracle.com
>>
>>
>>
>>
>