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
