hg: jdk7/tl/jdk: 6830721: (fc) test/java/nio/channels/AsynchronousFileChannel/Basic.java intermittent failure

Changeset: ccd08d4b19cf Author:alanb Date: 2009-04-20 09:30 +0100 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/ccd08d4b19cf 6830721: (fc) test/java/nio/channels/AsynchronousFileChannel/Basic.java intermittent failure Reviewed-by: sherman !

Re: Review request for 6829503

David Holmes - Sun Microsystems wrote: Hi Alan, Alan Bateman said the following on 04/20/09 00:00: As it happens, there was a bug in that code (6526376) that caused NPE to be thrown so jdk7 b10 is the first build where IllegalStateException is possible. Ah I see. Seems to me that 6526376

Re: Review request 6831461

Looks fine. -Chris. On 04/17/09 15:52, Alan Bateman wrote: 6831461: (sample) Copy -r fails with IllegalArgumentexception: 'maxDepth' is negative Sherman - this is bug in the Copy sample code that one of the tech writers ran into. For the -r option the sample code is calling walkFileTree

BigInteger and MutableBigInteger should use Integer bit-twiddling methods

Hi! Could someone take care about CR 6832035? -- Christian

Re: Review request for 6829503

Alan, Thanks for the review and comments. Here is the revised webrev incorporating your comments. See below for my inlined reply. http://cr.openjdk.java.net/~mchung/6829503/webrev.01/ Alan Bateman wrote: Good work! It mostly looks good to me and I've only a few comments: 1. I see that

REVIEW 6511515: poor performance of LogRecord.inferCaller depending on java.lang.Throwable.getStackTraceElement

Hi java.util.logging maintainers, Here is a patch to improve the performance of LogRecord.inferCaller. This improves the performance of the microbenchmark in 6511515 by 5x. Swamy, please review. Contributed by Jeremy Manson. http://cr.openjdk.java.net/~martin/inferCaller As a followon, it makes

Re: REVIEW 6511515: poor performance of LogRecord.inferCaller depending on java.lang.Throwable.getStackTraceElement

Hi Martin, Jeremy, I'm assuming inferCaller always expects to find a caller, or at least that would be the common case - yes? If so then this might be a case where it is quicker to forego the getStackTraceDepth() call and simply catch the potential exception if we reach the end. Aside: we

hg: jdk7/tl/jdk: 3 new changesets

Changeset: 697bf0cf039b Author:martin Date: 2009-04-20 21:23 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jdk/rev/697bf0cf039b 6830220: Logging issues due to regression from bug fix 6797480 Reviewed-by: swamyv Contributed-by: jeremyman...@google.com !

hg: jdk7/tl/jaxp: 2 new changesets

Changeset: b56d870cb5c8 Author:tbell Date: 2009-04-20 22:50 -0700 URL: http://hg.openjdk.java.net/jdk7/tl/jaxp/rev/b56d870cb5c8 6738894: Merge jaxp fixes from 6 update train into OpenJDK 6 and 7 6573268: Four JCK-devtools-6a tests report OOM: Java Heap space since JDK7 b14