commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Phil Steitz <phil.ste...@gmail.com>
Subject Re: [math] 2.2 compatibility issues
Date Tue, 25 Jan 2011 12:21:54 GMT
On Mon, Jan 24, 2011 at 11:01 AM,  <luc.maisonobe@free.fr> wrote:
>
> ----- "Phil Steitz" <phil.steitz@gmail.com> a écrit :
>
>> On Mon, Jan 24, 2011 at 7:58 AM,  <luc.maisonobe@free.fr> wrote:
>> >
>> > ----- "Phil Steitz" <phil.steitz@gmail.com> a écrit :
>> >
>> >> On Sun, Jan 16, 2011 at 12:26 PM, Phil Steitz
>> <phil.steitz@gmail.com>
>> >> wrote:
>> >> > On Sun, Jan 2, 2011 at 1:01 PM, Phil Steitz
>> <phil.steitz@gmail.com>
>> >> wrote:
>> >> >> The clirr report run from the current MATH_2_X branch is, as
>> >> expected,
>> >> >> problematic.  To get 2.2. out, we need to agree on what breaks
>> we
>> >> are going
>> >> >> to allow and what we are going to fix.   Here is a first cut
>> and
>> >> proposal
>> >> >> for some immediate fixes that I would appreciate feedback on.
>> >> >>
>> >> >> 0)  The improvements to the distributions classes to add
>> >> characteristic
>> >> >> support and positive mass domains have added some new methods
>> to
>> >> interfaces
>> >> >> and new abstract methods to abstract classes.  I apologize for
>> not
>> >> spotting
>> >> >> this in initial patch reviews or being clear in discussion of
>> the
>> >> >> features.   I think we can keep the functionality without
>> >> introducing the
>> >> >> compatibility breaks by removing the added methods from
>> interfaces
>> >> /
>> >> >> abstract classes.  The only painful part is the nice solution
>> for
>> >> caching
>> >> >> numerical characteristics that will have to be repeated in the
>> >> >> implementation classes that need it.  I would like to proceed
>> with
>> >> these
>> >> >> changes in the 2.2 branch if others are OK with it.
>> >> >
>> >> > Fixed
>> >> >>
>> >> >> 1) Removed superclasses in the exception hierarchy.  I am OK
>> >> leaving these
>> >> >> as is.
>> >> >
>> >> > I am now starting to wonder if we should fix this.  Problem is
>> user
>> >> > code that may be catching the superclass exceptions (which is
>> why
>> >> > clirr is complaining).
>> >> >
>> >>
>> >> Sorry to flip/flop on this, but I now think we really need to fix
>> >> this
>> >> (i,e., revert the incompatible changes). I have started doing the
>> >> work, most of which is replacing the new, unchecked
>> MathUserException
>> >> with the deprecated checked FunctionEvaluationException.   I don't
>> >> think we *need* to force users to do refactor or surprise them
>> with
>> >> unchecked exceptions in the upgrade to 2.2 and I am willing to do
>> the
>> >> work to fix this.   If I hear no objections, I will commit the
>> >> changes
>> >> when I have finished (next day or two).  We can add some info to
>> the
>> >> release notes warning users of upcoming incompatible changes in
>> 3.0.
>> >
>> > I do object.
>> > As the new exception are unchecked, users were not forced to
>> migrate
>> > immediately, but those users who where ready to migrate (for
>> example
>> > due to their own publication schedule) could do so.
>> >
>> The problem is the users who are catching
>> FunctionEvaluationException,
>> the checked exception that occurs in *lots* of places in the 2.1
>> code.
>
> These users still catch FunctionEvaluationException which still exists,
> still is is the same package, but is unchecked. So they could avoid catching
> it but if they do, it will work.
>
>>  I don't see how 2.1 users are going to be able to avoid lots of
>> changes to get 2.2 to work.  Could be I am missing something.  Is it
>> really true somehow that 2.1 users will not have to make changes?
>
> For this specific point, I don't think they need to change anything. This
> is what I tested some weeks ago.

I am sorry, Luc.  This is what I was missing / forgot that you had
tested.  I am OK with this.

> There are other points where change would be needed, as some incompatible
> changes were introduced to solve bugs.
>
Per my previous note, I think the compatibility-breaking changes in
optimization can be reverted without losing the associated bug fixes.
If there is no way to do it in ode, then so be it.

Phil

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


Mime
View raw message