Request for Review: Consistent Behavior of Exceptions Chaining and CR 7081804 (original) (raw)

Sebastian Sickelmann sebastian.sickelmann at gmx.de
Tue Dec 27 19:13:33 UTC 2011

Am 26.12.2011 12:38, schrieb Weijun Wang:

On 12/26/2011 05:39 PM, Sebastian Sickelmann wrote: Hi,

one week ago (2011-12-15) [0] i asked for the downsides of changing the legacy Exceptions in core-libs. There where only one answer from "/Weijun Wang" who said that there may be serialisation issues. I With your current solution still using the cause field inside the child class, there is no serialisation issue at all. I had a solution (for javax/xml/crypto) that removes the field. But that was far to complex for this simple goal. In this solution i discussed with Alan Bateman how we can check that the serialized form in jdk8 can also be deserialized by jdk7 and prio. I came to the solution that we can diff the jdk7 diff and the jdk8 diff. And if it's equals, every thing is fine. There is one minor error in this assumption. I think there is a cutom-serialization-flag so that we cannot compare the serialization result binary. So i had the idea to compare hexdumps to make the compare more "sematically" and the kind of the difference more visible/readable. Haven't done that. If someone had another good idea who we can regression test serialization-compatibility (even backward) please let us/me know.

created a webrev[1] /with the suggested change and tests. The dumps inside the test directories are created with [3a,3b]. Don't know if there is the possibility to introduce such In/Outputstreams to I'm not sure the HexInputStream class is a good idea. There are quite a lot of different HEX output format, with different headers, sometimes ":" between successive HEX numbers, etc, etc. If the class is only able to recognize your own HexOutputStream, it might not be very useful. As for the output side, I use HexDumpEncoder. Of course, it's not a stream and it's sun-internal... Fine didn't know HexDumpEncoder till now. I will change the output to HexDumpEncoders version and modify my HexDumpInputStream to an HexDumpDecoder. I think an HexDumpDecoder that can only manage the internal HexDumpEncoders dumps is reasonable for the regression tests.

-Max

corelibs as well. @Sean Mullan: I updated the webrev[2] for the change in javax/xml/crypto to fit the excact behavior

[0] http://mail.openjdk.java.net/pipermail/core-libs-dev/2011-December/008721.html

[1] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/LegacyExceptions/webrev0/index.html [2] http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/70818049/index.html [3a] https://github.com/picpromusic/incubator/blob/master/misc/inc-utils/src/inc/main/DumpExceptions.java [3b] https://github.com/picpromusic/incubator/blob/master/misc/inc-utils/src/inc/util/HexDumpOutputstream.java

More information about the core-libs-dev mailing list