+1 to sebb.
Am 2. November 2024 10:27:39 MEZ schrieb sebb <seb...@gmail.com>: >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. > > >> 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 >
