[
https://issues.apache.org/jira/browse/LANG-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035687#comment-18035687
]
Gary D. Gregory commented on LANG-1786:
---------------------------------------
The whole point of this issue is that Java 25 and 26-ea (build 22) have an
unguarded write to {{System.err}} in a {{{}TimeZone method{}}}. Specifically,
this lovely method:
{code:java}
private static TimeZone getTimeZone(String ID, boolean fallback) {
if (ZoneId.SHORT_IDS.containsKey(ID)) {
System.err.printf(
"WARNING: Use of the three-letter time zone ID \"%s\" is
deprecated and it will be removed in a future release%n",
ID);
}
TimeZone tz = ZoneInfo.getTimeZone(ID);
if (tz == null) {
tz = parseCustomTimeZone(ID);
if (tz == null && fallback) {
tz = new ZoneInfo(GMT_ID, 0);
}
}
return tz;
}
{code}
That's a bug IMO. Java writes warnings to the console, but many have an "off"
switch.
The desire to skip this logging is understandable and worth discussing and
possibly addressing if a not-too-nasty solution is possible.
IMO, there seem to be 2 types of solutions: Code that avoids the logging, or
pretend that you care about deprecated time zone strings and try to whack in a
solution that has the side-effect of not calling the method, which then has the
side-effect of avoiding the logging.
Whatever the solution, it should not break compatibility. If I write or
maintain an application today using {{FastDateParser}} on Java 8 through 25
that uses a short ID, it always works. The short strings are deprecated on Java
25 and 26-ea, _not_ removed. It's up to the call site to decide when to migrate
from using deprecated short IDs, not us to enforce it.
A straightforward solution is to attack the logging directly; this is what the
PR [https://github.com/apache/commons-lang/pull/1481] does. The only drawback
is that other threads may attempt to write to the error stream while the method
is called, and those bytes will go to dev null. This would be a window
nanoseconds wide, but it can, therefore, it will happen, I suspect.
An alternative solution has been proposed in the PR
[https://github.com/apache/commons-lang/pull/1480], but this feels like a bit
of a hack (to me) because it introduces a global variable. If your library or
app stack cares about this behavior, it has to call "set disable of short IDs
that write to the console" feature to true every time it uses a FastDateParser.
Over time, and to preserve compatibility, call sites will call the same API and
set it to "keep the old behavior", so you'll have competition for the setting
value, just like any global variable. It's going to be a looooong time until
the majority of stacks are on Java 25.
A third solution for which I've not written a PR yet is to cache the TimeZone
for short IDs such that the logging for a short ID'd TimeZone only happens
once. Maybe that's the happy compromise.
> A lot of warnings on the console when using FastDateFormat with JDK25
> ---------------------------------------------------------------------
>
> Key: LANG-1786
> URL: https://issues.apache.org/jira/browse/LANG-1786
> Project: Commons Lang
> Issue Type: Improvement
> Components: lang.time.*
> Affects Versions: 3.19.0
> Reporter: Daniel Migowski
> Priority: Major
> Fix For: Patch Needed
>
>
> When using an instance of FastDateFormat with e.g.
> {code:java}
> FastDateFormat.getInstance( "yyyy-MM-dd'T'HH:mm:ssZ" );{code}
> the timezone database of the commons.lang package iterates throught all
> timezones and adds them to the local database. This sadly calls
> {code:java}
> java.util.TimeZone.getTimeZone(String){code}
> with a bunch of timezone strings that are considered deprecated with the new
> JDK25 (or something between 18 and 25, didn't check that), and each of these
> timezone strings leads to a message like
> {noformat}
> WARNING: Use of the three-letter time zone ID "ACT" is deprecated and it will
> be removed in a future release{noformat}
> printed directly from the getTimeZone function to system.err!
> This is actually really annoying. The timezone strings which are deprecated
> can be found in
> {code:java}
> java.time.ZoneId.SHORT_IDS.{code}
> My suggestion is to check in
> {code:java}
> org.apache.commons.lang3.time.FastDateParser.TimeZoneStrategy.TimeZoneStrategy{code}
> if the JDK version 25 is running and then to filter the values from SHORT_IDS
> to be recognized. SHORT_IDS should be copied into commons.lang to make this
> still work with older JDKs.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
