From claes.redestad at oracle.com  Tue Feb 13 10:29:17 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 13 Feb 2018 11:29:17 +0100
Subject: <i18n dev> [11] RFR: 8197829: Optimize
 CLDRCalendarDataProviderImpl::retrieveInteger
Message-ID: <9df825f3-680f-61df-644e-74e5a8247451@oracle.com>

Hi,

please review this improvement to the retrieveInteger method in 
CLDRCalendarDataProviderImpl.

Bug: https://bugs.openjdk.java.net/browse/JDK-8197829
Webrev: http://cr.openjdk.java.net/~redestad/8197829/jdk.00/

This deals with a tiny startup regression that appeared in 10+36 on some 
applications and systems[1]

Thanks!

/Claes

[1] Likely due to https://bugs.openjdk.java.net/browse/JDK-8190918

From naoto.sato at oracle.com  Tue Feb 13 16:51:58 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 13 Feb 2018 08:51:58 -0800
Subject: <i18n dev> [11] RFR: 8197829: Optimize
 CLDRCalendarDataProviderImpl::retrieveInteger
In-Reply-To: <9df825f3-680f-61df-644e-74e5a8247451@oracle.com>
References: <9df825f3-680f-61df-644e-74e5a8247451@oracle.com>
Message-ID: <9584d80a-5a4d-9c6d-ded1-50336eba46b3@oracle.com>

Hi Claes,

Looks good to me. Please add noreg-perf tag to the issue.

Naoto

On 2/13/18 2:29 AM, Claes Redestad wrote:
> Hi,
> 
> please review this improvement to the retrieveInteger method in 
> CLDRCalendarDataProviderImpl.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8197829
> Webrev: http://cr.openjdk.java.net/~redestad/8197829/jdk.00/
> 
> This deals with a tiny startup regression that appeared in 10+36 on some 
> applications and systems[1]
> 
> Thanks!
> 
> /Claes
> 
> [1] Likely due to https://bugs.openjdk.java.net/browse/JDK-8190918

From claes.redestad at oracle.com  Tue Feb 13 16:59:22 2018
From: claes.redestad at oracle.com (Claes Redestad)
Date: Tue, 13 Feb 2018 17:59:22 +0100
Subject: <i18n dev> [11] RFR: 8197829: Optimize
 CLDRCalendarDataProviderImpl::retrieveInteger
In-Reply-To: <9584d80a-5a4d-9c6d-ded1-50336eba46b3@oracle.com>
References: <9df825f3-680f-61df-644e-74e5a8247451@oracle.com>
 <9584d80a-5a4d-9c6d-ded1-50336eba46b3@oracle.com>
Message-ID: <8a8a4435-d9f7-b5b9-48ad-5571aee72def@oracle.com>

On 2018-02-13 17:51, Naoto Sato wrote:
> Hi Claes,
>
> Looks good to me.

Thanks, Naoto!

> Please add noreg-perf tag to the issue.

Done.

/Claes

From y.umaoka at gmail.com  Tue Feb 13 22:20:41 2018
From: y.umaoka at gmail.com (Yoshito Umaoka)
Date: Tue, 13 Feb 2018 17:20:41 -0500
Subject: <i18n dev> CLDR Irish time zone name
Message-ID: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>

Hello Sato-san,

As you know, tz database 2018a flipped Europe/Dublin winter/summer time 
rules. There were many messages posted in the tz mailing list, and Paul 
Eggert decided to revert the change in tz database 2018c. For future 
releases, it looks he want to add a zic build option to swap the rule.

We also discussed what to do in CLDR project. For now, we decided not to 
make any changes for Europe/Dublin in CLDR release 33 (GA in March 2018) 
at least. We don't have a solid plan for post CLDR 33 releases.

My understanding is that OpenJDK also consumes CLDR zone name data. Is 
this true? If so, do you have any input for post CLDR 33 releases?


-Yoshito (Unicode CLDR/ICU project)


From naoto.sato at oracle.com  Tue Feb 13 22:33:32 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 13 Feb 2018 14:33:32 -0800
Subject: <i18n dev> CLDR Irish time zone name
In-Reply-To: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>
References: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>
Message-ID: <caef352b-ba92-a37a-1439-f2caa38d8624@oracle.com>

