[JAVA-3851] JsonReader EN locale assumption leads to NPE in natively compiled Java Created: 02/Oct/20 Updated: 28/Oct/23 Resolved: 03/Nov/20 |
|
| Status: | Closed |
| Project: | Java Driver |
| Component/s: | JSON |
| Affects Version/s: | 4.1.0 |
| Fix Version/s: | 4.2.0 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Galder Zamarreño | Assignee: | Jeffrey Yemin |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Backwards Compatibility: | Fully Compatible |
| Description |
|
GraalVM native images only supports a single locale, which is leading to an NPE in the mongodb driver, see this quarkus issue The problem is in the JsonReader, which assumes EN as an available locale. When the user changes the language to something else, e.g. Italian, the NPE appears. JsonReader should assume the locale provided by the user and not EN. I've created a temporary substitution that avoids the problem by returning a date as soon as its found (without checking the length), see here. I'm unsure whether such fix would work for mongodb in general. The real fix should be to use the language provided by the user, and then it'd be no problems. |
| Comments |
| Comment by Githook User [ 03/Nov/20 ] |
|
Author: {'name': 'Jeff Yemin', 'email': 'jeff.yemin@mongodb.com', 'username': 'jyemin'}Message: Replace SimpleDateFormat with DateDateFormatter for ISODate string parsing The JsonReader class already uses java.time.format.DateTimeFormatter for parsing This patch replaces the SimpleDateFormat usage with DateTimeFormatter, which will Note that SimpleDateFormat is still used when parsing date strings for the shell-mode
|
| Comment by Galder Zamarreño [ 27/Oct/20 ] |
|
This is not so much about Quarkus, but GraalVM in general. It only includes resource bundles for the local locale when building native executables, see https://github.com/oracle/graal/issues/911. Time and timezones can be translated using these resource bundles. If the user has a different locale to ENGLISH, would things work fine when mongodb is accessed via a natively compiled java application? In some cases, like https://github.com/quarkusio/quarkus/issues/11524, it seems to break, but fortunately a workaround was found. Maybe other workarounds can be found. |
| Comment by Jeffrey Yemin [ 26/Oct/20 ] |
|
Glad to hear that this can be worked around in Quarkus itself for now. Regarding my question from earlier:
Similarly, Locale.ROOT is also used all over the place in the JDK. Can you or someone else from the Quarkus team respond? I'd like to know the answer before we invest in addressing this. |
| Comment by Jeffrey Yemin [ 02/Oct/20 ] |
|
I posted a proposed workaround to the original reporter at https://github.com/quarkusio/quarkus/issues/11524 |
| Comment by Jeffrey Yemin [ 02/Oct/20 ] |
|
Hi galder@redhat.com thanks for reporting this, as we really want MongoDB to work well with both Quarkus and GraalVM. I also noticed that there are hundreds of places in the JDK itself that reference Locale.ENGLISH. I haven't investigated the usages deeply, but it seems likely that at least one of them could cause application issues if that Locale is unavailable. Are you sure that it's a safe assumption to say that Locale.ENGLISH should not generally be required? Regarding your workaround, I don't think it's correct. It avoids the exception by breaking out of the loop before it gets to the format string that contains the time zone. This will cause the method to return a date that is stripped of everything but the date. For example, the string 2013-10-04T12:07:30.443Z will return the date 1380859200000 instead of 1380888450443. If we can figure out a substitution that does work correctly, also note that there are two other methods in JsonReader that rely on Locale.ENGLISH. |