commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <ki...@apache.org>
Subject Re: [functor] Keep Serializable in [functor] or drop it?
Date Mon, 11 Feb 2013 23:24:45 GMT
Hi all, 

Any objections to removing serialization from [functor]? Here's why I think we should drop
it: 

* It's been discussed in the mailing list in the past about other components dropping support
to serialization, I think [math] already had problems maintaining compatibility+serialization
[1]

* There are classes that create internal objects that, although not exposed to the users,
would have to be serialized or treated before being serialized. e.g.: IsEquivalent has a Comparator
field, that is passed in the constructor. When no comparator is given, it uses a comparator
that is bundled in [functor] (ComparableComparator) that implements Serializable. But if a
user wrote code like the below, it would raise an exception: 

        IsEquivalent<Double> isEq = new IsEquivalent<Double>(new Comparator<Double>()
{ // not serializable
            public int compare(Double o1, Double o2) {
                return (o1>o2 ? -1 : (o1==o2 ? 0 : 1));
            }
        });
        System.out.println(isEq.test(1.0, 2.0));
        System.out.println(isEq.test(1.0, 1.0));
        try {
            ByteArrayOutputStream bos = new ByteArrayOutputStream();
            ObjectOutputStream out = new ObjectOutputStream(bos);
            
            out.writeObject(isEq);
        } catch (Exception e) {
            throw new AssertionError(e);
        }

* A user may create a recursive function with several levels (think of thousands of levels
for this example, and see RecursiveEvaluation too). This could cause a StackOverFlow since
"the default serialization procedure performs a recursive traversal of the object graph" (Bloch).

* Also, there are classes in aggregator that don't support serialization yet (see o.a.c.functor.aggregator).

Thoughts on this? I've removed the serialization feature from [functor] in my GitHub mirror,
and the only major change required was removing existing tests that handled serialization.
Thus, the number of tests decreased to less than 1000 (we have now _only_ ~900 :-).

Most of the existing classes have a paragraph about serialization, but some don't (e.g.: IsEquivalent).
If we don't drop serialization, I'll fix that in the classes missing that paragraph. I intend
to use [functor] with Jenkins plug-ins, where serialization (and commons-jelly!) is used a
lot (it sends objects to the slaves), but I prefer to write proxies or some other trick to
serialize my functions, than have to deal with problems with different versions of [functor]
:-)

Thanks!
 
[1] http://markmail.org/thread/3dpionbxkzyktrno

Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


----- Original Message -----
> From: Bruno P. Kinoshita <brunodepaulak@yahoo.com.br>
> To: Commons Developers List <dev@commons.apache.org>
> Cc: 
> Sent: Monday, April 9, 2012 1:55 PM
> Subject: [functor] Keep Serializable in [functor] or drop it?
> 
> Hi all,
> 
> I was writing some tests for [functor] when I found that one of my tests was 
> failing with a NotSerializableException. The test uses a class that extends 
> PredicatedLoop. This class contains a Procedure and a Predicate member fields, 
> which are not serializable.
> 
> I remember seeing some discussion about keeping serialization support in the 
> API, or dropping it and letting the user handle this in his code.
> 
> Should we keep it or drop it? :)
> 
> If we decide to keep it:
> 
> - PredicatedLoop serializable but some of its members are not. We could make 
> them implement Serializable or use writeObject and readObject. If we went with 
> the former, a series of other changes would be required as well (Limit and 
> Offset don't implement equals or hashcode, for instance, and are used in 
> some tests of algorithms). The latter choice would require attention in case 
> someone changed the object members (adding/removing/...).
> 
> - Probably there are other classes in the same situation, then these classes 
> would have to be updated as well.
> 
> If we decide to drop the serialization support in [functor] API:
> 
> - Users would have to handle serialization in their code.
> 
> - We would have to refactor many functors
> 
> - The BaseFunctorTest methods related to serialization would be removed
> 
> - Javadoc would have to be updated in some classes as well
> 
> Many thanks in advance.
> 
> -- Bruno P. Kinoshita
> http://www.kinoshita.eti.br
> http://www.tupilabs.com
> 

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


Mime
View raw message