Hi Umaoka-san,

Yes, JDK uses the time zone name translations from CLDR. Currently we 
simply map names from CLDR's standard/daylight/generic to Java's 
equivalents. Do you mean in CLDR, you guys discussed whether to flip 
standard/daylight names based on the offset being positive/negative? Or 
something else?

Naoto

On 2/13/18 2:20 PM, Yoshito Umaoka wrote:
> Hello Sato-san,
> 
> As you know, tz database 2018a flipped Europe/Dublin winter/summer time 
> rules. There were many messages posted in the tz mailing list, and Paul 
> Eggert decided to revert the change in tz database 2018c. For future 
> releases, it looks he want to add a zic build option to swap the rule.
> 
> We also discussed what to do in CLDR project. For now, we decided not to 
> make any changes for Europe/Dublin in CLDR release 33 (GA in March 2018) 
> at least. We don't have a solid plan for post CLDR 33 releases.
> 
> My understanding is that OpenJDK also consumes CLDR zone name data. Is 
> this true? If so, do you have any input for post CLDR 33 releases?
> 
> 
> -Yoshito (Unicode CLDR/ICU project)
> 

From scolebourne at joda.org  Tue Feb 13 23:02:39 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Tue, 13 Feb 2018 23:02:39 +0000
Subject: <i18n dev> CLDR Irish time zone name
In-Reply-To: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>
References: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>
Message-ID: <CACzrW9BDKouHec0-U-e9T9zYAS4DRTcjL=R-JmqzvNG3uFAfRg@mail.gmail.com>

On 13 February 2018 at 22:20, Yoshito Umaoka <y.umaoka at gmail.com> wrote:
> Hello Sato-san,
>
> As you know, tz database 2018a flipped Europe/Dublin winter/summer time
> rules. There were many messages posted in the tz mailing list, and Paul
> Eggert decided to revert the change in tz database 2018c. For future
> releases, it looks he want to add a zic build option to swap the rule.
>
> We also discussed what to do in CLDR project. For now, we decided not to
> make any changes for Europe/Dublin in CLDR release 33 (GA in March 2018) at
> least. We don't have a solid plan for post CLDR 33 releases.
>
> My understanding is that OpenJDK also consumes CLDR zone name data. Is this
> true? If so, do you have any input for post CLDR 33 releases?

FWIW, my personal opinion is that CLDR should fork TZDB (with the
prior buy-in of Apple, MS, Android, Oracle etc,), but thats a
relatively big decision for CLDR.

In the short term, I don't think CLDR should change its data, nor do I
think OpenJDK should change. ie. for Ireland, standard=winter and
daylight=summer should continue to be true in both projects.

If TZDB insists on continuing with the change, the TZDB compiler in
OpenJDK will have to be changed. I've managed to make a change (hack)
to the compiler in Joda-Time, so a solution should be possible to some
degree in OpenJDK too.
https://github.com/JodaOrg/joda-time/commit/c5c681c91c74a508e67911e0af4980846d676ba2

Stephen

From martinrb at google.com  Tue Feb 13 23:25:41 2018
From: martinrb at google.com (Martin Buchholz)
Date: Tue, 13 Feb 2018 15:25:41 -0800
Subject: <i18n dev> CLDR Irish time zone name
In-Reply-To: <CACzrW9BDKouHec0-U-e9T9zYAS4DRTcjL=R-JmqzvNG3uFAfRg@mail.gmail.com>
References: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>
 <CACzrW9BDKouHec0-U-e9T9zYAS4DRTcjL=R-JmqzvNG3uFAfRg@mail.gmail.com>
Message-ID: <CA+kOe0__HSM0VJpjs+jE1Y8EsU8V8jb5qzev58rtas3uXeDJ-A@mail.gmail.com>

On Tue, Feb 13, 2018 at 3:02 PM, Stephen Colebourne <scolebourne at joda.org>
wrote:

>
> In the short term, I don't think CLDR should change its data, nor do I
> think OpenJDK should change. ie. for Ireland, standard=winter and
> daylight=summer should continue to be true in both projects.
>

I agree


