Bug 1837376
| Summary: | openjdk and timezone database | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Milivoje Legenovic <m.legenovic> |
| Component: | java-11-openjdk | Assignee: | Andrew John Hughes <ahughes> |
| Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
| Severity: | medium | Docs Contact: | |
| Priority: | unspecified | ||
| Version: | 31 | CC: | ahughes, ashundi, jerboaa, jvanek |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | java-11-openjdk-11.0.7.10-1.fc31 | Doc Type: | If docs needed, set a value |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2020-06-14 17:10:55 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: | |||
This code shows null-pointers in result array:
String[][] zoneStrings = DateFormatSymbols.getInstance().getZoneStrings();
for (int i = 0; i < zoneStrings.length; ++i) {
System.out.println(zoneStrings[i][0]);
for (int j = 1; j < zoneStrings[i].length; ++j) {
System.out.println(" " + zoneStrings[i][j]);
}
}
This is due to the system timezone data being ahead of OpenJDK. The America/Godthab zone was renamed to America/Nuuk in tzdata 2020a. While we can generate updated Java timezone data using the tzdata sources, these don't include translations. Hence, in cases where a new zone is introduced, there is no translation and this failure occurs. The fix for this is coming in OpenJDK 11.0.8. I'll backport that fix to get it sorted in Fedora in the meantime. As a workaround, tzdata-java can be downgraded back to 2019c. FEDORA-2020-2b062b04b5 has been submitted as an update to Fedora 31. https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b062b04b5 FEDORA-2020-2b062b04b5 has been pushed to the Fedora 31 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-2b062b04b5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-2b062b04b5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates. java-11-openjdk-11.0.7.10-1.fc31 has been pushed to the Fedora 31 stable repository. If problems still persist, please make note of it in this bug report. |
Description of problem: This code fails with NPE on Fedora with java-11-openjdk: try { SimpleDateFormat simpleDateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss Z yyyy"); simpleDateFormat.parse("Tue Feb 2 23:20:02 ABC 2016"); } catch (ParseException e) { e.printStackTrace(); } OpenJDK package from Fedora behaves differently than OpenJDK downloaded from https://openjdk.java.net Difference is: Fedora has its own tzdb.dat (timezone database) provided by tzdata-java package. If you call DateFormatSymbols.getInstance().getZoneStrings() you get an array with 599 items. The same call with OpenJDK from https://openjdk.java.net returns 598 items. Additional item on Fedora is "America/Nuuk", which is an existing timezone. Problem with that timezone is, it does not has short and long names. In result array, short and long name is null. Method SimpleDateFormat.matchZoneString() does not expect null for short and long name, there is no null-check. Because of that, NPE is the result of the call. According to JDK documentation, NPE should not happen in SimpleDateFormat.parse() Version-Release number of selected component (if applicable): java-11-openjdk-11.0.6.10-0.fc32.x86_64 java-latest-openjdk-14.0.1.7-2.rolling.fc32.x86_64 How reproducible: Compile and run this code: try { SimpleDateFormat simpleDateFormat = new SimpleDateFormat("EEE MMM dd HH:mm:ss Z yyyy"); simpleDateFormat.parse("Tue Feb 2 23:20:02 ABC 2016"); } catch (ParseException e) { e.printStackTrace(); } Steps to Reproduce: 1. Compile 2. Run 3. NPE is result Actual results: NPE Expected results: No NPE Additional info: OpenJDK tarball has its own tzdb.dat. With that file everything works as expected. RHEL 7 and RHEL 8 have the same problem.