Hi Gary,
On 4.12.2024 12:44, Gary Gregory wrote:
The StringUtils methods return a mix of null and "" for each method on null
input. Each method does one of the following:
- null out for null in
- "" out for null in
- null for null and "" for ""
- throw an NPE
We definitively need to put some order in `StringUtils`. Personally I
think that:
* All the methods should accept `null` arguments. Since the JDK `String`
class evolved quite a lot since 2011, the only reason users would have
to use `isEmpty()` or `isBlank()` is that those methods accept null
arguments.
* All the methods (except obviously `emptyToNull()`, `stripToNull()`,
etc.) should NOT return null. In 2011 static analysis tools that checked
for nullability were in their infancy, so null checks on the return of
each method might have been common. Nowadays nullability checkers are
common and work quite well. Unfortunately only the Checker Framework
supports the "return null if and only if the argument is null"
paradigm[1] (@PolyNull).
Changing the null-behavior of `StringUtils` will certainly cause certain
applications to misbehave, so I would propose to:
1. Introduce any changes in 4.x in a `lang4.StringUtils` or
`lang4.Strings` class.
2. In 4.x we can still publish a `commons-lang3` artifact with the
`lang3.*` classes, so people can immediately migrate to 4.x and profit
from bug and security fixes. Of course all the classes in the artifact
should be deprecated and (except for the emulation of null-for-null)
should call the corresponding `lang4.*` methods.
Piotr
[1] https://checkerframework.org/manual/#nullness-qualifiers
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