> If TZDB insists on continuing with the change, the TZDB compiler in
> OpenJDK will have to be changed. I've managed to make a change (hack)
> to the compiler in Joda-Time, so a solution should be possible to some
> degree in OpenJDK too.
> https://github.com/JodaOrg/joda-time/commit/c5c681c91c74a508e67911e0af4980
> 846d676ba2


I was thinking about how to "reverse the polarity".  The advantage of a
source transformation is that the code can be shared among all downstream
tzdata consumers.  The advantage of building it into the "compiler" is
defense against the maintainer/user mistake of simply overwriting the
tzdata files.

From mark at macchiato.com  Wed Feb 14 06:24:23 2018
From: mark at macchiato.com (=?UTF-8?B?TWFyayBEYXZpcyDimJXvuI8=?=)
Date: Wed, 14 Feb 2018 07:24:23 +0100
Subject: <i18n dev> CLDR Irish time zone name
In-Reply-To: <CA+kOe0__HSM0VJpjs+jE1Y8EsU8V8jb5qzev58rtas3uXeDJ-A@mail.gmail.com>
References: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>
 <CACzrW9BDKouHec0-U-e9T9zYAS4DRTcjL=R-JmqzvNG3uFAfRg@mail.gmail.com>
 <CA+kOe0__HSM0VJpjs+jE1Y8EsU8V8jb5qzev58rtas3uXeDJ-A@mail.gmail.com>
Message-ID: <CAJ2xs_FaYu-C0SbHf_-fJLsEz056dpJERN6k2=f1bjJm4nb32A@mail.gmail.com>

I'm pretty annoyed with the TZ group lately; there seems to be little
consideration for compatibility.

I think, if it comes to it, we may need to be prepared to fork the "input
data" in CLDR. My hope is that they will instead at least maintain the
current format AND some new-fangled format that goes off into the weeds as
part of the TZ project.

Mark

On Wed, Feb 14, 2018 at 12:25 AM, Martin Buchholz <martinrb at google.com>
wrote:

> On Tue, Feb 13, 2018 at 3:02 PM, Stephen Colebourne <scolebourne at joda.org>
> wrote:
>
> >
> > In the short term, I don't think CLDR should change its data, nor do I
> > think OpenJDK should change. ie. for Ireland, standard=winter and
> > daylight=summer should continue to be true in both projects.
> >
>
> I agree
>
>
> > If TZDB insists on continuing with the change, the TZDB compiler in
> > OpenJDK will have to be changed. I've managed to make a change (hack)
> > to the compiler in Joda-Time, so a solution should be possible to some
> > degree in OpenJDK too.
> > https://github.com/JodaOrg/joda-time/commit/
> c5c681c91c74a508e67911e0af4980
> > 846d676ba2
>
>
> I was thinking about how to "reverse the polarity".  The advantage of a
> source transformation is that the code can be shared among all downstream
> tzdata consumers.  The advantage of building it into the "compiler" is
> defense against the maintainer/user mistake of simply overwriting the
> tzdata files.
>

From scolebourne at joda.org  Wed Feb 14 09:38:33 2018
From: scolebourne at joda.org (Stephen Colebourne)
Date: Wed, 14 Feb 2018 09:38:33 +0000
Subject: <i18n dev> CLDR Irish time zone name
In-Reply-To: <CA+kOe0__HSM0VJpjs+jE1Y8EsU8V8jb5qzev58rtas3uXeDJ-A@mail.gmail.com>
References: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>
 <CACzrW9BDKouHec0-U-e9T9zYAS4DRTcjL=R-JmqzvNG3uFAfRg@mail.gmail.com>
 <CA+kOe0__HSM0VJpjs+jE1Y8EsU8V8jb5qzev58rtas3uXeDJ-A@mail.gmail.com>
Message-ID: <CACzrW9BJvCLhiQsDsP0Z6C1E+4Q2SF+ns=TZYynWf8Ct68VPnw@mail.gmail.com>

