JDK-8013086 : NPE thrown by SimpleDateFormat with TimeZoneNameProvider supplied
  • Type: Bug
  • Component: core-libs
  • Sub-Component: java.text
  • Affected Version: 7,8
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2013-04-04
  • Updated: 2013-05-24
  • Resolved: 2013-05-07
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
8 b91Fixed
Description
FULL PRODUCT VERSION :
java version  " 1.7.0_07 " 
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)

ADDITIONAL OS VERSION INFORMATION :
Not OS dependent.

EXTRA RELEVANT SYSTEM CONFIGURATION :
-Djava.ext.dirs=<path>, where <path> includes a custom TimeZoneNameProvider implementation available.

A DESCRIPTION OF THE PROBLEM :
A user can subclass java.util.spi.TimeZoneNameProvider to create a custom time zone name provider implementation. When the method  " public String getDisplayName(String ID, boolean daylight, int style, Locale locale) "  in a custom provider only support partial combination of daylight/style (for example, an implementation support long and short standard display names, but not daylight saving time names), then SimpleDateFormat#parse method could throw NPE like below -

----
java.lang.NullPointerException
at java.text.SimpleDateFormat.matchZoneString(SimpleDateFormat.java:1566)
at java.text.SimpleDateFormat.subParseZoneString(SimpleDateFormat.java:1628)
at java.text.SimpleDateFormat.subParse(SimpleDateFormat.java:2017)
at java.text.SimpleDateFormat.parse(SimpleDateFormat.java:1455)
at java.text.DateFormat.parse(DateFormat.java:355)
----

The problem is caused by sun.util.TimeZoneNameUtility#buildZoneStrings(TimeZoneNameProvider tznp, Locale locale, String id) loading display name array with some entries with null value when a custom TimeZoneNameProvider is provided and the provider returns non-null value for long standard name, but null for any of other combinations. buildZoneStrings() only checks if names[1] is not null, that is, long standard name. However, SimpleDateFormat#matchZoneString() expects the name array is fully filled with non-null names.

STEPS TO FOLLOW TO REPRODUCE THE PROBLEM :
See http://bugs.icu-project.org/trac/ticket/9400

EXPECTED VERSUS ACTUAL BEHAVIOR :
EXPECTED -
When time zone names are loaded into zoneStrings array, each name should be initialized independently. That is, if a custom TimeZoneNameProvider's getDisplayName returns partial set of names for a zone ID, names not supported by the provider should be initialized by Java's own fallback implementation.

REPRODUCIBILITY :
This bug can be reproduced always.