Re: Request for review Remove private cause in jdk exceptions
Sebastian Sickelmann wrote: OK. Webrev is there: http://oss-patches.24.eu/openjdk8/NoSuchMechanismException/REBASED_ON_8018d541a7b2_2/ Can someone review this? I think this one will require careful review and I'm not even sure that it's worth it. Using serialPersistentFields and overriding the readObject/writeObject method is the right thing for this kind of issue but it's bringing complexity that hardy seems worth it. There are a few awkward issues in here. I have to admit that I don't know, without checking, what the deal is with APIs that continued life as standalone JSRs after going into Java SE. I also suspect that some of these changes have subtly changed the behavior of a few of the exceptions. On RemoteException the patch removes a public field which we can't do. I think the other clean-up patches that you have posted here in the last week or two are good and we should move forward on them. -Alan.
Re: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile)
Looks fine though you missed updating the copyright date on the test. --Sean On 8/25/11 9:44 PM, Weijun Wang wrote: [ Add security-dev@openjdk.java.net to CC] I think so. javax/xml/crypto is public API and it should go to jdk_security2 (along with javax/crypto). Of course, that is still not included in the default run. I've filed a bug: 7083576: add javax/xml/crypto into jdk_security2 test rule and here is a webrev: http://cr.openjdk.java.net/~weijun/7083576/webrev.00 Note that one test now uses /othervm because it loads a SecurityManager with its own policy file. JPRT runs fine except that one windows-i586 job is still initializing. Ignored. Thanks Max On 08/26/2011 03:26 AM, Sean Mullan wrote: I noticed that none of the jprt test targets in test/Makefile run tests in the javax/xml/crypto directory (i.e. JSR 105 tests) - would that be considered a bug? --Sean
Re: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile)
On 08/26/2011 09:15 PM, Sean Mullan wrote: Looks fine though you missed updating the copyright date on the test. Recently I form a new habit of not touching copyright years at all, so that a changeset can be ported to another version with no change at all. -Max --Sean On 8/25/11 9:44 PM, Weijun Wang wrote: [ Add security-dev@openjdk.java.net to CC] I think so. javax/xml/crypto is public API and it should go to jdk_security2 (along with javax/crypto). Of course, that is still not included in the default run. I've filed a bug: 7083576: add javax/xml/crypto into jdk_security2 test rule and here is a webrev: http://cr.openjdk.java.net/~weijun/7083576/webrev.00 Note that one test now uses /othervm because it loads a SecurityManager with its own policy file. JPRT runs fine except that one windows-i586 job is still initializing. Ignored. Thanks Max On 08/26/2011 03:26 AM, Sean Mullan wrote: I noticed that none of the jprt test targets in test/Makefile run tests in the javax/xml/crypto directory (i.e. JSR 105 tests) - would that be considered a bug? --Sean
Re: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile)
On 8/26/11 9:42 AM, Weijun Wang wrote: On 08/26/2011 09:15 PM, Sean Mullan wrote: Looks fine though you missed updating the copyright date on the test. Recently I form a new habit of not touching copyright years at all, so that a changeset can be ported to another version with no change at all. Ok, so does that mean someone else will update the copyright later on? --Sean
hg: jdk8/tl/jdk: 7060243: (dc) Multicasting tests fail on Windows XP if IPv6 is enabled
Changeset: 6d2f09eed4e3 Author:alanb Date: 2011-08-26 22:24 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6d2f09eed4e3 7060243: (dc) Multicasting tests fail on Windows XP if IPv6 is enabled Reviewed-by: alanb Contributed-by: kurchi.subhra.ha...@oracle.com ! test/java/nio/channels/DatagramChannel/NetworkConfiguration.java
Re: 7081804: Remove cause field from javax.xml.crypto.NoSuchMechnismException
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? 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 checked it for binary compatibility and source compatibility and it seems to me that both are preserved. So i don't see any reason cause this should be handled as API change. Have you heard something about this topic? I have a discussion with Peter Jones and Alan Bateman in this Thread (swapped over to core-libs-dev again, cause i made bigger CR) there is also a other way of handling cause chaining in a way more like Trowable.cause. I think we should consider to choose this type of change for javax/xml/crypto too. So we got only one pattern how to use Throwable.cause in cases where a cause-chain was available long time before. -- Sebastian
Re: Request-Review: Remove two simple warnings in HttpsURLConnection.java
Hi Sebastian, Thank you for your contribution on OpenJDK. The update looks fine to me. Do you have a CR (Change Request) for this update? BTW, have you signed the Oracle Contribution Agreement [1]? I did not find you name in the OpenJDK people list. Thanks, Xuelei [1] http://openjdk.java.net/contribute/ On 8/27/2011 5:45 AM, Alan Bateman wrote: Sebastian Sickelmann wrote: Hi, is there someone who wants to review / support this simple warning removal? The webrev is: http://oss-patches.24.eu/openjdk8/Simple_Warning/ -- Sebastian* * This is JSSE so probably best if someone from the security area pushes this for Sebastian. -Alan.