On 13 February 2018 at 23:25, Martin Buchholz <martinrb at google.com> wrote:
> On Tue, Feb 13, 2018 at 3:02 PM, Stephen Colebourne <scolebourne at joda.org>
>> If TZDB insists on continuing with the change, the TZDB compiler in
>> OpenJDK will have to be changed. I've managed to make a change (hack)
>> to the compiler in Joda-Time, so a solution should be possible to some
>> degree in OpenJDK too.
>>
>> https://github.com/JodaOrg/joda-time/commit/c5c681c91c74a508e67911e0af4980846d676ba2
>
> I was thinking about how to "reverse the polarity".  The advantage of a
> source transformation is that the code can be shared among all downstream
> tzdata consumers.  The advantage of building it into the "compiler" is
> defense against the maintainer/user mistake of simply overwriting the tzdata
> files.

The approach I used was based on Meno Hochschild's approach. When it
binds the set of "Rule" entries to a line in the "Zone", it examines
the rules to see if any are negative SAVE values, and does the
reversal. The only constraint is that the set of "Rule" entries with
the same name cannot contain both positive and negative SAVE values,
but I don't think the tzdb encoding of a short name could cope with
that anyway.

AFAICT, this approach should be applicable to ThreeTen-Backport and
OpenJDK. I imagine something similar can be done in ICU4J.
Stephen

From martinrb at google.com  Thu Feb 15 01:32:46 2018
From: martinrb at google.com (Martin Buchholz)
Date: Wed, 14 Feb 2018 17:32:46 -0800
Subject: <i18n dev> CLDR Irish time zone name
In-Reply-To: <CAJ2xs_FaYu-C0SbHf_-fJLsEz056dpJERN6k2=f1bjJm4nb32A@mail.gmail.com>
References: <5b4acc3b-87eb-53df-b460-cc852fd21f43@gmail.com>
 <CACzrW9BDKouHec0-U-e9T9zYAS4DRTcjL=R-JmqzvNG3uFAfRg@mail.gmail.com>
 <CA+kOe0__HSM0VJpjs+jE1Y8EsU8V8jb5qzev58rtas3uXeDJ-A@mail.gmail.com>
 <CAJ2xs_FaYu-C0SbHf_-fJLsEz056dpJERN6k2=f1bjJm4nb32A@mail.gmail.com>
Message-ID: <CA+kOe0--YQ4MG4o1596bsfXOJMC=a_3nvoBWux29y683UDCgOA@mail.gmail.com>

On Tue, Feb 13, 2018 at 10:24 PM, Mark Davis ?? <mark at macchiato.com> wrote:

> I'm pretty annoyed with the TZ group lately; there seems to be little
> consideration for compatibility.
>
> I think, if it comes to it, we may need to be prepared to fork the "input
> data" in CLDR. My hope is that they will instead at least maintain the
> current format AND some new-fangled format that goes off into the weeds
> as part of the TZ project.
>

This may end up with a model similar to openssh.  There's the "pure"
version of openssh, but in the real world everyone uses the "portable"
version.  Similarly, the impure version of tzdata would revert any negative
and fractional-second zone offsets in the pure version.

From nishit.jain at oracle.com  Fri Feb 16 11:50:04 2018
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 16 Feb 2018 17:20:04 +0530
Subject: <i18n dev> [11] RFR JDK-8190904: Incorrect currency instance
 returned by java.util.Currency.getInstance()
Message-ID: <84420a48-d666-c42e-e071-da37726e3e2a@oracle.com>

Hi,

Please review the fix for JDK-8190904.

Bug: https://bugs.openjdk.java.net/browse/JDK-8190904
Webrev: http://cr.openjdk.java.net/~nishjain/8190904/webrev.07/
CSR: https://bugs.openjdk.java.net/browse/JDK-8196835

Issue: The currency superseding feature gives the possibility of 
allowing two similar Currency instances for a currency code, which is 
against the principle that "There can never more than one Currency 
instance for any given currency".

Fix: Modify the superseding feature to not allow multiple entries with 
same currency code but different numeric and/or minor unit. These are 
ignored as inconsistent entries. Also, If there is any ISO 4217 currency 
data with same currency code as the currency entry given in the 
properties file, then the existing Currency data should be updated with 
the given currency values.


Regards,
Nishit Jain

