FULL PRODUCT VERSION :
java version "9-ea"
Java(TM) SE Runtime Environment (build 9-ea+169)
Java HotSpot(TM) Server VM (build 9-ea+169, mixed mode, emulated-client)
ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601]
A DESCRIPTION OF THE PROBLEM :
By JDK-8173423, the issue of the wrong formatted string for a supplemental new era is resolved. However, there is new issue for the short form.
At the Japanese Era, the JDK's built-in resource for the short form of Eras are same to the full form. Dispite of this, The changes on JDK-8173423, the CalendarDataProviderImpl returns Era.getName() value if only the LONG style requested.Thus, Era.getAbbreviation() value is returned when the short form is requested.
STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
The following code snippet demonstrate the issue (" -Djdk.calendar.japanese.supplemental.era=name=NewEra,abbr=N.E.,since=1546300800000" is given on invocation):
--
LocalDate ldHeisei = LocalDate.of(2018, 1, 1);
LocalDate ldNewEra = LocalDate.of(2019, 1, 1); // first day of NewEra
DateTimeFormatter dtf = DateTimeFormatter.ofPattern("GGGGG GGGG G")
.withChronology(JapaneseChronology.INSTANCE)
.withLocale(Locale.US);
System.out.println(dtf.format(ldHeisei));
System.out.println(dtf.format(ldNewEra));
--
EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
H Heisei Heisei
N.E. NewEra NewEra
ACTUAL -
H Heisei Heisei
N.E. NewEra N.E.
REPRODUCIBILITY :
This bug can be reproduced always.