[functor] Keep Serializable in [functor] or drop it?

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

[functor] Keep Serializable in [functor] or drop it?

Bruno P. Kinoshita
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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [functor] Keep Serializable in [functor] or drop it?

Bruno P. Kinoshita-2
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 <[hidden email]>
> To: Commons Developers List <[hidden email]>
> 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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [functor] Keep Serializable in [functor] or drop it?

Bruno P. Kinoshita
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 <[hidden email]>
> To: Commons List <[hidden email]>
> 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 <[hidden email]>
>>  To: Commons Developers List <[hidden email]>
>>  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: [hidden email]
For additional commands, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [functor] Keep Serializable in [functor] or drop it?

Benedikt Ritter-4
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 <[hidden email]>

> 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 <[hidden email]>
> > To: Commons List <[hidden email]>
> > 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 <[hidden email]>
> >>  To: Commons Developers List <[hidden email]>
> >>  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: [hidden email]
> For additional commands, e-mail: [hidden email]
>
>


--
http://people.apache.org/~britter/
http://www.systemoutprintln.de/
http://twitter.com/BenediktRitter
http://github.com/britter
Reply | Threaded
Open this post in threaded view
|

Re: [functor] Keep Serializable in [functor] or drop it?

Matt Benson-2
Sure, go ahead.  :)

Matt


On Thu, Oct 31, 2013 at 1:25 AM, Benedikt Ritter <[hidden email]> 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 <[hidden email]>
>
> > 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 <[hidden email]>
> > > To: Commons List <[hidden email]>
> > > 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 <[hidden email]>
> > >>  To: Commons Developers List <[hidden email]>
> > >>  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: [hidden email]
> > For additional commands, e-mail: [hidden email]
> >
> >
>
>
> --
> http://people.apache.org/~britter/
> http://www.systemoutprintln.de/
> http://twitter.com/BenediktRitter
> http://github.com/britter
>
Reply | Threaded
Open this post in threaded view
|

Re: [functor] Keep Serializable in [functor] or drop it?

Bruno P. Kinoshita
Done! Thanks!
 
Bruno P. Kinoshita
http://kinoshita.eti.br
http://tupilabs.com


----- Original Message -----

> From: Matt Benson <[hidden email]>
> To: Commons Developers List <[hidden email]>
> 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 <[hidden email]>
> 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 <[hidden email]>
>>
>>  > 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 <[hidden email]>
>>  > > To: Commons List <[hidden email]>
>>  > > 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 <[hidden email]>
>>  > >>  To: Commons Developers List <[hidden email]>
>>  > >>  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: [hidden email]
>>  > For additional commands, e-mail: [hidden email]
>>  >
>>  >
>>
>>
>>  --
>>  http://people.apache.org/~britter/
>>  http://www.systemoutprintln.de/
>>  http://twitter.com/BenediktRitter
>>  http://github.com/britter
>>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: [hidden email]
For additional commands, e-mail: [hidden email]