From naoto.sato at oracle.com  Fri Feb 16 16:51:53 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 16 Feb 2018 08:51:53 -0800
Subject: <i18n dev> [11] RFR JDK-8190904: Incorrect currency instance
 returned by java.util.Currency.getInstance()
In-Reply-To: <84420a48-d666-c42e-e071-da37726e3e2a@oracle.com>
References: <84420a48-d666-c42e-e071-da37726e3e2a@oracle.com>
Message-ID: <7a6087a3-746d-d5a5-f630-1160d09f1e92@oracle.com>

Looks good to me.

Naoto

On 2/16/18 3:50 AM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8190904.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8190904
> Webrev: http://cr.openjdk.java.net/~nishjain/8190904/webrev.07/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8196835
> 
> Issue: The currency superseding feature gives the possibility of 
> allowing two similar Currency instances for a currency code, which is 
> against the principle that "There can never more than one Currency 
> instance for any given currency".
> 
> Fix: Modify the superseding feature to not allow multiple entries with 
> same currency code but different numeric and/or minor unit. These are 
> ignored as inconsistent entries. Also, If there is any ISO 4217 currency 
> data with same currency code as the currency entry given in the 
> properties file, then the existing Currency data should be updated with 
> the given currency values.
> 
> 
> Regards,
> Nishit Jain

From naoto.sato at oracle.com  Fri Feb 16 19:22:24 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 16 Feb 2018 11:22:24 -0800
Subject: <i18n dev> [11] RFR: JDK-8198228: Spec clarification:
 j.u.Locale.getDisplayName()
Message-ID: <e90890bd-1948-8dd7-c1e9-f4b7cc66772f@oracle.com>

Hello,

Please review this small doc-only fix for this issue:

https://bugs.openjdk.java.net/browse/JDK-8198228

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8198228/webrev.00/

It is just to clarify the field separator in locale display names. 
Corresponding CSR (8198236) is already approved.

Naoto

From naoto.sato at oracle.com  Wed Feb 21 21:13:51 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Wed, 21 Feb 2018 13:13:51 -0800
Subject: <i18n dev> [11] RFR: JDK-8198385: Remove property
	sun.locale.formatasdefault
Message-ID: <81803e97-2eb9-7efe-4c32-5be1e92b82f8@oracle.com>

Hello,

Please review the fix to the following issue:

https://bugs.openjdk.java.net/browse/JDK-8198385

The proposed changeset is located at:

http://cr.openjdk.java.net/~naoto/8198385/webrev.00/

The property was introduced in JDK7 for the backward compatibility, 
which at this point is no longer needed. Corresponding CSR is already 
approved.

Naoto

From brian.burkhalter at oracle.com  Wed Feb 21 22:25:21 2018
From: brian.burkhalter at oracle.com (Brian Burkhalter)
Date: Wed, 21 Feb 2018 14:25:21 -0800
Subject: <i18n dev> [11] RFR: JDK-8198385: Remove property
	sun.locale.formatasdefault
In-Reply-To: <81803e97-2eb9-7efe-4c32-5be1e92b82f8@oracle.com>
References: <81803e97-2eb9-7efe-4c32-5be1e92b82f8@oracle.com>
Message-ID: <8D1E79AC-BBDE-4D5F-8DA4-7EEEDBCF9B85@oracle.com>

Hi Naoto,

+1

Brian

On Feb 21, 2018, at 1:13 PM, naoto.sato at oracle.com wrote:

> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8198385
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8198385/webrev.00/
> 
> The property was introduced in JDK7 for the backward compatibility, which at this point is no longer needed. Corresponding CSR is already approved.


From nishit.jain at oracle.com  Thu Feb 22 11:51:13 2018
From: nishit.jain at oracle.com (Nishit Jain)
Date: Thu, 22 Feb 2018 17:21:13 +0530
Subject: <i18n dev> [11] RFR JDK-8060094: java/util/Formatter/Basic.java
 failed in tr locale
Message-ID: <ceada88b-3369-52ab-b7ed-4de95e98b122@oracle.com>

Hi,

Please review the fix for JDK-8060094.

Bug: https://bugs.openjdk.java.net/browse/JDK-8060094
Webrev: http://cr.openjdk.java.net/~nishjain/8060094/webrev.03/
CSR: https://bugs.openjdk.java.net/browse/JDK-8197916

