Re: Reviewer and committer request for 7197642

2012-10-02 Thread Paul Sandoz
On Oct 1, 2012, at 7:35 PM, Alan Bateman alan.bate...@oracle.com wrote: On 01/10/2012 14:14, Paul Sandoz wrote: Hi, See here: http://cr.openjdk.java.net/~psandoz/tl/7197642/webrev/ Thanks, Paul. If I have it right, this moves the NPE from the ServiceLoader's iterator methods to

Re: ServiceLoader.load(Class, ClassLoader) bug

2012-10-02 Thread Paul Sandoz
Hi Peter, On Oct 1, 2012, at 7:00 PM, Peter Levart peter.lev...@gmail.com wrote: Hi Paul, It would be very strange code indeed that acted on the ServiceConfigurationError in a way that you describe. After all, the java.lang.Error hierarchy of throwables is reserved for things that should

Re: RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent

2012-10-02 Thread Chris Hegarty
On 01/10/12 22:46, Martin Buchholz wrote: On Mon, Oct 1, 2012 at 2:22 PM, Jim Gish jim.g...@oracle.com wrote: Alan Chris, However, let me propose something else. How about /all /the methods in StringBuffer be synchronized? Although this is not strictly necessary, it works because reentrant

Re: RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent

2012-10-02 Thread Alan Bateman
On 01/10/2012 22:22, Jim Gish wrote: Alan Chris, I agree with you that the new approach is less clear than the previous approach, but the original approach suffered from code duplication which was the motivation for the change. However, let me propose something else. How about /all /the

hg: jdk8/tl/jdk: 7050528: Improve performance of java.text.DecimalFormat.format() call stack

2012-10-02 Thread alan . bateman
Changeset: 75080f572f84 Author:olagneau Date: 2012-10-02 10:11 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/75080f572f84 7050528: Improve performance of java.text.DecimalFormat.format() call stack Reviewed-by: darcy ! src/share/classes/java/text/DecimalFormat.java !

hg: jdk8/tl/jdk: 7197642: (sl) ServiceLoader.load(null) doesn't throw NPE

2012-10-02 Thread alan . bateman
Changeset: 041c687c4f40 Author:psandoz Date: 2012-10-02 10:36 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/041c687c4f40 7197642: (sl) ServiceLoader.load(null) doesn't throw NPE Reviewed-by: alanb ! src/share/classes/java/util/ServiceLoader.java +

hg: jdk8/tl/jdk: 8000268: sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit

2012-10-02 Thread alan . bateman
Changeset: 6750ab947255 Author:alanb Date: 2012-10-02 12:23 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/6750ab947255 8000268: sun/security/provider/X509Factory/BigCRL.java failing on Linux 32-bit Reviewed-by: mullan ! test/sun/security/provider/X509Factory/BigCRL.java

Re: RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent

2012-10-02 Thread Jim Gish
Ok -- I have some comments prepared, so I'll wrap it up with that. However, I am curious about suggested approaches for tests to ensure that methods are synchronizing properly ( as I mentioned in my message below ). Thanks, Jim On 10/02/2012 05:07 AM, Alan Bateman wrote: On 01/10/2012

Re: RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent

2012-10-02 Thread Vitaly Davidovich
Jim, how about an assert with Thread.holdsLock() work for tests? Sent from my phone On Oct 2, 2012 9:34 AM, Jim Gish jim.g...@oracle.com wrote: Ok -- I have some comments prepared, so I'll wrap it up with that. However, I am curious about suggested approaches for tests to ensure that methods

Re: RFR: 6206780 (str) Forwarding append methods in String{Buffer, Builder} are inconsistent

2012-10-02 Thread Alan Bateman
On 02/10/2012 18:20, Vitaly Davidovich wrote: Jim, how about an assert with Thread.holdsLock() work for tests? A concern is that this could disrupt the inlining. In any case, I think Jim has figured out how to test this with a blackbox test. If nothing else, at least this exercise should

Review Request for 8000333 - Typo in : java.io.ObjectOutputStream.reset() refered

2012-10-02 Thread Dan Xu
Hi, This is a simple fix to correct a typo in the java doc. Please review the change at http://cr.openjdk.java.net/~dxu/8000333/webrev/. Thanks! -Dan