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
