Michael Keppler created LANG-1714:
-------------------------------------
Summary: Deprecation of StringUtils.defaultString(...,...) is not
useful
Key: LANG-1714
URL: https://issues.apache.org/jira/browse/LANG-1714
Project: Commons Lang
Issue Type: Bug
Reporter: Michael Keppler
Upgrading lang3 from 3.12.0 to 3.13.0 produces a huge amount of deprecations on
a project of mine, all caused by the deprecation of the 2 argument version of
StringUtils.defaultString().
That deprecation causes more harm than good. It's perfectly fine to tell users
via implNote that there is Objects.toString(), which they can also use for
reaching their goal, if they want. But it should not be enforced by means of a
deprecation.
In my experience someone using the StringUtils class does so because there are
_semantically rich_ method names, not because the implementation behind the
method names is done a specific or clever way. Basically you can "think in
String semantics", without having to remember other classes and how their
combination would produce the wanted String. That's why the changed
implementation (from a conditional operator towards the Objects method) should
remain an implementation detail behind that semantically rich method name,
instead of now forcing developers to think of the Objects class when they need
to deal with a String.
If, on the other hand, we would deprecate all methods that can also be done by
some other means, the consistency of the StringUtils API would severely
decrease. By now a developer has to remember to call either
StringUtils.defaultString or Objects.toString if he wants a default string. In
the future that would be the case for many more methods. Essentially he has to
remember what has been implementation details behind StringUtils in the past.
Basically it boils down to: Does Commons Lang provide a set of consistent
methods on certain domains, or just a set of missing methods? The first is much
more useful to its userbase, probably.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
