Le 19/11/2010 16:39, Phil Steitz a écrit : > On 11/19/10 8:52 AM, Luc Maisonobe wrote: >> Le 17/11/2010 21:08, sebb a écrit : >>> On 17 November 2010 19:53, Luc Maisonobe<luc.maison...@free.fr> wrote: >>>> Le 17/11/2010 13:48, Phil Steitz a écrit : >>>>> On 11/16/10 7:10 PM, Gilles Sadowski wrote: >>>>>>>>> [...] >>>>>>>>> I think this transition is the smoother path for our users. Do you >>>>>>>>> think >>>>>>>>> this change is the way to go ? >>>>>>>> >>>>>>>> -0 >>>>>>> >>>>>>> +1 >>>>>>> >>>>>>>> >>>>>>>> My first impression is that it is a lot of changes for 2.2 >>>>>>>> without any >>>>>>>> benefit when users will switch to 3.0; they will still have to scan >>>>>>>> their >>>>>>>> code for all the exceptions that will have disappeared. >>>>>>> >>>>>>> Won't the deprecations take care of that? >>>>>> >>>>>> I didn't mean that they have to scan "manually", just that they will >>>>>> have to >>>>>> make the same change in 3.0 as they would in 2.2 (not more, not less >>>>>> work). >>>>>> Hence, I see no benefit in breaking the "no compatibility breaking" >>>>>> rule in >>>>>> 2.2. >>>>> >>>>> I think what Luc is suggesting is that by introducing >>>>> MathUserException >>>>> in 2.2 without a material compatibility break (i.e. nothing that would >>>>> actually break any 2.1 code) we could set users to start doing this >>>>> work >>>>> incrementally before 3.0 is released. That seems like a good idea >>>>> to me >>>>> IIUC what the impacts are. >>>> >>>> You are right, this is exactly what I try to do. >>>> >>>>> >>>>>> >>>>>>> >>>>>>>> In 3.0 it will clear that they *have* to do it while, in 2.2, >>>>>>>> you would >>>>>>>> have to explain to users that it's better that they do it but >>>>>>>> that it >>>>>>>> will still work if they don't... And they will probably say: "If it >>>>>>>> ain't >>>>>>>> broken, I won't fix it." ;-) >>>>>>> >>>>>>> However, deprecation warnings are a strong hint that failure is >>>>>>> imminent, and they may wish to prepare for the change. >>>>>> >>>>>> Yes. We should advertise the list of exceptions that are going to be >>>>>> replaced by "MathUserException" when users switch 3.0, by deprecating >>>>>> them in 2.2. >>>>>> The preparation is to have a perl (or sed or ...) script ready. >>>>>> >>>>> I think we all agree on the deprecations. I understand your view, >>>>> Gilles, that Luc's suggestion does not reduce work for those upgrading >>>>> to 3.0; but don't you agree it would be helpful for them to be able to >>>>> start - even just with new code they are developing - using the new >>>>> user >>>>> exception, assuming we can introduce it in 2.2 without breaking >>>>> anything? >>>>> >>>>> Luc / Sebb - can you see any real backward compat issue? Would this >>>>> change force a recompile? >>>> >>>> I don't think a recompile should be needed because the new exceptions >>>> going out of the complete integration algorithm are now unchecked, and >>>> in fact since the current exception are checked exception, existing >>>> user >>>> code probably already catches them. >>> >>> Should be easy enough to check with some actual source. >> >> I just checked with an old tutorial, compiled with 2.1. >> It runs perfectly and throws exceptions correctly with both 2.1 and the >> current version in 2.X branch with the proposed change, without >> recompiling. > > What happens when you try to recompile it against a new jar built from > the current sources?
The compiler displays a warning, as expected: Note: ODEExample.java uses or overrides a deprecated API. Note: Recompile with -Xlint:deprecation for details. Luc > > Phil >> >> Luc >> >>> >>>> Luc >>>> >>>>> >>>>> Phil >>>>>> >>>>>> Best, >>>>>> Gilles >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>>> >>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>>> >>>> >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>>> For additional commands, e-mail: dev-h...@commons.apache.org >>>> >>>> >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >>> For additional commands, e-mail: dev-h...@commons.apache.org >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org >> For additional commands, e-mail: dev-h...@commons.apache.org >> > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org > For additional commands, e-mail: dev-h...@commons.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
