replace io.micrometer.core.instrument.util.StringUtils with org.apache.commons.lang3.StringUtils if both are available in the classpath

[yeikel]

Importing io.micrometer.core.instrument.util.StringUtils instead of org.apache.commons.lang3.StringUtils is likely an user error when both of them are in the classpath

Both of them define the methods isBlank isNotBlank truncate and others

See https://github.com/micrometer-metrics/micrometer/blob/main/micrometer-core/src/main/java/io/micrometer/core/instrument/util/StringUtils.java and https://github.com/apache/commons-lang/blob/master/src/main/java/org/apache/commons/lang3/StringUtils.java

Maybe we should not do this if lang3.StringUtils is not available in the classpath as maybe this was done intentionally to save one extra dependency. At the same time, I think that doing so is an overkill. It is not clear why the micrometer team decided to do so

[jkschneider]

not do this if lang3.StringUtils is not available in the classpath as maybe this was done intentionally to save one extra dependency

Micrometer is a very low level library, so dependency avoidance is huge. In main app code, I agree that I'd swap it out with one of the many equivalent StringUtils classes if they are on the classpath. Wouldn't necessarily add a dep just to get that functionality though, at least not as part of automation like this. Can fall back on commons-lang 2, Guava, etc which have roughly equivalent behavior.

[timtebeek]

I'm going to close this issue as likely by design for folks using micrometer StringUtils; in parallel we have a rewrite-apache module if you do feel others would benefit from recipes to go between StringUtils implementations. Welcome to continue there! :)