commons-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From John Bollinger <>
Subject Re: [math] Re: commons-math, matrix-toolkits-java and consolidation
Date Thu, 21 May 2009 20:54:09 GMT
-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

+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 <>
To: Commons Developers List <>
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 <> wrote:

> Merely implementing Serializable will prevent the warnings, however in
> general it's not trivial to ensure that serialization works correctly.

Ted Dunning, CTO

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message