commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Luc Maisonobe <Luc.Maison...@free.fr>
Subject Re: [math] preparing smooth interface upgrade for users
Date Fri, 19 Nov 2010 17:50:12 GMT
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.Maisonobe@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-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
>>>
>>
>>
>> ---------------------------------------------------------------------
>> 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