[ 
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)

Reply via email to