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
