Re: McKoi db error

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Geert" == Geert Bevin <gbevin at uwyn dot com> writes:

Geert> The Serializable interface documents that when the
Geert> serialization requires special handling both the readObject and
Geert> writeObject methods should be implemented. Apparently most jdk
Geert> implementation provide the default implementation if either one
Geert> isn't implemented, but gcj apparently takes the other route.

If readObject and writeObject aren't implemented, all serialization
implementations are required to fall back on the default behavior.
Are you saying that libgcj doesn't do this in some situation?
That would be a libgcj bug.

Geert> But, after hours of searching I couldn't replicate the problem in
Geert> memory. Then I decided to check what the bytes are that are available
Geert> after serialization and what the ones are that are available for
Geert> deserialization. I came to the constatation that they are very
Geert> different. In fact after 109 bytes, the rest of the byte array that is
Geert> provided to the deserialization method is filled with bytes that are
Geert> equal to 0! Therefore it's of course impossible to deserialize
Geert> correctly.
Geert> Is there something known about the IO of the current 3.3
Geert> branch?

I don't know of any java.io bugs that would cause this behavior.
It is possible that you've run into a serialization bug, however.
The easiest way to tell would be to try to reduce it to a simple test
case.  You could also look through gnats to see if there are other
serialization bugs; maybe you've run into a known one.  I'm afraid
this is an area that hasn't gotten a lot of attention in the past.

Tom