commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Julius Davies <>
Subject Re: [codec] Moving on to codec 2.0
Date Thu, 31 Mar 2011 19:23:46 GMT
On Wed, Mar 30, 2011 at 4:28 PM, sebb <> wrote:
> On 31 March 2011 00:17, Jochen Wiedmann <> wrote:
>> On Wed, Mar 30, 2011 at 7:04 PM, sebb <> wrote:
>>> But does the API have to change, or could these additional features be
>>> supported by adding new methods and classes?
>> Not necessarily. But my point is that codec is in a state where
>> breaking the API will make work just easier. So why not take the
>> opportunity?
> Because making work easier for a few developers has to be balanced
> against making more work for lots of users.

I'm confused.  We support streaming for Base64 since codec-1.4 (and
now Base32 since codec-1.5).  You committed the Base64InputStream
patch, Jochen!

Is there other streaming you would like to see in commons-codec?

As for a 2.0 branch, even though the numbering (2.0) implies a break
with reverse-compatibility, I still urge us to hesitate before
breaking drop in reverse-compatibility.  I agree with Sebb in this
case.  I think strong drop in reverse-compatibility is particularly
welcome in cases like commons-codec:  small, foundational,
zero-dependency libraries, that are used everywhere!

As for Java 5.0, sure go for it.  Doesn't really benefit commons-codec
that much, but doesn't hurt, either.

As for JUnit 4.0, yes!  Doesn't hurt any end users.


Julius Davies
250-592-2284 (Home)

$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n

To unsubscribe, e-mail:
For additional commands, e-mail:

View raw message