<i18n dev> [10] RFR 8180469: Wrong short form text for supplemental Japanese era

[Mitsuru Matsushima]

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
> >>>
> >