commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jörg Schaible <joerg.schai...@gmx.de>
Subject Re: svn commit: r1744132 - in /commons/proper/codec/trunk/src: changes/ main/java/org/apache/commons/codec/digest/ test/java/org/apache/commons/codec/digest/
Date Thu, 19 May 2016 07:53:23 GMT
sebb wrote:

> On 18 May 2016 at 17:55, Gary Gregory <garydgregory@gmail.com> wrote:
>> On Mon, May 16, 2016 at 5:33 PM, sebb <sebbaz@gmail.com> wrote:
>>
>>> On 17 May 2016 at 00:05, Gary Gregory <garydgregory@gmail.com> wrote:
>>> > On Mon, May 16, 2016 at 3:50 PM, sebb <sebbaz@gmail.com> wrote:
>>> >
>>> >> On 16 May 2016 at 21:47,  <ggregory@apache.org> wrote:
>>> >> > Author: ggregory
>>> >> > Date: Mon May 16 20:47:47 2016
>>> >> > New Revision: 1744132
>>> >> >
>>> >> > URL: http://svn.apache.org/viewvc?rev=1744132&view=rev
>>> >> > Log:
>>> >> > [CODEC-218] Refactor HmacUtils methods into the HmacAlgorithms
>>> >> > [enum.
>>> >>
>>> >> -1
>>> >>
>>> >> I don't see the point in deprecating perfectly good methods and
>>> >> forcing users to update their source.
>>> >>
>>> >
>>> > Because when the next major version of [codec] comes out we can remove
>>> > deprecated methods, which are clearly not OO. Using the enum (yes, it
>>> could
>>> > be a class too) is OO, cleaner, leaner, and clearer IMO.
>>>
>>> I suppose it's possible that using an enum instead of multiple
>>> HmacUtils methods will require less code.
>>> But it would be even less code to drop all the specific HmacUtils
>>> methods and replace with string versions.
>>>
>>> It's not cleaner because the enum cannot replace all the possible Hmac
>>> instances.
>>> The String interfaces will still be needed.
>>>
>>> And it's not clearer because there will be two different ways of using
>>> the methods.
>>> One which works with every algorithm and the enum style which only
>>> works for some algos.
>>>
>>> > I suppose that in a new major version we can do whatever we want with
>>> APIs,
>>> > so we strictly do not need to deprecate. Is that what you'd rather
>>> > see?
>>>
>>> No, because non-standard Hmac methods will still need to use Strings.
>>>
>>> Enums only make sense when they fully "enum"erate the parameter range.
>>>
>>
>> So it would make sense to define a SunMessageDigestAlgorithm enum per
>> 
https://docs.oracle.com/javase/6/docs/technotes/guides/security/SunProviders.html
>> for
>>
>> MD2
>> MD5
>> SHA-1
>> SHA-256
>> SHA-384
>> SHA-512
>>
>> It looks like IBM supports the same in Java 7:
>> 
https://www.ibm.com/support/knowledgecenter/SSYKE2_7.0.0/com.ibm.java.security.component.71.doc/security-component/JceDocs/architecture.html%23Architecture__j2sdkenginelist?lang=en
>>
> 
> No, because the above list would not fully enumerate all the possible
> algorithm names.
> 
> There would still need to be generic methods for algorithms that are
> either non-standard or which were not standard when the code was
> written.
> 
> An enum is designed for situations where it encompasses ALL the possible
> values. Otherwise, the constant approach is better.

+1

- Jörg



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org


Mime
View raw message