Re: Review request for JDK-8080266: Failed to create CharInfo due to ResourceBundle update for modules

Hi Frank, I could push it for you. -- daniel On 6/25/15 5:05 AM, Frank Yuan wrote: So, would you like to push the code for me? Best Regards Frank -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Thursday, June 25, 2015 12:57 AM To: Daniel Fuchs Cc: Frank Yua

Re: RFR/RFA (8u-dev) 8080524: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profiles

Hi Ivan, On 25/06/2015 4:11 AM, Ivan Gerasimov wrote: Hello! This test fails when running on compact1 and compact2, since it tries to access all the jars from "sun.boot.class.path". The easiest approach would be to include it in the group, which requires at least compact3. Easy yes but is it

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

I have to agree with Vitaly here, the use of AtomicBoolean seems out of context in an otherwise thread-unsafe class. Why are we concerned about concurrent closing of a "stream" that shouldn't be being shared across threads ? On 25/06/2015 11:32 AM, Vitaly Davidovich wrote: Right, but that's j

Re: RFR: 8098547: (tz) Support tzdata2015e

+1 Masayoshi On 6/24/2015 9:58 PM, Seán Coffey wrote: Looks fine. Regards, Sean. On 24/06/15 12:05, Aleksej Efimov wrote: Hello, Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 Testing shows no TZ related failures on a

RE: Review request for JDK-8080266: Failed to create CharInfo due to ResourceBundle update for modules

