Hello Gilles, Thank you for your thoughtful message. You raise some interesting points. I've tried to address some and clarify others below.
On Fri, Oct 25, 2024 at 8:46 AM Gilles Sadowski <gillese...@gmail.com> wrote: > Hi Gary. > > Le ven. 25 oct. 2024 à 13:48, Gary Gregory <garydgreg...@gmail.com> a > écrit : > > > > >The recent flip-flopping changes in [CLI] and [Configuration] > > > > [CLI] has zero runtime dependencies. Are test dependencies an issue from > > your POV? > > A few days ago, I think I saw another change which you questioned. > I did not question the change, I vetoed the commits with a -1. I expect the author to revert those changes. > Sorry for the confusion if it was not in [CLI]... > It was in Compress. > > > > > > try to raise the question of when and how Commons components should > > depend on other Commons components. > > > > Some components are low-level like Lang and IO, while others sit higher, > > like VFS, Configuration, and Compress. > > Exactly, it is that hierarchy which I'd like to have consensus about, > while, in practice, everyone here has its own. Indeed ;-) In my view, Compress is a higher-level library since it provides an SPI abstraction over archiving and compression using implementation through third-party libraries. Configuration is also a higher-level library that provides an SPI and different implementations, using third-party libraries like Spring. > > > > > I think it is normal for higher-level components to reuse lower-level > > building blocks, especially within our ecosystem. > > I agree, but it is a fact that any and all additions of a dependency > to a (perceived) low-level component raised quite strong opposition. > [A decade and some ago, the usual answer to such requests was: > Do _not_ add; use the "shade" plugin instead.] > I hope people stop giving that advice. I always tell people to never shade, it makes it impossible to pick up a bug fix, much less a CVE fix. Talk about making JAR files bigger! ;-) Look at the mess some tooling creates by shading in ASM: It's impossible to use a new JDK until that JAR re-shades (I know, not a word) and releases a new version. What a nightmare. I think it's the same with in-lining another JAR's code. Both are anti-patterns in my book. > > > We also go > > outside Commons as well, for example: Compress depends on many > third-party > > libraries to do its archiving and compression work: Zstd, Brotfi, and XZ. > > > > Lang has been justified since its inception as code low-level enough it > > could have been in the JDK itself. > > Sure but, like several other components, it has grown a lot since its > inception, and as Emmanuel points out (IIUC), it may have become > too much of a bloat for the benefit of saving a few keystrokes (and, > sometimes even not, if the JDK equivalent would be shorter). > > > I include Lang in my projects and > > Some developers do not. > [That is not to say that it isn't useful to many of them.] > > > consider it part of the Java vocabulary. > > Strictly speaking it is not. > I started that sentence with "I"; I'm making a statement about what I do and think, not what anyone else does and thinks. > Also, I don't think that this consideration has any bearing on the > subject of this thread, unless you advocate that all components > should depend on [Lang] in preference over the JDK-equivalent > functionality (?). [Obviously, many people would object to this.] > Please see my previous comment; I'm not advocating that for Commons as a rule. > > On the one example I gave: Is it polemical to deprecate Commons > functionality that has made its way into the JDK in favour of the > latter? > I think there is confusion here, this type of functionality is already deprecated, for example, org.apache.commons.lang3.ObjectUtils.equals(Object, Object) is deprecated. I don't see a reference to a specific example in this thread. > > > > Over the years, features have crept into Lang that we now have deprecated > > and moved to Text. > > I know; I was there, and (IIRC) this (good IMO) move met some > resistance. > > [FTR, my suggested move of modularizing Commons Math was > met with fierce resistance by some, ending up in a fork (where > the new codebase was actually... modularized).] > FWIW, in the future, I'd like to see Compress split into modules so that all dependencies can be non-optional, no surprises about missing JARs. I hope the above is helpful, thank you for reading through it all, Gary > > I am mindful of what belongs where. > > I didn't say otherwise. > [You may remember that I also advocate(d) in order for a few > things to be shuffled around to a more appropriate (IMHO) > location...] > > However, there possibly are pathways that may satisfy everyone. > Namely: Modularize any component that is composed of different > functionalities and/or has grown "too large" (stricter definition TBD). > Modularization has all sorts of benefits (security-wise, too) and is > among the current "best practices". > > [As an aside, it is also a good "first project" for would-be contributors > (because it does not require a deep understanding of the algorithms > implemented, only of their interdependence, and at every point, it is > easy to ensure that no functionality is lost).] > > Regards, > Gilles > > > > > HTH, > > Gary > > > > On Fri, Oct 25, 2024 at 7:16 AM Gilles Sadowski <gillese...@gmail.com> > > wrote: > > > > > Hi. > > > > > > The recent flip-flopping changes in [CLI] and [Configuration] > > > made me wonder if I should, again, try to raise the question > > > of when and how Commons components should depend on > > > other Commons components. > > > > > > Previous attempts (hinting at "when" and "how") have been > > > ignored, but shouldn't we at least have a consensus, backed > > > with a few hard rules? > > > One such rule could be that if the minimum required JDK > > > provides functionality that is also implemented in a Commons > > > component, that component should > > > 1. call the JDK equivalent functionality, > > > 2. deprecate its (redundant) implementation > > > in order to encourage developers to use the JDK instead, and > > > allow us to trim down the Commons "bloat". > > > > > > WDYT? > > > > > > Regards, > > > Gilles > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
