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
On 6/24/15 4:10 PM, Paul Sandoz wrote:
On Jun 24, 2015, at 10:05 AM, Amy Lu amy...@oracle.com
mailto:amy...@oracle.com 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
On 23/06/2015 23:14, Kirk Shoop (MS OPEN TECH) wrote:
Hi,
webrev
http://cr.openjdk.java.net/~kshoop/6415680/
bug:
https://bugs.openjdk.java.net/browse/JDK-6415680
The changes for unix to handle SIGBUS need matching work for Windows
EXCEPTION_IN_PAGE_ERROR
This change uses
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
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
On Jun 24, 2015, at 10:05 AM, Amy Lu amy...@oracle.com 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).
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
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]
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
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
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:08
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';
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
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:
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
On Jun 24, 2015, at 1:54 PM, Chris Hegarty chris.hega...@oracle.com 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
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
Am Wed, 24 Jun 2015 12:04:58 -0700
schrieb Brian Burkhalter brian.burkhal...@oracle.com:
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
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
On 24 Jun 2015, at 21:28, Brian Burkhalter brian.burkhal...@oracle.com
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
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
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 stuart.ma...@oracle.com wrote:
Hi all,
Please review this small javadoc change to the
Double/Int/LongSummaryStatistics
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
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
On Jun 24, 2015, at 1:54 PM, Chris Hegarty chris.hega...@oracle.com 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/
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.
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
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
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
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
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 vita...@gmail.com wrote:
Sorry, where was the
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';
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
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:
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
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:
+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
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
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
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:
+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
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
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
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
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:
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()
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 ivan.gerasi...@oracle.com wrote:
I'm not sure if it's still needed to have @SuppressWarnings(try)
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:
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
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 jason_mehr...@hotmail.com wrote:
Not sure on this but, isn't it a little risky to import AtomicBoolean into
such low level
50 matches
Mail list logo