So, would you like to push the code for me? Best Regards Frank -Original Message- From: huizhe wang [mailto:huizhe.w...@oracle.com] Sent: Thursday, June 25, 2015 12:57 AM To: Daniel Fuchs Cc: Frank Yuan; 'core-libs-dev'; 'Lance Andersen'; 'jibing chen'; 'Gustavo Galimberti'; sandeep.kon

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Right, but that's just to no-op duplicate close() calls which makes sense to me since there's no way to query the output stream to see if it's closed. But that version wasn't trying to deal with (rightfully IMO given this class isn't threadsafe) concurrent calls to close() from different threads.

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

To be picky about it, it is not exactly locking but a very similar pattern: 158 public void close() throws IOException { 159 if (closed) 160 return; 161 closed = true; On Jun 24, 2015, at 6:16 PM, Vitaly Davidovich wrote: > Sorry, where was the double checked lo

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Sorry, where was the double checked locking in FilterOutputStream? I see a plain "closed" boolean before. sent from my phone The intent here was to fix a specific problem of exception throwing in close(). Prior to this, re-closing the stream was “protected” by double checked locking. Extending cov

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

The intent here was to fix a specific problem of exception throwing in close(). Prior to this, re-closing the stream was “protected” by double checked locking. Extending coverage of synchronicity problems to the rest of the class could be addressed in the context of another issue, yet to be file

RE: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

If the other I/O classes are using it then it should be safe here then. Just wanted make sure it wasn't creating a new issue. Thanks, Jason > From: brian.burkhal...@oracle.com > Subject: Re: [9] RFR of 8042377: BufferedWriter and > FilteredOutputStre

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

I must say it's a bit odd seeing an atomic field in an otherwise non-threadsafe class. To be pedantic, what's to prevent close (being called on a different thread from one that allocated the filtered output stream) from seeing inconsistent out field values (assume the stream was published unsafely

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

On Jun 24, 2015, at 1:54 PM, Chris Hegarty wrote: > The changes themselves look ok to me. Maybe the test could exercise > FilterOutputStream directly too? I have updated the patch to exercise FilterOutputStream as well: http://cr.openjdk.java.net/~bpb/8042377/webrev.01/ Barring objections to

Re: RFR(s): 8080450: doc for Double/Int/LongSummaryStatistics.toString has errors

Joe, great, I'll go ahead and push. Thanks. Lance, thanks for looking as well. s'marks On 6/24/15 1:56 PM, Joseph D. Darcy wrote: Hi Stuart, The changes look good; a ccc is not necessary IMO. Thanks, -Joe On 6/24/2015 1:37 PM, Stuart Marks wrote: Hi all, Please review this small javadoc

Re: RFR/RFA (8u-dev) 8080524: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profiles

Thanks Seán! Added 9-na and noreg labels. Sincerely yours, Ivan On 24.06.2015 23:47, Seán Coffey wrote: Looks ok to me Ivan. Is this required for JDK 9 also ? If not, please add 9-na label. Approved. Regards, Sean. On 24/06/2015 19:11, Ivan Gerasimov wrote: Hello! This test fails when ru

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Am Wed, 24 Jun 2015 12:04:58 -0700 schrieb Brian Burkhalter : > Please review at your convenience. > > Issue:https://bugs.openjdk.java.net/browse/JDK-8042377 > Patch:http://cr.openjdk.java.net/~bpb/8042377/webrev.00/ > > The use of try-with-resources in FilteredOutputStream.close

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

On Jun 24, 2015, at 1:54 PM, Chris Hegarty wrote: > I remember the initialization problem with java.lang.Thread, but I think the > usage here is ok. As you correctly point out, AtomicBoolean is already used > in other java.io classes. If HelloWorld starts up then I think you’re good. I don’t

Re: RFR(s): 8080450: doc for Double/Int/LongSummaryStatistics.toString has errors

Hi Stuart, Looks fine. seems more of a bug fix so I am not sure a ccc is needed but I am sure Joe will let us know :-) On Jun 24, 2015, at 4:37 PM, Stuart Marks wrote: > Hi all, > > Please review this small javadoc change to the > Double/Int/LongSummaryStatistics classes' toString() method

Re: RFR(s): 8080450: doc for Double/Int/LongSummaryStatistics.toString has errors

Hi Stuart, The changes look good; a ccc is not necessary IMO. Thanks, -Joe On 6/24/2015 1:37 PM, Stuart Marks wrote: Hi all, Please review this small javadoc change to the Double/Int/LongSummaryStatistics classes' toString() method specifications. Basically they all inherit the Object.toSt

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

> On 24 Jun 2015, at 21:28, Brian Burkhalter > wrote: > > I should however note that equivalent usage is already present in the close() > methods of FileInputStream, FileOutputStream, and RandomAccessFile which are > also in java.io. Perhaps the problem you allude to would be more pertinent t

Re: RFR/RFA (8u-dev) 8080524: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profiles

Looks ok to me Ivan. Is this required for JDK 9 also ? If not, please add 9-na label. Approved. Regards, Sean. On 24/06/2015 19:11, Ivan Gerasimov wrote: Hello! This test fails when running on compact1 and compact2, since it tries to access all the jars from "sun.boot.class.path". The easie

RFR(s): 8080450: doc for Double/Int/LongSummaryStatistics.toString has errors

Hi all, Please review this small javadoc change to the Double/Int/LongSummaryStatistics classes' toString() method specifications. Basically they all inherit the Object.toString() doc, which is mostly irrelevant, and in two cases the doc comment is placed erroneously and so is entirely ignored

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

I should however note that equivalent usage is already present in the close() methods of FileInputStream, FileOutputStream, and RandomAccessFile which are also in java.io. Perhaps the problem you allude to would be more pertinent to java.lang classes? Brian On Jun 24, 2015, at 1:21 PM, Brian B

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Jason, Thanks for pointing this out. I am not sure of the answer. Let’s see what the experts have to say. Thanks, Brian On Jun 24, 2015, at 1:03 PM, Jason Mehrens wrote: > Not sure on this but, isn't it a little risky to import AtomicBoolean into > such low level class? I vaguely remember

Re: JDK 9 RFR of JDK-8129597: Add tier 3 test definitions to the JDK 9 forest

Hi Joe, Changes look good to me. I hope the initial tier3 test run passes. :-) s'marks On 6/24/15 10:19 AM, joe darcy wrote: Hello, Per the recent email to jdk9-dev, "Test policy follow-up, third testing tier," http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html plea

RE: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Brian, Not sure on this but, isn't it a little risky to import AtomicBoolean into such low level class? I vaguely remember there was an issue with using AtomicXXX in java.lang.Thread. Not sure if this case suffers the same fate. Jason > From: brian.

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Hi Ivan, I believe you are correct that this is vestigial. I removed it in my patch but will not post another webrev for this alone. Thanks, Brian On Jun 24, 2015, at 12:34 PM, Ivan Gerasimov wrote: > I'm not sure if it's still needed to have @SuppressWarnings("try") before > FilterOutputSt

Re: [9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Hi Brian! I'm not sure if it's still needed to have @SuppressWarnings("try") before FilterOutputStream.close(). Sincerely yours, Ivan On 24.06.2015 22:04, Brian Burkhalter wrote: Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8042377 Patch: http://cr.op

[9] RFR of 8042377: BufferedWriter and FilteredOutputStream.close throw IAE if flush and close throw equal exceptions

Please review at your convenience. Issue: https://bugs.openjdk.java.net/browse/JDK-8042377 Patch: http://cr.openjdk.java.net/~bpb/8042377/webrev.00/ The use of try-with-resources in FilteredOutputStream.close() is replaced with explicit handling of IOExceptions potentially thrown by flush() or

RFR/RFA (8u-dev) 8080524: [TESTBUG] java/lang/Class/getDeclaredField/FieldSetAccessibleTest.java fails on compact profiles

Hello! This test fails when running on compact1 and compact2, since it tries to access all the jars from "sun.boot.class.path". The easiest approach would be to include it in the group, which requires at least compact3. BUGURL: https://bugs.openjdk.java.net/browse/JDK-8080524 WEBREV: http://c

Re: RFR JDK-8129544: ArrayIndexOutOfBoundsException when decoding corrupt Base64 string

On 24/06/2015 18:38, Xueming Shen wrote: Hi, Please help review the change for JDK-8129544. Issue: https://bugs.openjdk.java.net/browse/JDK-8129544 Webrev: http://cr.openjdk.java.net/~sherman/8129544 An easy oversight, this looks okay to me. -Alan

RFR JDK-8129544: ArrayIndexOutOfBoundsException when decoding corrupt Base64 string

Hi, Please help review the change for JDK-8129544. Issue: https://bugs.openjdk.java.net/browse/JDK-8129544 Webrev: http://cr.openjdk.java.net/~sherman/8129544 Thanks, -Sherman

JDK 9 RFR of JDK-8129597: Add tier 3 test definitions to the JDK 9 forest

Hello, Per the recent email to jdk9-dev, "Test policy follow-up, third testing tier," http://mail.openjdk.java.net/pipermail/jdk9-dev/2015-June/002325.html please review the patch below to address JDK-8129597 : Add tier 3 test definitions to the JDK 9 forest http://cr.openjdk.java.

Re: Review request for JDK-8080266: Failed to create CharInfo due to ResourceBundle update for modules

+1. -Joe On 6/24/2015 1:58 AM, Daniel Fuchs wrote: Hi Frank, The proposed changes look good to me. best regards, -- daniel On 24/06/15 09:58, Frank Yuan wrote: Hi, Would you like to have a review for bug https://bugs.openjdk.java.net/browse/JDK-8080266? This bug is caused by jigsaw chang

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

Sorry, I didn't realize these are TEST.properties files, not java files. The changes are ok, sorry for the confusion. Best regards, Alexander - Original Message - From: alexander.kulyakh...@oracle.com To: konstantin.she...@oracle.com, alan.bate...@oracle.com Cc: core-libs-dev@openjdk.jav

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

Konstantin, Apparently the script does not yet provide for the same formatting as was done with the bulk updates. You may want to make the changes format consistent with how it was done for multiple modules in the bulk update patches such as here: http://sette0.ru.oracle.com/akulyakh/open_no_p

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

On 24/06/2015 16:40, Konstantin Shefov wrote: Hi Alan, Please review updated patch. I made it using the tool Alexander Kulyakhtin has given me. http://cr.openjdk.java.net/~kshefov/8129595/webrev.01/ This looks okay to me. Thanks for sorting this out. -Alan

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

Hi Alan, Please review updated patch. I made it using the tool Alexander Kulyakhtin has given me. http://cr.openjdk.java.net/~kshefov/8129595/webrev.01/ Thanks -Konstantin On 06/24/2015 01:52 PM, Alan Bateman wrote: On 24/06/2015 11:29, Konstantin Shefov wrote: Alan, Do the tests form "

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

Adding Shura - Original Message - From: alexander.kulyakh...@oracle.com To: alan.bate...@oracle.com Cc: core-libs-dev@openjdk.java.net, konstantin.she...@oracle.com, security-...@openjdk.java.net Sent: Wednesday, June 24, 2015 3:59:14 PM GMT +03:00 Iraq Subject: Re: [9] Review request: JDK

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

Konstantin, Shura has developed a tool to add @modules to jtreg tests specified as input. The wiki is here: https://wiki.se.oracle.com/display/JPG/@modules+in+JTReg+tests#id-@modulesinJTRegtests-Script Please, let me know if any additional help is needed, or if there are any issues. Best rega

Re: RFR: 8098547: (tz) Support tzdata2015e

Looks fine. Regards, Sean. On 24/06/15 12:05, Aleksej Efimov wrote: Hello, Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 Testing shows no TZ related failures on all platforms. With Best Regards, Aleksej [1] https://bu

RFR: 8098547: (tz) Support tzdata2015e

Hello, Please, review the latest tzdata (2015e) [1] integration to JDK9: http://cr.openjdk.java.net/~aefimov/tzdata/2015e/9/0 Testing shows no TZ related failures on all platforms. With Best Regards, Aleksej [1] https://bugs.openjdk.java.net/browse/JDK-8098547

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

On 24/06/2015 11:29, Konstantin Shefov wrote: Alan, Do the tests form "test/javax/net/ssl/DTLS" compile against jake? They have just the same dependencies as "test/javax/net/ssl/TLS" and the TEST.properties file just like one suggested in this fix. If yes, it is not worth changing TEST.prop

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

Alan, Do the tests form "test/javax/net/ssl/DTLS" compile against jake? They have just the same dependencies as "test/javax/net/ssl/TLS" and the TEST.properties file just like one suggested in this fix. If yes, it is not worth changing TEST.properties any more. -Konstantin On 06/24/2015 01:0

Re: [9] Review request: JDK-8129595: New DTLS tests need @modules

On 24/06/2015 11:01, Konstantin Shefov wrote: Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8129595 Webrev is http://cr.openjdk.java.net/~kshefov/8129595/webrev.00/ security-dev would be a better place to review this. The updates to TEST.properties look okay bu

[9] Review request: JDK-8129595: New DTLS tests need @modules

Hello, Please review the test bug fix https://bugs.openjdk.java.net/browse/JDK-8129595 Webrev is http://cr.openjdk.java.net/~kshefov/8129595/webrev.00/ Thanks -Konstantin

RE: Review request for JDK-8080266: Failed to create CharInfo due to ResourceBundle update for modules

Hi Many thanks for your review! Best Regards Frank -Original Message- From: Daniel Fuchs [mailto:daniel.fu...@oracle.com] Sent: Wednesday, June 24, 2015 4:59 PM To: Frank Yuan; 'core-libs-dev'; 'Joe Wang' Cc: 'Lance Andersen'; 'jibing chen'; 'Gustavo Galimberti'; sandeep.konch...@oracle

Re: Review request for JDK-8080266: Failed to create CharInfo due to ResourceBundle update for modules

Hi Frank, The proposed changes look good to me. best regards, -- daniel On 24/06/15 09:58, Frank Yuan wrote: Hi, Would you like to have a review for bug https://bugs.openjdk.java.net/browse/JDK-8080266? This bug is caused by jigsaw change, the context class loader can't load internal resour

Re: JDK 9 RFR of JDK-8129759: Mark two tests from DistinctOpTest.java and SliceOpTest.java as serialization hostile

On 6/24/15 4:10 PM, Paul Sandoz wrote: On Jun 24, 2015, at 10:05 AM, Amy Lu > wrote: Testcase testStable was newly introduced in JDK-8129120 in DistinctOpTest, this test should be marked as serialization-hostile. (such tests will ignored by by lambda serialization testi

Re: JDK 9 RFR of JDK-8129759: Mark two tests from DistinctOpTest.java and SliceOpTest.java as serialization hostile

On Jun 24, 2015, at 10:05 AM, Amy Lu wrote: > Testcase testStable was newly introduced in JDK-8129120 in DistinctOpTest, > this test should be marked as serialization-hostile. (such tests will ignored > by by lambda serialization testing framework). > testSkipLimitOpsWithNonSplittingSpliterator

JDK 9 RFR of JDK-8129759: Mark two tests from DistinctOpTest.java and SliceOpTest.java as serialization hostile

Testcase testStable was newly introduced in JDK-8129120 in DistinctOpTest, this test should be marked as serialization-hostile. (such tests will ignored by by lambda serialization testing framework). testSkipLimitOpsWithNonSplittingSpliterator from SliceOpTest also need same change. Please re

Review request for JDK-8080266: Failed to create CharInfo due to ResourceBundle update for modules

Hi, Would you like to have a review for bug https://bugs.openjdk.java.net/browse/JDK-8080266? This bug is caused by jigsaw change, the context class loader can't load internal resource which is in a named module any more. To fix it, LSSerializerImpl shall invoke ResourceBundle.getBundle