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 <brunodepau...@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-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org
