Re: Proxy.isProxyClass scalability

Hi Peter, We both prefer the interface types as the subKey.See my comment inlined below. On 4/23/2013 11:58 PM, Peter Levart wrote: I developed two different approaches: 1. Key made of WeakReference-s to interface Class objects. Strong points: - no key aliasing, validation can be pushed

Re: Review Request for JDK-8012937: Correct errors in javadoc comments

Please remove lines 157-159; otherwise, looks fine. Thanks, -Joe On 04/24/2013 09:35 AM, Eric McCorkle wrote: Any further comments, or is this one good to go? On 04/23/13 19:54, Joseph Darcy wrote: Acknowledged; thanks for checking, -Joe On 4/23/2013 7:46 AM, Eric McCorkle wrote: I believ

Re: Proxy.isProxyClass scalability

On 4/23/2013 11:58 PM, Peter Levart wrote: The isAssignableFrom check should be correct for well-behaved class loaders [1]. However, for non well-behaved class loaders, I'm not absolutely confident that this is right. The case that I was concerned is when intf.isAssignableFrom(proxyClass) re

Re-Review: 7032154 - Performance tuning of sun.misc.FloatingDecimal/FormattedFloatingDecimal

Hello, Re-post of the proposed fix for http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7032154. The updated webrev is at http://cr.openjdk.java.net/~bpb/7032154/. Since this change proposal was originally posted, more extensive review and testing has been performed, a couple of bugs found a

RFR:7184195 - java.util.logging.Logger.getGlobal().info() doesn't log without configuration

Please review http://cr.openjdk.java.net/~jgish/Bug7184195-global-logger-failure.1/ This is a simple fix that removes a long-standing bug in acquiring a using the global Logger in which Logger.getGlobal().info() (for ex

hg: jdk8/tl/jdk: 8012638: test/java/time/test/java/util/TestFormatter fails in UTC TZ

Changeset: 8c06a38aa2c5 Author:sherman Date: 2013-04-24 21:27 + URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8c06a38aa2c5 8012638: test/java/time/test/java/util/TestFormatter fails in UTC TZ Summary: updated the offending test case Reviewed-by: alanb ! test/java/time/test/ja

Re: RFR: 7150256: Add back Diagnostic Command JMX API

Hi Frederic, I reviewed the jdk webrev that is looking good. I reviewed com.sun.management.DiagnosticCommandMBean spec almost half a year ago. Reviewing it now with a fresh memory has some benefit that I have a few comments on the spec. java.lang.management.PlatformManagedObject is specifi

hg: jdk8/tl/jdk: 8005555: TEST_BUG: java/io/Serializable/accessConstants/AccessConstants.java should be removed

Changeset: bbcebf893b83 Author:alanb Date: 2013-04-24 19:03 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bbcebf893b83 800: TEST_BUG: java/io/Serializable/accessConstants/AccessConstants.java should be removed Reviewed-by: chegar - test/java/io/Serializable/accessConst

Re: RFR 8009581: Xpathexception does not honor initcause()

On 24/04/2013 14:53, Aleksej Efimov wrote: Hi all, Can I have a reviews for the following change: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.0/ Summary: There is an erroneous behavior in 'initCause' method of javax.xml.xpath.X

Re: RFR: 8005051: optimized defaults for Iterator.forEachRemaining

On 24/04/2013 18:24, Akhil Arora wrote: Good question. forEachRemaining docs state - Implementation Requirements: The default implementation behaves as if: while (hasNext()) action.accept(next()); so a subsequent remove() should remove the last element. That specifies ho

Re: RFR: 8005051: optimized defaults for Iterator.forEachRemaining

On 04/24/2013 07:24 PM, Akhil Arora wrote: On 04/24/2013 06:19 AM, Alan Bateman wrote: On 23/04/2013 20:18, Akhil Arora wrote: On 04/22/2013 11:42 AM, Alan Bateman wrote: One thing I meant to ask when forEachRemaining was added was whether it should say anything about the "last element"? I se

Re: RFR: 8005051: optimized defaults for Iterator.forEachRemaining

On 04/24/2013 06:19 AM, Alan Bateman wrote: On 23/04/2013 20:18, Akhil Arora wrote: On 04/22/2013 11:42 AM, Alan Bateman wrote: One thing I meant to ask when forEachRemaining was added was whether it should say anything about the "last element"? I see in the webrev that you've set it for the Ar

Re: Review Request for JDK-8012937: Correct errors in javadoc comments

Any further comments, or is this one good to go? On 04/23/13 19:54, Joseph Darcy wrote: > Acknowledged; thanks for checking, > > -Joe > > On 4/23/2013 7:46 AM, Eric McCorkle wrote: >> I believe so. Alex Buckley recommended the exact wording. >> >> On 04/22/13 22:09, Joseph Darcy wrote: >>> Hell

Re: 8005555: TEST_BUG: java/io/Serializable/accessConstants/AccessConstants.java can probably be removed

On 04/24/2013 05:15 PM, Alan Bateman wrote: This test has been failing recently for me with the error "No action after @build", I think possibly related to an update in jtreg (I built jtreg from code-tools-jtreg). The test is a compile-only test, it doesn't actually run or do anything. It basic

