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:
>>>> 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?
I'll do that.
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.
>
>> ... 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.
Thanks,
Blair
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Fri Apr 27 00:44:14 2007