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.s...@oracle.com] > Sent: Saturday, September 09, 2017 7:20 AM > To: Matsushima Mitsuru(松島 充) <m-matsush...@bk.jp.nec.com>; core-libs-dev > <core-libs-...@openjdk.java.net>; i18n-dev > <i18n-dev@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.s...@oracle.com] > >> Sent: Friday, September 08, 2017 2:29 AM > >> To: Matsushima Mitsuru(松島 充) <m-matsush...@bk.jp.nec.com>; core-libs-dev > >> <core-libs-...@openjdk.java.net>; > i18n-dev > >> <i18n-dev@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.s...@oracle.com] > >>>> Sent: Saturday, September 02, 2017 2:49 AM > >>>> To: Matsushima Mitsuru(松島 充) <m-matsush...@bk.jp.nec.com>; > >>>> core-libs-dev <core-libs-...@openjdk.java.net>; i18n-dev > >>>> <i18n-dev@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-boun...@openjdk.java.net] On Behalf > >>>>>> Of Naoto Sato > >>>>>> Sent: Thursday, August 31, 2017 7:56 AM > >>>>>> To: core-libs-dev <core-libs-...@openjdk.java.net>; i18n-dev > >>>>>> <i18n-dev@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 > >>> > >
