Re: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a fallback for migration

On 15/04/2015 10:36, Paul Sandoz wrote: : Yes, one could use a Pattern.splitAsStream, sorry could not resist :-) assuming this area is not sensitive to bootstrap issues e.g. hander = p.splitAsStream().map(String::trim).flatMap(this::getHandler).findFirst().orElse(null); This is a fallback

Re: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a fallback for migration

On 15/04/2015 15:35, Chris Hegarty wrote: That's better. For completeness, the updated webrev: http://cr.openjdk.java.net/~chegar/8075139/webrev.03/ Either is okay with me, the main thing is that the legacy tokenizer is gone. -Alan.

Re: RFR [9] 8075139: Restore java.protocol.handler.pkgs to work as a fallback for migration

On 21/04/2015 11:20, Chris Hegarty wrote: On 15 Apr 2015, at 16:43, Paul Sandoz wrote: On Apr 15, 2015, at 4:35 PM, Chris Hegarty wrote: I marginally prefer using flatMap rather than map/filter e.g. change getHandler to return Stream< URLStreamHandler> and change the last line to be "retu

Re: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws NumberFormatException

On 20/04/2015 18:32, Severin Gehwolf wrote: : OK fixed: http://cr.openjdk.java.net/~sgehwolf/webrevs/JDK-6991580/webrev.02/ FWIW, I don't think the test needs IP addresses of DNS servers to be functional, though. All it really does is passing it to InetAddress.getByName(). Prior this patch DnsC

Re: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws NumberFormatException

On 21/04/2015 16:04, Michael McMahon wrote: On 21/04/15 14:56, Alan Bateman wrote: : Can the test be moved to jdk/test/com/sun/jndi/dns as that seems to be where the other tests are? Also I assume this will need a copyright header before it is pushed. -Alan I had pushed it already. So

Re: RFR(xs): 6991580: IPv6 Nameservers in resolv.conf throws NumberFormatException

On 21/04/2015 16:04, Michael McMahon wrote: : http://cr.openjdk.java.net/~michaelm/8078276/webrev.1/ Before you push this, shouldn't the test have copyright Red Hat? There's an example in the same directory. -Alan

Re: RFR: JDK-8041677 - java/net/MulticastSocket/TestInterfaces failed on Oracle VM Virtual Ethernet Adapter

On 26/05/2015 20:21, Mark Sheppard wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8041677/webrev/ which addresses the issue https://bugs.openjdk.java.net/browse/JDK-8041677 analysis has shown that the Teredo interfaces causes issue, due to its dy

Re: RFR: JDK-8077377 - java/net/MulticastSocket/SetOutgoingIf.java fails intermittently with NullPointerException

On 26/05/2015 20:34, Mark Sheppard wrote: Hi please oblige and review the following change http://cr.openjdk.java.net/~msheppar/8077377/webrev/ to address the issue https://bugs.openjdk.java.net/browse/JDK-8077377 it is possible that "stray" packets can be received in this MulticastSocket t

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

On 02/06/2015 14:37, Paul Sandoz wrote: : There is one small area of uncertainty with NetworkInterface. Can the following method ever return null? 342 public static Enumeration getNetworkInterfaces() 343 throws SocketException { 344 NetworkInterface[] netifs = getAl

Re: RFR 8081678: Add Stream returning methods to classes where there currently exist only Enumeration returning methods

On 03/06/2015 17:47, Paul Sandoz wrote: : Ok, i removed it but added an assert for the array being non-null and containing at least one element. I also refined the documentation of the stream returning method in light of this: http://cr.openjdk.java.net/~psandoz/jdk9/JDK-8081678-enumeratio

Re: [Preliminary] RFR JDK-8064925: URLConnection::getContent needs to be updated to work with modules

On 24/06/2015 12:08, Pavel Rappo wrote: Hi everyone, Could you please review my change for JDK-8064925? http://cr.openjdk.java.net/~prappo/8064925/webrev.01/ The main goal is to see if the proposed spec change and the overall approach are correct. The update to the API docs looks good to

Re: [Preliminary] RFR JDK-8064925: URLConnection::getContent needs to be updated to work with modules

On 24/06/2015 13:20, Pavel Rappo wrote: Thanks Alan. Both issues are fixed now, webrev updated in place. Thanks, I think it looks good now. Do you want to finalize the changes now? -Alan

Re: RFR 8080486: JNI exception pending in jdk/src/java.base/windows/native/libnet/DualStackPlainSocketImpl.c

On 04/09/2015 16:04, Daniel Fuchs wrote: Hi Vyom, I'm not a net/JNI expert but what you are proposing looks good to me too. Ivan has already given his assent. Unless I hear objections - or comments from other reviewers, I will sponsor this change and push it for you (I'll wait for Monday). I

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

