Hello,
I don’t think a new shared library for HexFormat is a good idea here and
removing codec with a simple code inline would be my preference as well. Do we
really want to maintain a new lib for code which hasn’t changed in ages as it
has a trivial specification.
Maybe to add another datapoint, with Java17 you can use the HexFornat utility
and remove that inlined helper.
Gruß
Bernd
Gilles Sadowski wrote on 28. Oct 2024 14:30 (GMT +01:00):
> Hi.
>
> Le lun. 28 oct. 2024 à 13:38, Emmanuel Bourg <ebo...@apache.org> a écrit
> :
>>
>> Le 26/10/2024 à 20:32, Elliotte Rusty Harold a écrit :
>>
>> > That's exactly backwards. Code changes have to be technically
>> > justified. The responsibility is on the proposer, not the vetoer, to
>> > demonstrate that the change os worthwhile. Code changes are not
>> > accepted by default unless there's good and valid reason for them. If
>> > you can't get even one committer to +1 a PR thgen it doesn't meet the
>> > threshold for merging.
>>
>> It goes both ways, you can't veto without a good reason either. "I don't
>> like it" is definitely not one.
>>
>> It looks like I have to explain in more details the change, so here it
>> is:
>>
>> When I implemented the plist configuration in 2005 [1] I needed a Base64
>> and an hex encoder/decoder. Base64 isn't exactly trivial to implement
>> and Commons Codec already has one, so I imported the dependency.
>>
>> The inflation of dependencies was seen as a concern, the plist
>> configuration initially used Commons Digester which was eventually
>> replaced by pure SAX code in 2007 [2], Commons Collections was also used
>> and got removed in 2014 [3]. Some dependencies were made optional to
>> reduce the amount of dependencies pulled [4], but this made an awkward
>> user experience where unsuspecting users would get a
>> ClassNotFoundException when trying to use the plist configurations.
>>
>> Java 8 was released in 2014 with a long awaited Base64 implementation,
>> and Commons Configuration moved to Java 8 in 2018. I've updated the code
>> last week to use java.util.Base64 instead of Commons Codec [5].
>
> Up to here, I don't think that anyone would dispute that it is an
> overall improvement (more code reuse, less maintenance).
>
>> At this
>> point Commons Codec was only retained for encoding/decoding hexadecimal
>> values. Commons Codec weighs 360KB and must be added manually to the
>> classpath, encoding/decoding hexadecimal is trivially handled by ~20
>> lines of code, so dropping the dependency was the obvious choice to me
>> and in the spirit of the previous dependency removals.
>
> The last part involves the trade-off between "code reuse" and
> "dependency".
> 20 lines is small, sure, but every "bloat" has always started small; then
> the
> same argument applied for every new small bit of code: Not worth adding a
> dependency).
>
> So this circles back to the proposal in the thread with "Subject:"
> Usage of (Commons) dependencies
> That is: _If_ we had a ("very low-level") module that provides the 20
> lines
> needed by [Configuration] and [Lang], they could both depend on it, with
> almost no overhead or additional risks: No undue dependency (Emmanuel's
> point), potential fixes would be implemented once (Gary's point).
>
> We could then "manage" this via JIRA:
> 1. Open a report stating the need for the "very low-level" module and its
> scope (i.e. the list of features, such as the "20 lines" referred to
> here).
> 2. Open a JIRA sub-task: Replace the "20 lines" once the module is
> released.
> 3. Add a comment around the "20 lines" with a reference to the sub-task.
>
> How does that sound?
>
> Regards,
> Gilles
>
>
>
>>
>> Emmanuel Bourg
>>
>> [1]
>> https://github.com/apache/commons-configuration/commit/02f66818#diff-a8d5e2a5cbeb500e59aca88e0613283c57d530c6df7630555d5a08bc5c3a660fR258
>> [2] https://github.com/apache/commons-configuration/commit/8b26e6e6
>> [3] https://github.com/apache/commons-configuration/commit/25490ca9
>> [4] https://github.com/apache/commons-configuration/commit/63776cc0
>> [5] https://github.com/apache/commons-configuration/commit/7b434dbd
>>
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
> For additional commands, e-mail: dev-h...@commons.apache.org
>
>
Gruß
Bernd
—
https://bernd.eckenfels.net
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
