...my 2 cents... I wasn't excited about it either when I made all the changes to our code base yesterday either. Especially since I was only updating the library to pick up a security fix. (which likely didn't even affect us, but like many, we have to keep the "numbers down", and explaining each security issue we don't "fix" is more effort than it's worth).
IMHO, such a change should have required a major version number bump, along with patches to the older branch for 2-3 years. I also find it very easy with the new naming to pick the wrong CS or CI. Very easy to miss in code review as well, for such a potentially important difference. So, I have notable concerns about the choice in the first place. IMHO, if a change was required, a better change would have been to have overloads to the methods with an "ignoreCase" boolean, much like Kotlin does (but most / all Java versions don't allow naming parameters being passed for increased clarity for booleans, etc.). This IMO is much more clear, and wouldn't have broken backwards compatibility (but then again, why even bother changing it in the first place?). Robert On Wed, Jul 16, 2025 at 10:14 AM Bence Hornák <bence.hor...@gmail.com> wrote: > Dear Commons Dev Team, > > In LANG-1777 <https://issues.apache.org/jira/browse/LANG-1777> I've > expressed my frustration with 3.18.0, after a very long day of trying to > migrate a single repository from using StringUtils to Strings.CI/CS. In my > opinion, this is a huge misstep for the commons lib, given its reputation > for stable APIs. > > Quote from the ticket: > > > Version 3.18.0 comes with many deprecations. Many of the most commonly > > used functions are now deprecated, which is breaking a lot of projects' > CI: > > > > - StringUtils.equals() -> Strings.CS.equals() > > - StringUtils.startsWith() -> Strings.CS.startsWith() > > - StringUtils.endsWith() -> Strings.CS.endsWith() > > - StringUtils.contains() -> Strings.CS.contains() > > - StringUtils.replace() -> Strings.CS.replace() > > - StringUtils.indexOf() -> Strings.CS.indexOf() > > - StringUtils.remove(String, String) -> Strings.CS.remove() > > - StringUtils.compare(String, String) -> Strings.CS.compare() > > - StringUtils.equalsIgnoreCase() -> Strings.CI.equals() > > - StringUtils.startsWithIgnoreCase() -> Strings.CI.startsWith() > > - StringUtils.endsWithIgnoreCase() -> Strings.CI.endsWith() > > - StringUtils.containsIgnoreCase() -> Strings.CI.contains() > > - StringUtils.replaceIgnoreCase() -> Strings.CI.replace() > > - ObjectsUtils.defaultIfNull() -> god knows what > > - ... > > > > I find the value of these refactors really questionable. They require > > thousands of developers world-wide to update millions of places in code > > bases to follow the new best practices... for what? I would even say the > > new syntax is more confusing, because it might not be intuitive for all, > > what 'CI' and 'CS' stand for. Besides, the old static method calls have > > become virtual method calls, which come with a considerable performance > > penalty <https://stackoverflow.com/a/28511095> for time-sensitive > > applications. > > > > The Apache commons libs are widely used due to their stability, meaning > > that once you refer a method from your code, you can keep using the > > function securely for decades to come. > > > > Timing-wise these breaking changes are quite critical, because > > CVE-2025-48924 <https://www.cve.org/CVERecord?id=CVE-2025-48924> has > just > > been published, so a lot of users are forced to upgrade their projects > from > > 3.x.x to 3.18.0 ASAP. One could argue that deprecations are not breaking > > changes, but for users, who are compiling with strict compiler flags > (e.g. > > -Werror) they are. > > > > My recommendation is to: > > > > 1. Release 3.17.1 ASAP with a security fix CVE-2025-48924 > > <https://www.cve.org/CVERecord?id=CVE-2025-48924> to to allow users > > to upgrade to a secure version without the need to go through all > these > > refactors > > 2. Reconsider these deprecations, and relax them to recommendations or > > just revert them altogether > > > > Let me know what you think. > > Best regards, > Bence >
