sebb wrote: > On 18 May 2016 at 17:55, Gary Gregory <garydgreg...@gmail.com> wrote: >> On Mon, May 16, 2016 at 5:33 PM, sebb <seb...@gmail.com> wrote: >> >>> On 17 May 2016 at 00:05, Gary Gregory <garydgreg...@gmail.com> wrote: >>> > On Mon, May 16, 2016 at 3:50 PM, sebb <seb...@gmail.com> wrote: >>> > >>> >> On 16 May 2016 at 21:47, <ggreg...@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-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
