Re: RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

On 22/05/2019 13:54, Chris Hegarty wrote: While we're here, let's address both the NPE and the IAE. Okay, I only mentioned it because the JIRA issue had two cases. Also it's one that we came across when working on the new implementation (it is called out as a compatibility difference in the Ri

Re: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed

Hi, I have observed an intermittent failure on Solaris. So I changed the patch to problem-list the test on all platform. Is that still OK? http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 best regards, -- daniel On 23/05/2019 10:32, Daniel Fuchs wrote: Hi, Please find a patch be

Re: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed

On 23/05/2019 11:30, Daniel Fuchs wrote: Hi, I have observed an intermittent failure on Solaris. So I changed the patch to problem-list the test on all platform. Is that still OK? http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 Looks fine.

Re: RFR: 8224656: Problem list java/security/SecureClassLoader/DefineClass.java until JDK-8224635 is fixed

Daniel, > On 23 May 2019, at 11:30, Daniel Fuchs wrote: > > Hi, > > I have observed an intermittent failure on Solaris. > So I changed the patch to problem-list the test on all platform. > > Is that still OK? > > http://cr.openjdk.java.net/~dfuchs/webrev_8224656/webrev.01 >

RE: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

Hi Stuart, big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/ So, for ConcurrentSkipListMap.java, the new coding is a real improvement, removing a @SuppressWarnings("unchecked") and a cast which are both unnecessary then

Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

On 23/05/2019 14:39, Langer, Christoph wrote: big thanks for your great updates here. This all looks a lot cleaner:http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/ I concur. Thanks Stuart! best regards, -- daniel

[teststabilization] RFR: 8224035 : Replace wildcard address with loopback or local host in tests - part 9

Hi, Please help to review another part of test fixes to address intermittent networking failures: http://cr.openjdk.java.net/~aefimov/8224035/00 JBS: https://bugs.openjdk.java.net/browse/JDK-8224035 With Best Regards, Aleksei

Re: [teststabilization] RFR: 8224035 : Replace wildcard address with loopback or local host in tests - part 9

Hi Aleks, Looks good to me. If possible please avoid long lines. Sometimes a convenient way to do that is to create a server socket without any arguments and then bind it. This has the additional advantage of avoiding the 3-args constructor which Alan doesn't like ;-) best regards, -- daniel

[RFR] 8224635: Revert 8224256 and add back java/security/SecureClassLoader/DefineClass.java test

bug: https://bugs.openjdk.java.net/browse/JDK-8224635 webrev: http://cr.openjdk.java.net/~aeubanks/8224635/webrev.00/index.html Test java/security/SecureClassLoader/DefineClass.java is failing after JDK-8224256 This change reverts the changes in JDK-8224256 and adds back in the test.

Re: [RFR] 8224635: Revert 8224256 and add back java/security/SecureClassLoader/DefineClass.java test

Looks fine although you should update the 8224635 title to match the changeset. Also, I assume you will file a followon bug for the original issue (JDK-8224256). I think a new bug must be filed instead of re-opening 8224256 because a changeset has already been pushed for it. --Sean On 5/23/

Re: RFR 8224477 [13] java.net.Socket::setOption - implementation mismatch to spec

Thank you Alan, I believe that I addressed all your comments and suggestions. Additionally, while here I noticed an issue where these methods were not always consistent with their spec to throw IOException when the socket has been closed. https://cr.openjdk.java.net/~chegar/8224477/webrev.02/ -

Re: [teststabilization] RFR: 8224035 : Replace wildcard address with loopback or local host in tests - part 9

Hi Daniel, Thank you for the review. I've tried to avoid 3-args constructor and/or long lines as you suggested: http://cr.openjdk.java.net/~aefimov/8224035/01/index.html Best, Aleksei On 23/05/2019 15:18, Daniel Fuchs wrote: Hi Aleks, Looks good to me. If possible please avoid long lines. S

[RFR] 8224645: Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException

bug: https://bugs.openjdk.java.net/browse/JDK-8224645 webrev: http://cr.openjdk.java.net/~aeubanks/8224645/webrev.00/ Test java/nio/channels/DatagramChannel/BasicMulticastTests.java fails with NoSuchElementException on Solaris. java.util.NoSuchElementException at java.base/java.util.Spliterators$

Re: [teststabilization] RFR: 8224035 : Replace wildcard address with loopback or local host in tests - part 9

Looks good to me! best regards, -- daniel On 23/05/2019 18:19, Aleks Efimov wrote: Hi Daniel, Thank you for the review. I've tried to avoid 3-args constructor and/or long lines as you suggested: http://cr.openjdk.java.net/~aefimov/8224035/01/index.html Best, Aleksei

Re: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

On 5/23/19 6:39 AM, Langer, Christoph wrote: big thanks for your great updates here. This all looks a lot cleaner: http://cr.openjdk.java.net/~clanger/webrevs/8223553.3/ Great, glad to help. While I'm still unsure about the underlying reasons for this disagreement between the compilers, th

RE: RFR: 8223553: Fix code constructs that do not compile with the Eclipse Java Compiler

> Overall, introducing a local variable is more-or-less reasonable even if it's > used only once. One point is that somebody might come along and "clean > up" the > code and inline local variables and reintroduce the problem. Another point is > that, hypothetically, if in the future Eclipse is chan