----- Original Message ----- From: "Ted Dunning" <ted.dunn...@gmail.com>
To: "Commons Developers List" <dev@commons.apache.org>
Sent: Sunday, May 24, 2009 11:47 PM
Subject: Re: [math] Serialization


Bill,

Did you commit those changes?


Yes, but just for o.a.c.m.linear.

I ask because I see similar issues with abstract and static classes. Gamma
is an example of the static class issue.  This class has only static
methods, but it is marked as serializable (why?).  ContinuedFraction is a
good example of an abstract class that is marked as serializable.  This
latter case leads to code that is either strange or incorrect. The strange
version has a version identifier even on anonymous classes as in this code
here:

I didn't say that I was finished ;)


        // create continued fraction
           ContinuedFraction cf = new ContinuedFraction() {

               private static final long serialVersionUID =
5378525034886164398L;

               @Override
               protected double getA(int n, double x) {
                   return ((2.0 * n) + 1.0) - a + x;
               }

               @Override
               protected double getB(int n, double x) {
                   return n * (a - n);
               }
           };

           ret = 1.0 / cf.evaluate(x, epsilon, maxIterations);
           ret = Math.exp(-x + (a * Math.log(x)) - logGamma(a)) * ret;

If the serialVersionUID is ommitted, the anonymous class would be
incorrectly serialized because it would inherit it's parent UID (I think).
More importantly, I can't imagine why an abstract class like
ContinuedFraction should be serializable.

On Sun, May 24, 2009 at 6:10 PM, Bill Barker <billwbar...@verizon.net>wrote:

Ok, most of the rest look like transient classes (e.g. all of
linear.decomposition). So asking for what needs to be Serialized, and what
doesn't.




--
Ted Dunning, CTO
DeepDyve



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@commons.apache.org
For additional commands, e-mail: dev-h...@commons.apache.org

Reply via email to