JDK-8139107 : DateTimeFormatter with Locale.UK throw a NullPointerException when parsing zone
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.time
  • Affected Version: 8u60
  • Priority: P3
  • Status: Closed
  • Resolution: Fixed
  • OS: windows_7
  • CPU: x86_64
  • Submitted: 2015-10-06
  • Updated: 2016-08-24
  • Resolved: 2015-10-10
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 8 JDK 9
8u72Fixed 9 b88Fixed
Related Reports
Duplicate :  
Relates :  
Description
FULL PRODUCT VERSION :
Windows
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Linux
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Microsoft Windows [Version 6.1.7601] -- Windows 7 x64 Enterprise SP1
Linux cpabfu01 3.0.101-0.47.52-default #1 SMP Thu Mar 26 10:55:49 UTC 2015 (0e3c7c8) x86_64 x86_64 x86_64 GNU/Linux

EXTRA RELEVANT SYSTEM CONFIGURATION :
This bug is Locale dependent! Locale on all machines configured to: English (United Kingdom).
on Linux:
% echo $LANG
en_GB


A DESCRIPTION OF THE PROBLEM :
Parsing a date from a String with a pattern containing zone pattern (short/long) throw a DateTimeParseException with a NullPointerException as a root cause.

REGRESSION.  Last worked in version 8u51

ADDITIONAL REGRESSION INFORMATION: 
Windows
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

Linux
java version "1.8.0_60"
Java(TM) SE Runtime Environment (build 1.8.0_60-b27)
Java HotSpot(TM) 64-Bit Server VM (build 25.60-b23, mixed mode)

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
1. Create a java.time.format.DateTimeFormatter with "dd-MM-yyyy HH:mm:ss z" and Locale.UK
2. Parse a date with zone description, for example: "06-10-2015 18:58:04 MSK"

(source code included)

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
Correct parsed temporal object is returned
ACTUAL -
DateTimeParseException exception is thrown

ERROR MESSAGES/STACK TRACES THAT OCCUR :
Exception in thread "main" java.lang.reflect.InvocationTargetException
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:130)
Caused by: java.time.format.DateTimeParseException: Text '06-10-2015 18:58:04 MSK' could not be parsed: null
	at java.time.format.DateTimeFormatter.createError(DateTimeFormatter.java:1920)
	at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1781)
	at com.db.abx.bondsserver.tradegate.jmx.FormatterNPE.main(FormatterNPE.java:14)
	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
	at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
	at java.lang.reflect.Method.invoke(Method.java:497)
	at com.intellij.rt.execution.application.AppMain.main(AppMain.java:140)
	... 5 more
Caused by: java.lang.NullPointerException
	at java.time.format.DateTimeFormatterBuilder$PrefixTree.prefixLength(DateTimeFormatterBuilder.java:4123)
	at java.time.format.DateTimeFormatterBuilder$PrefixTree.add0(DateTimeFormatterBuilder.java:3992)
	at java.time.format.DateTimeFormatterBuilder$PrefixTree.add(DateTimeFormatterBuilder.java:3987)
	at java.time.format.DateTimeFormatterBuilder$ZoneTextPrinterParser.getTree(DateTimeFormatterBuilder.java:3738)
	at java.time.format.DateTimeFormatterBuilder$ZoneIdPrinterParser.parse(DateTimeFormatterBuilder.java:3845)
	at java.time.format.DateTimeFormatterBuilder$CompositePrinterParser.parse(DateTimeFormatterBuilder.java:2208)
	at java.time.format.DateTimeFormatter.parseUnresolved0(DateTimeFormatter.java:2010)
	at java.time.format.DateTimeFormatter.parseResolved0(DateTimeFormatter.java:1939)
	at java.time.format.DateTimeFormatter.parse(DateTimeFormatter.java:1777)
	... 11 more

REPRODUCIBILITY :
This bug can be reproduced always.

---------- BEGIN SOURCE ----------
import java.time.ZonedDateTime;
import java.time.format.DateTimeFormatter;
import java.util.Locale;

public class FormatterNPE {
    public static void main(String[] args) {
        DateTimeFormatter inputDateTimeFormat = DateTimeFormatter
                .ofPattern("dd-MM-yyyy HH:mm:ss z")
                .withLocale(Locale.UK);
        String format = "06-10-2015 18:58:04 MSK";
        System.out.println("Parsed   : " + inputDateTimeFormat.parse(format));
        System.out.println(ZonedDateTime.parse(format, inputDateTimeFormat));
    }
}
---------- END SOURCE ----------

CUSTOMER SUBMITTED WORKAROUND :
Create DateTimeFormatter with Locale.ENGLISH seems works correctly


Comments
Taking into account this is too late for October PSU and this is not a regression in 8u66 UR SQE is OK to defer it from PSU15_04
13-10-2015

Regression caused by 8076287 where the fix requires generic timezone names in TimeZoneNames bundle.
09-10-2015

Same problem is observable with hi_IN locale too. The root cause of the problem that TimeZoneNames for "en_GB" and "hi_IN" don't have defined generic names. Problem can be reproduced with JDK9 when default locale provider is JRE: -Djava.locale.providers=JRE,SPI,CLDR
08-10-2015

Assigning to Aleksej for further investigation, as the bug seems to be caused by JDK-8080644
08-10-2015

Appears to be introduced with the build 8u60b14
08-10-2015

Attached Test case was executed on Windows 7 on following JDK versions: JDK 8u51 - Pass JDK 8u60 - Fail JDK 8u66 - Fail JDK 9eab84 -Pass Related bug : JDK-8080644 was fixed for 9 , backporting was not done for 8u60 and 66. Moving to dev-team for action.
08-10-2015