2017-09-15 37 views
13

Próbowałem kodu w Java 8 (1.8.0_77) i Java 9 (Java HotSpot (TM) 64-bitowy serwer VM (kompilacja 9 + 181, tryb mieszany))JDK dataformater parsowanie DayOfWeek w języku niemieckim, java8 kontra java9

DateTimeFormatter dtf = DateTimeFormatter.ofPattern("eee", Locale.GERMAN); 
DayOfWeek mo = dtf.parse("Mo", DayOfWeek::from); 
System.out.println("mo = " + mo); 

nie jestem zbyt obeznany ze szczegółami tych klas, ale w Java 8 to działa, druk:

MO = poniedziałek

w Javie 9, jednak nie jest on

Wyjątek nici "głównym" java.time.format.DateTimeParseException: Text 'Mo' nie może być analizowany w indeksie 0 w java.base/java.time.format.DateTimeFormatter.parseResolved0 (DateTimeFormatter.java : 1988) na java.base/java.time.format.DateTimeFormatter.parse (DateTimeFormatter.java:1890) na day.main (day.java:10)

Wszelkie pomysły, to jest powtarzalne?

więc kiedy formatowanie: stosując kod:

DateTimeFormatter dtf = DateTimeFormatter.ofPattern("eee", Locale.GERMAN); 
String format = dtf.format(DayOfWeek.MONDAY); 
System.out.println("format = " + format); 

jdk1.8.0-77:

formatu

= Mo

jdk-9 (budowy 9 + 181)

forma t = Mo.

+2

https://ideone.com/6t60j1 Czy jesteś pewien/pewna java-8? –

+0

oraz użyłem 1.8.0_77. czy można korzystać z tej wersji na tej stronie? – user140547

+0

Ideone dostarcza pewną wersję, nad którą nie masz nad nią kontroli. (a usługa jest już naprawdę miła IMHO) –

Odpowiedz

10

Wydaje się, że w wynikać z aktualnej realizacji CLDR date-time-patterns z realizacją JEP - 252 który stwierdza, że ​​

Użyj danych locale z konsorcjum Unicode Common Locale danych Repository (CLDR) domyślnie.

Zlokalizowane wzorce formatowania i tłumaczenia znaków wyświetlania ciągi znaków, takie jak nazwa locale, mogą się różnić w niektórych lokalizacjach.

celu umożliwienia zachowania zgodnego z JDK 8, ustawić system własność java.locale.providers do wartości z COMPAT przed projekcie CLDR konsorcjum.


I druga część danych, tym international components for Unicode in German locale który ma następujące istotne informacje można uzasadnić, że zachowanie jest celowe -

enter image description here

Edit/Uwagi: W powiązaniu z @ManiGrover, migration guide określa podobne ostrzeżenie dla takiego wdrożenia kiwania -

Jeśli aplikacja uruchamia się pomyślnie, uważnie przyjrzeć się swoim testów i upewnić się, że zachowanie jest takie samo jak na JDK 8. Na przykład, kilka wczesne wprowadzenie zauważyli, że ich terminy i waluty są sformatowane inaczej. Zobacz Use CLDR Locale Data by Default.

+2

Z https://docs.oracle.com/javase/9/migrate/toc.htm#JSMIG-GUID-AFD3BDEC-99FC-4F3C-946F-A1CD2D05B74B "Jeśli twoja aplikacja uruchamia się pomyślnie, dokładnie przejrzyj testy i upewnij się, że zachowanie jest takie samo jak w JDK 8. Na przykład, kilku pierwszych użytkowników zauważyło, że ich daty i waluty są sformatowane inaczej (patrz Domyślnie używaj danych regionalnych CLDR. " –

6

W abbreviatiions „Mo”, „Di” itd. Bez kropki nie zniknęły w projekcie CLDR konsorcjum, ale są dostępne za pośrednictwem trybie autonomicznym. Należy zmienić wzór używając formatu samodzielny symbol „C” zamiast „e”:

DateTimeFormatter dtf = DateTimeFormatter.ofPattern("ccc", Locale.GERMAN); 
DayOfWeek mo = dtf.parse("Mo", DayOfWeek::from); 

Rzeczywiście uważam zmianę danych bazowych jako łamanie wsteczną kompatybilność (beton jako przerwę behawioralnej).

+5

Przejście do używania danych regionalnych CDLR domyślnie jest rzeczywiście destrukcyjną zmianą. JDK 8 zawiera dane locale CDLR, dzięki czemu można uruchomić za pomocą '-Djava.locale.providers = CLDR', aby zidentyfikować wszelkie problemy przed przejściem do JDK 9. –