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.