On 07/09/2015 10:26, Vyom Tewari wrote: Hi everyone, Can you please review my changes for below bug. Bug: JDK-8080402 : File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java Webrev: http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.01/ This change ensure that if c

Re: RFR 8080402: File Leak in jdk/src/java.base/share/classes/sun/net/sdp/SdpSupport.java

On 07/09/2015 14:08, Vyom Tewari wrote: Hi All, Please find the latest diff, which contains the latest fix. http://cr.openjdk.java.net/~dfuchs/vyom/8080402/webrev.02/ I think this looks okay now. -Alan

Re: RFR [9] 8139179: URLStreamHandler* should link to URL ctor that specifies how factories/providers are located

This looks okay to me. On 09/10/2015 14:52, Chris Hegarty wrote: It was pointed out that the updated URL spec that describes how URL protocol handlers are located isn't prominent in the avadoc. In particular it was noted that it's not linked from URLStreamHandlerFactory or URLStreamHandlerProv

Re: SO_REUSEPORT feature support in JDK 9 for socket communication

On 22/10/2015 14:04, Roger Riggs wrote: Hi Sandhya, The folks on net-dev@openjdk.java.net will be interested too. Yes, net-dev is the best list for this. One other thing to mention is the SocketOption interface and the setOption/getOption methods. This allows for platform or JDK-specific s

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 25/10/2015 23:32, Mark Sheppard wrote: Hi, please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8134577/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8134577 the operative word has been "eliminate". This has been a very t

Re: Patch for adding SO_REUSEPORT socket option

On 16/11/2015 18:49, Kharbas, Kishor wrote: P.S. Based on Alan Baleman's comment on JBS, we are in meanwhile working on adding this option to 'java.net.ExtendedSocketOption'. My comment in the bug was just to bring up the question as to whether this should be a standard or JDK-specific so

Re: Patch for adding SO_REUSEPORT socket option

On 20/11/2015 20:59, Lu, Yingqi wrote: Hello All, We added Version 3 of the patch here. http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.03/ It has the exact same implementation as Version 1 which implements SO_REUSEPORT

Re: Patch for adding SO_REUSEPORT socket option

On 21/11/2015 02:08, Lu, Yingqi wrote: Hi Alan, Please let me know if there is anything we can do at the meantime to help. We are more than happy to help. Sorry, I wasn't clear. I meant that you will need to work on the javadoc. In many of the classes you've added the following to the spec

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 12/11/2015 16:46, Mark Sheppard wrote: Hi, based on feedback from first review the updates have been amended please oblige and review the current set of changes as per http://cr.openjdk.java.net/~msheppar/8134577/webrev.02/ I'm looked through the changes in this webrev. At a high-leve

Re: Patch for adding SO_REUSEPORT socket option

On 23/11/2015 04:12, Lu, Yingqi wrote: Hi Alan, One more question please JI want to make sure I understand correctly on your following suggestion. In order to use supportedOptions method to test SO_REUSEPORT, I will need to first write a native function to check if SO_REUSEPORT is supporte

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 22/11/2015 16:09, Mark Sheppard wrote: Alan thanks for the feedback ... the implementation is based on what is currently being used in the tests via the existing set of NameService implementations. yes, the processing of the hosts file returns the first mapping it encounters. The function

Re: [PING] Re: Unexpected BindException in Endpoint.publish

