Re: JavaHL: Serializable and breaking binary compatibility?

On Mon, 23 Apr 2007, Mark Phippard wrote:

> On 4/23/07, Blair Zajac <blair@orcaware.com> wrote:
> >I needed to serialize a Revision and discovered that the class doesn't
> >implement java.io.Serializable.
> >
> >I have a patch ready that serialized this class and any other class that
> >doesn't include native methods and just acts like a C structure for data.
> >
> >ChangePath
> >CommitItem
> >CopySource
> >DirEntry
> >Info
> >Info2
> >Lock
> >MergeInfo
> >ProgressEvent
> >Revision
> >RevisionRange
> >Status
> >
> >Will this break Java code that compiled against the old,
> >non-serializable classes?
>
> No. The only thing that would break old clients is removing methods
> that used to exist or making them work differently. Making classes
> Serializable will not do that.

Yup, we're safe here.

> >Thoughts?
>
> My only concern is maintaining it properly. Handling serializing old
> versions etc. OTOH, we probably do not change data elements very
> often, so it is not likely too big of a deal.

Another problem with Java Serialization is that not just your class
needs to implement Serializable, but every Object referenced by any
instance fields in your class -- or in turn referenced by their
instance fields, and so on -- must also implement Serializable. While
in JavaHL's case this is likely doable, it's often more difficult when
you don't control referenced classes.

Since doing this for JavaHL does add maintenance overhead, I'd like to
see a regression test introduced which serializes instances of all of
these class types to help assure that they remain serializable as the
code base changes over time. To create instances of some of these
classes, you may need to add a test which lives in the same root
"org.tigris.subversion.javahl" package as the majority of the code.

It's actually a Java best practice to split your unit test and
application code into two orthogonal source trees (e.g. "src/" and
"test/"), to easily access protected or package-private members from
the unit test code (like some of the constructors), while still
providing a clear separation -- by way of directory layout -- between
application and unit test code. I've been meaning to take this simple
step for quite some time, but other things have been more pressing.

Thanks, Dan