-1 on interfaces extending Serializable. It's poor form because it dilutes the
meaning of the interface, and also because it places a non-trivial requirement
on *every* implementation. Interfaces should extend Serializable only in the
rare case that serialization and deserialization of instances are essential
activities, thus inherent in the meaning of the interface. I realize that the
various implementations provided by Math probably can be serialized
successfully without any extra work, but it is unreasonable to assume that the
same will be true of all possible implementations (consider, for instance, a
matrix view of a dynamic, non-serializable data source). Also, do not neglect
the issue with binary compatibility of the serialized form.
+0 for making the implementations serializable, though if you do, I agree with
the recommendation to document the classes as not guaranteeing compatibility of
the serialized form. Moreover, consider making all Serializable classes
declare explicit serialVersionUID constants (preferrably sensible serial
numbers, i.e. 1) to make it easier and clearer for updated classes to maintain
serialization compatibility if they wish to do so. The down side of
serialVersionUID, of course, is that once you declare it, you have to maintain
it.
I don't view compiler warnings as a good justification for making the
interfaces extend Serializable. Yes, if the interfaces were Serializable then
the compiler would be happier, but your code wouldn't be much safer (vs. only
implementations being serializable). These are warnings that you want to have,
or it least that you want to explicitly suppress.
John Bollinger
________________________________
From: Ted Dunning <ted.dunn...@gmail.com>
To: Commons Developers List <dev@commons.apache.org>
Sent: Thursday, May 21, 2009 3:08:27 PM
Subject: Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
-1 on declaring things Serializable, especially if this is done everywhere.
Unless there is extensive testing and careful implementation, it is very,
very misleading to advertise this capability. In addition, there are a
number of formats which are reasonable candidates. Casting a particular
format in stone as the one true serialized format seems like a big mistake.
If you need to implement a serializable object, it is much better to mark
the field as transient and pick the wire format you really want to use from
a selection of alternatives.
On Thu, May 21, 2009 at 5:47 AM, sebb <seb...@gmail.com> wrote:
> Merely implementing Serializable will prevent the warnings, however in
> general it's not trivial to ensure that serialization works correctly.
>
--
Ted Dunning, CTO
DeepDyve
