Request for Review: Consistent Behavior of Exceptions Chaining and CR 7081804

[Sebastian Sickelmann]

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/webrev_0/index.html 
>>
>>
>>
>> [2]
>> http://dl.dropbox.com/u/43692695/oss-patches/openjdk8/NoSuchMechanismException/7081804_9/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 
>>
>>
>>