[
https://issues.apache.org/jira/browse/LANG-1786?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18035812#comment-18035812
]
Gary D. Gregory commented on LANG-1786:
---------------------------------------
Hi All,
Thank you ALL for the constructive conversation.
Note that https://github.com/apache/commons-lang/pull/1480 doesn't solve the
issue entirely because other callers of {{TimeZone.getTimeZone(String)}} in
Lang will still cause console warnings, so depending on your app stack, it'll
be "now you see me, now you don't"; which will be confusing. The other two PRs
address _all_ call sites. Whatever the solution, I think funneling calls
through Lang's {{TimeZones}} will allow handling all cases.
> Unfortunately #1482 doesn't solve the problem, just lessens the amount of
> warnings (there would still be at least one) which would break most builds
> that fail when new warnings appear.
But see how the requirements have now changed from "This is actually really
annoying.", (which I agree!) to "would break most builds that fail when new
warnings appear". Let's try not to move the goal posts; I know the quotes come
from different authors, but still ;)
- You might want to create a ticket against the JRE.
- IMO, if a build checks for console output that says "Foo", then it can be
made to ignore "Bar".
You are correct, PR 1482 was designed as a compromise.
I don't think we want to kill all warnings unless an application opts in for
that. As a developer, I want to know that I need to change my app or library,
not have it break mysteriously when the JRE actually removes support for these
IDs.
I believe PR https://github.com/apache/commons-lang/pull/1482 offers some
balance because:
- It follows the JRE's desire to log warnings but doesn't do it 100% of the
time, only once.
- It doesn't use a global variable, which different clients may end up fighting
over
> Wouldn't it be nice if the Apache team just initialized the problematic
> timezones when they are actually used somewhere, in a lazy fashion?
This is what https://github.com/apache/commons-lang/pull/1482 does.
(Yet another (not great) alternative would be a combination of
https://github.com/apache/commons-lang/pull/1482 and
https://github.com/apache/commons-lang/pull/1481 where:
Instead of or in addition to {{TimeZones.getTimeZone(String)}} in the PR
1481/2, there would be a {{TimeZones.getTimeZone(String, boolean)}} where the
boolean allows you to opt out of logging. I'm not fond of that because then it
would trickle to having the boolean in other APIs.)
All of this to say that I think PR 1482 is the way to go, but I could see in
adding a system property that would cause the logging to be null'd out through
the bypass in #1481.
Thoughts?
> 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)
