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] Re: svn commit: r1078734
Date Wed, 09 Mar 2011 08:48:19 GMT
Hi,

Le 08/03/2011 23:51, Jörg Schaible a écrit :
> sebb wrote:
> 
>> On 8 March 2011 20:17, Luc Maisonobe <Luc.Maisonobe@free.fr> wrote:
>>> Le 07/03/2011 11:37, erans@apache.org a écrit :
>>>> Author: erans
>>>> Date: Mon Mar  7 10:37:52 2011
>>>> New Revision: 1078734
>>>>
>>>> URL: http://svn.apache.org/viewvc?rev=1078734&view=rev
>>>> Log:
>>>> MATH-542
>>>> "MathRuntimeException" provides two ways for enhancing the information
>>>> content: one for localized messages and one for storing "context"
>>>> objects. The additional methods have been added to "MathThrowable".
>>>> Consequently, dummy implementations were needed in the old
>>>> "MathRuntimeException" and "MathException".
>>>> Some parts of the tests for old exceptions were removed as they used
>>>> methods that were deleted. A call to "MathUserException" in
>>>> "AbstractContinuousDistribution" was simplified for the same reason.
>>>> "MathUtils" still contained "String" (instead of "Localizable") as
>>>> argument to the constructor of a "MathArithmeticException".
>>>> I don't know why a test in "DummyStepInterpolatorTest" stopped working.
>>>> It is now commented out; please have a look.
>>>
>>> [snip]
>>>
>>>
>>>> Modified:
>>>>
> commons/proper/math/trunk/src/test/java/org/apache/commons/math/ode/sampling/DummyStepInterpolatorTest.java
>>>> URL:
>>>>
> http://svn.apache.org/viewvc/commons/proper/math/trunk/src/test/java/org/apache/commons/math/ode/sampling/DummyStepInterpolatorTest.java?rev=1078734&r1=1078733&r2=1078734&view=diff
>>>>
> ==============================================================================
>>>> ---
>>>>
> commons/proper/math/trunk/src/test/java/org/apache/commons/math/ode/sampling/DummyStepInterpolatorTest.java
>>>> (original) +++
>>>>
> commons/proper/math/trunk/src/test/java/org/apache/commons/math/ode/sampling/DummyStepInterpolatorTest.java
>>>> Mon Mar  7 10:37:52 2011 @@ -123,7 +123,9 @@ public class
>>>> DummyStepInterpolatorTest { fail("an exception should have been
>>>> thrown"); } catch (IOException ioe) { // expected behavior -       
>>>> assertEquals(0, ioe.getMessage().length()); +        // XXX Why was the
>>>> message supposed to be empty? +        // With the current code it is
>>>> "org.apache.commons.math.util.Pair". +        // assertEquals(0,
>>>> ioe.getMessage().length());
>>>
>>> The problem here is that the exception thrown which is an IOException
>>> built from the empty string in the BadStepInterpolator below is not the
>>> IOException that is caught here. In fact the IOException caught is
>>> really a java.io.NotSerializableException which is built with the
>>> message "org.apache.commons.math.util.Pair" automatically by the
>>> serialization process in the JVM (at least for Oracle implementation).
>>>
>>> All exceptions must be serializable (this comes from java.lang.Throwable
>>> implementing the Serializable interface). This was also one reason why
>>> our Localizable interface had to extends Serializable, so it could be
>>> used as a field in our exceptions.
>>>
>>> This change added a List<Pair<Localizable, Object[]>> field in
>>> MathRuntimeException. Pair is not serializable. Adding Serializable to
>>> the implemented interfaces in Pair does solve the problem (if also the
>>> change below is reverted, of course) but I don't think it would be wise
>>> unless we also enforce the two generic parameters of Pair to be
>>> serializable too. Perhaps we should use a Map<Localizable, Object[]>
>>> instead ?
>>>
>>> The problem also makes me think that we already had a similar bug in
>>> another part of the exceptions for a long time : the Object or Object[]
>>> parameters of the exceptions are stored and may not be Serializable too.
>>> This was never a problem either because the parameters are often simple
>>> primitive ones (int, double ...) or arrays so they were serializable.
>>> Perhaps we should change the signature from Object and Object[] to
>>> Serializable and Serializable[] ?
>>>
>>
>> Or make the fields transient?
>>
>> That would perhaps cause problems if the Exceptions were ever
>> serialised, but can that happen?
> 
> Yes, it's a typical JEE scenario and I cannot say how often I cursed Sun for 
> stuffing an unserializable object into NamingException.setResolvedObject 
> within their LDAP implementation ...
> 
> Actually the MathRE should contain a writeObject implementation that 
> replaces any non-serializable object in that array with some kind of 
> replacement (e.g. with its String representation). Otherwise the MathRE will 
> not reach its destination and all the localization was for nothing.

That's a good idea. We could even do that replacement directly at
construction and never store the Object themselves, regardless of their
status with respect to serialization.

Thanks Jörg

> 
> However, with a writeObject/readObject pair, such a field can be made 
> transparent, if the objects are put directly into the object streams.
> 
> Note, that anything of this requires a change of the serialVersionUID.
> 
> - Jörg
> 
> 
> ---------------------------------------------------------------------
> 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