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

Weijun Wang weijun.wang at oracle.com
Mon Dec 26 11:38:20 UTC 2011

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.

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

-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