Am 22.08.2011 17:28, schrieb Sean Mullan:
(dropping core-libs-dev)
On 8/22/11 9:03 AM, Sebastian Sickelmann wrote:
Hi,
while making some change for using exception-chaining on RuntimeException in
more cases, i found that javax.xml.crypto.NoSuchMechnismException had a private
cause field that isn't necessary since throwable can handle it. But just
removing isn't that simple as Alan pointed out[1].
The history behind this is that this API is part of JSR 105. JSR 105 was
released independently of Java SE as a "standalone JSR" and later integrated
into Java SE 6 as part of the platform JSR. Thus as I understand, all JSR 105
API changes need to first go through a maintenance revision of JSR 105.
JSR 105 was designed to be used by applications using JDK 1.2 and up, thus there
are no API dependencies on any releases later than that. Therefore, this class
(and other exception classes in JSR 105) included their own methods to capture
the cause.
I've been aware of this issue for a little while but I did not have the cycles
to analyze it thoroughly so I am glad you are looking into it.
I think you will find the same issue in the other Exception classes in the
javax.xml.crypto package and its subpackages. Have you looked at those yet?
Yes. It is also in:
dsig/XMLSignatureException.java: private Throwable cause;
dsig/TransformException.java: private Throwable cause;
KeySelectorException.java: private Throwable cause;
MarshalException.java: private Throwable cause;
URIReferenceException.java: private Throwable cause;
I am not sure if removing the 3 overloaded methods qualifies as an API change.
If so, it would first require it go through a maintenance JSR. I will need to
ask someone else about that and get back to you.
I don't think that it is an api change. It should at least be source
compatible.
I will make a check if its is binary compatible, too. Then there
shouldn't be any problem isn't it?
First of all i thought just changing the serialversionUID was the right
solution, but Alan disagreed and i actually think that too. Unfortunatly Alan
doen't had the time to explain it in detail, but i think that we must search for
a solution that doen't break backward serialization compatability.
I created a webrev for my suggested change here:
http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2/
In a following post Alan writes that this should best be discussed here. What is
the hg repository for patches in this mailinglist? I don't see any security-dev
related repository for openjdk8 in http://hg.openjdk.java.net/ the patch is
based on ***<http://hg.openjdk.java.net/jdk8/tl/jdk/>*jdk8/tl/jdk maybe i
should rebase it onto another repository.
Another problem i have is testing. I think we should add some test for this. But
got no real clue how to do it right. I tested it manually with the source
here[2] and the files in here[3].
The files are created with an openjdk7 build(Unfortunatly i think with an quite
old private build) and with an openjdk8(with my patches to
NoSuchMechanismException). I tested it manually with my openjdk 7 and 8 build
and in both cases the serialized objects could be loaded correctly in all cases.
What is the best way to test this automatically. I thought about checking if the
newly created openjdk8 serialization is binary equal to the jdk7 output, but it
isn't because of some unavoidable changes (ex. jdk8 has the
custom-serialization-bit)
Alan mentioned that it may be ok to embed some serialized-objects as byte[] in
testcode.
Yes, that is probably the best solution. I remember I had created some tests for
this a while back. I'll see if I can find them.
I will try to create a jtreg for this. Hope to be back on this soon. In the
meantime it would be great to have someone reviewed the webrev.
I am pretty busy but will try to find some cycles to review it more carefully in
the next couple of days.
No Problem, i will prepare the tests. Thanks for taking the time.
--Sean
-- Sebastian
