Done! Thanks! Bruno P. Kinoshita http://kinoshita.eti.br http://tupilabs.com
----- Original Message ----- > From: Matt Benson <gudnabr...@gmail.com> > To: Commons Developers List <dev@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 <brit...@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 <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 >> > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org For additional commands, e-mail: dev-h...@commons.apache.org
