On 15/06/2013 16:39, Christopher Schultz wrote:
> All,
>
> While looking into a patch for BasicRealm, I noticed that there are two
> classes that convert byte[] to a hex-encoded string (e.g. byte[] { 1, 2,
> a, b ] -> "12ab"): HexUtils and MD5Encoder.
That isn't what those methods do. There are 2 output characters for each
input byte.
> MD5Encoder only has a single method (encode) and it does exactly what
> HexUtils.toHexString does, except that it only works for exactly 16-byte
> arrays.
Agreed.
> I haven't actually written any performance tests, but looking at the
> code it seems that HexUtils.toHexString would execute slightly faster
> for a 16-byte array because of repeated integer multiplication in the loop.
I'd want to see some hard numbers on both methods before making are
decisions based on performance.
> Is there a reason for MD5Encoder to exist? It appears only to be used in
> the following classes:
>
> RealmBase
> DigestAuthenticator
> WebdavServlet
The check that the input is exactly 16 bytes might be a useful one in
that it confirms other code is behaving as expected.
I just took a look and in every case it is converting the output of a
call to MessageDigest.digest() for an MD5 digest. I don't see a need to
confirm that the JRE is behaving as expected here.
> Although I suppose a specialty 16-byte-only method might be written to
> be slightly faster than the general-purpose HexUtils.toHexString method,
> I'm not sure it's worth having a separate class/method to do it.
>
> Any objections to using HexUtils.toHexString uniformly and removing the
> MD5Encoder class entirely?
In Tomcat 8, no objections here.
In Tomcat 7, MD5Encoder will have to remain but be deprecated.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
