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 >
