From m-matsushima at bk.jp.nec.com  Fri Sep  1 02:34:30 2017
From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima)
Date: Fri, 1 Sep 2017 02:34:30 +0000
Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
 supplemental	Japanese era
In-Reply-To: <04f6fa07-019f-27f3-5971-b2b27d40ca0c@oracle.com>
References: <04f6fa07-019f-27f3-5971-b2b27d40ca0c@oracle.com>
Message-ID: <FB6AC4542FE4A34A927ACA180392EDAD0262520B@BPXM11GP.gisp.nec.co.jp>

Hi Naoto-san,

The fix looks good, though I'm not a reviewer...
 
By the way, I may have forgotten to inform you that there exist an issue at the short form of SimpleDateFormat has an issue.

The SimpleDateFormat class is only capable to treat two form, Short and Long.
At JDK9, the CLDR Provider become to default, the provider returns the same value for the Short form and the Long form.
So, the behavior of SimpleDateFormat is incompatible to previous versions.
(See the Comparison table, I described before.)

---
Mitsuru

> -----Original Message-----
> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf Of Naoto Sato
> Sent: Thursday, August 31, 2017 7:56 AM
> To: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev <i18n-dev at openjdk.java.net>
> Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
> 
> Hi,
> 
> Please review the fix to the following issue:
> 
> https://bugs.openjdk.java.net/browse/JDK-8180469
> 
> The proposed changeset is located at:
> 
> http://cr.openjdk.java.net/~naoto/8180469/webrev.00/
> 
> The problem was caused by the difference of the Era display name for "SHORT" style between java.time and java.util.Calendar.
> 
> Naoto

From naoto.sato at oracle.com  Fri Sep  1 17:48:32 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 1 Sep 2017 10:48:32 -0700
Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
 supplemental Japanese era
In-Reply-To: <FB6AC4542FE4A34A927ACA180392EDAD0262520B@BPXM11GP.gisp.nec.co.jp>
References: <04f6fa07-019f-27f3-5971-b2b27d40ca0c@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD0262520B@BPXM11GP.gisp.nec.co.jp>
Message-ID: <5a6c018f-1292-a49b-a015-bd3154ff27cc@oracle.com>

Hi Mitsuru-san,

Yes, I remember we discussed on this issue before. The reason that LONG 
and SHORT names for Japanese era are the same is that CLDR's era names 
are not very consistent on length. They have "eraNames", "eraAbbr", and 
"eraNarrow" variations. We simply assign LONG to eraNames and SHORT to 
eraAbbr in SimpleDateFormat. Possibly the right solution is to provide 
"narrow" option in SimpleDateFormat, but it would be breaking the 
compatibility (text length of those pattern characters just have two 
options, one is 4 or greater (=LONG), and the other is less than 4 
(=SHORT)).

So, considering these, I have a couple of options. One is to use the 
newer java.time.format APIs which can correctly handle this, or use the 
JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.

HTH,
Naoto

On 8/31/17 7:34 PM, Mitsuru Matsushima wrote:
> Hi Naoto-san,
> 
> The fix looks good, though I'm not a reviewer...
>   
> By the way, I may have forgotten to inform you that there exist an issue at the short form of SimpleDateFormat has an issue.
> 
> The SimpleDateFormat class is only capable to treat two form, Short and Long.
> At JDK9, the CLDR Provider become to default, the provider returns the same value for the Short form and the Long form.
> So, the behavior of SimpleDateFormat is incompatible to previous versions.
> (See the Comparison table, I described before.)
> 
> ---
> Mitsuru
> 
>> -----Original Message-----
>> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf Of Naoto Sato
>> Sent: Thursday, August 31, 2017 7:56 AM
>> To: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev <i18n-dev at openjdk.java.net>
>> Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
>>
>> Hi,
>>
>> Please review the fix to the following issue:
>>
>> https://bugs.openjdk.java.net/browse/JDK-8180469
>>
>> The proposed changeset is located at:
>>
>> http://cr.openjdk.java.net/~naoto/8180469/webrev.00/
>>
>> The problem was caused by the difference of the Era display name for "SHORT" style between java.time and java.util.Calendar.
>>
>> Naoto

