Re: [Jsynthlib-devel] test refactor branch

[Chris W. <chr...@ch...>]

Chris Wareham said on 26/12/11 11:37:
> Martin Tarenskeen said on 26/12/11 08:54:
>>
>> Hi,
>>
>> I'm trying the refactor branch from SVN. I have not done much testing yet
>> but it seems I am getting error messages, and failure, if I try to load a
>> (for example) TX81Z xxx.patchlib from the current trunk in the new
>> refactor version. Creating and then loading a new xxx.patchlib library
>> works fine.
>>
>> Has backward compatibility been broken on purpose ?
>>
>
> Damn, I'd forgotten about one of the changes I'd made - the
> de-serialisation of existing patchlibs wont work, as I converted several
> members from StringBuffers to Strings. I'll write a converter for old
> style patches by implementing a custom deserialisation method and
> checking the sereial version UID. I should get a chance to do it
> tomorrow (Tuesday 27th UK time).
>
> Regards,
>
> Chris
>

Hi Martin,

I've implemented a readObject method in the Patch class, which attempts 
to deserialize bothe the new version of the class and the previous one 
that used StringBuffers for three of the data members.

I have a nasty feeling that this still won't work, as the Patch class 
has also moved from a "core" package to an "org.jsynthlib.core" one, so 
the deserialization may not even get as far as my readObject method.

Relying on serialised objects for long-term persistence, particularly 
when the data isn't held in another form as well (such an RDBMS or flat 
files), is asking for trouble. With JSynthLib in particular, the rather 
messy class hierarchy makes things even worse.

If you could let me have any stack trace from attempting to read a patch 
library, and possibly a copy of the patchlib itself, then that would be 
most helpful for me to try and come up with a solution.

Regards,

Chris