Cause: The Formatter APIs were not using the correct locale for upper 
casing when specified during instance creation or during format() call. 
The default locale was getting used irrespective of whether a Locale is 
specified in the API.
Fix: Modified the APIs to use the locale specified.

Regards,
Nishit Jain

From Alan.Bateman at oracle.com  Thu Feb 22 13:34:39 2018
From: Alan.Bateman at oracle.com (Alan Bateman)
Date: Thu, 22 Feb 2018 13:34:39 +0000
Subject: <i18n dev> [11] RFR: JDK-8198385: Remove property
	sun.locale.formatasdefault
In-Reply-To: <81803e97-2eb9-7efe-4c32-5be1e92b82f8@oracle.com>
References: <81803e97-2eb9-7efe-4c32-5be1e92b82f8@oracle.com>
Message-ID: <071b4dc7-0ea6-2460-9a3f-57ed18d01b9b@oracle.com>

On 21/02/2018 21:13, naoto.sato at oracle.com wrote:
> Hello,
>
> Please review the fix to the following issue:
>
> https://bugs.openjdk.java.net/browse/JDK-8198385
>
> The proposed changeset is located at:
>
> http://cr.openjdk.java.net/~naoto/8198385/webrev.00/
>
> The property was introduced in JDK7 for the backward compatibility, 
> which at this point is no longer needed. Corresponding CSR is already 
> approved.
This looks okay. Are there are tests to be adjusted/removed as part of this?

-Alan

From naoto.sato at oracle.com  Thu Feb 22 17:12:31 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 22 Feb 2018 09:12:31 -0800
Subject: <i18n dev> [11] RFR: JDK-8198385: Remove property
	sun.locale.formatasdefault
In-Reply-To: <071b4dc7-0ea6-2460-9a3f-57ed18d01b9b@oracle.com>
References: <81803e97-2eb9-7efe-4c32-5be1e92b82f8@oracle.com>
 <071b4dc7-0ea6-2460-9a3f-57ed18d01b9b@oracle.com>
Message-ID: <f5694a2e-97e2-8c94-6b82-a65064b20956@oracle.com>

Thanks, Alan. There is no test case affected by this change, so I added 
"noreg" label to the jira issue.

Naoto

On 2/22/18 5:34 AM, Alan Bateman wrote:
> On 21/02/2018 21:13, naoto.sato at oracle.com wrote:
>> Hello,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8198385
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8198385/webrev.00/
>>
>> The property was introduced in JDK7 for the backward compatibility, 
>> which at this point is no longer needed. Corresponding CSR is already 
>> approved.
> This looks okay. Are there are tests to be adjusted/removed as part of 
> this?
> 
> -Alan

From naoto.sato at oracle.com  Thu Feb 22 19:26:59 2018
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 22 Feb 2018 11:26:59 -0800
Subject: <i18n dev> [11] RFR JDK-8060094: java/util/Formatter/Basic.java
 failed in tr locale
In-Reply-To: <ceada88b-3369-52ab-b7ed-4de95e98b122@oracle.com>
References: <ceada88b-3369-52ab-b7ed-4de95e98b122@oracle.com>
Message-ID: <8118448f-b842-b802-3413-12e429878bd5@oracle.com>

Hi Nishit,

In the test case, the exception error messages may be more helpful if 
there is a distinction between the two (line 103 and 120) mentioning the 
formatter is using the default or specified locale.

Naoto

On 2/22/18 3:51 AM, Nishit Jain wrote:
> Hi,
> 
> Please review the fix for JDK-8060094.
> 
> Bug: https://bugs.openjdk.java.net/browse/JDK-8060094
> Webrev: http://cr.openjdk.java.net/~nishjain/8060094/webrev.03/
> CSR: https://bugs.openjdk.java.net/browse/JDK-8197916
> 
> Cause: The Formatter APIs were not using the correct locale for upper 
> casing when specified during instance creation or during format() call. 
> The default locale was getting used irrespective of whether a Locale is 
> specified in the API.
> Fix: Modified the APIs to use the locale specified.
> 
> Regards,
> Nishit Jain

