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

[Mitsuru Matsushima]

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