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

[Weijun Wang]

On 12/28/2011 03:13 AM, Sebastian Sickelmann wrote:
> 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.

I don't think you can compare the binary or hexdump, maybe the order of 
2 fields can change. (is that possible?)  It should be OK if you can 
serialize with one version and deserialize with the other.

Given that all your changes are made on methods and not fields and all 
classes already have their serialVer field, I don't think there is a 
possibility that the serialization format would change.

I had a test on a similar case:

http://hg.openjdk.java.net/jdk8/tl/jdk/file/3c1ab134db71/test/sun/security/util/Oid/S11N.sh

It's based on my belief that computers inside the Oracle network should 
see all versions of Java on /java/re/...  Until now, this is still 
correct here.

>
>>
>>> 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.

Why not just serialize the byte[] objects into an ObjectOutputStream? I 
know a lot of people don't like binary files in a test, but the cryptic 
hexdump is no better than that.

Thanks
Max


>
>>
>> -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
>>>
>>>
>>>
>