Re: RFR(s): 8170864: java/net/URLClassLoader/closetest/CloseTest.java has undeclared dependensies

Hi Colleagues, Thank you for review. Issue: One of networking tests fails in case using a command line option "--limit-module". Root cause: there is undeclared dependency on java.logging. Are you sure of this? The test does not use logging directly, and the HTTP server no longer uses jdk.ut

Re: RFR(s): 8170864: java/net/URLClassLoader/closetest/CloseTest.java has undeclared dependensies

Hi Sergei, On 07/12/16 15:01, Chris Hegarty wrote: On 7 Dec 2016, at 14:55, Sergei Kovalev wrote: Hi Team, Please review a simple fix for networking test. BugID: https://bugs.openjdk.java.net/browse/JDK-8170864 WebRev: http://cr.openjdk.java.net/~skovalev/8170864/webrev.00/ Issue: One of ne

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

On 07/12/16 14:50, Chris Hegarty wrote: It is intended, as that is the code path that will be executed when the test invokes itself. Oh - right - I see it now. So looks good to me too :-) -- daniel -Chris. best regards, -- daniel On 07/12/16 14:29, Felix Yang wrote: :-) -Felix On 6

Re: RFR(s): 8170864: java/net/URLClassLoader/closetest/CloseTest.java has undeclared dependensies

Sergei, > On 7 Dec 2016, at 14:55, Sergei Kovalev wrote: > > Hi Team, > > Please review a simple fix for networking test. > > BugID: https://bugs.openjdk.java.net/browse/JDK-8170864 > WebRev: http://cr.openjdk.java.net/~skovalev/8170864/webrev.00/ > > Issue: One of networking tests fails in c

RFR(s): 8170864: java/net/URLClassLoader/closetest/CloseTest.java has undeclared dependensies

Hi Team, Please review a simple fix for networking test. BugID: https://bugs.openjdk.java.net/browse/JDK-8170864 WebRev: http://cr.openjdk.java.net/~skovalev/8170864/webrev.00/ Issue: One of networking tests fails in case using a command line option "--limit-module". Root cause: there is unde

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

> On 7 Dec 2016, at 14:48, Daniel Fuchs wrote: > > Hi Felix, > > Looks good in general, but is > 74 return; > intended, or is that a test bug? It is intended, as that is the code path that will be executed when the test invokes itself. -Chris. > best regards, > > -- d

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

Hi Felix, Looks good in general, but is 74 return; intended, or is that a test bug? best regards, -- daniel On 07/12/16 14:29, Felix Yang wrote: :-) -Felix On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: Add core-libs. Thanks, Felix On 2016/12/5 22:14, Felix Yang wrote

Re: Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

> On 7 Dec 2016, at 14:29, Felix Yang wrote: >>> ... >>> updated webrev. May I have a reviewer to review this >>> >>> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ I think this is ok Felix. -Chris.

Ping - Re: RFR 8043838, Test java/net/ServerSocket/AcceptCauseFileDescriptorLeak.java failed intermittently in nightly

:-) -Felix > On 6 Dec 2016, at 9:28 AM, Felix Yang wrote: > > Add core-libs. > > Thanks, > Felix > On 2016/12/5 22:14, Felix Yang wrote: >> Hi, >> >> updated webrev. May I have a reviewer to review this >> >> http://cr.openjdk.java.net/~xiaofeya/8043838/webrev.01/ >> >> -Felix >> On 2016/1

Re: Special exception for EMFILE / ENFILE when using sockets.

+1 Also I think it is more consistent with things we already do at the moment. For example there is already a ConnectException, ChannelClosedException etc which is also just an IOException with a “special” errno value. Just my 2 cents, Norman > On 7 Dec 2016, at 15:01, David M. Lloyd wrote:

Re: Special exception for EMFILE / ENFILE when using sockets.

If you're already having to turn the native error code into (say) an enum or something, it's effectively equivalent to just having different types for every error code. The difference is just like: try { ... } catch (IOException e) { switch (e.getErrorCode()) { case E

Re: Special exception for EMFILE / ENFILE when using sockets.

If we go this route we should also reconsider: https://bugs.openjdk.java.net/browse/JDK-8167161 Still not sure what solution I would prefer tho. > On 6 Dec 2016, at 12:14, Langer, Christoph wrote: > > Hi, > > I would also support if IOExce

RE: RFR (S): 8164057: Fix @since for java.net.Inet[46]Address

Hi Chris, Ok, thanks. Let me know when ccc is processed and it can be pushed. Best regards Christoph > -Original Message- > From: Chris Hegarty [mailto:chris.hega...@oracle.com] > Sent: Mittwoch, 7. Dezember 2016 11:52 > To: Langer, Christoph > Cc: net-dev@openjdk.java.net > Subject: Re

Re: RFR (S): 8164057: Fix @since for java.net.Inet[46]Address

Hi Christoph, > On 7 Dec 2016, at 08:38, Langer, Christoph wrote: > > Hi, > > please review this small fix. > > Bug: https://bugs.openjdk.java.net/browse/JDK-8164057 > Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8164057.0/ > > The root cause of the wrong “@since” tags probably is t

Re: RFR (S): 8164057: Fix @since for java.net.Inet[46]Address

Hi Christoph, this change looks reasonable but I wonder if this requires one of these dubious CCC requests/approvals? Maybe one of the process experts can answer :) Regards, Volker On Wed, Dec 7, 2016 at 9:38 AM, Langer, Christoph wrote: > Hi, > > > > please review this small fix. > > > > Bug:

Re: RFR 8169115, java/net/InetAddress/ptr/lookup.sh failed intermittently

Hi Dmitry, thanks for the comments. My opinions inlined... Updated webrev: http://cr.openjdk.java.net/~xiaofeya/8169115/webrev.01/ -Felix On 2016/12/6 19:16, Dmitry Samersoff wrote: Felix, 1. I'm not sure that javaweb.sfbay.sun.com is the best domain name for this test. Could we use diffe

RFR (S): 8164057: Fix @since for java.net.Inet[46]Address

Hi, please review this small fix. Bug: https://bugs.openjdk.java.net/browse/JDK-8164057 Webrev: http://cr.openjdk.java.net/~clanger/webrevs/8164057.0/ The root cause of the wrong "@since" tags probably is that the classes Inet[46]Address had been created as copy of InetAddress. InetAddress itse