On Mon, 23 Apr 2007, Daniel Rall wrote:
> 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.
Blair, can you do this?
> ... 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.
I've done this in r24797.
- application/pgp-signature attachment: stored
Received on Fri Apr 27 00:05:31 2007