On Sat, 2 Nov 2024 at 09:28, sebb <seb...@gmail.com> wrote: > On Sat, 2 Nov 2024 at 09:11, Tushar Kapila <tgkp...@gmail.com> wrote: > > > > If you only want code that is used, you can use an obfuscator? Using > > dependencies is the way to go, IMHO. Keep concerns tight. Change in one > > place in case of bugs and vulnerabilities > > Again, that only applies where there is bunch of code to replace. > Code re-use has to be balanced against the extra resource and maintenance > costs. > > Remember that when a vulnerability is found in a component, all users > have to check whether their project is affected. And even if their > project does not use the vulnerable code, they will still have to > upgrade be prepared to deal with the inevitable follow-up. > > Dependencies have both advantages and disadvantages.
+1 Also, historically there used to be few “commons wide” rules with the people who worked on a component deciding how that was done. I haven’t checked, but I believe Emmanuel has been the main person working on Configuration for a long time and therefore he should have the biggest say in its development rather than imposing rules from those of us not involved. Niall > > > > On Sat, 2 Nov 2024, 04:13 sebb, <seb...@gmail.com> wrote: > > > > > On Fri, 1 Nov 2024 at 22:27, 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. > > > > > > That would be a reasonable argument if a substantial amount of code > > > were involved. > > > That is clearly not the case here. > > > > > > > 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. > > > > > > That is not the case here. > > > > > > > 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 > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > > > For additional commands, e-mail: dev-h...@commons.apache.org > > > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > >
