You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@commons.apache.org by "Michael Keppler (Jira)" <ji...@apache.org> on 2023/10/06 09:06:00 UTC

[jira] [Created] (LANG-1714) Deprecation of StringUtils.defaultString(...,...) is not useful

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)