8005555: TEST_BUG: java/io/Serializable/accessConstants/AccessConstants.java can probably be removed

This test has been failing recently for me with the error "No action after @build", I think possibly related to an update in jtreg (I built jtreg from code-tools-jtreg). The test is a compile-only test, it doesn't actually run or do anything. It basically just tests that ObjectStreamConstant

Re: Codereview request: 8012638: test/java/time/test/java/util/TestFormatter fails in UTC TZ

On 22/04/2013 19:32, Xueming Shen wrote: Hi, This is a "test regression" caused by the JSR310 latest push into TL repository, in which the timezone name handling is slightly different for those "special" timezone name such as UTC, GMT and UT. The offending test case has not been updated accor

Re: Review request: JDK-8012453 (process) Runtime.exec(String) fails if command contains spaces [win]

On 24/04/2013 13:58, Alexey Utkin wrote: I changed in the ProcessBuilder class to restore the compatibility with Java documentation. In accordance with spec, the IllegalArgumentException exception could not be thrown from the start method. I made it a cause for declared IOException. This par

Re: RFR: JDK-8012650 and JDK-8011918

On 24/04/2013 00:09, Henry Jen wrote: Hi, Please review static Stream factory methods and methods for Arrays. Webrev is at http://cr.openjdk.java.net/~henryjen/tl/8012650-8011918.0 Stream methods are covered in a test suite which will be put back soon once all depends part is in place. Arrays

RFR 8009581: Xpathexception does not honor initcause()

Hi all, Can I have a reviews for the following change: http://cr.openjdk.java.net/~dmeetry/8009581/webrev.0/ Summary: There is an erroneous behavior in 'initCause' method of javax.xml.xpath.XPathException class. Lets look at the follo

Re: RFR: 8005051: optimized defaults for Iterator.forEachRemaining

On 23/04/2013 20:18, Akhil Arora wrote: On 04/22/2013 11:42 AM, Alan Bateman wrote: One thing I meant to ask when forEachRemaining was added was whether it should say anything about the "last element"? I see in the webrev that you've set it for the ArrayList iterators but not the LinkedList iter

Re: Review request: JDK-8012453 (process) Runtime.exec(String) fails if command contains spaces [win]

Thanks for clarification, Alan! A part of the fix was not covered by summary, but need to be mentioned. I changed in the ProcessBuilder class to restore the compatibility with Java documentation. In accordance with spec, the IllegalArgumentException exception could not be thrown from the start

hg: jdk8/tl/jdk: 8009985: [parfait] Uninitialised variable at jdk/src/solaris/native/com/sun/management/UnixOperatingSystem_md.c

Changeset: 754c9bb4f085 Author:sla Date: 2013-04-24 14:49 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/754c9bb4f085 8009985: [parfait] Uninitialised variable at jdk/src/solaris/native/com/sun/management/UnixOperatingSystem_md.c Reviewed-by: sla, rbackman, alanb, dholmes, r

Re: Proxy.isProxyClass scalability

Hi Mandy, I have noticed recently on the hotspot-runime-dev mailing list: "RFR(XXS): 8012714: Assign the unique traceid directly to the Klass upon creation"... Could this be accessed from Java? It looks like a perfect key to identify a class within a JVM. Can it be represented as int or long

Re: Proxy.isProxyClass scalability

On 04/24/2013 09:16 AM, Peter Levart wrote: On 04/24/2013 01:43 AM, Mandy Chung wrote: Precise check should be to validate if the given interfaces == the proxy interfaces implemented by the cached proxy class (i.e. proxyClass.getInterfaces()). Hi Mandy, I will try to profile this approach a

Re: Review request: JDK-8012453 (process) Runtime.exec(String) fails if command contains spaces [win]

Hi Martin, On 23.04.2013 20:45, Martin Buchholz wrote: Random comments from a former maintainer: I was never brave enough to tackle windows argument parsing or trying to change legacy behavior. I'm surprised you used LinkedList, which is almost never useful. Why not ArrayList? Here is the

Re: Proxy.isProxyClass scalability

On 04/24/2013 08:58 AM, Peter Levart wrote: In your revisions, you optimize for 0-interface and 1-interface proxy class. What I hacked up earlier was just to use Class[] as the key (need to make a copy of the array to prevent that being mutated during runtime) that is a simpler and straight

Re: Proxy.isProxyClass scalability

On 04/24/2013 01:43 AM, Mandy Chung wrote: Precise check should be to validate if the given interfaces == the proxy interfaces implemented by the cached proxy class (i.e. proxyClass.getInterfaces()). Hi Mandy, I will try to profile this approach as a post-validation and let you know the res

Re: Proxy.isProxyClass scalability

On 04/24/2013 07:33 AM, Mandy Chung wrote: More comments in addition to what I replied earlier On 4/23/2013 4:43 PM, Mandy Chung wrote: Each ClassLoader maintains explicit hard-references to all Class objects for classes defined by the loader. So proxy Class object can not be GC-ed unti