Hi all, 

I posted it in the mailing list some time ago and now I will have time to work 
on this during the next days. I've flled FUNCTOR-29 to work on this. Let me 
know if there are any objections to this.

Thanks!

[1] https://issues.apache.org/jira/browse/FUNCTOR-29
 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


----- Original Message -----
> From: Bruno P. Kinoshita <ki...@apache.org>
> To: Commons List <dev@commons.apache.org>
> Cc: 
> Sent: Monday, February 11, 2013 9:24 PM
> Subject: Re: [functor] Keep Serializable in [functor] or drop it?
> 
> 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

Reply via email to