commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From luc.maison...@free.fr
Subject Re: [math] 2.2 compatibility issues
Date Mon, 24 Jan 2011 16:01:08 GMT

----- "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.
There are other points where change would be needed, as some incompatible
changes were introduced to solve bugs.

> Sorry if I am being dense here.

You are right to look for maximal compatibility.

> 
> > Reverting this change force them to go back first,
> 
> Only if they have started using the 2_X branch or trunk before it was
> split.  Our compatibility obligation is against *released* code.

Yes, you are right.

> 
>  then to wait for 3.0
> > and do the change at that time. This is exactly what happens to me
> for
> > Orekit.
> >
> > The change was designed as a smooth transition and allowing users
> > to change at their own pace. So I would prefer these change to be
> > available in 2.2.
> >
> If I can understand how 2.1 code that catches and handles
> FunctionEvaluationException  will still work, then I am OK with this;

Catching an exception depends only on the exception itself, not on its
base class. What changes in 2.2 is the base class of FunctionEvaluation.
Since this exception is never thrown directly by commons-math but only by
user code, then if the user code did throw it, it will still throw it 
and it can be caught by upper layers. The same is true for DerivativeException.

Luc

> otherwise I really think we need to revert.  I should have yelled
> more
> loudly about the incompatible changes as they were introduced in
> trunk
> prior to the 3.0 split.  Given that we have split 3.0, there is no
> reason for us to break Commons guidelines for 2.2 unless there is no
> other way to fix bugs (as I assume is the case in some of the ODE
> changes).

> 
> Phil
> 
> 
> > Luc
> >
> >>
> >> Phil
> >>
> >> >>
> >> >> I don't know what, if anything, to do about the following:
> >> >>
> >> >> 2) Changed return type of interpolate in BicubicSpline.
> >> >
> >> > Fixed
> >> >>
> >> >> 3) Incompatible changes in the ode package.
> >> >
> >> > I agree that unfortunately this is hopeless.
> >> >
> >> >>
> >> >> 4) Incompatible changes in the optimization package.
> >> >
> >> > Fixing...
> >> >
> >> > Phil
> >> >
> >>
> >>
> ---------------------------------------------------------------------
> >> 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
> >
> >
> 
> ---------------------------------------------------------------------
> 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