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