From m-matsushima at bk.jp.nec.com  Thu Sep  7 06:16:13 2017
From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima)
Date: Thu, 7 Sep 2017 06:16:13 +0000
Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
 supplemental Japanese era
In-Reply-To: <5a6c018f-1292-a49b-a015-bd3154ff27cc@oracle.com>
References: <04f6fa07-019f-27f3-5971-b2b27d40ca0c@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD0262520B@BPXM11GP.gisp.nec.co.jp>
 <5a6c018f-1292-a49b-a015-bd3154ff27cc@oracle.com>
Message-ID: <FB6AC4542FE4A34A927ACA180392EDAD02631175@BPXM11GP.gisp.nec.co.jp>

Hi, Naoto-san,

> So, considering these, I have a couple of options. One is to use the newer
> java.time.format APIs which can correctly handle
> this, or use the
> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.

Hmm, I think the first option is ok.
However, the second one seems to be confused.

I guess the behaviors with COPMAT and Supplemental Era become follows:

* COMPAT (SimpleDateFormat)
 Long: Heisei
 Short: H

* COMPAT (DateTimeFormatter)
 Long: Heisei
 Short: H
 Narrow: H

* Supplemental Era (SimpleDateFormat)
 Long: NewEra
 Short: N.E

* Supplemental Era (DateTimeFormatter)
 Long: NewEra
 Short: NewEra
 Narrow: N.E

If this is true, the short value of Supplemental Era differs from COMPAT.
So CalendarNameProviderImpl should be conscious about the type of provider.

---
Mitsuru

> -----Original Message-----
> From: Naoto Sato [mailto:naoto.sato at oracle.com]
> Sent: Saturday, September 02, 2017 2:49 AM
> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
> <i18n-dev at openjdk.java.net>
> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
> 
> Hi Mitsuru-san,
> 
> Yes, I remember we discussed on this issue before. The reason that LONG and SHORT names for Japanese era are the same
> is that CLDR's era names are not very consistent on length. They have "eraNames", "eraAbbr", and "eraNarrow" variations.
> We simply assign LONG to eraNames and SHORT to eraAbbr in SimpleDateFormat. Possibly the right solution is to provide
> "narrow" option in SimpleDateFormat, but it would be breaking the compatibility (text length of those pattern characters
> just have two options, one is 4 or greater (=LONG), and the other is less than 4 (=SHORT)).
> 
> So, considering these, I have a couple of options. One is to use the newer java.time.format APIs which can correctly handle
> this, or use the
> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
> 
> HTH,
> Naoto
> 
> On 8/31/17 7:34 PM, Mitsuru Matsushima wrote:
> > Hi Naoto-san,
> >
> > The fix looks good, though I'm not a reviewer...
> >
> > By the way, I may have forgotten to inform you that there exist an issue at the short form of SimpleDateFormat has an
> issue.
> >
> > The SimpleDateFormat class is only capable to treat two form, Short and Long.
> > At JDK9, the CLDR Provider become to default, the provider returns the same value for the Short form and the Long form.
> > So, the behavior of SimpleDateFormat is incompatible to previous versions.
> > (See the Comparison table, I described before.)
> >
> > ---
> > Mitsuru
> >
> >> -----Original Message-----
> >> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf
> >> Of Naoto Sato
> >> Sent: Thursday, August 31, 2017 7:56 AM
> >> To: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
> >> <i18n-dev at openjdk.java.net>
> >> Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
> >> supplemental Japanese era
> >>
> >> Hi,
> >>
> >> Please review the fix to the following issue:
> >>
> >> https://bugs.openjdk.java.net/browse/JDK-8180469
> >>
> >> The proposed changeset is located at:
> >>
> >> http://cr.openjdk.java.net/~naoto/8180469/webrev.00/
> >>
> >> The problem was caused by the difference of the Era display name for "SHORT" style between java.time and java.util.Calendar.
> >>
> >> Naoto


From naoto.sato at oracle.com  Thu Sep  7 17:28:41 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Thu, 7 Sep 2017 10:28:41 -0700
Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
 supplemental Japanese era
