Bug 1838229

Summary: NullPointerException in ZonedDateTime.parse after tzdata-2020a update
Product: Red Hat Enterprise Linux 7 Reporter: Scott Spurrier <spurrier>
Component: java-1.8.0-openjdkAssignee: Andrew John Hughes <ahughes>
Status: CLOSED ERRATA QA Contact: OpenJDK QA <java-qa>
Severity: high Docs Contact:
Priority: unspecified    
Version: 7.8CC: ahughes, jandrlik, java-qa, jvanek, jwright, list_custom_itonlineapps_rhn
Target Milestone: rc   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: java-1.8.0-openjdk-1.8.0.262.b05-0.2.ea.el7 Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-09-29 19:54:11 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Scott Spurrier 2020-05-20 16:59:32 UTC
Description of problem:

NullPointerException after updating to tzdata-2020a-1.el7.noarch and tzdata-java-2020a-1.el7.noarch

Version-Release number of selected component (if applicable):

java -version && rpm -qa | grep tzdata
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
tzdata-java-2020a-1.el7.noarch
tzdata-2020a-1.el7.noarch

How reproducible:

Always

Steps to Reproduce:

In jshell:

1. import java.time.*;
2. import java.time.format.*;
3. ZonedDateTime.parse("20170505T173000.000Z", DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss'.'SSSz"))

Actual results:

|  Exception java.time.format.DateTimeParseException: Text '20170505T173000.000Z' could not be parsed: null
|        at DateTimeFormatter.createError (DateTimeFormatter.java:2017)
|        at DateTimeFormatter.parse (DateTimeFormatter.java:1952)
|        at ZonedDateTime.parse (ZonedDateTime.java:598)
|        at (#3:1)
|  Caused by: java.lang.NullPointerException
|        at DateTimeFormatterBuilder$PrefixTree.prefixLength (DateTimeFormatterBuilder.java:4527)
|        at DateTimeFormatterBuilder$PrefixTree.add0 (DateTimeFormatterBuilder.java:4396)
|        at DateTimeFormatterBuilder$PrefixTree.add (DateTimeFormatterBuilder.java:4391)
|        at DateTimeFormatterBuilder$ZoneTextPrinterParser.getTree (DateTimeFormatterBuilder.java:4138)
|        at DateTimeFormatterBuilder$ZoneIdPrinterParser.parse (DateTimeFormatterBuilder.java:4249)
|        at DateTimeFormatterBuilder$CompositePrinterParser.parse (DateTimeFormatterBuilder.java:2370)
|        at DateTimeFormatter.parseUnresolved0 (DateTimeFormatter.java:2107)
|        at DateTimeFormatter.parseResolved0 (DateTimeFormatter.java:203

Expected results:

$3 ==> 2017-05-05T17:30Z

Additional info:

Downgrading the tzdata and tzdata-java packages works around the issue.  

# yum downgrade tzdata
# yum downgrade tzdata-java

# java -version && rpm -qa | grep tzdata
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)
tzdata-2019c-1.el7.noarch
tzdata-java-2019c-1.el7.noarch

# jshell 
|  Welcome to JShell -- Version 11.0.7
|  For an introduction type: /help intro

jshell> import java.time.*;
jshell> import java.time.format.*;
jshell> ZonedDateTime.parse("20170505T173000.000Z", DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss'.'SSSz"))
$3 ==> 2017-05-05T17:30Z

Upstream bug:
https://bugzilla.redhat.com/show_bug.cgi?id=1789468

Comment 2 Andrew John Hughes 2020-05-26 17:12:32 UTC
I'm not able to replicate this locally on RHEL 8:

$ rpm -qi tzdata
Name        : tzdata
Version     : 2020a
Release     : 1.el8

$ cat RH1838229.java 
import java.time.*;
import java.time.format.*;

public class RH1838229 {
    public static void main(String[] args) {
	System.out.println(ZonedDateTime.parse("20170505T173000.000Z", DateTimeFormatter.ofPattern("yyyyMMdd'T'HHmmss'.'SSSz")));
    }
}

$ /usr/lib/jvm/java-1.8.0-openjdk/bin/java -version
openjdk version "1.8.0_252"
OpenJDK Runtime Environment (build 1.8.0_252-b09)
OpenJDK 64-Bit Server VM (build 25.252-b09, mixed mode)

$ /usr/lib/jvm/java-1.8.0-openjdk/bin/java RH1838229 
2017-05-05T17:30Z

$ /usr/lib/jvm/java-11-openjdk/bin/java -version
openjdk version "11.0.7" 2020-04-14 LTS
OpenJDK Runtime Environment 18.9 (build 11.0.7+10-LTS)
OpenJDK 64-Bit Server VM 18.9 (build 11.0.7+10-LTS, mixed mode, sharing)

$ /usr/lib/jvm/java-11-openjdk/bin/java RH1838229 
2017-05-05T17:30Z

Will try on a RHEL 7 box.

Comment 4 Andrew John Hughes 2020-06-05 01:15:19 UTC
Similar issue in bug 1837376 for Fedora.

Comment 14 list_custom_itonlineapps_rhn 2020-07-16 13:25:01 UTC
This problems happens with all distributed jvm. The workaround, downgrading tzdata-java, is not a real solution. Is there any release date for it ? It's critical for us, it break production code.

Comment 16 Andrew John Hughes 2020-08-17 21:47:14 UTC
This should have been fixed in the batch of security updates for July.

Which version of RHEL & java-1.8.0-openjdk is the customer using?

Comment 17 list_custom_itonlineapps_rhn 2020-08-18 08:24:36 UTC
It's now OK for me.

Comment 19 errata-xmlrpc 2020-09-29 19:54:11 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (java-1.8.0-openjdk bug fix and enhancement update), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3920