You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by Gary Gregory <ga...@gmail.com> on 2012/03/06 15:11:40 UTC
[codec] What version should implement a behavior change?
Hello All,
We have a patch for
[CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
but it is a change in behavior. In order to avoid a potential nasty
surprise for call sites, we need to decide when something like this can be
done.
In 1.6 and before, we had garbage-in-garbage-out behavior. With the patch,
you get an exception.
1) Is the proposed patch acceptable in the sense that we do not whant GIGO?
Should there instead be a validate method for example?
2) What kind of version is this change in behavior acceptable? Maintenance
(1.6.1), Minor (1.7) or Major (2.0)?
Thank you,
Gary
[CODEC-134] Base32 would decode some invalid Base32 encoded string into
arbitrary value
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [codec] What version should implement a behavior change?
Posted by sebb <se...@gmail.com>.
On 9 March 2012 19:15, Gary Gregory <ga...@gmail.com> wrote:
> On Fri, Mar 9, 2012 at 2:12 PM, sebb <se...@gmail.com> wrote:
>
>> On 9 March 2012 19:02, Gary Gregory <ga...@gmail.com> wrote:
>> > Ok, so now, it look like the next release will be 1.7 and not 1.6.1
>> because
>> > of the addition of new Nysiis codec.
>>
>> +1, it's significant new code.
>>
>> > Would [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>] be
>> OK
>> > in 1.7 or should it be for a 2.0?
>>
>> Depends on how it's implemented - does it change the behaviour for
>> end-users?
>>
>
> If implemented [CODEC-134] throws an exception on garbage input. The
> current behavior is garbage-in-garbage-out.
>
> There is an argument for creating a separate "strict" codec...
Yes
Base64Strict would need to have the same public ctors and methods as Base64.
Unfortunately, there are a lot of static methods which create default
instances of Base64().
I suspect it may be impossible to share the encode/decode static
methods, but the other static methods don't create instances, which
would reduce duplication somewhat.
> Gary
>
>
>>
>> > Gary
>> >
>> > On Thu, Mar 8, 2012 at 11:14 AM, Gary Gregory <garydgregory@gmail.com
>> >wrote:
>> >
>> >> Ok, so where are we on all this and specifically [CODEC-134<
>> https://issues.apache.org/jira/browse/CODEC-134>
>> >> ]?
>> >>
>> >> It seems that [CODEC-134 <
>> https://issues.apache.org/jira/browse/CODEC-134>],
>> >> if applied should be for a 1.x, not a 1.x.y because of the change of
>> >> behavior.
>> >>
>> >> If it is not applied, then we need... new classes or more behavior in
>> the
>> >> current class tunnable with something (constructor, config object)
>> >>
>> >> We also need someone to implement it...
>> >>
>> >> Thoughts?
>> >>
>> >> Gary
>> >>
>> >>
>> >> On Tue, Mar 6, 2012 at 10:35 PM, Julius Davies <juliusdavies@gmail.com
>> >wrote:
>> >>
>> >>> Maybe time to add a Base64(int mode) constructor! Yay, room for 32
>> >>> true/false bitwise fields!
>> >>>
>> >>> Sorry I can't respond inline to the email like a normal person. Bad
>> >>> habit.
>> >>>
>> >>> yours,
>> >>>
>> >>> Julius
>> >>>
>> >>> On Tue, Mar 6, 2012 at 11:40 AM, sebb <se...@gmail.com> wrote:
>> >>> > On 6 March 2012 19:33, Gary Gregory <ga...@gmail.com> wrote:
>> >>> >> What about passing in a "boolean strict" to the constructor of the
>> >>> codecs?
>> >>> >
>> >>> > What does strict mean? See my comment:
>> >>> >
>> >>> > https://issues.apache.org/jira/browse/CODEC-95#comment-12986951
>> >>> >
>> >>> > If we do add another parameter (which is not popular with others), at
>> >>> > least let's make sure it's the last one we need to add.
>> >>> >
>> >>> >> Gary
>> >>> >>
>> >>> >> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <
>> juliusdavies@gmail.com
>> >>> >wrote:
>> >>> >>
>> >>> >>> Hi,
>> >>> >>>
>> >>> >>>
>> >>> >>> CODEC-95 talked about these issues, too (in this case with Base64).
>> >>> >>>
>> >>> >>> https://issues.apache.org/jira/browse/CODEC-95
>> >>> >>>
>> >>> >>>
>> >>> >>> Personally, I would prefer to see some new "strict" classes
>> defined,
>> >>> >>> and to preserve the garbage-in/garbage-out behaviour on the current
>> >>> >>> existing classes.
>> >>> >>>
>> >>> >>>
>> >>> >>> Here are the new classes I would like to see:
>> >>> >>>
>> >>> >>>
>> >>> >>> Base32Strict
>> >>> >>> Base32StrictInputStream
>> >>> >>> Base32StrictOutputStream
>> >>> >>> Base64Strict
>> >>> >>> Base64StrictInputStream
>> >>> >>> Base64StrictOutputStream
>> >>> >>>
>> >>> >>>
>> >>> >>> At the same time it does make the API a bit more intimidating and
>> >>> >>> harder to learn, but I think striving for drop-in
>> >>> >>> reverse-compatibility of the existing classes is desirable.
>> >>> >>>
>> >>> >>>
>> >>> >>> yours,
>> >>> >>>
>> >>> >>> Julius
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <
>> garydgregory@gmail.com>
>> >>> >>> wrote:
>> >>> >>> > Hello All,
>> >>> >>> >
>> >>> >>> > We have a patch for
>> >>> >>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
>> >>> >>> > but it is a change in behavior. In order to avoid a potential
>> nasty
>> >>> >>> > surprise for call sites, we need to decide when something like
>> this
>> >>> can
>> >>> >>> be
>> >>> >>> > done.
>> >>> >>> >
>> >>> >>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With
>> the
>> >>> >>> patch,
>> >>> >>> > you get an exception.
>> >>> >>> >
>> >>> >>> > 1) Is the proposed patch acceptable in the sense that we do not
>> >>> whant
>> >>> >>> GIGO?
>> >>> >>> > Should there instead be a validate method for example?
>> >>> >>> >
>> >>> >>> > 2) What kind of version is this change in behavior acceptable?
>> >>> >>> Maintenance
>> >>> >>> > (1.6.1), Minor (1.7) or Major (2.0)?
>> >>> >>> >
>> >>> >>> > Thank you,
>> >>> >>> > Gary
>> >>> >>> >
>> >>> >>> > [CODEC-134] Base32 would decode some invalid Base32 encoded
>> string
>> >>> into
>> >>> >>> > arbitrary value
>> >>> >>> >
>> >>> >>> > --
>> >>> >>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>> >>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>
>> >>> http://bit.ly/ECvg0
>> >>> >>> > Spring Batch in Action: <http://s.apache.org/HOq>
>> >>> http://bit.ly/bqpbCK
>> >>> >>> > Blog: http://garygregory.wordpress.com
>> >>> >>> > Home: http://garygregory.com/
>> >>> >>> > Tweet! http://twitter.com/GaryGregory
>> >>> >>>
>> >>> >>>
>> >>> >>>
>> >>> >>> --
>> >>> >>> yours,
>> >>> >>>
>> >>> >>> Julius Davies
>> >>> >>> 604-222-3310 (Home)
>> >>> >>>
>> >>> >>> $ sudo apt-get install cowsay
>> >>> >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
>> >>> >>> http://juliusdavies.ca/cowsay/
>> >>> >>>
>> >>> >>>
>> ---------------------------------------------------------------------
>> >>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>> >>>
>> >>> >>>
>> >>> >>
>> >>> >>
>> >>> >> --
>> >>> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>
>> http://bit.ly/ECvg0
>> >>> >> Spring Batch in Action: <http://s.apache.org/HOq>
>> http://bit.ly/bqpbCK
>> >>> >> Blog: http://garygregory.wordpress.com
>> >>> >> Home: http://garygregory.com/
>> >>> >> Tweet! http://twitter.com/GaryGregory
>> >>> >
>> >>> > ---------------------------------------------------------------------
>> >>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >>> >
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> yours,
>> >>>
>> >>> Julius Davies
>> >>> 604-222-3310 (Home)
>> >>>
>> >>> $ sudo apt-get install cowsay
>> >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
>> >>> http://juliusdavies.ca/cowsay/
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> >>
>> >> Blog: http://garygregory.wordpress.com
>> >> Home: http://garygregory.com/
>> >> Tweet! http://twitter.com/GaryGregory
>> >>
>> >
>> >
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] What version should implement a behavior change?
Posted by Gary Gregory <ga...@gmail.com>.
On Fri, Mar 9, 2012 at 2:12 PM, sebb <se...@gmail.com> wrote:
> On 9 March 2012 19:02, Gary Gregory <ga...@gmail.com> wrote:
> > Ok, so now, it look like the next release will be 1.7 and not 1.6.1
> because
> > of the addition of new Nysiis codec.
>
> +1, it's significant new code.
>
> > Would [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>] be
> OK
> > in 1.7 or should it be for a 2.0?
>
> Depends on how it's implemented - does it change the behaviour for
> end-users?
>
If implemented [CODEC-134] throws an exception on garbage input. The
current behavior is garbage-in-garbage-out.
There is an argument for creating a separate "strict" codec...
Gary
>
> > Gary
> >
> > On Thu, Mar 8, 2012 at 11:14 AM, Gary Gregory <garydgregory@gmail.com
> >wrote:
> >
> >> Ok, so where are we on all this and specifically [CODEC-134<
> https://issues.apache.org/jira/browse/CODEC-134>
> >> ]?
> >>
> >> It seems that [CODEC-134 <
> https://issues.apache.org/jira/browse/CODEC-134>],
> >> if applied should be for a 1.x, not a 1.x.y because of the change of
> >> behavior.
> >>
> >> If it is not applied, then we need... new classes or more behavior in
> the
> >> current class tunnable with something (constructor, config object)
> >>
> >> We also need someone to implement it...
> >>
> >> Thoughts?
> >>
> >> Gary
> >>
> >>
> >> On Tue, Mar 6, 2012 at 10:35 PM, Julius Davies <juliusdavies@gmail.com
> >wrote:
> >>
> >>> Maybe time to add a Base64(int mode) constructor! Yay, room for 32
> >>> true/false bitwise fields!
> >>>
> >>> Sorry I can't respond inline to the email like a normal person. Bad
> >>> habit.
> >>>
> >>> yours,
> >>>
> >>> Julius
> >>>
> >>> On Tue, Mar 6, 2012 at 11:40 AM, sebb <se...@gmail.com> wrote:
> >>> > On 6 March 2012 19:33, Gary Gregory <ga...@gmail.com> wrote:
> >>> >> What about passing in a "boolean strict" to the constructor of the
> >>> codecs?
> >>> >
> >>> > What does strict mean? See my comment:
> >>> >
> >>> > https://issues.apache.org/jira/browse/CODEC-95#comment-12986951
> >>> >
> >>> > If we do add another parameter (which is not popular with others), at
> >>> > least let's make sure it's the last one we need to add.
> >>> >
> >>> >> Gary
> >>> >>
> >>> >> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <
> juliusdavies@gmail.com
> >>> >wrote:
> >>> >>
> >>> >>> Hi,
> >>> >>>
> >>> >>>
> >>> >>> CODEC-95 talked about these issues, too (in this case with Base64).
> >>> >>>
> >>> >>> https://issues.apache.org/jira/browse/CODEC-95
> >>> >>>
> >>> >>>
> >>> >>> Personally, I would prefer to see some new "strict" classes
> defined,
> >>> >>> and to preserve the garbage-in/garbage-out behaviour on the current
> >>> >>> existing classes.
> >>> >>>
> >>> >>>
> >>> >>> Here are the new classes I would like to see:
> >>> >>>
> >>> >>>
> >>> >>> Base32Strict
> >>> >>> Base32StrictInputStream
> >>> >>> Base32StrictOutputStream
> >>> >>> Base64Strict
> >>> >>> Base64StrictInputStream
> >>> >>> Base64StrictOutputStream
> >>> >>>
> >>> >>>
> >>> >>> At the same time it does make the API a bit more intimidating and
> >>> >>> harder to learn, but I think striving for drop-in
> >>> >>> reverse-compatibility of the existing classes is desirable.
> >>> >>>
> >>> >>>
> >>> >>> yours,
> >>> >>>
> >>> >>> Julius
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <
> garydgregory@gmail.com>
> >>> >>> wrote:
> >>> >>> > Hello All,
> >>> >>> >
> >>> >>> > We have a patch for
> >>> >>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
> >>> >>> > but it is a change in behavior. In order to avoid a potential
> nasty
> >>> >>> > surprise for call sites, we need to decide when something like
> this
> >>> can
> >>> >>> be
> >>> >>> > done.
> >>> >>> >
> >>> >>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With
> the
> >>> >>> patch,
> >>> >>> > you get an exception.
> >>> >>> >
> >>> >>> > 1) Is the proposed patch acceptable in the sense that we do not
> >>> whant
> >>> >>> GIGO?
> >>> >>> > Should there instead be a validate method for example?
> >>> >>> >
> >>> >>> > 2) What kind of version is this change in behavior acceptable?
> >>> >>> Maintenance
> >>> >>> > (1.6.1), Minor (1.7) or Major (2.0)?
> >>> >>> >
> >>> >>> > Thank you,
> >>> >>> > Gary
> >>> >>> >
> >>> >>> > [CODEC-134] Base32 would decode some invalid Base32 encoded
> string
> >>> into
> >>> >>> > arbitrary value
> >>> >>> >
> >>> >>> > --
> >>> >>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> >>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>
> >>> http://bit.ly/ECvg0
> >>> >>> > Spring Batch in Action: <http://s.apache.org/HOq>
> >>> http://bit.ly/bqpbCK
> >>> >>> > Blog: http://garygregory.wordpress.com
> >>> >>> > Home: http://garygregory.com/
> >>> >>> > Tweet! http://twitter.com/GaryGregory
> >>> >>>
> >>> >>>
> >>> >>>
> >>> >>> --
> >>> >>> yours,
> >>> >>>
> >>> >>> Julius Davies
> >>> >>> 604-222-3310 (Home)
> >>> >>>
> >>> >>> $ sudo apt-get install cowsay
> >>> >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> >>> >>> http://juliusdavies.ca/cowsay/
> >>> >>>
> >>> >>>
> ---------------------------------------------------------------------
> >>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>> >>>
> >>> >>>
> >>> >>
> >>> >>
> >>> >> --
> >>> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>
> http://bit.ly/ECvg0
> >>> >> Spring Batch in Action: <http://s.apache.org/HOq>
> http://bit.ly/bqpbCK
> >>> >> Blog: http://garygregory.wordpress.com
> >>> >> Home: http://garygregory.com/
> >>> >> Tweet! http://twitter.com/GaryGregory
> >>> >
> >>> > ---------------------------------------------------------------------
> >>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> > For additional commands, e-mail: dev-help@commons.apache.org
> >>> >
> >>>
> >>>
> >>>
> >>> --
> >>> yours,
> >>>
> >>> Julius Davies
> >>> 604-222-3310 (Home)
> >>>
> >>> $ sudo apt-get install cowsay
> >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> >>> http://juliusdavies.ca/cowsay/
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> >>
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >>
> >
> >
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [codec] What version should implement a behavior change?
Posted by sebb <se...@gmail.com>.
On 9 March 2012 19:02, Gary Gregory <ga...@gmail.com> wrote:
> Ok, so now, it look like the next release will be 1.7 and not 1.6.1 because
> of the addition of new Nysiis codec.
+1, it's significant new code.
> Would [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>] be OK
> in 1.7 or should it be for a 2.0?
Depends on how it's implemented - does it change the behaviour for end-users?
> Gary
>
> On Thu, Mar 8, 2012 at 11:14 AM, Gary Gregory <ga...@gmail.com>wrote:
>
>> Ok, so where are we on all this and specifically [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>
>> ]?
>>
>> It seems that [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>],
>> if applied should be for a 1.x, not a 1.x.y because of the change of
>> behavior.
>>
>> If it is not applied, then we need... new classes or more behavior in the
>> current class tunnable with something (constructor, config object)
>>
>> We also need someone to implement it...
>>
>> Thoughts?
>>
>> Gary
>>
>>
>> On Tue, Mar 6, 2012 at 10:35 PM, Julius Davies <ju...@gmail.com>wrote:
>>
>>> Maybe time to add a Base64(int mode) constructor! Yay, room for 32
>>> true/false bitwise fields!
>>>
>>> Sorry I can't respond inline to the email like a normal person. Bad
>>> habit.
>>>
>>> yours,
>>>
>>> Julius
>>>
>>> On Tue, Mar 6, 2012 at 11:40 AM, sebb <se...@gmail.com> wrote:
>>> > On 6 March 2012 19:33, Gary Gregory <ga...@gmail.com> wrote:
>>> >> What about passing in a "boolean strict" to the constructor of the
>>> codecs?
>>> >
>>> > What does strict mean? See my comment:
>>> >
>>> > https://issues.apache.org/jira/browse/CODEC-95#comment-12986951
>>> >
>>> > If we do add another parameter (which is not popular with others), at
>>> > least let's make sure it's the last one we need to add.
>>> >
>>> >> Gary
>>> >>
>>> >> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <juliusdavies@gmail.com
>>> >wrote:
>>> >>
>>> >>> Hi,
>>> >>>
>>> >>>
>>> >>> CODEC-95 talked about these issues, too (in this case with Base64).
>>> >>>
>>> >>> https://issues.apache.org/jira/browse/CODEC-95
>>> >>>
>>> >>>
>>> >>> Personally, I would prefer to see some new "strict" classes defined,
>>> >>> and to preserve the garbage-in/garbage-out behaviour on the current
>>> >>> existing classes.
>>> >>>
>>> >>>
>>> >>> Here are the new classes I would like to see:
>>> >>>
>>> >>>
>>> >>> Base32Strict
>>> >>> Base32StrictInputStream
>>> >>> Base32StrictOutputStream
>>> >>> Base64Strict
>>> >>> Base64StrictInputStream
>>> >>> Base64StrictOutputStream
>>> >>>
>>> >>>
>>> >>> At the same time it does make the API a bit more intimidating and
>>> >>> harder to learn, but I think striving for drop-in
>>> >>> reverse-compatibility of the existing classes is desirable.
>>> >>>
>>> >>>
>>> >>> yours,
>>> >>>
>>> >>> Julius
>>> >>>
>>> >>>
>>> >>>
>>> >>>
>>> >>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <ga...@gmail.com>
>>> >>> wrote:
>>> >>> > Hello All,
>>> >>> >
>>> >>> > We have a patch for
>>> >>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
>>> >>> > but it is a change in behavior. In order to avoid a potential nasty
>>> >>> > surprise for call sites, we need to decide when something like this
>>> can
>>> >>> be
>>> >>> > done.
>>> >>> >
>>> >>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With the
>>> >>> patch,
>>> >>> > you get an exception.
>>> >>> >
>>> >>> > 1) Is the proposed patch acceptable in the sense that we do not
>>> whant
>>> >>> GIGO?
>>> >>> > Should there instead be a validate method for example?
>>> >>> >
>>> >>> > 2) What kind of version is this change in behavior acceptable?
>>> >>> Maintenance
>>> >>> > (1.6.1), Minor (1.7) or Major (2.0)?
>>> >>> >
>>> >>> > Thank you,
>>> >>> > Gary
>>> >>> >
>>> >>> > [CODEC-134] Base32 would decode some invalid Base32 encoded string
>>> into
>>> >>> > arbitrary value
>>> >>> >
>>> >>> > --
>>> >>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> >>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>
>>> http://bit.ly/ECvg0
>>> >>> > Spring Batch in Action: <http://s.apache.org/HOq>
>>> http://bit.ly/bqpbCK
>>> >>> > Blog: http://garygregory.wordpress.com
>>> >>> > Home: http://garygregory.com/
>>> >>> > Tweet! http://twitter.com/GaryGregory
>>> >>>
>>> >>>
>>> >>>
>>> >>> --
>>> >>> yours,
>>> >>>
>>> >>> Julius Davies
>>> >>> 604-222-3310 (Home)
>>> >>>
>>> >>> $ sudo apt-get install cowsay
>>> >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
>>> >>> http://juliusdavies.ca/cowsay/
>>> >>>
>>> >>> ---------------------------------------------------------------------
>>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>>> >>>
>>> >>>
>>> >>
>>> >>
>>> >> --
>>> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> >> Blog: http://garygregory.wordpress.com
>>> >> Home: http://garygregory.com/
>>> >> Tweet! http://twitter.com/GaryGregory
>>> >
>>> > ---------------------------------------------------------------------
>>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> > For additional commands, e-mail: dev-help@commons.apache.org
>>> >
>>>
>>>
>>>
>>> --
>>> yours,
>>>
>>> Julius Davies
>>> 604-222-3310 (Home)
>>>
>>> $ sudo apt-get install cowsay
>>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
>>> http://juliusdavies.ca/cowsay/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>>
>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] What version should implement a behavior change?
Posted by Gary Gregory <ga...@gmail.com>.
Ok, so now, it look like the next release will be 1.7 and not 1.6.1 because
of the addition of new Nysiis codec.
Would [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>] be OK
in 1.7 or should it be for a 2.0?
Gary
On Thu, Mar 8, 2012 at 11:14 AM, Gary Gregory <ga...@gmail.com>wrote:
> Ok, so where are we on all this and specifically [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>
> ]?
>
> It seems that [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>],
> if applied should be for a 1.x, not a 1.x.y because of the change of
> behavior.
>
> If it is not applied, then we need... new classes or more behavior in the
> current class tunnable with something (constructor, config object)
>
> We also need someone to implement it...
>
> Thoughts?
>
> Gary
>
>
> On Tue, Mar 6, 2012 at 10:35 PM, Julius Davies <ju...@gmail.com>wrote:
>
>> Maybe time to add a Base64(int mode) constructor! Yay, room for 32
>> true/false bitwise fields!
>>
>> Sorry I can't respond inline to the email like a normal person. Bad
>> habit.
>>
>> yours,
>>
>> Julius
>>
>> On Tue, Mar 6, 2012 at 11:40 AM, sebb <se...@gmail.com> wrote:
>> > On 6 March 2012 19:33, Gary Gregory <ga...@gmail.com> wrote:
>> >> What about passing in a "boolean strict" to the constructor of the
>> codecs?
>> >
>> > What does strict mean? See my comment:
>> >
>> > https://issues.apache.org/jira/browse/CODEC-95#comment-12986951
>> >
>> > If we do add another parameter (which is not popular with others), at
>> > least let's make sure it's the last one we need to add.
>> >
>> >> Gary
>> >>
>> >> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <juliusdavies@gmail.com
>> >wrote:
>> >>
>> >>> Hi,
>> >>>
>> >>>
>> >>> CODEC-95 talked about these issues, too (in this case with Base64).
>> >>>
>> >>> https://issues.apache.org/jira/browse/CODEC-95
>> >>>
>> >>>
>> >>> Personally, I would prefer to see some new "strict" classes defined,
>> >>> and to preserve the garbage-in/garbage-out behaviour on the current
>> >>> existing classes.
>> >>>
>> >>>
>> >>> Here are the new classes I would like to see:
>> >>>
>> >>>
>> >>> Base32Strict
>> >>> Base32StrictInputStream
>> >>> Base32StrictOutputStream
>> >>> Base64Strict
>> >>> Base64StrictInputStream
>> >>> Base64StrictOutputStream
>> >>>
>> >>>
>> >>> At the same time it does make the API a bit more intimidating and
>> >>> harder to learn, but I think striving for drop-in
>> >>> reverse-compatibility of the existing classes is desirable.
>> >>>
>> >>>
>> >>> yours,
>> >>>
>> >>> Julius
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <ga...@gmail.com>
>> >>> wrote:
>> >>> > Hello All,
>> >>> >
>> >>> > We have a patch for
>> >>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
>> >>> > but it is a change in behavior. In order to avoid a potential nasty
>> >>> > surprise for call sites, we need to decide when something like this
>> can
>> >>> be
>> >>> > done.
>> >>> >
>> >>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With the
>> >>> patch,
>> >>> > you get an exception.
>> >>> >
>> >>> > 1) Is the proposed patch acceptable in the sense that we do not
>> whant
>> >>> GIGO?
>> >>> > Should there instead be a validate method for example?
>> >>> >
>> >>> > 2) What kind of version is this change in behavior acceptable?
>> >>> Maintenance
>> >>> > (1.6.1), Minor (1.7) or Major (2.0)?
>> >>> >
>> >>> > Thank you,
>> >>> > Gary
>> >>> >
>> >>> > [CODEC-134] Base32 would decode some invalid Base32 encoded string
>> into
>> >>> > arbitrary value
>> >>> >
>> >>> > --
>> >>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>
>> http://bit.ly/ECvg0
>> >>> > Spring Batch in Action: <http://s.apache.org/HOq>
>> http://bit.ly/bqpbCK
>> >>> > Blog: http://garygregory.wordpress.com
>> >>> > Home: http://garygregory.com/
>> >>> > Tweet! http://twitter.com/GaryGregory
>> >>>
>> >>>
>> >>>
>> >>> --
>> >>> yours,
>> >>>
>> >>> Julius Davies
>> >>> 604-222-3310 (Home)
>> >>>
>> >>> $ sudo apt-get install cowsay
>> >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
>> >>> http://juliusdavies.ca/cowsay/
>> >>>
>> >>> ---------------------------------------------------------------------
>> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> >>> For additional commands, e-mail: dev-help@commons.apache.org
>> >>>
>> >>>
>> >>
>> >>
>> >> --
>> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> >> Blog: http://garygregory.wordpress.com
>> >> Home: http://garygregory.com/
>> >> Tweet! http://twitter.com/GaryGregory
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> > For additional commands, e-mail: dev-help@commons.apache.org
>> >
>>
>>
>>
>> --
>> yours,
>>
>> Julius Davies
>> 604-222-3310 (Home)
>>
>> $ sudo apt-get install cowsay
>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
>> http://juliusdavies.ca/cowsay/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [codec] What version should implement a behavior change?
Posted by Gary Gregory <ga...@gmail.com>.
Ok, so where are we on all this and specifically
[CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>
]?
It seems that [CODEC-134 <https://issues.apache.org/jira/browse/CODEC-134>],
if applied should be for a 1.x, not a 1.x.y because of the change of
behavior.
If it is not applied, then we need... new classes or more behavior in the
current class tunnable with something (constructor, config object)
We also need someone to implement it...
Thoughts?
Gary
On Tue, Mar 6, 2012 at 10:35 PM, Julius Davies <ju...@gmail.com>wrote:
> Maybe time to add a Base64(int mode) constructor! Yay, room for 32
> true/false bitwise fields!
>
> Sorry I can't respond inline to the email like a normal person. Bad
> habit.
>
> yours,
>
> Julius
>
> On Tue, Mar 6, 2012 at 11:40 AM, sebb <se...@gmail.com> wrote:
> > On 6 March 2012 19:33, Gary Gregory <ga...@gmail.com> wrote:
> >> What about passing in a "boolean strict" to the constructor of the
> codecs?
> >
> > What does strict mean? See my comment:
> >
> > https://issues.apache.org/jira/browse/CODEC-95#comment-12986951
> >
> > If we do add another parameter (which is not popular with others), at
> > least let's make sure it's the last one we need to add.
> >
> >> Gary
> >>
> >> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <juliusdavies@gmail.com
> >wrote:
> >>
> >>> Hi,
> >>>
> >>>
> >>> CODEC-95 talked about these issues, too (in this case with Base64).
> >>>
> >>> https://issues.apache.org/jira/browse/CODEC-95
> >>>
> >>>
> >>> Personally, I would prefer to see some new "strict" classes defined,
> >>> and to preserve the garbage-in/garbage-out behaviour on the current
> >>> existing classes.
> >>>
> >>>
> >>> Here are the new classes I would like to see:
> >>>
> >>>
> >>> Base32Strict
> >>> Base32StrictInputStream
> >>> Base32StrictOutputStream
> >>> Base64Strict
> >>> Base64StrictInputStream
> >>> Base64StrictOutputStream
> >>>
> >>>
> >>> At the same time it does make the API a bit more intimidating and
> >>> harder to learn, but I think striving for drop-in
> >>> reverse-compatibility of the existing classes is desirable.
> >>>
> >>>
> >>> yours,
> >>>
> >>> Julius
> >>>
> >>>
> >>>
> >>>
> >>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <ga...@gmail.com>
> >>> wrote:
> >>> > Hello All,
> >>> >
> >>> > We have a patch for
> >>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
> >>> > but it is a change in behavior. In order to avoid a potential nasty
> >>> > surprise for call sites, we need to decide when something like this
> can
> >>> be
> >>> > done.
> >>> >
> >>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With the
> >>> patch,
> >>> > you get an exception.
> >>> >
> >>> > 1) Is the proposed patch acceptable in the sense that we do not whant
> >>> GIGO?
> >>> > Should there instead be a validate method for example?
> >>> >
> >>> > 2) What kind of version is this change in behavior acceptable?
> >>> Maintenance
> >>> > (1.6.1), Minor (1.7) or Major (2.0)?
> >>> >
> >>> > Thank you,
> >>> > Gary
> >>> >
> >>> > [CODEC-134] Base32 would decode some invalid Base32 encoded string
> into
> >>> > arbitrary value
> >>> >
> >>> > --
> >>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> >>> > Spring Batch in Action: <http://s.apache.org/HOq>
> http://bit.ly/bqpbCK
> >>> > Blog: http://garygregory.wordpress.com
> >>> > Home: http://garygregory.com/
> >>> > Tweet! http://twitter.com/GaryGregory
> >>>
> >>>
> >>>
> >>> --
> >>> yours,
> >>>
> >>> Julius Davies
> >>> 604-222-3310 (Home)
> >>>
> >>> $ sudo apt-get install cowsay
> >>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> >>> http://juliusdavies.ca/cowsay/
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> >>> For additional commands, e-mail: dev-help@commons.apache.org
> >>>
> >>>
> >>
> >>
> >> --
> >> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> >> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> >> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> >> Blog: http://garygregory.wordpress.com
> >> Home: http://garygregory.com/
> >> Tweet! http://twitter.com/GaryGregory
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> > For additional commands, e-mail: dev-help@commons.apache.org
> >
>
>
>
> --
> yours,
>
> Julius Davies
> 604-222-3310 (Home)
>
> $ sudo apt-get install cowsay
> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> http://juliusdavies.ca/cowsay/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [codec] What version should implement a behavior change?
Posted by Julius Davies <ju...@gmail.com>.
Maybe time to add a Base64(int mode) constructor! Yay, room for 32
true/false bitwise fields!
Sorry I can't respond inline to the email like a normal person. Bad habit.
yours,
Julius
On Tue, Mar 6, 2012 at 11:40 AM, sebb <se...@gmail.com> wrote:
> On 6 March 2012 19:33, Gary Gregory <ga...@gmail.com> wrote:
>> What about passing in a "boolean strict" to the constructor of the codecs?
>
> What does strict mean? See my comment:
>
> https://issues.apache.org/jira/browse/CODEC-95#comment-12986951
>
> If we do add another parameter (which is not popular with others), at
> least let's make sure it's the last one we need to add.
>
>> Gary
>>
>> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <ju...@gmail.com>wrote:
>>
>>> Hi,
>>>
>>>
>>> CODEC-95 talked about these issues, too (in this case with Base64).
>>>
>>> https://issues.apache.org/jira/browse/CODEC-95
>>>
>>>
>>> Personally, I would prefer to see some new "strict" classes defined,
>>> and to preserve the garbage-in/garbage-out behaviour on the current
>>> existing classes.
>>>
>>>
>>> Here are the new classes I would like to see:
>>>
>>>
>>> Base32Strict
>>> Base32StrictInputStream
>>> Base32StrictOutputStream
>>> Base64Strict
>>> Base64StrictInputStream
>>> Base64StrictOutputStream
>>>
>>>
>>> At the same time it does make the API a bit more intimidating and
>>> harder to learn, but I think striving for drop-in
>>> reverse-compatibility of the existing classes is desirable.
>>>
>>>
>>> yours,
>>>
>>> Julius
>>>
>>>
>>>
>>>
>>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <ga...@gmail.com>
>>> wrote:
>>> > Hello All,
>>> >
>>> > We have a patch for
>>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
>>> > but it is a change in behavior. In order to avoid a potential nasty
>>> > surprise for call sites, we need to decide when something like this can
>>> be
>>> > done.
>>> >
>>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With the
>>> patch,
>>> > you get an exception.
>>> >
>>> > 1) Is the proposed patch acceptable in the sense that we do not whant
>>> GIGO?
>>> > Should there instead be a validate method for example?
>>> >
>>> > 2) What kind of version is this change in behavior acceptable?
>>> Maintenance
>>> > (1.6.1), Minor (1.7) or Major (2.0)?
>>> >
>>> > Thank you,
>>> > Gary
>>> >
>>> > [CODEC-134] Base32 would decode some invalid Base32 encoded string into
>>> > arbitrary value
>>> >
>>> > --
>>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>>> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>>> > Blog: http://garygregory.wordpress.com
>>> > Home: http://garygregory.com/
>>> > Tweet! http://twitter.com/GaryGregory
>>>
>>>
>>>
>>> --
>>> yours,
>>>
>>> Julius Davies
>>> 604-222-3310 (Home)
>>>
>>> $ sudo apt-get install cowsay
>>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
>>> http://juliusdavies.ca/cowsay/
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>>> For additional commands, e-mail: dev-help@commons.apache.org
>>>
>>>
>>
>>
>> --
>> E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> Blog: http://garygregory.wordpress.com
>> Home: http://garygregory.com/
>> Tweet! http://twitter.com/GaryGregory
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
--
yours,
Julius Davies
604-222-3310 (Home)
$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] What version should implement a behavior change?
Posted by sebb <se...@gmail.com>.
On 6 March 2012 19:33, Gary Gregory <ga...@gmail.com> wrote:
> What about passing in a "boolean strict" to the constructor of the codecs?
What does strict mean? See my comment:
https://issues.apache.org/jira/browse/CODEC-95#comment-12986951
If we do add another parameter (which is not popular with others), at
least let's make sure it's the last one we need to add.
> Gary
>
> On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <ju...@gmail.com>wrote:
>
>> Hi,
>>
>>
>> CODEC-95 talked about these issues, too (in this case with Base64).
>>
>> https://issues.apache.org/jira/browse/CODEC-95
>>
>>
>> Personally, I would prefer to see some new "strict" classes defined,
>> and to preserve the garbage-in/garbage-out behaviour on the current
>> existing classes.
>>
>>
>> Here are the new classes I would like to see:
>>
>>
>> Base32Strict
>> Base32StrictInputStream
>> Base32StrictOutputStream
>> Base64Strict
>> Base64StrictInputStream
>> Base64StrictOutputStream
>>
>>
>> At the same time it does make the API a bit more intimidating and
>> harder to learn, but I think striving for drop-in
>> reverse-compatibility of the existing classes is desirable.
>>
>>
>> yours,
>>
>> Julius
>>
>>
>>
>>
>> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <ga...@gmail.com>
>> wrote:
>> > Hello All,
>> >
>> > We have a patch for
>> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
>> > but it is a change in behavior. In order to avoid a potential nasty
>> > surprise for call sites, we need to decide when something like this can
>> be
>> > done.
>> >
>> > In 1.6 and before, we had garbage-in-garbage-out behavior. With the
>> patch,
>> > you get an exception.
>> >
>> > 1) Is the proposed patch acceptable in the sense that we do not whant
>> GIGO?
>> > Should there instead be a validate method for example?
>> >
>> > 2) What kind of version is this change in behavior acceptable?
>> Maintenance
>> > (1.6.1), Minor (1.7) or Major (2.0)?
>> >
>> > Thank you,
>> > Gary
>> >
>> > [CODEC-134] Base32 would decode some invalid Base32 encoded string into
>> > arbitrary value
>> >
>> > --
>> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
>> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
>> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
>> > Blog: http://garygregory.wordpress.com
>> > Home: http://garygregory.com/
>> > Tweet! http://twitter.com/GaryGregory
>>
>>
>>
>> --
>> yours,
>>
>> Julius Davies
>> 604-222-3310 (Home)
>>
>> $ sudo apt-get install cowsay
>> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
>> http://juliusdavies.ca/cowsay/
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
>> For additional commands, e-mail: dev-help@commons.apache.org
>>
>>
>
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org
Re: [codec] What version should implement a behavior change?
Posted by Gary Gregory <ga...@gmail.com>.
What about passing in a "boolean strict" to the constructor of the codecs?
Gary
On Tue, Mar 6, 2012 at 2:07 PM, Julius Davies <ju...@gmail.com>wrote:
> Hi,
>
>
> CODEC-95 talked about these issues, too (in this case with Base64).
>
> https://issues.apache.org/jira/browse/CODEC-95
>
>
> Personally, I would prefer to see some new "strict" classes defined,
> and to preserve the garbage-in/garbage-out behaviour on the current
> existing classes.
>
>
> Here are the new classes I would like to see:
>
>
> Base32Strict
> Base32StrictInputStream
> Base32StrictOutputStream
> Base64Strict
> Base64StrictInputStream
> Base64StrictOutputStream
>
>
> At the same time it does make the API a bit more intimidating and
> harder to learn, but I think striving for drop-in
> reverse-compatibility of the existing classes is desirable.
>
>
> yours,
>
> Julius
>
>
>
>
> On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <ga...@gmail.com>
> wrote:
> > Hello All,
> >
> > We have a patch for
> > [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
> > but it is a change in behavior. In order to avoid a potential nasty
> > surprise for call sites, we need to decide when something like this can
> be
> > done.
> >
> > In 1.6 and before, we had garbage-in-garbage-out behavior. With the
> patch,
> > you get an exception.
> >
> > 1) Is the proposed patch acceptable in the sense that we do not whant
> GIGO?
> > Should there instead be a validate method for example?
> >
> > 2) What kind of version is this change in behavior acceptable?
> Maintenance
> > (1.6.1), Minor (1.7) or Major (2.0)?
> >
> > Thank you,
> > Gary
> >
> > [CODEC-134] Base32 would decode some invalid Base32 encoded string into
> > arbitrary value
> >
> > --
> > E-Mail: garydgregory@gmail.com | ggregory@apache.org
> > JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> > Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> > Blog: http://garygregory.wordpress.com
> > Home: http://garygregory.com/
> > Tweet! http://twitter.com/GaryGregory
>
>
>
> --
> yours,
>
> Julius Davies
> 604-222-3310 (Home)
>
> $ sudo apt-get install cowsay
> $ echo "Moo." | cowsay | cowsay -n | cowsay -n
> http://juliusdavies.ca/cowsay/
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
> For additional commands, e-mail: dev-help@commons.apache.org
>
>
--
E-Mail: garydgregory@gmail.com | ggregory@apache.org
JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
Blog: http://garygregory.wordpress.com
Home: http://garygregory.com/
Tweet! http://twitter.com/GaryGregory
Re: [codec] What version should implement a behavior change?
Posted by Julius Davies <ju...@gmail.com>.
Hi,
CODEC-95 talked about these issues, too (in this case with Base64).
https://issues.apache.org/jira/browse/CODEC-95
Personally, I would prefer to see some new "strict" classes defined,
and to preserve the garbage-in/garbage-out behaviour on the current
existing classes.
Here are the new classes I would like to see:
Base32Strict
Base32StrictInputStream
Base32StrictOutputStream
Base64Strict
Base64StrictInputStream
Base64StrictOutputStream
At the same time it does make the API a bit more intimidating and
harder to learn, but I think striving for drop-in
reverse-compatibility of the existing classes is desirable.
yours,
Julius
On Tue, Mar 6, 2012 at 6:11 AM, Gary Gregory <ga...@gmail.com> wrote:
> Hello All,
>
> We have a patch for
> [CODEC-134<https://issues.apache.org/jira/browse/CODEC-134>]
> but it is a change in behavior. In order to avoid a potential nasty
> surprise for call sites, we need to decide when something like this can be
> done.
>
> In 1.6 and before, we had garbage-in-garbage-out behavior. With the patch,
> you get an exception.
>
> 1) Is the proposed patch acceptable in the sense that we do not whant GIGO?
> Should there instead be a validate method for example?
>
> 2) What kind of version is this change in behavior acceptable? Maintenance
> (1.6.1), Minor (1.7) or Major (2.0)?
>
> Thank you,
> Gary
>
> [CODEC-134] Base32 would decode some invalid Base32 encoded string into
> arbitrary value
>
> --
> E-Mail: garydgregory@gmail.com | ggregory@apache.org
> JUnit in Action, 2nd Ed: <http://goog_1249600977>http://bit.ly/ECvg0
> Spring Batch in Action: <http://s.apache.org/HOq>http://bit.ly/bqpbCK
> Blog: http://garygregory.wordpress.com
> Home: http://garygregory.com/
> Tweet! http://twitter.com/GaryGregory
--
yours,
Julius Davies
604-222-3310 (Home)
$ sudo apt-get install cowsay
$ echo "Moo." | cowsay | cowsay -n | cowsay -n
http://juliusdavies.ca/cowsay/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@commons.apache.org
For additional commands, e-mail: dev-help@commons.apache.org