On Thu, 26 Apr 2007, Blair Zajac wrote:
>
> On Apr 26, 2007, at 3:05 PM, Daniel Rall wrote:
>
> >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:
...
> >>>>ChangePath
> >>>>CommitItem
> >>>>CopySource
> >>>>DirEntry
> >>>>Info
> >>>>Info2
> >>>>Lock
> >>>>MergeInfo
> >>>>ProgressEvent
> >>>>Revision
> >>>>RevisionRange
> >>>>Status
...
> >>>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?
>
> I'll do that.
Thanks!
> Should we have tests where we serialize instances of the existing
> classes to disk, commit them into svn, and then attempt to read them
> back in the test suite with the class? This will catch when somebody
> makes an incompatible change.
...
That's even more thorough than I'd hoped for. I'd be statisfied with
a simple serialization (preferably in-memory, to keep the tests
running faster), but your suggested addition of de-serialization is
better.
- Dan
- application/pgp-signature attachment: stored
Received on Fri Apr 27 01:29:54 2007