commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bruno P. Kinoshita" <brunodepau...@yahoo.com.br>
Subject Re: [functor] Keep Serializable in [functor] or drop it?
Date Fri, 01 Nov 2013 12:43:02 GMT
Done! Thanks!
 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


----- Original Message -----
> From: Matt Benson <gudnabrsam@gmail.com>
> To: Commons Developers List <dev@commons.apache.org>
> Cc: 
> Sent: Thursday, October 31, 2013 1:09 PM
> Subject: Re: [functor] Keep Serializable in [functor] or drop it?
> 
> Sure, go ahead.  :)
> 
> Matt
> 
> 
> 
> On Thu, Oct 31, 2013 at 1:25 AM, Benedikt Ritter <britter@apache.org> 
> wrote:
> 
>>  Makes sense for me t dro serialization support for 1.0. If users really
>>  demand it, it can be added afterwards.
>> 
>>  Benedikt
>> 
>>  2013/10/31 Bruno P. Kinoshita <brunodepaulak@yahoo.com.br>
>> 
>>  > 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 <kinow@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 <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
>>  >
>>  >
>> 
>> 
>>  --
>>  http://people.apache.org/~britter/
>>  http://www.systemoutprintln.de/
>>  http://twitter.com/BenediktRitter
>>  http://github.com/britter
>> 
> 

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


Mime
View raw message