Vladimir: do you use all classes of all your classpath? 🤔 There is no reason commons would be different. Cassandra or tika can now (java >8) easily drop commons for that and it would benefit the projects so either fork as most projects or drop and use the language is the way to go if you care about the bloated dep. Micromodules will just create more mess in terms of dependency converge and require more tooling IMHO - and everybody does not always use maven or gradle, as well as encourage to not use most of other dependencies cause you need to add a dep or cause it is not in the completion which defeats a bit the goal of commons lang for ex.
Romain Manni-Bucau @rmannibucau <https://x.com/rmannibucau> | .NET Blog <https://dotnetbirdie.github.io/> | Blog <https://rmannibucau.github.io/> | Old Blog <http://rmannibucau.wordpress.com> | Github <https://github.com/rmannibucau> | LinkedIn <https://www.linkedin.com/in/rmannibucau> | Book <https://www.packtpub.com/en-us/product/java-ee-8-high-performance-9781788473064> Javaccino founder (Java/.NET service - contact via linkedin) Le jeu. 30 oct. 2025 à 15:43, Vladimir Sitnikov <[email protected]> a écrit : > >easily upgrade to a non vulnerable version of the > >library in the next release > >Yes, the decision to shade should not be taken lightly > > Piotr, you are on Commons PMC while I am not. > You have much more power, so please clarify exactly the way you think > Commons should handle the modularization request. > > Frankly, I would accept either way: > a) Commons team might decide to start with commons-stringuits. Great, and I > could help with that. > b) Commons team might decide that "single jar or big jars is the way to > go". > That's fine as well. In that case I would love to see a clear message on > the project webpage that would > clarify how the team suggests to use the jar if only a small subset is > needed (e.g. StringUtils). > > >I am trying to prove that > >VEX generation for OSS projects this size is feasible with some > automation. > > Can you share a **reproducible** way to generate the same VEX? > If not, then it does not sound like a proof to me. > In other words, could you cover your PR [1] with tests? > > >In most Java > >artifacts, `ClassUtils.getClass` is never called and this verdict can be > >delivered automatically. > > Please clarify how can you do so with reflection in place. > Many libraries use java.lang.reflect, and it is hard to prove none of the > call sites > can end up calling vulnerable class. > Sometimes libraries use bytecode generation in the runtime which might > trigger the problematic classes as well. > Any application that uses Spring might be affected by ClassUtils CVE > since an attacker might inject ClassUtils to spring.xml configuration. > > >- In new code that uses nullability annotations, I prefer > > `String.isBlank()` over `StringUtils.isBlank()`. > > Take Apache Tika or Apache Cassandra as an example. > They use a bit of StringUtils. > Do you suggest they should migrate to machine-verifiable nullability? > Sure it might help, however, it would be a significant effort. > It would help a lot if there was commons-stringutils which they can use > before they apply nullability. > > >- I disagree with adding `commons-lang3` as a dependency of > > `commons-compress` just to “reuse” four methods (see my PR [3]). > > It would be fine to reuse if the needed classes were in the respective > micro-modules though. > > [1] https://github.com/apache/solr-site/pull/152 > > Vladimir >
