commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From sebb <seb...@gmail.com>
Subject Re: [codec] regression in 1.4
Date Wed, 02 Dec 2009 19:18:17 GMT
On 02/12/2009, Mat Booth <apache@matbooth.co.uk> wrote:
> 2009/12/2 sebb <sebbaz@gmail.com>:
>
> > On 02/12/2009, Gary Gregory <GGregory@seagullsoftware.com> wrote:
>  >> What about making the offending class configurable for 1.3 or 1.4 behavior?
>  >
>  > How? System property? That's not usually advisable for a library.
>  >
>  >>  The issue becomes which should be the default behavior...
>  >>
>  >>  Should the default behavior be the one closest to the B64 spec?
>  >
>  > As far as I can tell
>  >
>  > new Base64(0).encode()
>  > is the same as
>  > Base64.encodeBas64()
>  >
>  > If the parameterless ctor were changed to set the line length to 0,
>  > then users wishing to have the existing behaviour of that ctor would
>  > need to use new Base64(false).
>  >
>
>
> Hi all,
>
>  I've only just found this thread. As I said on the ticket, I'd be
>  content if you can get the old behaviour with that method (which I now
>  know is possible by passing 0, thanks for that Sebb) and behavioural
>  changes such as this were documented in the release notes.
>
>  If these behavioural changes are documented some place, then I can
>  talk to the consumers of commons-codec in Fedora and make sure they
>  are doing the Right Thing and submit patches upstream where necessary.

[Perhaps it's stating the obvious, but]

If they are currently doing

new Base64().encode()

and expecting the old (1.3) behaviour, then they can of course use the
static encodeBase64() method instead. This will work with 1.3 and 1.4
and 1.4.1 (and hopefully forever)

I guess we should add a test that checks that the static encode method
does not chunk.
[There does not seem to be such a test at present] I'll add this to JIRA.

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

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


Mime
View raw message