Re: RFR: 8065172: More core reflection final and volatile annotations

On Dec 9, 2014, at 5:49 PM, Martin Buchholz wrote: > Oops sorry - classic mistake of forgetting to hg qrefresh before publishing. > It's in sync now, thanks. +1 Paul.

RFR 8067112: Update jdk/test/java/util/Collections/EmptyIterator.java to eliminate dependency on sun.tools.java

Please review the fix for removing internal JDK API dependency from test java/util/Collections/EmptyIterator.java This test has dependency on sun.tools.java from one of it’s test case, this fixed by using public API for the same testing purpose. bug: https://bugs.openjdk.java.net/browse/JDK-8

Re: RFR 8067112: Update jdk/test/java/util/Collections/EmptyIterator.java to eliminate dependency on sun.tools.java

This looks good to me Amy. Do you need a sponsor ? -Chris. On 10/12/14 10:15, Amy Lu wrote: Please review the fix for removing internal JDK API dependency from test java/util/Collections/EmptyIterator.java This test has dependency on sun.tools.java from one of it’s test case, this fixed by usi

Re: RFR 8067112: Update jdk/test/java/util/Collections/EmptyIterator.java to eliminate dependency on sun.tools.java

A quick question: can we piggyback on this particular issue and remove some generics here? (see javac warnings): diff -r cb475099ceac test/java/util/Collections/EmptyIterator.java --- a/test/java/util/Collections/EmptyIterator.java Tue Dec 09 09:22:07 2014 -0800 +++ b/test/java/util/Collectio

Re: [9] Review request : JDK-8066798: [TEST] Make java/lang/invoke/LFCaching tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to define their number of iterations

On 09.12.2014 16:50, Igor Ignatyev wrote: on last thing to think about: does it make sense to move 'if (!run.passed) { ... } else { ... }' code into TestRun class? Yes, here is a webrev: http://cr.openjdk.java.net/~kshefov/8066798/webrev.03 On 12/09/2014 04:03 PM, Konstantin Shefov wrote:

Re: RFR JDK-8066867: Add InputStream transferTo to transfer content to an OutputStream

> Apologies Patrick, that's me who misread you. I assume I had a mix of your > reply, our recent conversation and David’s question in my head. No problem > About your actual reply. That's probably a matter of taste, since nowhere else > except for this particular method this thing is not used (

Re: [9] Review request : JDK-8066798: [TEST] Make java/lang/invoke/LFCaching tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to define their number of iterations

147 testCounter++; 148 } 155 throw new Error(String.format("%d of %d test cases FAILED! %n" 156 + "Rerun the test with the same \"-Dseed=\" option as in the log file!", 157 failCounter, testCounter));

Re: RFR 8067112: Update jdk/test/java/util/Collections/EmptyIterator.java to eliminate dependency on sun.tools.java

On 12/10/14 6:26 PM, Chris Hegarty wrote: This looks good to me Amy. Do you need a sponsor ? Thank you Chris for your review. Yes, please sponsor it. Thanks, Amy -Chris. On 10/12/14 10:15, Amy Lu wrote: Please review the fix for removing internal JDK API dependency from test java/util/Co

RFR JDK-8067127: Tags cleanup

Hi everyone, Could you please review my change for JDK-8067127? http://cr.openjdk.java.net/~prappo/8067127/webrev.00/ http://cr.openjdk.java.net/~prappo/8067127/specdiff.00/java/io/package-summary.html -- The purpose of this

Re: [9] Review request : JDK-8066798: [TEST] Make java/lang/invoke/LFCaching tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to define their number of iterations

Igor, I changed to printf and indent: http://cr.openjdk.java.net/~kshefov/8066798/webrev.04 -Konstantin On 10.12.2014 16:39, Igor Ignatyev wrote: 147 testCounter++; 148 } 155 throw new Error(String.format("%d of %d test cases FAILED! %n" 1

Re: [9] Review request : JDK-8066798: [TEST] Make java/lang/invoke/LFCaching tests use lib/testlibrary/jdk/testlibrary/TimeLimitedRunner.java to define their number of iterations

cool. reviewed. -- Igor On 12/10/2014 06:01 PM, Konstantin Shefov wrote: Igor, I changed to printf and indent: http://cr.openjdk.java.net/~kshefov/8066798/webrev.04 -Konstantin On 10.12.2014 16:39, Igor Ignatyev wrote: 147 testCounter++; 148 } 155

Re: RFR JDK-8067127: Tags cleanup

2014/12/10 6:38 -0800, pavel.ra...@oracle.com: > ... > > The overall goal of the parent task (JDK-8067126) though is to make it even > less > wordy and more readable where possible: > > * The first byte read is stored into {@code b[0]}, the next > * one into {@code b[1]}, and so on. The number

Re: RFR JDK-8067127: Tags cleanup

> ...I don't see how this last version is an > improvement. The phrase "the number of bytes read is <= b.length", in > particular, is jarring since it switches abruptly from prose to symbols; > the original "the number of bytes read is, at most, equal to len" is far > preferable. Agreed. And yet

Re: RFR JDK-8067127: Tags cleanup

Hi Pavel, I'd stick to just fixing the html formatting; leave the language alone. If the wording is changed even slightly, it makes the review more difficult and usually does not make a significant improvement. BTW, some of the JCK test tools are keyed off the exact wording (think checksum) an

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

Today I Leaned that "release fence" and "acquire fence" are technical terms defined in the C/C++ 11 standards. So my latest version reads instead: * Ensures that loads and stores before the fence will not be reordered with * stores after the fence; a "StoreStore plus LoadStore barrier".

RFR JDK-8046219: (str spec) String(byte[], int, int, Charset) should be clearer when IndexOutOfBoundsException is thrown

Hi Please help review this doc only change, in which the rewording precisely specifies when the IndexOutOfBoundsException should be thrown, while be compatible with the long standing behavior. issue: https://bugs.openjdk.java.net/browse/JDK-8046219 webrev: http://cr.openjdk.java.net/~sherman/80

Re: RFR JDK-8046219: (str spec) String(byte[], int, int, Charset) should be clearer when IndexOutOfBoundsException is thrown

The wording changes seem clear Sherman On Dec 10, 2014, at 2:05 PM, Xueming Shen wrote: > Hi > > Please help review this doc only change, in which the rewording precisely > specifies > when the IndexOutOfBoundsException should be thrown, while be compatible with > the long standing behavior.

RFR 8067183: TEST_BUG:File locked when processing the cleanup on test jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java

Hi All Could you please review a small fix for JAXP test bug. We found this one in JPRT running. It’s caused by resource isn’t released correctly. webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01/ bug: https://bugs.openjdk.java.net

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

On 12/05/2014 09:49 PM, Martin Buchholz wrote: > The actual implementations of storestore (see below) seem to > universally give you the stronger ::release barrier, and it seems > likely that hotspot engineers are implicitly relying on that, that > some uses of ::storestore in the hotspot sources a

Re: RFR 8067183: TEST_BUG:File locked when processing the cleanup on test jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java

Hi Tristan, Thanks for the fix, looks good. I also agree that we do further improvement/clean-up (such as failUnexpected as Lance pointed out) across all tests migrated. Thanks, Joe On 12/10/2014 12:42 PM, Tristan Yan wrote: Hi All Could you please review a small fix for JAXP test bug. We

Re: RFR 8067183: TEST_BUG:File locked when processing the cleanup on test jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java

looks ok tristan best lance On Dec 10, 2014, at 3:42 PM, Tristan Yan wrote: > Hi All > > Could you please review a small fix for JAXP test bug. We found this one in > JPRT running. It’s caused by resource isn’t released correctly. > > webrev: http://cr.openjdk.java.net/~tyan/8067183/webrev.01

Re: RFR 8067183: TEST_BUG:File locked when processing the cleanup on test jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java

Thank you. Could you sponsor this for me. Tristan On 12/10/2014 1:49 PM, huizhe wang wrote: Hi Tristan, Thanks for the fix, looks good. I also agree that we do further improvement/clean-up (such as failUnexpected as Lance pointed out) across all tests migrated. Thanks, Joe On 12/10/2014 1

Re: [concurrency-interest] RFR: 8065804:JEP171:Clarifications/corrections for fence intrinsics

This surely does not mean that on non-TSO architectures it is not possible to implement linearizable algorithms. Nor does it mean that the algorithm will contain /independent/ writes. Count the proofs that rely on synchronization order. That's the measure of how common IRIW pattern is. And yet

Re: RFR 8067183: TEST_BUG:File locked when processing the cleanup on test jaxp/test/javax/xml/jaxp/functional/javax/xml/transform/ptests/TransformerFactoryTest.java

Done. Joe On 12/10/2014 2:02 PM, tristan yan wrote: Thank you. Could you sponsor this for me. Tristan On 12/10/2014 1:49 PM, huizhe wang wrote: Hi Tristan, Thanks for the fix, looks good. I also agree that we do further improvement/clean-up (such as failUnexpected as Lance pointed out) ac

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

On 11/12/2014 3:31 AM, Martin Buchholz wrote: Today I Leaned that "release fence" and "acquire fence" are technical terms defined in the C/C++ 11 standards. So my latest version reads instead: * Ensures that loads and stores before the fence will not be reordered with * stores afte

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

On 11/12/2014 7:02 AM, Andrew Haley wrote: On 12/05/2014 09:49 PM, Martin Buchholz wrote: The actual implementations of storestore (see below) seem to universally give you the stronger ::release barrier, and it seems likely that hotspot engineers are implicitly relying on that, that some uses of

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

On Wed, Dec 10, 2014 at 4:52 PM, David Holmes wrote: > For the email record, as I have written in the bug report, I think the > "correction" of the semantics for storeFence have resulted in problematic > naming where storeFence and loadFence have opposite directionality > constraints but the name

Re: [concurrency-interest] RFR: 8065804: JEP 171: Clarifications/corrections for fence intrinsics

On Wed, Dec 10, 2014 at 1:02 PM, Andrew Haley wrote: > On 12/05/2014 09:49 PM, Martin Buchholz wrote: >> The actual implementations of storestore (see below) seem to >> universally give you the stronger ::release barrier, and it seems >> likely that hotspot engineers are implicitly relying on that