P3 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.
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.