commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Thomas Neidhart <thomas.neidh...@gmail.com>
Subject Re: [Codec] Next Commons-Codec release?
Date Mon, 20 Aug 2012 20:39:16 GMT
On 08/17/2012 09:15 PM, Gary Gregory wrote:
> On Fri, Aug 17, 2012 at 2:49 PM, Thomas Neidhart
> <thomas.neidhart@gmail.com>wrote:
> 
>> On 08/16/2012 01:37 PM, Gary Gregory wrote:
>>> (edited message subject to add "[Codec]" prefix)
>>>
>>> Yes, there is a certain amount of rain dancing, keeping of fingers
>> crossed,
>>> and cussing involved when cutting releasing, and it's fallen off my radar
>>> to due other priorities.
>>>
>>> Is the ML content by the state of the new Crypt classes in
>>> org.apache.commons.codec.digest?
>>
>> I did some javadoc cleanup of the package.
>>
> 
> Thank you TN!
> 
> 
>>
>> (btw. I find non-closing <p> tags on a separate line the most readable
>> solution as outlined in the javadoc tutorial
>>
>> http://www.oracle.com/technetwork/java/javase/documentation/index-137868.html
>>
>> what do other people think about it?)
>>
> 
> It is nice and clear. I personally do not use the style but am willing to
> change ;) Since we all know that Javadoc is [X?]HTML-lite, using "broken"
> XHTML feels odd (unbalanced tags). I might be speaking from fuzzy memory
> but I vaguely recall odd things happening in combination with opening,
> closing and nesting some tags. I guess we could use <p> and deal with
> special cases when they come up.
> 
> 
>> What is a bit odd is that the methods throw Exception although it's not
>> needed at all (e.g. UnixCrypt)
> 
> 
> I see that with org.apache.commons.codec.digest.UnixCrypt.crypt(String)...
> nasty! Good catch!
> 
> 
>> or could be constrained to
>> NoSuchAlgorithmException (e.g. in Md5Crypt).
>>
> 
> Yes, more nastiness.
> 
> The exceptions might have been there with the though of making all of these
> classes implement a common interface. I do not seen the need for that ATM.
> We can always add it later if needed.
> 
> 
>>
>> Javadoc does not yet mention the exceptions too (but I can fix that).
>>
> 
> 
> Yes, please fix it all up as much as you can.

ok done.

Regarding the TODO in the B64 class:

I do not think that the existing Base64 implementation can be reused, as
the cipher text encoded by crypt is only "in a form of" Base64.

Actually the encoding alphabet is slightly different ('.' instead of
'+') and also the encoding itself is not the same.

Thomas

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


Mime
View raw message