The next version of webrev:
http://cr.openjdk.java.net/~dmeetry/8009581/webrev.4/
<http://cr.openjdk.java.net/%7Edmeetry/8009581/webrev.4/>
The list of changes:
1. The test was moved to jdk/test/javax/xml/jaxp/XPath/8009579
2. Throw of InvalidClassException was added
3. Two test cases were added:
a) Deserialization of XPathException initialized by ordinary values
and serialized by JDK7 build (normal_jdk7.ser file)
b) Deserialization of "new XPathException(new
Exception()).initCause(null)" XPathException serialized by JDK7 build
(twocauses_jdk7.ser file).
-Aleksej
On 05/31/2013 06:20 PM, Alan Bateman wrote:
On 31/05/2013 14:39, Aleksej Efimov wrote:
Obviously, we can't throw the ISE - it's not described in docs for
readObject() method.
Exceptions suggested by Jason have the following descriptions:
InvalidClassException: Something is wrong with a class used by
serialization.
StreamCorruptedException: Control information in the stream is
inconsistent.
I think InvalidClassException more suitable for our case, because we
have here the problem with inconsistent state of serialized class,
but not the control information in the stream (invalid stream header,
invalid type code and etc).
Aleksej
Yes, InvalidClassException would be best.
I see you've added a serialization/deserialization test (thanks) but
it wouldn't have caught this. What would you think about serializing a
few XPathException instances with a jdk7 build and use the byte stream
in the test to check that they are handled correctly. That would give
more confident that there aren't any other holes.
-Alan
