commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Benson <gudnabr...@gmail.com>
Subject Re: [functor] Keep Serializable in [functor] or drop it?
Date Thu, 31 Oct 2013 15:09:30 GMT
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
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message