Patricia Shanahan wrote:
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?
I'll have to read the source and get back to you, since it's an SPI
(service provider interface), it would have to be set in a jar file
manifest.
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