In-Reply-To: <FB6AC4542FE4A34A927ACA180392EDAD02631175@BPXM11GP.gisp.nec.co.jp>
References: <04f6fa07-019f-27f3-5971-b2b27d40ca0c@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD0262520B@BPXM11GP.gisp.nec.co.jp>
 <5a6c018f-1292-a49b-a015-bd3154ff27cc@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD02631175@BPXM11GP.gisp.nec.co.jp>
Message-ID: <77a2201b-cb28-425d-37a1-7f4492928050@oracle.com>

Mitsuru-san,

By those options I meant to address the inconsistency in 
SimpleDateFormat, between COMPAT and CLDR, for the existing eras (e.g. 
Heisei). As to the inconsistency you wrote below, I am not sure that's 
worth doing, considering 1) it is aligned with CLDR, 2) supplemental era 
functionality is for emergency situations till the era is officially 
supported.

Naoto



On 9/6/17 11:16 PM, Mitsuru Matsushima wrote:
> Hi, Naoto-san,
> 
>> So, considering these, I have a couple of options. One is to use the newer
>> java.time.format APIs which can correctly handle
>> this, or use the
>> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
> 
> Hmm, I think the first option is ok.
> However, the second one seems to be confused >
> I guess the behaviors with COPMAT and Supplemental Era become follows:
> 
> * COMPAT (SimpleDateFormat)
>   Long: Heisei
>   Short: H
> 
> * COMPAT (DateTimeFormatter)
>   Long: Heisei
>   Short: H
>   Narrow: H
> 
> * Supplemental Era (SimpleDateFormat)
>   Long: NewEra
>   Short: N.E
> 
> * Supplemental Era (DateTimeFormatter)
>   Long: NewEra
>   Short: NewEra
>   Narrow: N.E
> 
> If this is true, the short value of Supplemental Era differs from COMPAT.
> So CalendarNameProviderImpl should be conscious about the type of provider.
> 
> ---
> Mitsuru
> 
>> -----Original Message-----
>> From: Naoto Sato [mailto:naoto.sato at oracle.com]
>> Sent: Saturday, September 02, 2017 2:49 AM
>> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
>> <i18n-dev at openjdk.java.net>
>> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
>>
>> Hi Mitsuru-san,
>>
>> Yes, I remember we discussed on this issue before. The reason that LONG and SHORT names for Japanese era are the same
>> is that CLDR's era names are not very consistent on length. They have "eraNames", "eraAbbr", and "eraNarrow" variations.
>> We simply assign LONG to eraNames and SHORT to eraAbbr in SimpleDateFormat. Possibly the right solution is to provide
>> "narrow" option in SimpleDateFormat, but it would be breaking the compatibility (text length of those pattern characters
>> just have two options, one is 4 or greater (=LONG), and the other is less than 4 (=SHORT)).
>>
>> So, considering these, I have a couple of options. One is to use the newer java.time.format APIs which can correctly handle
>> this, or use the
>> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
>>
>> HTH,
>> Naoto
>>
>> On 8/31/17 7:34 PM, Mitsuru Matsushima wrote:
>>> Hi Naoto-san,
>>>
>>> The fix looks good, though I'm not a reviewer...
>>>
>>> By the way, I may have forgotten to inform you that there exist an issue at the short form of SimpleDateFormat has an
>> issue.
>>>
>>> The SimpleDateFormat class is only capable to treat two form, Short and Long.
>>> At JDK9, the CLDR Provider become to default, the provider returns the same value for the Short form and the Long form.
>>> So, the behavior of SimpleDateFormat is incompatible to previous versions.
>>> (See the Comparison table, I described before.)
>>>
>>> ---
>>> Mitsuru
>>>
>>>> -----Original Message-----
>>>> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf
>>>> Of Naoto Sato
>>>> Sent: Thursday, August 31, 2017 7:56 AM
>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
>>>> <i18n-dev at openjdk.java.net>
>>>> Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
>>>> supplemental Japanese era
>>>>
>>>> Hi,
>>>>
>>>> Please review the fix to the following issue:
>>>>
>>>> https://bugs.openjdk.java.net/browse/JDK-8180469
>>>>
>>>> The proposed changeset is located at:
>>>>
>>>> http://cr.openjdk.java.net/~naoto/8180469/webrev.00/
>>>>
>>>> The problem was caused by the difference of the Era display name for "SHORT" style between java.time and java.util.Calendar.
>>>>
>>>> Naoto
> 

