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
