On 14 August 2011 03:02, sebb <seb...@gmail.com> wrote: > On 12 August 2011 20:56, Gary Gregory <garydgreg...@gmail.com> wrote: >> Hello All: >> >> For a first cut at generics support in Codec, please checkout the >> branch >> https://svn.apache.org/repos/asf/commons/proper/codec/branches/generics >> >> I wrote a migration guide in the root of the project called >> Codec2-Migration.htm. >> >> Let's discuss. > > The original code used Encoder and Decoder interfaces which operated > on Object, and extended these with > BinaryEncoder (byte[]) > StringEncoder(String) > > So for example StringEncoder classes need to implement > encode(Object) : Object > encode(String) : String > > As far as I can tell, those interfaces cannot be directly generified, > because type erasure causes a method signature clash. > So adding generics here means breaking binary compatibilty. > > Question is, what does adding generics to these interfaces actually provide? > Would it not be just as effective to deprecate Decoder and Encoder, > and code can then use either BinaryEncoder or StringEncoder (etc)? > > At the moment test code is of the form: > > Encoder enc = new Base64(); > ... > byte [] ba = (byte[]) enc.encode(binary)); // unchecked cast > > However this could be written: > > BinaryEncoder enc = new Base64(); > ... > byte [] ba = enc.encode(binary)); // no cast needed >
Note that the Encoder/Decoder interfaces do not _require_ generification. The only non-generified part of trunk is StringEncoderComparator. This appears from the name as if it compares Strings, but in fact it compares Objects in the current code. Making it implement Comparator<Object> fixes the warning without compromising binary (or source?) compatibility. The StringEncoders generate an EncoderException if the parameter is not a String. This does mean that comparison with a non-String will return 0 (equal) which is rather strange, but that is the way that the code current works. So what I suggest is - let's release Codec as a binary compatible implementation, at least for now. If we do decide to break binary compatibility in a later release, then I think the Encoder/Decoder hierarchy needs a bit more work. For example, several of the new xxxCodec classes only implement Decoder, not Encoder; this is because of the need to avoid erasure clashes. I just wonder if trying to use generics here is not causing more problems than it solves? It's not as if there are lots of different types that are used here - only String, byte[] and char[]. Perhaps we could just add CharEncoder/CharDecoder interfaces instead? >> I plan on not touching trunk until the generics code is flushed out >> and brought back to trunk. >> >> Thank you, >> Gary >> >> -- >> http://garygregory.wordpress.com/ >> http://garygregory.com/ >> http://people.apache.org/~ggregory/ >> http://twitter.com/GaryGregory >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
