Re: Request-Review: Remove two simple warnings in HttpsURLConnection.java

Xuelei Fan wrote: 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. I don't think there is

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

hg: jdk8/tl/jdk: 2 new changesets

Changeset: 973d923af88c Author:sherman Date: 2011-08-26 15:36 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/973d923af88c 7077769: (zipfs) ZipFileSystem.writeCEN() writes wrong "data size" for ZIP64 extended information extra field Summary: fixed the wrong size when writing

Re: Request-Review: Remove two simple warnings in HttpsURLConnection.java

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.

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 i

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

Re: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile)

On Aug 26, 2011, at 7:08 AM, Chris Hegarty wrote: > On 08/26/11 02:45 PM, Sean Mullan wrote: >> 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

7024771 code review request

Hi Vinnie, Could you review the following webrev: http://cr.openjdk.java.net/~mullan/webrevs/7024771/webrev.00/ A couple of notes on the webrev: - I have removed support for DNs which use <> as delimiters, ex "". This is an obscure syntax that I have never seen used in practice, and our parser

Re: Fix for: 6415637: PKCS#12 key stores with empty passwords

On Aug 26, 2011, at 10:52 PM, Florian Weimer wrote: > * Weijun Wang: > >> I think security changeset should go to tl forest first. > > Is this ? Yes. > > This forest rejects OpenJDK 6 as a bootstrap compiler. Do I need a > working build of OpenJDK 7 fir

Re: Fix for: 6415637: PKCS#12 key stores with empty passwords

* Weijun Wang: > I think security changeset should go to tl forest first. Is this ? This forest rejects OpenJDK 6 as a bootstrap compiler. Do I need a working build of OpenJDK 7 first? -- Florian Weimer BFK edv-consulting GmbH http://w

Re: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile)

On 08/26/11 02:45 PM, Sean Mullan wrote: 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 por

Re: code review request: 7083576 (was Re: no javax/xml/crypto jprt test targets in jdk/test/Makefile)

On 08/26/2011 09:45 PM, Sean Mullan wrote: 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

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

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 P

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

Re: Request for review Remove "private" cause in jdk exceptions

Am 26.08.2011 09:22, schrieb Alan Bateman: 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.

Re: Request for review Remove "private" cause in jdk exceptions

Am 26.08.2011 08:32, schrieb Peter Jones: On Aug 25, 2011, at 8:00 PM, Sebastian Sickelmann wrote: Am 26.08.2011 00:24, schrieb Sebastian Sickelmann: Am 26.08.2011 00:03, schrieb Sebastian Sickelmann: I have found more places in jdk source where an Exception has a private cause field. share/

hg: jdk8/tl/jdk: 7024697: SessionRef.dispose() should determine if the token referred to by the token object is still valid

Changeset: 3a13b7ab57f7 Author:coffeys Date: 2011-08-26 10:47 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3a13b7ab57f7 7024697: SessionRef.dispose() should determine if the token referred to by the token object is still valid Reviewed-by: valeriep ! src/share/classes/sun

Re: Fix for: 6415637: PKCS#12 key stores with empty passwords

I think security changeset should go to tl forest first. -Max On 08/26/2011 03:35 PM, Florian Weimer wrote: * Florian Weimer: Presumably, this does not count as a small change, so BFK needs to sign a contributor agreement. Is the sun.com email address still the right one to submit the scanne

Re: Fix for: 6415637: PKCS#12 key stores with empty passwords

* Florian Weimer: > Presumably, this does not count as a small change, so BFK needs to sign > a contributor agreement. Is the sun.com email address still the right > one to submit the scanned copy? We got the paperwork sorted out, so we can start work on the process of getting the change in. Ma

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

Re: Enhance toString() to return structured info, for certificate and probably more

* Weijun Wang: > What's your ideas? Do you also need such a method? I suspect that many applications which need to look at certificates in detail would benefit more from an official ASN.1 decoder. Defining yet another data model for X.509 certificates (after ASN.1 and the current Java API) seems