Repository navigation
Deprecate StringUtils.replace and contains - #427
Merged
Merged
Conversation
String has carried equivalents since Java 5, so these overloads only
exist to be null-tolerant.
Only the overloads with a direct JDK counterpart are marked. The max
variants and replaceOnce stay, because String.replace cannot limit the
number of replacements.
The javadoc spells out where the JDK method is not a drop-in swap:
"abc".replace("", "-") returns -a-b-c-, while this replace returns the
text unchanged when repl is empty. interpolate() now calls the 4-arg
overload so the class does not warn against itself.
slachiewicz
marked this pull request as ready for review
September 10, 2026 16:54
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Deprecates the
StringUtils.replaceandcontainsoverloads thatStringhas had an equivalent for since Java 5. Their only remaining value is toleratingnull.Fixes #362.
Marked:
replace(String, char, char)->String.replace(char, char)replace(String, String, String)->String.replace(CharSequence, CharSequence)contains(String, String)->String.contains(CharSequence)contains(String, char)->String.indexOf(int) >= 0Left alone:
replace(..., int max)in both forms, andreplaceOnce.String.replacecannot limit the number of replacements, so there is nothing to point those at.The issue lists three methods;
contains(String, char)is the fourth here. Deprecating onecontainsoverload and not the other would read as an oversight, and its replacement is just as direct. Say the word if you would rather it stayed.Two caveats are written into the javadoc rather than left for callers to discover, because neither replacement is a blind swap:
NullPointerExceptionwhere these returnnullorfalse"abc".replace("", "-")returns-a-b-c-, whileStringUtils.replace("abc", "", "-")returns"abc"unchangedinterpolate()now calls the 4-argreplaceso the class does not warn against itself. That is a delegation change only -- the 3-arg form isreplace(text, repl, with, -1).Verified:
mvn -B verifyon JDK 17 -> Tests run: 788, Failures: 0, Errors: 0. Spotless clean, no deprecation warnings in the build.This change was created with AI assistance.