> > Reusing a library allows the host component to focus more on its business > than having to draw attention from it. The benefits far outweigh any > drawbacks in my view. >
At least for commons-compress, I don't agree with this view. I don't see enough benefit, and I just feel that commons-compress is too big and bloated right now. We use commons-compress in a small program[1] of about 5MiB. I have decided to stay on commons-compress 1.25.0 due to size. Then I will pick up the fork[2] I developed earlier to split and modularize commons-compress, which will keep our program compact. Since I have decided to maintain my fork, I don't want to express my opposition too much. I just wanted to present our decision here as an example of how this could indeed discourage some people from choosing commons-compress. Glavo [1]: https://github.com/HMCL-dev/HMCL [2]: https://github.com/Glavo/kala-compress On Sat, Nov 2, 2024 at 6:27 AM Gary Gregory <garydgreg...@gmail.com> wrote: > Emanuel and all, > > I see dependencies here and in other libraries a natural aspect of Java > development in that it helps reuse proven solutions, where bug fixes and > implementations are improved, while externalizing that cost to the library > which is otherwise born by the host code base. > > Reusing a library allows the host component to focus more on its business > than having to draw attention from it. The benefits far outweigh any > drawbacks in my view. > > In addition, reuse makes the code easier to read, easier to maintain, and > easier to contribute to without getting lost in the weeds of code that's > been copy pasted all over the place. > > A mention was made of the size on disk of jar files, this feels immaterial > when a JVM is now very good at only loading the classes it needs out of a > jar file. > > HTH, > Gary > > On Fri, Nov 1, 2024, 5:53 PM Emmanuel Bourg <ebo...@apache.org> wrote: > > > Le 01/11/2024 à 20:04, Gary Gregory a écrit : > > > Emanuel, > > > > > > -1 you are duplicating code (again) as a one-off while adding the > clutter > > > of a ternary expression (and unnecessary parentheses). It is much > cleaner > > > to use canonical-like code from our low level Commons IO library we > > already > > > use elsewhere. There is no benefit to expanding this API call. This > > change > > > forces the reader to parse out the ternary expreasion, the how, instead > > of > > > focusing on the what of the method. > > > > Gary, > > > > There are 4 other ternary expressions in the ZipFile class, 90+ in the > > zip package and over 270 in the whole code, not counting the unit tests. > > Some of these expressions were added by you this year, in commits > > labeled "Use ternary expression" [1][2][3]. So I conclude that it's > > acceptable to use this syntax. > > > > The extra parentheses improve the readability in my opinion, but I don't > > mind removing them. > > > > Expanding the API call is necessary to remove the undesired dependency > > on Commons IO. > > > > Emmanuel Bourg > > > > [1] https://github.com/apache/commons-compress/commit/bbe6fd9a > > [2] https://github.com/apache/commons-compress/commit/aa71cb93 > > [3] https://github.com/apache/commons-compress/commit/b3e34e89 > > > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > >
