JDK 9 RFR of 8160215: jdk/test/java/io/Reader/ReaderBulkReadContract.java should clean up better

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8160215 Diff: --- a/test/java/io/Reader/ReaderBulkReadContract.java +++ b/test/java/io/Reader/ReaderBulkReadContract.java @@ -148,7 +148,8 @@ private static File createTempFileWithContents(String contents)

Re: RFR: jsr166 jdk9 integration wave 7

On Thu, Jul 7, 2016 at 3:39 AM, Paul Sandoz wrote: > > Here is a spec diff for the atomics: > > > http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8080603-concurrent-unsafe-vhs/specdiff/java/util/concurrent/atomic/package-summary.html > < >

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

jdk/test/java/util/concurrent/tck has thousands of test methods. It used to take minutes to run them all, but now only takes 10 seconds, mostly due to replacements of sleeps with faster and more robust alternatives, often CountDownLatch. On Fri, Jul 8, 2016 at 10:17 AM, joe darcy

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

The most surefire way to make sure the test doesn't fail anymore is to hg rm the test; if and unless the code is actually removed, that would not be the most appropriate approach though ;-) While it might be overkill for this particular test, I think it would be preferable to start replacing

RFR: JDK-8161067 - jlink: Enable plugins to use the module pool for class lookup

http://cr.openjdk.java.net/~jlaskey/8161067/webrev/index.html https://bugs.openjdk.java.net/browse/JDK-8161067

Re: JEP 293: Guidelines for JDK Command-Line Tool Options

> On Jul 8, 2016, at 8:01 AM, Jonathan Gibbons > wrote: > > On 07/07/2016 11:07 PM, Dan Smith wrote: >> A suggestion for clarifying the text: I was confused about whether "may" >> refers to choices that the tool developer is allowed to make, or choices >> that

Re: JEP 293: Guidelines for JDK Command-Line Tool Options

On 07/07/2016 11:07 PM, Dan Smith wrote: A suggestion for clarifying the text: I was confused about whether "may" refers to choices that the tool developer is allowed to make, or choices that the end user is allowed to make. For example: "Options can require an argument to be provided. For a

Re: RFR 8161055: Remove plugin ordering by isAfter, isBefore.

+1 > On Jul 8, 2016, at 8:19 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8161055/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8161055 > > Thanks > > -Sundar >

Re: RFR 8161055: Remove plugin ordering by isAfter, isBefore.

> On Jul 8, 2016, at 4:19 AM, Sundararajan Athijegannathan > wrote: > > Please review http://cr.openjdk.java.net/~sundar/8161055/webrev.00/ for > https://bugs.openjdk.java.net/browse/JDK-8161055 +1 It’s good to see the plugin API being cleaned up.

RFR 8161055: Remove plugin ordering by isAfter, isBefore.

Please review http://cr.openjdk.java.net/~sundar/8161055/webrev.00/ for https://bugs.openjdk.java.net/browse/JDK-8161055 Thanks -Sundar

Re: Advice on cross-repo change: JDK-8160997

On 07/07/2016 21:10, Coleen Phillimore wrote: Hi, You can send this to core-libs-dev@openjdk.java.net and hotspot-...@openjdk.java.net I don't have author rights on cr.openjdk.java.net yet so I'm looking for someone to upload the webrev for me. The sponsor should be from the runtime

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Yes, but I just thought that for a test that testing a deprecated (since 1.2) API, and failed with very very low frequency (actually, only one time during the years), we might not want to spend much effort on a big change, like rewrite with CountDownLatch :-) Thanks, Amy On 7/8/16 2:36 PM,

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

CountDownLatch is a better way of waiting for events, like for the two threads to be started and for Thread.stop to have been called. The test should ensure that ThreadDeath is indeed thrown. If the threads in the group notify the main thread via a latch when they catch ThreadDeath, then all the

Re: JEP 293: Guidelines for JDK Command-Line Tool Options

A suggestion for clarifying the text: I was confused about whether "may" refers to choices that the tool developer is allowed to make, or choices that the end user is allowed to make. For example: "Options can require an argument to be provided. For a long-form options, the argument may be

Re: JDK 9 RFR of JDK-8132548: java/lang/ThreadGroup/Stop.java fails with "RuntimeException: Failure"

Thank you Joe for your review. The intent is to give it more chance "for the thread group stop to be issued", not to extend the whole test execution timeout. I updated the webrev to make this in a retry, limit to 5 times of retry: http://cr.openjdk.java.net/~amlu/8132548/webrev.01/ Thanks,