From m-matsushima at bk.jp.nec.com  Fri Sep  8 07:51:19 2017
From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima)
Date: Fri, 8 Sep 2017 07:51:19 +0000
Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
 supplemental Japanese era
In-Reply-To: <77a2201b-cb28-425d-37a1-7f4492928050@oracle.com>
References: <04f6fa07-019f-27f3-5971-b2b27d40ca0c@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD0262520B@BPXM11GP.gisp.nec.co.jp>
 <5a6c018f-1292-a49b-a015-bd3154ff27cc@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD02631175@BPXM11GP.gisp.nec.co.jp>
 <77a2201b-cb28-425d-37a1-7f4492928050@oracle.com>
Message-ID: <FB6AC4542FE4A34A927ACA180392EDAD02631C8F@BPXM11GP.gisp.nec.co.jp>

Hi, Naoto-san,

Oh, I think I had misunderstood the behavior of COMPAT Provider.

COMPAT Provider provide values, each of them are the same form as Supplemental Era, right?

I think the value I wrote before are wrong at Short form of COMPAT (DateTimeFormatter).
Is there no inconsistency, isn't it?

---
Mitsuru

> -----Original Message-----
> From: Naoto Sato [mailto:naoto.sato at oracle.com]
> Sent: Friday, September 08, 2017 2:29 AM
> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
> <i18n-dev at openjdk.java.net>
> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
> 
> Mitsuru-san,
> 
> By those options I meant to address the inconsistency in SimpleDateFormat, between COMPAT and CLDR, for the existing eras
> (e.g.
> Heisei). As to the inconsistency you wrote below, I am not sure that's worth doing, considering 1) it is aligned with
> CLDR, 2) supplemental era functionality is for emergency situations till the era is officially supported.
> 
> Naoto
> 
> 
> 
> On 9/6/17 11:16 PM, Mitsuru Matsushima wrote:
> > Hi, Naoto-san,
> >
> >> So, considering these, I have a couple of options. One is to use the
> >> newer java.time.format APIs which can correctly handle this, or use
> >> the
> >> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
> >
> > Hmm, I think the first option is ok.
> > However, the second one seems to be confused > I guess the behaviors
> > with COPMAT and Supplemental Era become follows:
> >
> > * COMPAT (SimpleDateFormat)
> >   Long: Heisei
> >   Short: H
> >
> > * COMPAT (DateTimeFormatter)
> >   Long: Heisei
> >   Short: H
> >   Narrow: H
> >
> > * Supplemental Era (SimpleDateFormat)
> >   Long: NewEra
> >   Short: N.E
> >
> > * Supplemental Era (DateTimeFormatter)
> >   Long: NewEra
> >   Short: NewEra
> >   Narrow: N.E
> >
> > If this is true, the short value of Supplemental Era differs from COMPAT.
> > So CalendarNameProviderImpl should be conscious about the type of provider.
> >
> > ---
> > Mitsuru
> >
> >> -----Original Message-----
> >> From: Naoto Sato [mailto:naoto.sato at oracle.com]
> >> Sent: Saturday, September 02, 2017 2:49 AM
> >> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>;
> >> core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
> >> <i18n-dev at openjdk.java.net>
> >> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for
> >> supplemental Japanese era
> >>
> >> Hi Mitsuru-san,
> >>
> >> Yes, I remember we discussed on this issue before. The reason that
> >> LONG and SHORT names for Japanese era are the same is that CLDR's era names are not very consistent on length. They
> have "eraNames", "eraAbbr", and "eraNarrow" variations.
> >> We simply assign LONG to eraNames and SHORT to eraAbbr in
> >> SimpleDateFormat. Possibly the right solution is to provide "narrow"
> >> option in SimpleDateFormat, but it would be breaking the compatibility (text length of those pattern characters just
> have two options, one is 4 or greater (=LONG), and the other is less than 4 (=SHORT)).
> >>
> >> So, considering these, I have a couple of options. One is to use the
> >> newer java.time.format APIs which can correctly handle this, or use
> >> the
> >> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
> >>
> >> HTH,
> >> Naoto
> >>
> >> On 8/31/17 7:34 PM, Mitsuru Matsushima wrote:
> >>> Hi Naoto-san,
> >>>
> >>> The fix looks good, though I'm not a reviewer...
> >>>
> >>> By the way, I may have forgotten to inform you that there exist an
> >>> issue at the short form of SimpleDateFormat has an
> >> issue.
> >>>
> >>> The SimpleDateFormat class is only capable to treat two form, Short and Long.
> >>> At JDK9, the CLDR Provider become to default, the provider returns the same value for the Short form and the Long
> form.
> >>> So, the behavior of SimpleDateFormat is incompatible to previous versions.
> >>> (See the Comparison table, I described before.)
> >>>
> >>> ---
> >>> Mitsuru
> >>>
> >>>> -----Original Message-----
> >>>> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf
> >>>> Of Naoto Sato
> >>>> Sent: Thursday, August 31, 2017 7:56 AM
> >>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
> >>>> <i18n-dev at openjdk.java.net>
> >>>> Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
> >>>> supplemental Japanese era
> >>>>
> >>>> Hi,
> >>>>
> >>>> Please review the fix to the following issue:
> >>>>
> >>>> https://bugs.openjdk.java.net/browse/JDK-8180469
> >>>>
> >>>> The proposed changeset is located at:
> >>>>
> >>>> http://cr.openjdk.java.net/~naoto/8180469/webrev.00/
> >>>>
> >>>> The problem was caused by the difference of the Era display name for "SHORT" style between java.time and
> java.util.Calendar.
> >>>>
> >>>> Naoto
> >


