[
https://issues.apache.org/jira/browse/LANG-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772500#comment-17772500
]
Michael Osipov commented on LANG-1714:
--------------------------------------
I support your request.
> 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
> Priority: Major
>
> 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)