You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@commons.apache.org by "Bruno P. Kinoshita" <br...@yahoo.com.br> on 2013/11/01 13:43:02 UTC
Re: [functor] Keep Serializable in [functor] or drop it?
Done! Thanks!
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com
----- Original Message -----
> From: Matt Benson <gu...@gmail.com>
> To: Commons Developers List <de...@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 <br...@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 <br...@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 <ki...@apache.org>
>> > > To: Commons List <de...@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 <br...@yahoo.com.br>
>> > >> To: Commons Developers List <de...@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