From naoto.sato at oracle.com  Fri Sep  8 22:19:31 2017
From: naoto.sato at oracle.com (Naoto Sato)
Date: Fri, 8 Sep 2017 15:19:31 -0700
Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
 supplemental Japanese era
In-Reply-To: <FB6AC4542FE4A34A927ACA180392EDAD02631C8F@BPXM11GP.gisp.nec.co.jp>
References: <04f6fa07-019f-27f3-5971-b2b27d40ca0c@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD0262520B@BPXM11GP.gisp.nec.co.jp>
 <5a6c018f-1292-a49b-a015-bd3154ff27cc@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD02631175@BPXM11GP.gisp.nec.co.jp>
 <77a2201b-cb28-425d-37a1-7f4492928050@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD02631C8F@BPXM11GP.gisp.nec.co.jp>
Message-ID: <cb5279d4-1230-38c3-0a5f-e00f34b2db03@oracle.com>

Yes, I believe that's correct.

Only inconsistency (outside of supplementary era support) is that "G" 
pattern for SimpleDateFormat outputs differently between COMPAT provider 
and CLDR provider, e.g., COMPAT returns "H" and CLDR returns "Heisei", 
which comes from CLDR data using "Heisei" for "abbreviated" names.

Naoto

On 9/8/17 12:51 AM, Mitsuru Matsushima wrote:
> Hi, Naoto-san,
> 
> Oh, I think I had misunderstood the behavior of COMPAT Provider.
> 
> COMPAT Provider provide values, each of them are the same form as Supplemental Era, right?
> 
> I think the value I wrote before are wrong at Short form of COMPAT (DateTimeFormatter).
> Is there no inconsistency, isn't it?
> 
> ---
> Mitsuru
> 
>> -----Original Message-----
>> From: Naoto Sato [mailto:naoto.sato at oracle.com]
>> Sent: Friday, September 08, 2017 2:29 AM
>> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
>> <i18n-dev at openjdk.java.net>
>> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
>>
>> Mitsuru-san,
>>
>> By those options I meant to address the inconsistency in SimpleDateFormat, between COMPAT and CLDR, for the existing eras
>> (e.g.
>> Heisei). As to the inconsistency you wrote below, I am not sure that's worth doing, considering 1) it is aligned with
>> CLDR, 2) supplemental era functionality is for emergency situations till the era is officially supported.
>>
>> Naoto
>>
>>
>>
>> On 9/6/17 11:16 PM, Mitsuru Matsushima wrote:
>>> Hi, Naoto-san,
>>>
>>>> So, considering these, I have a couple of options. One is to use the
>>>> newer java.time.format APIs which can correctly handle this, or use
>>>> the
>>>> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
>>>
>>> Hmm, I think the first option is ok.
>>> However, the second one seems to be confused > I guess the behaviors
>>> with COPMAT and Supplemental Era become follows:
>>>
>>> * COMPAT (SimpleDateFormat)
>>>    Long: Heisei
>>>    Short: H
>>>
>>> * COMPAT (DateTimeFormatter)
>>>    Long: Heisei
>>>    Short: H
>>>    Narrow: H
>>>
>>> * Supplemental Era (SimpleDateFormat)
>>>    Long: NewEra
>>>    Short: N.E
>>>
>>> * Supplemental Era (DateTimeFormatter)
>>>    Long: NewEra
>>>    Short: NewEra
>>>    Narrow: N.E
>>>
>>> If this is true, the short value of Supplemental Era differs from COMPAT.
>>> So CalendarNameProviderImpl should be conscious about the type of provider.
>>>
>>> ---
>>> Mitsuru
>>>
>>>> -----Original Message-----
>>>> From: Naoto Sato [mailto:naoto.sato at oracle.com]
>>>> Sent: Saturday, September 02, 2017 2:49 AM
>>>> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>;
>>>> core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
>>>> <i18n-dev at openjdk.java.net>
>>>> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for
>>>> supplemental Japanese era
>>>>
>>>> Hi Mitsuru-san,
>>>>
>>>> Yes, I remember we discussed on this issue before. The reason that
>>>> LONG and SHORT names for Japanese era are the same is that CLDR's era names are not very consistent on length. They
>> have "eraNames", "eraAbbr", and "eraNarrow" variations.
>>>> We simply assign LONG to eraNames and SHORT to eraAbbr in
>>>> SimpleDateFormat. Possibly the right solution is to provide "narrow"
>>>> option in SimpleDateFormat, but it would be breaking the compatibility (text length of those pattern characters just
>> have two options, one is 4 or greater (=LONG), and the other is less than 4 (=SHORT)).
>>>>
>>>> So, considering these, I have a couple of options. One is to use the
>>>> newer java.time.format APIs which can correctly handle this, or use
>>>> the
>>>> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
>>>>
>>>> HTH,
>>>> Naoto
>>>>
>>>> On 8/31/17 7:34 PM, Mitsuru Matsushima wrote:
>>>>> Hi Naoto-san,
>>>>>
>>>>> The fix looks good, though I'm not a reviewer...
>>>>>
>>>>> By the way, I may have forgotten to inform you that there exist an
>>>>> issue at the short form of SimpleDateFormat has an
>>>> issue.
>>>>>
>>>>> The SimpleDateFormat class is only capable to treat two form, Short and Long.
>>>>> At JDK9, the CLDR Provider become to default, the provider returns the same value for the Short form and the Long
>> form.
>>>>> So, the behavior of SimpleDateFormat is incompatible to previous versions.
>>>>> (See the Comparison table, I described before.)
>>>>>
>>>>> ---
>>>>> Mitsuru
>>>>>
>>>>>> -----Original Message-----
>>>>>> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf
>>>>>> Of Naoto Sato
>>>>>> Sent: Thursday, August 31, 2017 7:56 AM
>>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
>>>>>> <i18n-dev at openjdk.java.net>
>>>>>> Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
>>>>>> supplemental Japanese era
>>>>>>
>>>>>> Hi,
>>>>>>
>>>>>> Please review the fix to the following issue:
>>>>>>
>>>>>> https://bugs.openjdk.java.net/browse/JDK-8180469
>>>>>>
>>>>>> The proposed changeset is located at:
>>>>>>
>>>>>> http://cr.openjdk.java.net/~naoto/8180469/webrev.00/
>>>>>>
>>>>>> The problem was caused by the difference of the Era display name for "SHORT" style between java.time and
>> java.util.Calendar.
>>>>>>
>>>>>> Naoto
>>>
> 