From nishit.jain at oracle.com  Fri Feb 23 08:33:28 2018
From: nishit.jain at oracle.com (Nishit Jain)
Date: Fri, 23 Feb 2018 14:03:28 +0530
Subject: <i18n dev> [11] RFR JDK-8060094: java/util/Formatter/Basic.java
 failed in tr locale
In-Reply-To: <8118448f-b842-b802-3413-12e429878bd5@oracle.com>
References: <ceada88b-3369-52ab-b7ed-4de95e98b122@oracle.com>
 <8118448f-b842-b802-3413-12e429878bd5@oracle.com>
Message-ID: <2c20ae94-7cbc-9991-8ec5-1aa3b92177db@oracle.com>

Thanks Naoto,

Please check the updated webrev
http://cr.openjdk.java.net/~nishjain/8060094/webrev.04/

Edits made: In FormatLocale.java, clarified the exception messages about 
the locale used and removed an unused import.

Regards,
Nishit Jain
On 23-02-2018 00:56, Naoto Sato wrote:
> Hi Nishit,
>
> In the test case, the exception error messages may be more helpful if 
> there is a distinction between the two (line 103 and 120) mentioning 
> the formatter is using the default or specified locale.
>
> Naoto
>
> On 2/22/18 3:51 AM, Nishit Jain wrote:
>> Hi,
>>
>> Please review the fix for JDK-8060094.
>>
>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060094
>> Webrev: http://cr.openjdk.java.net/~nishjain/8060094/webrev.03/
>> CSR: https://bugs.openjdk.java.net/browse/JDK-8197916
>>
>> Cause: The Formatter APIs were not using the correct locale for upper 
>> casing when specified during instance creation or during format() 
>> call. The default locale was getting used irrespective of whether a 
>> Locale is specified in the API.
>> Fix: Modified the APIs to use the locale specified.
>>
>> Regards,
>> Nishit Jain


From naoto.sato at oracle.com  Fri Feb 23 17:40:01 2018
From: naoto.sato at oracle.com (naoto.sato at oracle.com)
Date: Fri, 23 Feb 2018 09:40:01 -0800
Subject: <i18n dev> [11] RFR JDK-8060094: java/util/Formatter/Basic.java
 failed in tr locale
In-Reply-To: <2c20ae94-7cbc-9991-8ec5-1aa3b92177db@oracle.com>
References: <ceada88b-3369-52ab-b7ed-4de95e98b122@oracle.com>
 <8118448f-b842-b802-3413-12e429878bd5@oracle.com>
 <2c20ae94-7cbc-9991-8ec5-1aa3b92177db@oracle.com>
Message-ID: <bafe88b2-90e2-3e8f-dd78-a60aeee47dfd@oracle.com>

+1

Naoto

On 2/23/18 12:33 AM, Nishit Jain wrote:
> Thanks Naoto,
> 
> Please check the updated webrev
> http://cr.openjdk.java.net/~nishjain/8060094/webrev.04/
> 
> Edits made: In FormatLocale.java, clarified the exception messages about 
> the locale used and removed an unused import.
> 
> Regards,
> Nishit Jain
> On 23-02-2018 00:56, Naoto Sato wrote:
>> Hi Nishit,
>>
>> In the test case, the exception error messages may be more helpful if 
>> there is a distinction between the two (line 103 and 120) mentioning 
>> the formatter is using the default or specified locale.
>>
>> Naoto
>>
>> On 2/22/18 3:51 AM, Nishit Jain wrote:
>>> Hi,
>>>
>>> Please review the fix for JDK-8060094.
>>>
>>> Bug: https://bugs.openjdk.java.net/browse/JDK-8060094
>>> Webrev: http://cr.openjdk.java.net/~nishjain/8060094/webrev.03/
>>> CSR: https://bugs.openjdk.java.net/browse/JDK-8197916
>>>
>>> Cause: The Formatter APIs were not using the correct locale for upper 
>>> casing when specified during instance creation or during format() 
>>> call. The default locale was getting used irrespective of whether a 
>>> Locale is specified in the API.
>>> Fix: Modified the APIs to use the locale specified.
>>>
>>> Regards,
>>> Nishit Jain
>