Hi all,
On 16.11.2024 14:45, Emmanuel Bourg wrote:
I don't understand your stubbornness on this subject, Commons Compress
had zero dependencies for over 10 years, the general sentiment from
the recent discussions seems to point toward avoiding such a
dependency bloat, your change was never discussed on the list, it
broke Commons Compress (COMPRESS-666 [1], with a highly ironic bug
number), and the project was even forked due to this issue.
I highly appreciate your dedication to maintain the Apache Commons
projects, but you've made an error here. It happens, that's not a big
deal, but please listen to the community.
I am a big fan of code reuse, but I am with Emmanuel on this one: you
add a MiB of dependencies to Commons Compress only to use a couple of
one-liners. Commons Compress only uses the following Commons Lang methods:
1. `ArrayFill.fill()` a total of 6 times, each time with a non-null
argument. What future advantage can this possibly give over Arrays.fill?
2. `SystemProperties.getOsName()` a total of 2 times. Since
SecurityManager is deprecated and the "os.name" property is a required
property on all JVMs, what is the advantage of this method over
`System.getProperty("os.name")`?
3. `FieldUtils` is used once in the Harmony code.
All rules are not applicable to all cases. In this case I would say that
adding 650 KiB of dependencies for a dozen simple method calls, is not
worth the effort.
On 16.11.2024 17:43, Gary Gregory wrote:
Shading is the mother of anti-patterns and a nightmare. IMO, it should only
be used as a workaround in the most dire situations.
Shading the entire Commons Lang3 library doesn't make sense, but shading
`ArrayFill`, `SystemProperties` and `FieldUtils` would be a good
compromise between code reuse and number of dependencies.
Unfortunately that is impossible, because `SystemProperties` and
`FieldUtils` depend on half of Commons Lang 3. `ArrayFill` on the other
hand is a standalone class.
Piotr
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