From m-matsushima at bk.jp.nec.com  Mon Sep 11 03:18:00 2017
From: m-matsushima at bk.jp.nec.com (Mitsuru Matsushima)
Date: Mon, 11 Sep 2017 03:18:00 +0000
Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
 supplemental Japanese era
In-Reply-To: <cb5279d4-1230-38c3-0a5f-e00f34b2db03@oracle.com>
References: <04f6fa07-019f-27f3-5971-b2b27d40ca0c@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD0262520B@BPXM11GP.gisp.nec.co.jp>
 <5a6c018f-1292-a49b-a015-bd3154ff27cc@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD02631175@BPXM11GP.gisp.nec.co.jp>
 <77a2201b-cb28-425d-37a1-7f4492928050@oracle.com>
 <FB6AC4542FE4A34A927ACA180392EDAD02631C8F@BPXM11GP.gisp.nec.co.jp>
 <cb5279d4-1230-38c3-0a5f-e00f34b2db03@oracle.com>
Message-ID: <FB6AC4542FE4A34A927ACA180392EDAD02633586@BPXM11GP.gisp.nec.co.jp>

Hi, Naoto-san,

Okay, I got it.
I'll intend to suggest refactoring with new API or using COMPAT provider, if there are issue relating about era forms on existing apps.

Thank you for your response.

