Well it is not white or black, there are a ton of cases killing commons is good - thinking to EE cases where it was leading to a ton of conflict (framework vs final app). Now at app level keeping it like that is the sanest and easiest for end user. So status quo sounds like the more consistent and better for everyone IMHO.
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 mer. 5 nov. 2025 à 02:27, Gary Gregory <[email protected]> a écrit : > It appears Vladimir is on a mission of "killing commons" ... > https://x.com/VladimirSitnikv/status/1985345749828223251 > > That's lovely. > > Gary > > > On Sat, Nov 1, 2025, 17:04 Phil Steitz <[email protected]> wrote: > > > On Fri, Oct 31, 2025 at 7:30 AM Gary Gregory <[email protected]> > > wrote: > > > > > On Fri, Oct 31, 2025, 10:03 Vladimir Sitnikov < > > [email protected] > > > > > > > wrote: > > > > > > > >it could be done as a fork > > > > > > > > That is fair. Everything could be done as a fork. > > > > > > > > On the other hand, since this proposal requires changes to both Maven > > > > coordinates and Java package, the change could be implemented > > > > right within the current commons-lang3 with full backward > > compatibility. > > > > > > > > For instance, the current commons-lang3 is 3.19.0, so > > > commons-stringutils3 > > > > could be > > > > published as 3.20.0 along with all the other lang3 artifacts. > > > > > > > > Do you have strong objections to doing the proposal in commons-lang3? > > > > > > > > > > As I stated earlier, I am -1 to making this mess. > > > > > > > I agree with Gary on this. I have one comment. We have often referred > to > > components like [lang]. [collections], [io], [pool] as "base" components. > > We know these things often nest deeply in the dependency hierarchy of > user > > applications. That is why we have traditionally been conservative about > 0) > > adding dependencies to them 1) bloating their scope. Instead of chopping > > them up into little pieces, IMO we are better off relentlessly pruning / > > preventing bloat in the base components. > > > > Phil > > > > > > > > Gary > > > > > > > > > > > Vladimir > > > > > > > > > >
