[
https://issues.apache.org/jira/browse/LANG-1714?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17772617#comment-17772617
]
Gary D. Gregory commented on LANG-1714:
---------------------------------------
{quote}Does Commons Lang provide a set of consistent methods on certain
domains, or just a set of missing methods?
{quote}
Yes and no. Lang (even at just the {{lang3}} level) has been around for so long
that what might once have been a consistent set of methods has evolved over
time to take advantage of and cover newer versions of Java and its APIs, and
it's not always possible to do this and provide "design purity" for whatever
definition that might take.
The next major version would be an opportunity to make Lang "prettier" or more
consistent, whatever that means for a given POV. It is worth noting that I
suspect pragmatism and utility have likely won over pretty/consistency.
> 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)
