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 <brunodepau...@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 <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 > > -- http://people.apache.org/~britter/ http://www.systemoutprintln.de/ http://twitter.com/BenediktRitter http://github.com/britter