---
Mitsuru

> -----Original Message-----
> From: Naoto Sato [mailto:naoto.sato at oracle.com]
> Sent: Saturday, September 09, 2017 7:20 AM
> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>; core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
> <i18n-dev at openjdk.java.net>
> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
> 
> Yes, I believe that's correct.
> 
> Only inconsistency (outside of supplementary era support) is that "G"
> pattern for SimpleDateFormat outputs differently between COMPAT provider
> and CLDR provider, e.g., COMPAT returns "H" and CLDR returns "Heisei",
> which comes from CLDR data using "Heisei" for "abbreviated" names.
> 
> Naoto
> 
> On 9/8/17 12:51 AM, Mitsuru Matsushima wrote:
> > Hi, Naoto-san,
> >
> > Oh, I think I had misunderstood the behavior of COMPAT Provider.
> >
> > COMPAT Provider provide values, each of them are the same form as Supplemental Era, right?
> >
> > I think the value I wrote before are wrong at Short form of COMPAT (DateTimeFormatter).
> > Is there no inconsistency, isn't it?
> >
> > ---
> > Mitsuru
> >
> >> -----Original Message-----
> >> From: Naoto Sato [mailto:naoto.sato at oracle.com]
> >> Sent: Friday, September 08, 2017 2:29 AM
> >> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>; core-libs-dev <core-libs-dev at openjdk.java.net>;
> i18n-dev
> >> <i18n-dev at openjdk.java.net>
> >> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era
> >>
> >> Mitsuru-san,
> >>
> >> By those options I meant to address the inconsistency in SimpleDateFormat, between COMPAT and CLDR, for the existing
> eras
> >> (e.g.
> >> Heisei). As to the inconsistency you wrote below, I am not sure that's worth doing, considering 1) it is aligned with
> >> CLDR, 2) supplemental era functionality is for emergency situations till the era is officially supported.
> >>
> >> Naoto
> >>
> >>
> >>
> >> On 9/6/17 11:16 PM, Mitsuru Matsushima wrote:
> >>> Hi, Naoto-san,
> >>>
> >>>> So, considering these, I have a couple of options. One is to use the
> >>>> newer java.time.format APIs which can correctly handle this, or use
> >>>> the
> >>>> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
> >>>
> >>> Hmm, I think the first option is ok.
> >>> However, the second one seems to be confused > I guess the behaviors
> >>> with COPMAT and Supplemental Era become follows:
> >>>
> >>> * COMPAT (SimpleDateFormat)
> >>>    Long: Heisei
> >>>    Short: H
> >>>
> >>> * COMPAT (DateTimeFormatter)
> >>>    Long: Heisei
> >>>    Short: H
> >>>    Narrow: H
> >>>
> >>> * Supplemental Era (SimpleDateFormat)
> >>>    Long: NewEra
> >>>    Short: N.E
> >>>
> >>> * Supplemental Era (DateTimeFormatter)
> >>>    Long: NewEra
> >>>    Short: NewEra
> >>>    Narrow: N.E
> >>>
> >>> If this is true, the short value of Supplemental Era differs from COMPAT.
> >>> So CalendarNameProviderImpl should be conscious about the type of provider.
> >>>
> >>> ---
> >>> Mitsuru
> >>>
> >>>> -----Original Message-----
> >>>> From: Naoto Sato [mailto:naoto.sato at oracle.com]
> >>>> Sent: Saturday, September 02, 2017 2:49 AM
> >>>> To: Matsushima Mitsuru(?? ?) <m-matsushima at bk.jp.nec.com>;
> >>>> core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
> >>>> <i18n-dev at openjdk.java.net>
> >>>> Subject: Re: <i18n dev> [10] RFR 8180469: Wrong short form text for
> >>>> supplemental Japanese era
> >>>>
> >>>> Hi Mitsuru-san,
> >>>>
> >>>> Yes, I remember we discussed on this issue before. The reason that
> >>>> LONG and SHORT names for Japanese era are the same is that CLDR's era names are not very consistent on length. They
> >> have "eraNames", "eraAbbr", and "eraNarrow" variations.
> >>>> We simply assign LONG to eraNames and SHORT to eraAbbr in
> >>>> SimpleDateFormat. Possibly the right solution is to provide "narrow"
> >>>> option in SimpleDateFormat, but it would be breaking the compatibility (text length of those pattern characters just
> >> have two options, one is 4 or greater (=LONG), and the other is less than 4 (=SHORT)).
> >>>>
> >>>> So, considering these, I have a couple of options. One is to use the
> >>>> newer java.time.format APIs which can correctly handle this, or use
> >>>> the
> >>>> JDK8 locale data by specifying -Djava.locale.providers=COMPAT at runtime.
> >>>>
> >>>> HTH,
> >>>> Naoto
> >>>>
> >>>> On 8/31/17 7:34 PM, Mitsuru Matsushima wrote:
> >>>>> Hi Naoto-san,
> >>>>>
> >>>>> The fix looks good, though I'm not a reviewer...
> >>>>>
> >>>>> By the way, I may have forgotten to inform you that there exist an
> >>>>> issue at the short form of SimpleDateFormat has an
> >>>> issue.
> >>>>>
> >>>>> The SimpleDateFormat class is only capable to treat two form, Short and Long.
> >>>>> At JDK9, the CLDR Provider become to default, the provider returns the same value for the Short form and the Long
> >> form.
> >>>>> So, the behavior of SimpleDateFormat is incompatible to previous versions.
> >>>>> (See the Comparison table, I described before.)
> >>>>>
> >>>>> ---
> >>>>> Mitsuru
> >>>>>
> >>>>>> -----Original Message-----
> >>>>>> From: i18n-dev [mailto:i18n-dev-bounces at openjdk.java.net] On Behalf
> >>>>>> Of Naoto Sato
> >>>>>> Sent: Thursday, August 31, 2017 7:56 AM
> >>>>>> To: core-libs-dev <core-libs-dev at openjdk.java.net>; i18n-dev
> >>>>>> <i18n-dev at openjdk.java.net>
> >>>>>> Subject: <i18n dev> [10] RFR 8180469: Wrong short form text for
> >>>>>> supplemental Japanese era
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> Please review the fix to the following issue:
> >>>>>>
> >>>>>> https://bugs.openjdk.java.net/browse/JDK-8180469
> >>>>>>
> >>>>>> The proposed changeset is located at:
> >>>>>>
> >>>>>> http://cr.openjdk.java.net/~naoto/8180469/webrev.00/
> >>>>>>
> >>>>>> The problem was caused by the difference of the Era display name for "SHORT" style between java.time and
> >> java.util.Calendar.
> >>>>>>
> >>>>>> Naoto
> >>>
> >