7.0.7 + Java 25: Fix for WARNING: Use of the three-letter time zone ID ... is deprecated and it will be removed in a future release#15432
Conversation
…ed and it will be removed in a future release
|
We already merged the fix for this ... |
|
I guess this is fixing it by changing to the new api instead of the lang update? |
yeah, but are you sure updating the new api still fixes it? |
|
@jdaugherty if it was already fixed, why am I still getting the error using the latest |
|
#15417 was merged 11hrs ago, I don't think we have merged up to 7.1.x yet |
|
I''ve merged these changes up, can you retest before your changes and see if that fixed it? We will still need to take this API to ultimately update the usages, but I assume we'll do that in 7.1.x instead of 7.0.x? @jamesfredley |
| */ | ||
| public CalendarMarshaller() { | ||
| this(FastDateFormat.getInstance("yyyy-MM-dd'T'HH:mm:ss.SSS'Z'", TimeZone.getTimeZone("GMT"), Locale.US)); | ||
| this.legacyFormatter = null; |
There was a problem hiding this comment.
Are there any known performance problems with the java.time.DateTimeFormatter vs the FastDateTimeFormatter?
There was a problem hiding this comment.
DateTimeFormatter is ~15% faster based on the following
https://gist.github.com/akostadinov/670a4dc93485128efb6023f5fa319521
jdaugherty
left a comment
There was a problem hiding this comment.
It doesn't look like any tests were added for this change and the default has been changed. This probably should be a 7.1 change.
|
This question isn’t related to the pull request. I can only help with questions about the PR’s code or comments. |
There was a problem hiding this comment.
Pull request overview
This PR addresses Java 25 deprecation warnings by migrating from Apache Commons FastDateFormat (which uses deprecated three-letter timezone IDs) to Java's java.time.format.DateTimeFormatter API. The change maintains backward compatibility by preserving support for custom formatters through a legacyFormatter field.
Changes:
- Replaced
FastDateFormatwithDateTimeFormatterin date/calendar marshallers - Added backward compatibility support for custom formatters via
legacyFormatterfield - Switched from deprecated three-letter timezone IDs to proper timezone handling
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| grails-converters/src/main/groovy/org/grails/web/converters/marshaller/xml/DateMarshaller.java | Migrated XML date marshaller to use DateTimeFormatter with system default timezone |
| grails-converters/src/main/groovy/org/grails/web/converters/marshaller/json/DateMarshaller.java | Migrated JSON date marshaller to use DateTimeFormatter with UTC timezone |
| grails-converters/src/main/groovy/org/grails/web/converters/marshaller/json/CalendarMarshaller.java | Migrated JSON calendar marshaller to use DateTimeFormatter with UTC timezone |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
|
|
||
| private final Format formatter; | ||
| private static final DateTimeFormatter DEFAULT_FORMATTER = | ||
| DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS z") |
There was a problem hiding this comment.
The date pattern has been changed from "yyyy-MM-dd HH:mm:ss.S z" (single 'S' for milliseconds) to "yyyy-MM-dd HH:mm:ss.SSS z" (triple 'S'). This changes the output format and is not backward compatible. A date with milliseconds value 5 would previously be formatted as "5" but will now be formatted as "005". This could break existing clients that parse these dates. Consider using the original pattern "yyyy-MM-dd HH:mm:ss.S z" to maintain backward compatibility.
| DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.SSS z") | |
| DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss.S z") |
There was a problem hiding this comment.
We need to revert or justify and add documentation for this change.
|
Since this doesn't fix a bug, but resolves annoying log lines when running on Java 25 by changing production code, I think this would be safer in 7.1.x. |
Cover default DateTimeFormatter output, millisecond padding, UTC conversion, legacy Format fallback, and supports() behavior for json/DateMarshaller, json/CalendarMarshaller, and xml/DateMarshaller. Assisted-by: Claude Code <Claude@Claude.ai>
|
@jamesfredley shouldn't we add functional / integration tests for this too given the impact? we're only testing the lower level stuff with this pr |
Add DateMarshallerController and DateMarshallerSpec integration tests to grails-test-examples/app1, exercising the DateTimeFormatter-based marshallers end-to-end through the Grails converters pipeline. Tests cover: - JSON Date marshalling (ISO 8601 UTC format) - JSON Calendar marshalling (ISO 8601 UTC format) - XML Date marshalling (system default timezone format) - 3-digit millisecond padding (.SSS) for both JSON and XML - URL extension-based content negotiation (.json, .xml) Assisted-by: Claude Code <Claude@Claude.ai>
When using Java 25, all grails applications startup with
This is due to the legacy FastDateFormat. This PR switches to java.time instead while maintaining backward compatibility.
The messages no longer occur after this fix.