On 01/12/2015 05:20, KUBOTA Yuji wrote: Hi all, Please review this issue and patch. This is JAX-WS so any changes to this code will probably need to go get pushed to the upstream project too. Best to send it to core-libs-dev (as the EE/JAX-* areas don't have their own mailing list here). M

Re: Patch for adding SO_REUSEPORT socket option

On 02/12/2015 17:08, Lu, Yingqi wrote: Hi All, A quick check here. Does anyone get a chance to try the most recent patch? Any feedback and comments? Thanks, Lucy I looked through the latest webrev (webrev.05) and it's looking quite good. I agree with Michael, we should decide whether

Re: Patch for adding SO_REUSEPORT socket option

On 07/12/2015 18:59, Lu, Yingqi wrote: Oh, I got it now. You want SO_REUSEPORT to be disabled by default for both ServerSocketChannelImpl and SocketChannelImpl. I am actually OK either way. Alan/Michael, what is your take on this? If we all think "default off" is the correct/better way to go

Re: RFR [9] 8143554: UnsupportedOperationException is not thrown for unsupported options

I'm sure Michael will look at this but I have a question - shouldn't SocketImpl throw UOE for this case? I'm just wondering if checking the supported options in setOption/getOption is just covering up an issue with the SocketImpl methods. -Alan On 08/12/2015 12:36, Svetlana Nikandrova wrot

Re: RFR [9] 8143554: UnsupportedOperationException is not thrown for unsupported options

On 08/12/2015 13:44, Svetlana Nikandrova wrote: Hi Alan, thank you for your replay. Please let me explain a little. For example ServerSocket and Socket have different supported options set, but the same SocketImpl under the hood. Yes, SocketImpl's setOptions() and getOptions() can be modified

Re: Patch for adding SO_REUSEPORT socket option

On 08/12/2015 00:53, Lu, Yingqi wrote: Hi Alan, I heard that the feature freeze for OpenJDK9 is approaching. Given the significant performance impact (up to 1.93x with Hadoop Distributed File System) this feature provides and the status of the existing work, we would be really interested in

Re: RFR [9] 8143554: UnsupportedOperationException is not thrown for unsupported options

On 23/12/2015 11:22, Svetlana Nikandrova wrote: Little remainder. On 19.12.2015 1:32, Svetlana Nikandrova wrote: Alan, Michael, thank you for your feedback. As you suggested I moved checking code down to the implementation. Please see updated webrev: http://cr.openjdk.java.net/~kshefov/8143

Re: Patch for adding SO_REUSEPORT socket option

On 21/12/2015 17:53, Lu, Yingqi wrote: Hi All, Sorry for the late reply. Here is the link to the most recent reversion of the patch (version #6). http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.06/ In this version, we have done following modifications based on the feedback we received.

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 31/12/2015 14:30, Mark Sheppard wrote: Hi please oblige and review the current version of the fix for https://bugs.openjdk.java.net/browse/JDK-8134577 at http://cr.openjdk.java.net/~msheppar/8134577/webrev.05/ which is based on feedback from the second review. I looked through the latest

Re: Patch for adding SO_REUSEPORT socket option

On 04/01/2016 18:43, Volker Simonis wrote: : Alan, what do you mean by "unknown" platform? Currently, as far as I know, 0x0200 is used by AIX and MacOS X. Do you suggest to name these platforms explicitly and set it to 0 otherwise? Leaving the default at 0x0200 has the advantage that it would i

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 05/01/2016 00:54, Mark Sheppard wrote: Hi, as per feedback below webrev has been updated http://cr.openjdk.java.net/~msheppar/8134577/webrev.06/ change summary: * List nameServices replaced with Nameservice nameService * references to nameServices removed * private interface NameServic

Re: Patch for adding SO_REUSEPORT socket option

On 04/01/2016 19:24, Volker Simonis wrote: On Mon, Jan 4, 2016 at 8:02 PM, Lu, Yingqi wrote: : 2. Regarding to the code snippet in net_util_md.c, the reason I check for ENOPROTOOPT is to enable SO_REUSEPORT in the situation that the feature is supported but something else happens during se

Re: Patch for adding SO_REUSEPORT socket option

On 05/01/2016 04:32, Lu, Yingqi wrote: Hi Alan/Volker, I just found out that the code works by adding the same static block (net library loading) into SocketImpl.java although isReusePortAvailable() is being defined in its subclass AbstractPlainSocketIml.java. I use a print statement to con

Re: RFR: 8146526: Improve java.net.URI$Parser startup characteristics

On 05/01/2016 22:47, Claes Redestad wrote: Hi, please review this patch to cleanup URI$Parser to help URI construction when run with the interpreter, mostly by inlining wrapping methods: Bug: https://bugs.openjdk.java.net/browse/JDK-8146526 Webrev: http://cr.openjdk.java.net/~redestad/81465

Re: Patch for adding SO_REUSEPORT socket option

On 05/01/2016 18:56, Lu, Yingqi wrote: Hi Alan, Sorry for the confusion. Let me be more detailed on the issue. In previous version of the patch, I added an initializer in SocketImpl.java to load the libnet.so since the isReusePortAvailable and its native implementation were there. Then, thi

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 06/01/2016 15:37, Mark Sheppard wrote: thanks for the feedback, Alan based on suggestions, all issues have been addressed and patch has been updated http://cr.openjdk.java.net/~msheppar/8134577/webrev.07 the following should be noted: ExtensionsWithLDAP.java is added to the exclude list

Re: Patch for adding SO_REUSEPORT socket option

On 07/01/2016 16:41, Lu, Yingqi wrote: Hi Alan, In AbstractPlainSocketImpl, I am using the existing/default initializer so that there is only 1 initializer. However, it does not execute. That is the issue I am seeing. Any suggestion on the issue? Are you 100% sure that your updated Abstrac

Re: RFR: 8146686: Create the schemeSpecificPart for non-opaque URIs lazily

On 08/01/2016 14:41, Claes Redestad wrote: Hi, please review this patch to lazily create schemeSpecificPart for non-opaque URIs. This change accounts for some improvement in footprint characteristics and a 10-20% improvement on URI creation microbenchmarks, while not regressing notably on a

Re: Patch for adding SO_REUSEPORT socket option

On 14/01/2016 18:28, Lu, Yingqi wrote: Hi Alan/Michael/Volker, Here is the link to the version 7 of the patch. http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.07/ Please note: after the code has been uploaded, I found out I forgot to remove extra check of ENOPROTOOPT in the net_util_md.

Re: RFR [9] 8143554: UnsupportedOperationException is not thrown for unsupported options

On 13/01/2016 15:48, Svetlana Nikandrova wrote: Alan, thank you for you replay. Here is my updated webrev with formatting fixes. http://cr.openjdk.java.net/~kshefov/8143554/webrev.03/ About getSocket() check - you are right, it is b

Re: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

On 17/01/2016 15:30, Claes Redestad wrote: Hi, please review this patch which might make URI.toURL more efficient Webrev: http://cr.openjdk.java.net/~redestad/8147462 Bug: https://bugs.openjdk.java.net/browse/JDK-8147462 This patch exploits the fact that URI will apply the same validation t

Re: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

On 18/01/2016 19:26, Chris Hegarty wrote: On 18 Jan 2016, at 16:20, Claes Redestad <mailto:claes.redes...@oracle.com>> wrote: On 2016-01-18 15:34, Chris Hegarty wrote: On 18/01/16 14:09, Alan Bateman wrote: On 17/01/2016 15:30, Claes Redestad wrote: Hi, please review this pa

Re: RFR: 8147962: URL should handle lower-casing of protocol locale-independently

On 21/01/2016 17:27, Claes Redestad wrote: Hi, using String.toLowerCase() in URL allows some strings to lower-case to a string that'd be invalid, e.g. "FILE".toLowerCase() -> "f\u0131le" in turkish locales. This patch suggests using the locale-independent String.toLowerCase(Locale.ENGLISH

Re: RFR: 8147962: URL should handle lower-casing of protocol locale-independently

On 22/01/2016 12:29, Claes Redestad wrote: : http://cr.openjdk.java.net/~redestad/8147962/webrev.02/ This looks good to me. -Alan

Re: JDK-8148424 Support ipv6-only environments

On 28/01/2016 02:29, Martin Buchholz wrote: Are y'all interested in our ipv6-only changes? https://bugs.openjdk.java.net/browse/JDK-8148424 If yes, there will be some work on both sides, mostly for multi-platform testing. I think so, this is configuration that we attempted to test several times,

Re: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

This looks okay. I think it would be good to put a javadoc comment on this method, also maybe move it to below all the constructors rather than in the middle. -Alan. On 28/01/2016 16:38, Claes Redestad wrote: On 2016-01-28 16:52, Chris Hegarty wrote: ... This looks fine Claes. Thanks

Re: RFR: 8147462: URI.toURL could be more efficient for most non-opaque URIs

On 28/01/2016 23:47, Claes Redestad wrote: Sure, as this is package-private API a short description and reference to the URI::toURL method whose specification we adhere to should suffice: http://cr.openjdk.java.net/~redestad/8147462/webrev.06/ This looks good - thanks! -Alan

Re: Patch for adding SO_REUSEPORT socket option

On 28/01/2016 06:03, Lu, Yingqi wrote: Hi Alan, Here is a new version of the patch: http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.08/ In this version, based on your comment, we have changed following items: 1. Remove the dependency of DatagramSocketImpl and MulticastSocket with Abstr

Re: Patch for adding SO_REUSEPORT socket option

On 05/02/2016 17:27, Lu, Yingqi wrote: Hi Alan, Here is the new modification of the patch. The link is available here: http://cr.openjdk.java.net/~mcberg/jdk/6432031/webrev.10/ In this version, we make supportedOptions() in AbstractPlainSocketImpl and AbstractPlainDatagramSocketImpl return an

Re: Patch for adding SO_REUSEPORT socket option

On 16/02/2016 18:03, Lu, Yingqi wrote: Hi Alan, I am wondering if you got chances to review the latest patch? Thank you! Thanks, Lucy I'm happy with the latest patch and I will try to get it into JDK 9 soon for you. -Alan

Re: Patch for adding SO_REUSEPORT socket option

On 17/02/2016 09:22, Volker Simonis wrote: Hi Alan, I'm just running a quick test build on AIX to see if everything is still working. I'll let you know once it completes (latest today evening). I've done the same and I think we need to drop the patches to the DatagramChannel multicast tests

Re: Patch for adding SO_REUSEPORT socket option

On 17/02/2016 11:43, Chris Hegarty wrote: I know this has gone through several rounds of review already. I do not want to stall progress, I am reasonably happy with the changes, but I have a few comments ( that can be addressed later, if needed ). - MulticastSocket.java: I would add a javado

Re: Patch for adding SO_REUSEPORT socket option

On 11/02/2016 17:47, Lu, Yingqi wrote: : Please let us know if everything is all right. Again, thank you very much for your help! I've pushed the changes to the jdk9/dev forest: http://hg.openjdk.java.net/jdk9/dev/jdk/rev/f92af283ab18 -Alan.

Re: RFR 8145635 : Add TCP_QUICKACK socket option

On 24/02/2016 09:16, vyom wrote: Hi All, Please review my code changes for the below issue. Bug: JDK-8145635 : Add TCP_QUICKACK socket option Webrev: http://cr.openjdk.java.net/~vtewari/8145635/webrev0.0/index.html Currently TCP_QUICKACK is only supported on Linux( since Linux 2.4.4) so i i

Re: RFR 8148609: supportedOptions() methods return a mutable set

On 01/03/2016 09:27, vyom wrote: Hi All, Please review my code changes for the below issue. Bug: JDK-8148609 : supportedOptions() methods return a mutable set Webrev: http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.0/ Can

Re: RFR 8150521: Test test/java/net/InetAddress/getOriginalHostName.java fails to load JavaNetInetAddressAccess from SharedSecrets

On 02/03/2016 07:44, vyom wrote: Hi Chris, Thanks for review please find the updated webrev(http://cr.openjdk.java.net/~nkumar/vyom/8150521/webrev0.1/index.html ). This looks okay to me. Style wide, can you put a space i

Re: RFR 8148609: supportedOptions() methods return a mutable set

On 02/03/2016 06:47, vyom wrote: Hi Chris/Alan, Thanks for review, please find the updated webrev(http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.1/index.html ). This looks much better. I see the test is name

Re: RFR 8148609: supportedOptions() methods return a mutable set

On 03/03/2016 09:03, Chris Hegarty wrote: On 3 Mar 2016, at 05:36, Vyom Tewari wrote: please find the updated webrev http://cr.openjdk.java.net/~nkumar/vyom/8148609/webrev0.2/ Looks fine. Looks okay to me too. -Alan

Re: RFR: JDK-8134577 - Eliminate or standardize a replacement for sun.net.spi.nameservice.NameServiceDescriptor

On 18/03/2016 11:17, Chris Hegarty wrote: Hi Mark, This mainly looks good. Some specific comments on InetAddress. - Why did you add transient to this field? private static TRANSIENT NameService nameService = null; - There will be support for IPv6, right? There is a comment in t

Re: RFR [9] 8153372: Remove sun.misc.ManagedLocalsThread from jdk.httpserver

This looks fine. On 18/04/2016 06:53, Chris Hegarty wrote: 8056152 added a new constructor to java.lang.Thread to constructing Threads that do not inherit inheritable-thread-local initial values. Given there is now a supported API for creating such threads, other areas of the JDK should be upd

Re: RFR: 8154238: Drop code to support Windows XP in windows socket impl

On 18/04/2016 10:45, Chris Hegarty wrote: The changes look fine. Maybe the bug description should be updated a before pushing, it looks like it affects only legacy networking code and not NIO. Maybe "... and async channels" ? The changes to the NIO code look okay but probably should be split in

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 25/04/2016 22:01, Chris Hegarty wrote: One of the remaining open issues in JEP 200 [1] is that the base module exports the jdk.net package, thereby violating Principle 4 of JEP 200: a Java SE module must not export any non-SE API packages without qualification. http://cr.openjdk.java.net/~c

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 26/04/2016 10:16, Chris Hegarty wrote: On 26 Apr 2016, at 09:20, Alan Bateman wrote: On 25/04/2016 22:01, Chris Hegarty wrote: One of the remaining open issues in JEP 200 [1] is that the base module exports the jdk.net package, thereby violating Principle 4 of JEP 200: a Java SE module

Re: RFR JDK-8151913: Fix module dependencies in java/net tests

On 27/04/2016 08:08, John Jiang wrote: Hi, Please review the fix for explicitly declaring module dependencies for java net tests. Issue: https://bugs.openjdk.java.net/browse/JDK-8151913 Webrev: http://cr.openjdk.java.net/~jjiang/8151913/webrev.00 Since every test in test/java/net/httpclient/*

Re: RFR [9] 8044773: Refactor jdk.net API so that it can be moved out of the base module

On 27/04/2016 10:04, Chris Hegarty wrote: On 26 Apr 2016, at 18:21, Alan Bateman wrote: I took a second pass over it. One thing that I'm wondering about is whether BaseExtendedSocketOptions + Support should be collapsed into one abstract class ExtendedSocketOptions (or better name) w

Re: RFR [9] 8155578: OpenJDK build failed after JDK-8044773

On 28/04/2016 09:17, Chris Hegarty wrote: This is a review for a trivial, but build-fatal, addition of a qualified export to the jdk.net module, that was mistakenly omitted from the changes for 8044773. This looks fine.

Re: RFR JDK-8151913: Fix module dependencies in java/net tests

On 28/04/2016 05:50, John Jiang wrote: Hi, Please review another webrev: http://cr.openjdk.java.net/~jjiang/8151913/webrev.02 The java.httpclient module declaration is removed from all of java/net/httpclient tests, even though some ones have to declare other modules. If a test has the @modules

Re: RFR(S): 8156521: Minor Fixes and cleanups in NetworkInterface.c

On 11/05/2016 09:50, Chris Hegarty wrote: Hi Christoph, On 11 May 2016, at 08:43, Dmitry Samersoff wrote: ... bugreport: https://bugs.openjdk.java.net/browse/JDK-8156521 webrev: http://cr.openjdk.java.net/~clanger/webrevs/8156521.0/ I think this is mainly fine, and good to have such clean

Re: Reminder about reported problem in NetworkInterface.c

On 12/05/2016 11:25, Langer, Christoph wrote: Hi Doychin, thanks for pointing me to this. I was already looking at that part of the code and know about some gaps. So I'll take this item and open a bug and work on integrating the proposed change. I don't see Doychin on the of OCA signatorie

Re: RFR 8048520 :File Descriptor Leak in jdk/src/solaris/native/java/net/net_util_md.c

On 20/05/2016 09:50, vyom wrote: Hi, Please review the simple fix for below issue. Bug: JDK-8048520 :File Descriptor Leak in jdk/src/solaris/native/java/net/net_util_md.c Webrev: http://cr.openjdk.java.net/~vtewari/8048520/webrev0.0/index.html

Re: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9

On 20/05/2016 11:16, Svetlana Nikandrova wrote: Hi Artem, thank you for your comments. Please see updated review: http://cr.openjdk.java.net/~snikandrova/8136933/webrev.01/ I've moved version check to OSInfo.java and used Process

Re: RFR 8136933: Additional tests for Solaris SO_FLOW_SLA socket option in JDK 9

On 20/05/2016 14:05, Svetlana Nikandrova wrote: Alan, another test related to this option is on the same level (test/jdk/net/SocketFlow) so I thought it's ok to maintain the same hierarchy. I can move test to test/jdk/net/Sockets/ExtendedSocketOptions/SO_FLOW_SLA or to test/jdk/net/Sockets

Re: RFR [9] 8155086: Replace usage of -Djdk.launcher.limitmods in tests with -limitmods

On 23/05/2016 23:05, Chris Hegarty wrote: Replace usage of -Djdk.launcher.limitmods, in several networking and NIO tests, with -limitmods now that jtreg with support for -limitmods is available. Looks fine. I think Mandy has switched this for an upcoming patch too. -Alan

Re: RFR 8157811 [9] Additional minor fixes and cleanups in NetworkInterface.c

On 25/05/2016 10:50, Chris Hegarty wrote: As a follow up to JDK-8156521, and when comparing against the version of this file in jdk8u-dev a few minor issues were noticed. There is a free of a memory structure that was missed somehow in the 9 version of this file ( it is already in the 8 versio

Re: RFR JDK-8151913: Fix module dependencies in java/net tests

On 11/06/2016 08:59, John Jiang wrote: Hi, Just restarted this job. On 2016/4/29 15:34, Alan Bateman wrote: On 28/04/2016 05:50, John Jiang wrote: Hi, Please review another webrev: http://cr.openjdk.java.net/~jjiang/8151913/webrev.02 The java.httpclient module declaration is removed from

Re: RFR [9] 8157166: Update spec to account for platforms that do not support multicast

On 16/06/2016 16:03, Chris Hegarty wrote: Some platforms do not support multicasting, but the current spec requires that it is supported. It seems reasonable to relax this, somewhat, so that multicasting is effectively optional on these platforms. java.net.MulticastSocket.joinGroup and java.ni

Re: RFR [9] 8157166: Update spec to account for platforms that do not support multicast

On 16/06/2016 16:38, Chris Hegarty wrote: On 16 Jun 2016, at 16:31, Alan Bateman wrote: On 16/06/2016 16:03, Chris Hegarty wrote: Some platforms do not support multicasting, but the current spec requires that it is supported. It seems reasonable to relax this, somewhat, so that

Re: RFR: 8159745: Remove java.net.Parts

On 17/06/2016 14:43, Claes Redestad wrote: Hi, URL.java defines a package-private class Parts, which can be trivially inlined in the one place where it's currently used. Webrev: http://cr.openjdk.java.net/~redestad/8159745/webrev.01/ Bug: https://bugs.openjdk.java.net/browse/JDK-8159745 I s

Re: RFR [9] 8160993: Fix headers in the java/net/http package

On 18/07/2016 11:26, Chris Hegarty wrote: This is a change fix the license headers in the java/net/http package. There was a cut'n'paste error that mostly missed the last line of the header. Also, I added a new line after the header consistently in every file. As well as a few places that had o

Re: Review request JDK-8165180: Provide a shared secret to access non-public ServerSocket constructor

On 31/08/2016 21:48, Mandy Chung wrote: This patch introduces JavaNetSocketAccess to allow access to non-public ServerSocket constructor that is accessed by some other area as a clean up. Webrev: http://cr.openjdk.java.net/~mchung/jdk9/webrevs/8165180/webrev.00/ This looks okay to me. -

Re: RFR(s): 8166791: Fix module dependencies for networking component tests

On 03/10/2016 14:33, Sergei Kovalev wrote: SSL engin requires security provider. Its implementation located in jdk.security.auth. In case no jdk module added we getting an exception: test ErrorTest.test(): failure java.lang.IllegalArgumentException: Cannot support TLS_KRB5_WITH_3DES_EDE_CB

Re: RFR(s): 8166791: Fix module dependencies for networking component tests

On 03/10/2016 15:05, Sergei Kovalev wrote: Such notation (module/package) helps to jtreg to understand that the module required on compilation stage. Jtreg adding "--add-exports module/package=ALL-UNNAMED" for each record of this type. In our case id adds a string: --add-exports java.compiler

Re: AF_INET6 support

On 13/10/2016 07:19, Langer, Christoph wrote: Hi networking experts, I’ve got a question regarding AF_INET6. In jdk native code you’ll still find lots of code guarded by “#ifdef AF_INET6”. I’m wondering if there are still supported build environments where AF_INET6 is not defined. Or is i

Re: RFR: JDK-8164815 - 3 JCK NetworkInterface tests fail on Raspberry Pi

On 10/11/2016 16:39, Mark Sheppard wrote: Hi, please oblige and review the change http://cr.openjdk.java.net/~msheppar/8164815/webrev/src/java.base/share/classes/java/net/NetworkInterface.java.sdiff.html to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8164815 It w

Re: RFR: JDK-8164815 - 3 JCK NetworkInterface tests fail on Raspberry Pi

On 10/11/2016 20:26, Chris Hegarty wrote: : It has, but, for me at least, since the changes for 7120665 [1] require a conformant implementation to support at least one network interface, it seems more like an error if we encounter this situation. Ugh, I'd forgotten that needs to be supported t

Re: RFR: 8167178 Exported elements referring to inaccessible types in java.naming

On 16/01/2017 09:10, Vyom Tewari wrote: Hi All, Please review below the small fix for the issue. BugId : https://bugs.openjdk.java.net/browse/JDK-8167178 The compatibility impact is minimum as no code in JDK is currently depend on it. I think this is okay, it is technically an API change bu

Re: RFR: JDK-8174716,,java/net/httpclient/security/Driver.java failing in JDK 9

Looks okay. On 10/02/2017 09:35, Michael McMahon wrote: This test has been failing since the introduction of the incubator mechanism but wasn't being run due to an issue with jtreg that is about to be fixed. This fixes the problem with the test first. http://cr.openjdk.java.net/~michaelm/81

Re: Let's improve IPv6 support

On 17/03/2017 18:47, Martin Buchholz wrote: Google cares a lot about IPv6, and not only because Vint Cerf works at Google. We have some local modifications and some networking expertise and intend to port/contribute that to openjdk10. Most of this is the work of my colleagues Alexander Smun

Re: Expose DNS Servers via public API

On 30/03/2017 15:36, Norman Maurer wrote: Hi there, I am not sure if this is the correct list for the question but as relate to network I will just try. If its the wrong list please tell me which one would be better fitted. Is there reason why not expose the DNS Servers configured on a syst

Re: Expose DNS Servers via public API

On 30/03/2017 15:59, Norman Maurer wrote: Thats why I tried to kick-off the topic :) Thanks for the quick reply btw…. So is this list the right place for this discussion ? I just checked the docs for the JNDI-DNS provider [1] and it documents that the provider updates the java.naming.provider

Re: [10] RFR: 8186930: Constant fold URI constants

On 29/08/2017 21:26, Claes Redestad wrote: Hi, please review this patch to pre-calculate constants in java.net.URI and sun.net.www.ParseUtil, removing work from runtime (reduces bytecodes executed in the interpreter on bootstrap by ~15K). This also removes use of BitSet from ParseUtil, which ap

Re: [10] RFR: 8186930: Constant fold URI constants

On 31/08/2017 00:11, Claes Redestad wrote: : I just wonder if ParseUtil should keep the lowMask/highMask methods in comments so that further maintainers can satisfy themselves that the values are correct. I thought leaving a comment in ParseUtil that they can be still found in URI was suf

Re: [10] RFR: 8186930: Constant fold URI constants

On 31/08/2017 16:26, Claes Redestad wrote: On 2017-08-30 17:17, Alan Bateman wrote: I think it could be useful as someone reading the code isn't going to immediately know to jump to URI. Done: http://cr.openjdk.java.net/~redestad/8186930/jdk.01/ This looks good to me. -Alan

Re: RFR 8145635 : Add TCP_QUICKACK socket option

On 11/10/2017 21:08, Chris Hegarty wrote: Given that this option is specific to TCP, then the `TCP_` prefix is more appropriate. I agree. We have StandardSocketOptions.TCP_NODELAY as an example to look at. -Alan

Re: RFR 8145635 : Add TCP_QUICKACK socket option

On 19/10/2017 03:56, vyom tewari wrote: Hi All, please find the latest webrev(http://cr.openjdk.java.net/~vtewari/8145635/webrev0.7/index.html). I can't recall if I brought this up already but we do have an issue to deprecate-for-removal jdk.net.Sockets? Socket and friends were rev'ed in Ja

Re: Per-Connection TCP keepalive parameters and application-wide keepalive enforcement.

On 10/11/2017 06:09, Bernd Eckenfels wrote: Hello, TCP keepalive is a rather elegant mechanism to detect abandoned TCP Connections. With increased distribution of components and inclusion of Cloud based services I have the feeling it has become more important. Yet it is rather clumsy to use

<    1   2   3   4   5   6   7   8   9   10   >