Thanks for your comments.
I realized I made a mistake when I had to reboot the VirtualBox, and the
second failure was also with the OpenJDK Client VM. I'm rerunning the
test now, but it is one failure every few hours.
On 2/16/2011 8:32 PM, Peter Firmstone wrote:
The code in ObjectOutputStream and ObjectStreamClass is a little flaky
too, both have non volatile, non final references which my not be
consistent between threads. ObjectStreamClass is first constructed then
initialized, perhaps it's reference is escaping before initialization.
Have you tried making field references in MarshalOutputStream and
MarshalInstanceOutputStream, final or volatile? I suspect the problem
originates in ObjectStreamClass.
I think it would be premature to attempt a fix, unless I were really
sure of the causes. Rather, I'm thinking about ways to increase the
failure rate, to make it easier to diagnose.
...
Is this test using FakeRMIClassLoaderSpi? If so, it might not throw a
null pointer exception for RMIClassLoadergetAnnotation(Class cl),
breaking the contract when cl is null.
How can I find out if it uses FakeRMIClassLoaderSpi?
When ObjectStreamClass.lookup(Class cl) looks up an object, if it
doesn't implement Serializable, it returns null.
ObjectOutputStream.writeObject(Object obj) is final, so we can't
override it, however this is an implementation of ObjectOutput, so we
could use a wrapper class to control synchronization and visibility, not
that I'm recommending it as the solution, we just might need to consider
refactoring so we can regain some control over visibility: "Favour
encapsulation over inheritance."
I agree. When I first started programming in Java, I was an inheritance
enthusiast, but I've shifted more and more towards encapsulation.
Patricia
