[
https://issues.apache.org/jira/browse/LANG-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035884#comment-18035884
]
Lenny Primak edited comment on LANG-1786 at 11/6/25 4:34 PM:
-------------------------------------------------------------
I agree with Daniel on both points:
{quote}Isn't the whole problem because Apache wants to be backward compatible
with older versions even when the JDK tries to fade something out?
{quote}
Yes. This is a problem. This i why I am asking to opt-into compatibility rather
than opt-out.
{quote}Wouldn't it be nice if the Apache team just initialized the problematic
timezones when they are actually used somewhere, in a lazy fashion? In that
case their users would get the warning when it becomes required and not during
the initialization of the library.
I don't know if Apache already allows to list available timezones, but even in
that case I would be OK to not have the problematic identifiers returned.
{quote}
Also yes.
What #1480 is trying to do is just that.
Now to address Gary's points.
The goal post hasn't been moved. My "goal post" was always warning-free builds
with Apache RAT plugin. This is not politics, but software :) It's not
either-or, we can both have compatibility and warning-free builds. We can both
be happy, and satisfied :)
My specific issue is not to support warning-free deprecated timezone calls.
It's OK if the call site *requests* "ACT" for JDK to have the warning.
The issue is that the call site is simply
{code:java}
DateFormatUtils.format(Date.from(Instant.now()), "yyyy-MM-dd HH:mm:ss"){code}
with default LOCALE that prints the warnings. As Daniel said, this should not
cause any warnings since the *call site* doesn't request the now-deprecated
timezone, but is self-requested by commons.lang
I still think that for this particular case, #1480 is the simplest and the most
pragmatic solution. Probably can be changed just to be controlled by system
property
What do you guys think?
was (Author: lprimak):
I agree with Daniel on both points:
{quote}Isn't the whole problem because Apache wants to be backward compatible
with older versions even when the JDK tries to fade something out?
{quote}
Yes. This is a problem. This i why I am asking to opt-into compatibility rather
than opt-out.
{quote}Wouldn't it be nice if the Apache team just initialized the problematic
timezones when they are actually used somewhere, in a lazy fashion? In that
case their users would get the warning when it becomes required and not during
the initialization of the library.
I don't know if Apache already allows to list available timezones, but even in
that case I would be OK to not have the problematic identifiers returned.
{quote}
Also yes.
What #1480 is trying to do is just that.
Now to address Gary's points.
The goal post hasn't been moved. My "goal post" was always warning-free builds
with Apache RAT plugin. This is not politics, but software :) It's not
either-or, we can both have compatibility and warning-free builds. We can both
be happy, and satisfied :)
My specific issue is not to support warning-free deprecated timezone calls.
It's OK if the call site *requests* "ACT" for JDK to have the warning.
The issue is that the call site is simply _DateFormatUtils.parse()_ with
default LOCALE that prints the warnings. As Daniel said, this should not cause
any warnings since the *call site* doesn't request the now-deprecated timezone,
but is self-requested by commons.lang
I still think that for this particular case, #1480 is the simplest and the most
pragmatic solution. Probably can be changed just to be controlled by system
property
What do you guys think?
> FastDateFormat logs warnings on the console using FastDateFormat on Java 25
> ---------------------------------------------------------------------------
>
> 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)
