Re: RFR [9] 8035868: Check for JNI pending exception in windows/native/sun/net/spi/DefaultProxySelector.c

On 28/02/2014 19:13, Chris Hegarty wrote: Some more trivial checking in the Windows native code for JNI pending exceptions. http://cr.openjdk.java.net/~chegar/8035868/webrev.00/webrev/ -Chris. This looks okay to me. We should probably fix up the indentation of this code some time too. -Alan

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

On 28/02/2014 14:40, Chris Hegarty wrote: : I think option 2 is preferable: http://cr.openjdk.java.net/~chegar/8035897/webrev.00/webrev/ I'm still checking to see it an automatic regression test is possible, but I wanted to circulate the changes for comment first. This mostly looks okay to me

Re: RFR [9] 8035897 : FD_SETSIZE should be set on macosx

On 03/03/2014 16:45, Chris Hegarty wrote: Alan, I pushed this changes before receiving your comments. If you agree, I'll push the following changes under a new bug number. http://cr.openjdk.java.net/~chegar/8035897/webrev.comments/webrev/ The error handling seems a little overly complicated

Re: RFR: 8025293 - JNI exception pending checks in java.net

On 04/03/2014 11:06, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8025293/webrev/ to address the issue in https://bugs.openjdk.java.net/browse/JDK-8025293 this applies additional checks after JNI native calls in src/solaris/nati

Re: RFR: 8025293 - JNI exception pending checks in java.net

On 04/03/2014 11:54, Mark Sheppard wrote: Hi Alan, thanks for the response. I originally had a CHECK_NULL_RETURN after getBraodcast and tests failed on Macos, but not on other platforms! The issue is that getBroadcast returns NULL when broadcast is not available for an interface, or when th

Re: RFR: JDK-8036607 - JNI exception pending in jdk/src/windows/native/java/net/DualStackPlainDatagramSocketImpl.c

On 07/03/2014 11:46, Mark Sheppard wrote: Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036607/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8036607 This looks okay to me. A slightly more efficient alternative woul

Re: RFR: JDK8036601 - NI exception pending in jdk/src/windows/native/sun/net/dns/ResolverConfigurationImpl.c

On 12/03/2014 16:43, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036601/webrev/ This mostly looks good to me. One observation is that is the return from loadConfig isn't clear. What would you think about adding STS_ERROR (-1)

Re: RFR: JDK-8036600 - JNI exception pending in src/jdk/src/windows/native/sun/net/www/protocol/http/ntlm/NTLMAuthSequence.c

On 13/03/2014 18:51, Mark Sheppard wrote: Hi Please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8036600/webrev/ which address the issues raised in https://bugs.openjdk.java.net/browse/JDK-8036600 summary: main changes are to check JNI return values, malloc r

Re: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0

On 22/03/2014 08:13, Chris Hegarty wrote: The native SCTP implementation assumes that the given byte buffer ( buffer address + position ) is memory aligned. It re-uses the buffer for handling notifications from the SCTP Stack ( as well as for reading data off the socket ). This can result in a

Re: RFR [9] 8034181: SIGBUS at Java_sun_nio_ch_SctpChannelImpl_receive0

On 24/03/2014 14:09, Chris Hegarty wrote: Alan, Dmitry, I updated the webrev. It now allocates memory dynamically, and asserts that the number of bytes read is less than the size of sctp_notification ( for notifications ). http://cr.openjdk.java.net/~chegar/8034181/webrev.01/webrev/ -Chris.

Re: Add IDN support to existing net APIs

On 25/03/2014 02:35, Jonathan Lu wrote: Hi Michael, I'm wondering how we could move this forward. For the next step, is it just to draft a JEP for this change as a beginning? or should I get supports and approvals from some other groups or leaders ? - Cheers Jonathan Is the proposal only for

Re: Add IDN support to existing net APIs

On 26/03/2014 02:58, Jonathan Lu wrote: : Only for the system property to configure the use of IDNs and some related code to do the checking and conversion, no plan to add new methods to InetAddress. Thanks, I'm just wondering whether it would make sense to add APIs. Michael - do you have a

8039253: Remove undocumented com.oracle.net

As part of our long standing effort to prepare the platform for modules then we need to go through the various JDK-specific APIs and see which APIs are really "exported", supported, documented, etc. One odd one is com.oracle.net and I'd like to propose that we remove it. The build doesn't ge

Re: RFR [9] 8039362: Read content-types.properties as a resource

On 07/04/2014 19:54, Chris Hegarty wrote: [ Including Alex; there is a question/confirmation related to a change he pushed, that needs his input ] Hi Erik, thanks for your feedback, comments inline… Updated webrev: http://cr.openjdk.java.net/~chegar/8039362/01/webrev/ Looks like JDK-71537

Re: RFR [9] 8039362: Read content-types.properties as a resource

Chris, One thing to avoid consider is the ContentHandler javadoc. It contains this: " By default it looks in sun.net.www.content, ..." but this is JDK-specific location and so shouldn't be in the javadoc. -Alan.

Re: RFR [9] 8039362: Read content-types.properties as a resource

On 08/04/2014 13:50, Chris Hegarty wrote: : Yes, this is a legacy bug. It is related to the location of specific content type handlers, and as such a separate issue. I would like to handle it separately so as not to confuse the changes being proposed for this 8039362. I’ll file a new JIRA bug

Re: RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes

On 09/04/2014 14:13, Chris Hegarty wrote: Flip-flop! Thinking again about this, you're right. http://cr.openjdk.java.net/~chegar/8039470/URLConnection-report.html http://cr.openjdk.java.net/~chegar/8039470/URLConnection-report_01.html I could go further with this change, but I just want to rem

Re: RFR: 8036979: Support java.net.SocketOption<> in java.net socket types

On 08/04/2014 18:49, Michael McMahon wrote: Could I get the following reviewed please? In addition to providing generic support for java.net.SocketOption, it also includes 8032808, which implements a platform specific socket option SO_FLOW_SLA (in jdk.net) There are changes to two repos: http:

Re: RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes

On 09/04/2014 18:21, Chris Hegarty wrote: Michael, Alan There is/was an additional reference to the implementation specific package name in ContentHandler. It is now removed. I think this is the last one! Latest specdiff: http://cr.openjdk.java.net/~chegar/8039470/02/java/net/package-summar

Re: RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes

On 09/04/2014 22:19, Chris Hegarty wrote: http://cr.openjdk.java.net/~chegar/8039470/02/webrev/ That, that is easier to see the changes. In URL then it's not clear to me why the javadoc has to admit to a "system default package". Would it make sense to change this to just say that it falls b

Re: [8u-dev] RFR: 8036979: Support java.net.SocketOption<> in java.net socket types

Reflection or shared secrets is a coin toss here, I think what you have is okay. An alternative name for the package private class in java.net is SocketSecrets, just a suggestion as SocketsUtil sounds more general that it is. I agree with Chris on throwing InternalError if any of the reflect

Re: RFR [9] 8040038 : Test java/net/URLPermission/nstest/lookup.sh fails with ClassNotFoundException

On 14/04/2014 16:30, Chris Hegarty wrote: It looks like the change for JDK-8027221 missed an @build on the dependent library type, Util. This is just another sighting of the dreaded @library with -conc issue. diff --git a/test/java/net/URLPermission/nstest/lookup.sh b/test/java/net/URLPermiss

Re: RFR [9] 8039470:URLConnection.getContent incorrectly specifies the default location of content handler classes

On 15/04/2014 14:28, Chris Hegarty wrote: Latest changes: http://cr.openjdk.java.net/~chegar/8039470/03/specdiff/java/net/package-summary.html http://cr.openjdk.java.net/~chegar/8039470/03/webrev/ -Chris. This looks much better, thanks for going this. -Alan

Re: RFR [9] 8022450: Fix deprecation warnings in UCharacterDirection.java

On 01/05/2014 09:01, Chris Hegarty wrote: 8022473 has been logged to request replacements for the deprecated UCharacterEnums, but for now the deprecated warnings from UCharacterDirection should be suppressed. diff --git a/src/share/classes/sun/net/idn/UCharacterDirection.java b/src/share/clas

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

On 12/05/2014 11:03, Paul Sandoz wrote: It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. The groupings are a bit odd but I looked through the -core, -io, -management and -rmi patches and don't see any issues. Noth

Re: JDK-8041679 Replace uses of StringBuffer with StringBuilder within the JDK

On 12/05/2014 11:55, Paul Sandoz wrote: On May 12, 2014, at 12:42 PM, Alan Bateman wrote: On 12/05/2014 11:03, Paul Sandoz wrote: It covers many areas and i have grouped the patches into such areas to aid reviewing. When commenting please including core-libs. The groupings are a bit odd

Re: RFR: 8043118: update test/java/net/URLPermission/nstest/lookup.sh to use explicit @build target

On 14/05/2014 11:35, Michael McMahon wrote: Could I get the following small test case change reviewed please? This fixes a sporadic test case failure due to incorrect use of @build tag in the script --- a/test/java/net/URLPermission/nstest/lookup.sh +++ b/test/java/net/URLPermission/nstest/lo

Re: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound

On 27/05/2014 10:40, Pavel Rappo wrote: Hi everyone, Could you please review my change for JDK-8024832? http://cr.openjdk.java.net/~prappo/8024832/webrev.00/ Can you try just removing the isBound check? I ask because ssc.accept() will throw NotYetBoundException if the ServerSocketChannel is n

Re: RFR JDK-8024832: (so) ServerSocketChannel.socket().accept() throws IllegalBlockingModeException if not bound

On 27/05/2014 11:19, Pavel Rappo wrote: Alan, I don't think it would be exactly the same behaviour since there's a conditional check (1) before the ssc.accept call: try { if (!ssc.isBound()) throw new NotYetBoundException(); (1) i

Re: RFR 8043954: Fix behavior difference of connect() for AIX

On 04/06/2014 07:31, Jonathan Lu wrote: Hi Volker, Thanks for your comment! an updated webrev was made at http://cr.openjdk.java.net/~luchsh/JDK-8043954.2/ Would it make sense to set errno to sockopt_arg for the case that getsockopt(SO_ERROR) returns an error? Otherwise it looks okay to me.

Re: RFR 8043954: Fix behavior difference of connect() for AIX

On 05/06/2014 11:37, Jonathan Lu wrote: If getsockopt(SO_ERROR) failed, I did not find any explicit docs about the behavior. but as I tested with some C code snippet, the value of sockopt_arg would not be changed if getsockopt(SO_ERROR) failed. So I prefer to keep the current approach, does

Re: RFR 8043954: Fix behavior difference of connect() for AIX

On 06/06/2014 11:03, Jonathan Lu wrote: You are right! errno will be checked by other code if NET_Connect() failed, I've updated the patch, please help to review. http://cr.openjdk.java.net/~luchsh/JDK-8043954.3/ Thanks for the update,

Re: RFR JDK-8027308: HttpURLConnection should better handle URLs with literal IPv6 addresses

On 09/06/2014 06:40, Chris Hegarty wrote: This looks good to me Pavel. -Chris. It looks okay to me too, I was just wondering if it would be simpler to use host.substring + sb.append(']'). -Alan

Re: RFR JDK-8027308: HttpURLConnection should better handle URLs with literal IPv6 addresses

On 09/06/2014 18:06, Pavel Rappo wrote: Alan, it looks simpler, indeed: http://cr.openjdk.java.net/~prappo/8027308/webrev.01/src/share/classes/sun/net/www/protocol/http/HttpURLConnection.java.sdiff.html I have removed the StringBuilder completely. It doesn't seem to be a performance critical p

Re: RFR 8046588: test for SO_FLOW_SLA availability does not check for EACCESS

On 12/06/2014 18:04, Michael McMahon wrote: Could I get this change reviewed please? We need to check if the current process has permission to use the SO_FLOW_SLA socket option as well as test if the feature is installed. The problem would cause the new test to fail on Solaris machines with

Re: RFR 8046588: test for SO_FLOW_SLA availability does not check for EACCESS

On 12/06/2014 20:15, Michael McMahon wrote: It would be possible to change the error back, but what about supportedOptions() - what should that return? It doesn't seem right that it would include an option that cannot be used and how do we test it, if we can't tell whether the option is usabl

Re: RFR 8046588: test for SO_FLOW_SLA availability does not check for EACCESS

On 13/06/2014 11:49, Michael McMahon wrote: Okay. I can see the reasoning why supportedOptions should refer to the platform rather than the process/instance running. We could consider adding a sub-class of IOException for permission related failures, but I'm not proposing to do that here. For

Re: RFR 8046588: test for SO_FLOW_SLA availability does not check for EACCESS

On 13/06/2014 12:15, Michael McMahon wrote: To be honest, the test doesn't/(can't easily) check if a flow has been created. So, in practice a success return code doesn't prove that everything is working. Exercising the code at least is a basic smoke test. If we add a new exception then maybe w

Re: RFR [9] 8047674: java/net/URLPermission/nstest/lookup.sh NoClassDefFoundError when run in concurrent mode

On 23/06/2014 11:51, Chris Hegarty wrote: This test has been seen to fail occasionally when run with concurrency enabled. I believe the reason to be two fold: I don't know if the order matter here because the @build should compile all of jdk.testlibrary.*. However, I think it's worth trying and

Re: RFR: 8029607 Type of Service (TOS) cannot be set in IPv6 header

On 25/06/2014 12:21, Michael McMahon wrote: Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8029607/webrev.1/ This mostly looks good to me. I assume you have run the :jdk_nio tests and also run them with -vmoption:-Djava.net.preferIPv4Stack=true to make

Re: RFR: 8048212 Two tests failed with "java.net.SocketException: Bad protocol option" on Windows after 8029607

On 30/06/2014 17:53, Michael McMahon wrote: Could I get the following change reviewed please? http://cr.openjdk.java.net/~michaelm/8048212/webrev.1/ It fixes a problem caused by the fix for 8029607. The changes for that fix should not have been applied to Windows. So, this fix ensures that the

Re: RFR 8049220: URL.factory data race

On 03/07/2014 09:43, Peter Levart wrote: Hi, I noticed a data race in java.net.URL: https://bugs.openjdk.java.net/browse/JDK-8049220 I propose the following simple patch: http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.01/ A good catch and the change looks good to me. I

Re: RFR JDK-8049228: Improve multithreaded scalability of InetAddress cache

On 03/07/2014 11:12, Peter Levart wrote: I have filed a RFE that is more suitable for this change: https://bugs.openjdk.java.net/browse/JDK-8049228 So, is it strictly necessary to fix JDK-7186258 alone before applying the change for JDK-8049228 although it would supersede it? We can close

Re: RFR: 8048212 Two tests failed with "java.net.SocketException: Bad protocol option" on Windows after 8029607

On 04/07/2014 19:33, Michael McMahon wrote: Sorry for the delay in getting back to this. The following is a simpler change that restores the original NIO behavior on Windows http://cr.openjdk.java.net/~michaelm/8048212/webrev.2/ Yes, this much simpler. A minor nit is that L300 in Net.c sho

Re: RFR 8049220: URL.factory data race

On 07/07/2014 12:07, Peter Levart wrote: Hi Pavel, Alan and Paul, Thanks for reviewing. I accepted the suggestions from Pavel and Paul and created webrev.02: http://cr.openjdk.java.net/~plevart/jdk9-dev/URL.factory/webrev.02/ Is this good to go into jdk9-dev? The comments looks okay to me (a

Re: java.net.URI and RFC 3986 compliance

On 10/07/2014 01:50, Peter Firmstone wrote: Are there parties on this list interested in updating java.net.URI to RFC3986? Is there anyone here who has previously attempted this? If so what issues did you find with regard to backward compatibility? Hopefully Michael McMahon will jump in and g

Re: RFR: JDK-8040810 - Uninitialised memory in jdk/src/windows/native/java/net: net_util_md.c, TwoStacksPlainSocketImpl.c, TwoStacksPlainDatagramSocketImpl.c, DualStackPlainSocketImpl.c, DualStackPla

On 16/07/2014 18:00, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8040810/webrev/ which address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8040810 resulting from static code analysis. these changes explicitl

Re: The future of Serialization

On 09/08/2014 06:56, Peter Firmstone wrote: I've noticed there's not much interest in improving Serialization on these lists. This makes me wonder if java Serialization has lost relevance in recent years with the rise of protocol buffers apache thrift and other means of data transfer over byt

Re: The future of Serialization

On 11/08/2014 13:06, Peter Firmstone wrote: Thanks Alan, I can relate to time poverty :) I might be assuming too much, but if there's interest in doing something with Serialization, I'd be interested in learning about plans or difficulties involved in deserialization and modules. It can be a

Re: The future of Serialization

On 12/08/2014 10:03, Peter Firmstone wrote: Interesting, language features for modules, won't necessarily involve ClassLoader's (my assumptions were based on existing systems) although you'd expect modules to have their own ProtectionDomain. I think it would be reasonable to expect to that y

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

On 13/08/2014 15:02, Claes Redestad wrote: Hi, can I have a review for this patch to take advantage of offset-based parseInt methods added in 8041972 for java.net/sun.net classes? bug: https://bugs.openjdk.java.net/browse/JDK-8055032 webrev: http://cr.openjdk.java.net/~redestad/8055032/webrev

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

On 14/08/2014 10:32, Claes Redestad wrote: : Any particular place where you think readability becomes a problem? I've grown fond of the parseInt(s, radix, offset) form myself, but I'm biased. ;-) It's somewhat subjective but when a method has a sequence of parameters that are the same type (i

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

On 14/08/2014 12:42, Claes Redestad wrote: Noone brought it up, as far as I can recall. Since parseInt(String, int radix) already existed, I figured adding the range parameters to the end would be overall less awkward than to push the radix parameter right in the new methods. The chosen imple

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

On 14/08/2014 14:23, Claes Redestad wrote: How about methods only taking beginIndex? Integer.parseInt("x: 1000", 3, 10)? I guess these could to be dropped to avoid ambiguity and instead allow for variations where radix can be left out. I think there are two alternatives to the current impl

Re: RFR(S): 8055032: Improve numerical parsing in java.net and sun.net

On 14/08/2014 14:39, Alan Bateman wrote: On 14/08/2014 14:23, Claes Redestad wrote: How about methods only taking beginIndex? Integer.parseInt("x: 1000", 3, 10)? I guess these could to be dropped to avoid ambiguity and instead allow for variations where radix can be left out.

Re: RFR: JDK-8044306 - java.net.Inet4AddressImpl.getLocalHostName() uses IPv6 rather than IPv4

On 21/08/2014 17:02, Mark Sheppard wrote: Hi please oblige and review the small change http://cr.openjdk.java.net/~msheppar/8044306/webrev/ to address the issue raised in https://bugs.openjdk.java.net/browse/JDK-8044306 hints.ai_family is assigned AF_INET rather than AF_UNSPEC as the native f

Re: RFR 8056065: sun/net/www/protocol/http/RedirectOnPost.java failing.

On 26/08/2014 15:01, Michael McMahon wrote: Could I get the following small change reviewed please? One file was missed from my earlier change to SimpleSSLContext http://cr.openjdk.java.net/~michaelm/8056065/webrev.1/ This looks okay to me, I assume that all the :jdk_net tests are passing now.

Re: RFR (S) 8057936: java.net.URLClassLoader.findClass uses exceptions in control flow

On 10/09/2014 11:11, Claes Redestad wrote: Hi, please review this simple patch to avoid raising PrivilegedActionExceptions when failing to find a class in URLClassLoader. bug: https://bugs.openjdk.java.net/browse/JDK-8057936 webrev: http://cr.openjdk.java.net/~redestad/8057936/webrev.2/ I t

Re: Taking advantage of TCP Loopback fast path in Windows

On 24/09/2014 02:19, Martin Sawicki (MS OPEN TECH) wrote: Hello We're proposing an improvement to the OpenJDK which enables users to take advantage of the TCP loopback fast path mechanism in Windows for significantly higher performance of sockets whose both end points are on the same machine

Re: Taking advantage of TCP Loopback fast path in Windows

On 24/09/2014 16:58, Kirk Shoop (MS OPEN TECH) wrote: SIO_LOOPBACK_FAST_PATH must be set on the socket passed to accept. The way I think about this is the socket instance passed to listen represents the port while the socket instance passed to accept represents a single TCP stream. SIO_LOOPBA

Re: Taking advantage of TCP Loopback fast path in Windows

On 24/09/2014 19:21, Kirk Shoop (MS OPEN TECH) wrote: My memory is that setting it on the socket before calling listen did not work. However, we will try again and verify. It would be good to check, it may be that we just need to set it after the listen (in the case of listener oriented chan

Re: RFR: JDK-8058932 - java/net/InetAddress/IPv4Formats.java failed because hello.foo.bar does exist

On 30/09/2014 08:21, Mark Sheppard wrote: Hi Please oblige and review the following small change to test test/java/net/InetAddress/IPv4Formats.java --- a/test/java/net/InetAddress/IPv4Formats.javaTue Sep 30 13:25:04 2014 +0100 +++ b/test/java/net/InetAddress/IPv4Formats.javaT

Re: Taking advantage of TCP Loopback fast path in Windows

On 02/10/2014 11:17, Kirk Shoop (MS OPEN TECH) wrote: : We tried the suggestions in this thread and the result is a much smaller patch that works as well as the previous patch. https://openjdkcontrib.blob.core.windows.net/tcploopback/webrev-20141002.zip GetVersionEx is not used and th

Re: Taking advantage of TCP Loopback fast path in Windows

On 09/10/2014 18:10, Kirk Shoop (MS OPEN TECH) wrote: Here is the webrev with both changes: I've tweaked your patch a ting bit on a few minor issues. One is so that running with -Djdk.net.useTcpFastLoopback enables the setting. Another one is to just rename from fast_loopback to fastLoo

Re: Taking advantage of TCP Loopback fast path in Windows

On 17/10/2014 18:34, Kirk Shoop (MS OPEN TECH) wrote: If you are okay with this then I will push it to the jdk9/dev forest listing you as the author. Valery and I both worked on this, but if only one author can be listed then use my name. The attribution line allows for multiple contribu

Re: RFR(M): 8060470 : Unify and simplify the implmentations of Inet{4, 6}AddressImpl_getLocalHostName()

On 27/10/2014 17:45, Volker Simonis wrote: : Well, the problem is that already that very file contains code in both code conventions (see for example the implementations of 'ping4()' and 'Java_java_net_Inet4AddressImpl_isReachable0()' in Inet4AddressImpl.c which are mostly indented by two spaces)

Re: RFR: 8062744 jdk.net.Sockets.setOption/getOption does not support IP_TOS

On 04/11/2014 10:44, Michael McMahon wrote: Could I get the following small change reviewed please? http://cr.openjdk.java.net/~michaelm/8062744/webrev.1/ In JDK 9 the problem only affects the Socket.supportedOptions() method, but the same change is needed in 8 to allow the IP_TOS option to be

Re: RFR: 8062744 jdk.net.Sockets.setOption/getOption does not support IP_TOS

On 04/11/2014 11:00, Michael McMahon wrote: Thanks Alan. How about I just split the test and check the option setting behavior in OptionsTest.java which doesn't have any reference to the jdk.net.Sockets APIs and then check the Sockets.supportedOptions() method in the new test? That sounds oka

Re: RFR: 8062744 jdk.net.Sockets.setOption/getOption does not support IP_TOS

On 04/11/2014 14:45, Michael McMahon wrote: Right. Good catch. I've updated the webrev including the test to catch the above. http://cr.openjdk.java.net/~michaelm/8062744/webrev.2/ The updated webrev looks okay, pity we can't reliably test the IP_TOS value. -Alan.

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

On 15/12/2014 11:25, Chris Hegarty wrote: Konstantin, I did reply to this RFR [1], with a question, that is still unanswered. -Chris. [1] http://mail.openjdk.java.net/pipermail/net-dev/2014-December/008782.html I can think of configurations where the scenario could arise. It make me wonder

Re: RFR 8067105: Socket returned by ServerSocket.accept() is inherited by child process on Windows

On 17/12/2014 15:47, Chris Hegarty wrote: A socket connection which is returned by ServerSocket.accept() is inherited by a child process. The expected behavior is that the socket connection is not inherited by the child process. This is an oversight in the original implementation, that only set

Re: RFR 8067105: Socket returned by ServerSocket.accept() is inherited by child process on Windows

On 18/12/2014 11:52, Chris Hegarty wrote: Thanks for looking at this Alan. Surprisingly this issue has existed for a long time. I tested with the FCS version of JRE 5, 6, 7, 8, and 9-ea, on Windows Server 2008 R2, and 2012, and the newly accepted socket inherit behaviour can be seen. NIO serv

Re: RFR 8042581: Intermittent failure in java/net/DatagramSocket/InheritHandle.java

On 29/12/2014 15:46, Chris Hegarty wrote: Looks ok Felix. You could put the construction of the new DatagramSocket in a try-with-resources, so it will be closed always, even if the test fails. -Chris I agree with Chris' comment. One other thing is that testing if e instanceof BindException i

Re: RFR 8042581: Intermittent failure in java/net/DatagramSocket/InheritHandle.java

On 30/12/2014 08:12, Chris Hegarty wrote: On 30 Dec 2014, at 05:43, FELIX YANG > wrote: Thanks for looking at this, Alan and Chris. Please check the updated webrev: http://cr.openjdk.java.net/~xiaofeya/8042581/webrev.01/ Looks ok to me. Thanks Felix. Looks

Re: About writing tests that need to setup ip addresses on dummy interface on the test machine

On 31/12/2014 12:16, Doychin Bondzhev wrote: Hi guys, There is already some preliminary changes ready regarding problem with NetworkInterfaces class that I wrote about in earlier email. Now the next thing we need to do is to write test that will work with predefined configuration on a dummy

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

On 14/01/2015 11:14, Konstantin Shefov wrote: Kindly reminder Did we establish if this requires a specification change to clarify the characters allowed in the host component? -Alan

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

On 16/01/2015 10:49, Chris Hegarty wrote: : I don't see any reason to update the spec here, given that the set of allowable character is not clearly defined in the relevant RFC's. I think we need to create a bug to look into this more. Inet6Address allows the scope of be any String but URI p

Re: [9] Review request : JDK-6933879: URISyntaxException when non-alphanumeric characters are present in scope_id

On 23/01/2015 10:28, Chris Hegarty wrote: On 21.01.2015 16:06, Konstantin Shefov wrote: Hi, Chris I have done a pre-integration testing for this fix on Linux, Windows, Mac and Solaris x64 and sparc. I have run all regression tests for core libraries, and no new failures appeared. Can I push th

Re: RFR 8071424: JCK test api/java_net/Socket/descriptions.html#Bind crashes on Windows

On 23/01/2015 13:51, Chris Hegarty wrote: This is a fix for a minor oversight when refactoring the initializing of Inet[4|6]Address IDs, used in many places in the networking native code. It would appear that there is an initInetAddressIDs() call missing from the Windows Dual Stacks Socket im

Re: RFR 8067105: Socket returned by ServerSocket.accept() is inherited by child process on Windows

On 28/01/2015 20:01, Chris Hegarty wrote: Reviving an old code review [1], after further investigation… Pertinent details from previous review: "A socket connection which is returned by ServerSocket.accept() is inherited by a child process. The expected behavior is that the socket connection is

Re: RFR 8067105: Socket returned by ServerSocket.accept() is inherited by child process on Windows

On 28/01/2015 21:40, Chris Hegarty wrote: I’ll make the change, add a test, and then update the webrev. On second thoughts, it shouldn't need to be changed because the child SOCKET is created before AcceptEx is used and so should already have the inherit flag set correctly. Has there been an

Re: RFR 8067105: Socket returned by ServerSocket.accept() is inherited by child process on Windows

On 29/01/2015 15:39, Chris Hegarty wrote: : Has there been any consideration given to writing a test for this? I thought we had one or two tests for this already. There are existing tests for client/connecting sockets, but none for accepted sockets. The test, and check, for accepted sockets

Re: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

On 26/01/2015 13:48, Seán Coffey wrote: Valeriy, those changes look fine to me and I've verified that they run through testing fine also. webrev here for reference : http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v3/webrev/ Can I have a jdk7u reviewer for this change ? There is a race

Re: RFR 8064924: Update java.net.URL to work with modules

On 30/01/2015 13:36, Chris Hegarty wrote: This is phase 1, of getting java.net.URL work with modules. Being able to effectively specify URL protocol handler factories as fully qualified class names, through the 'java.protocol.handler.pkgs' system property is problematic. It requires the protoc

Re: Backporting the TCP loopback fast path (Windows) improvement to OpenJDK v7

On 30/01/2015 12:18, Seán Coffey wrote: Alan, hadn't spotted the race issue. I guess we could delay setting ver_initialized until OSVERSIONINFO is populated. Alternatively - like you say, I think we can revert back to the simpler edit : http://cr.openjdk.java.net/~coffeys/webrev.8060170.7u.v

Re: RFR 8064924: Update java.net.URL to work with modules

On 30/01/2015 15:35, Chris Hegarty wrote: : Update webrev and spec diffs: http://cr.openjdk.java.net/~chegar/8064924/01/ I think the javadoc looks much better now, thanks. -Alan

Re: RFR 8064924: Update java.net.URL to work with modules

On 31/01/2015 19:42, Peter Levart wrote: Hi Chris, I looked at your solution to make URLStreamHandlerFactory interface a service provider using ServiceLoader API and in addition adding new URL static method to programmaticaly register URLStreamHandlerFactories. There are a couple of issues wi

Re: RFR 8064924: Update java.net.URL to work with modules

On 31/01/2015 23:47, Peter Levart wrote: I agree. Putting the order on the SPI API is not the right solution. The order should be configured in one place. But there needs to be some kind of handle each service exposes for order configuration to reference. So one idea how to extend the Service

Re: RFR 8064924: Update java.net.URL to work with modules

On 01/02/2015 10:45, Peter Levart wrote: : I see. But if URLStreamHandlerFactories are only supposed to be located via the system class loader, is that different from what we have now when URLStreamHandlers are being located directly via class name construction (prefix + protocol + .Handler)

Re: RFR 8064924: Update java.net.URL to work with modules

On 02/02/2015 11:26, Chris Hegarty wrote: I agree with Alan, addURLStreamHandlerFactory is probably an attractive nuisance. It is not strictly necessary to achieve the goal here; replace the problematic ( with modules ) system property with a service lookup. For now, I'd like to move this iss

Re: RFR 8064924: Update java.net.URL to work with modules

On 04/02/2015 14:29, Peter Levart wrote: : I agree that this is the most appropriate way with which you can force some provider's class code (the constructor) in the call stack so that you get correct AccessControlContext to check against. But the name starts to sound like German words. :-)

Re: RFR 8064924: Update java.net.URL to work with modules

On 04/02/2015 15:10, Weijun Wang wrote: It should be checked, otherwise a non-initialized parent object comes into being. In general then permission checks in constructors are a bad idea but we have an established idiom that has the no-arg constructor invoking a static method that does the perm

Re: RFR 8064924: Update java.net.URL to work with modules

On 04/02/2015 15:11, Chris Hegarty wrote: Agreed. Updated in-place http://cr.openjdk.java.net/~chegar/8064924/03/specdiff/overview-summary.html I think the approach and naming is good. A few small comments on the wording: 1. "used to locate URLStreamHandlerProvider providers" - the wording

Re: RFR 8064924: Update java.net.URL to work with modules

On 09/02/2015 14:57, Chris Hegarty wrote: : Updated webrev [ spec and implementation] : http://cr.openjdk.java.net/~chegar/8064924/04/ The updated javadoc looks good. I haven't had a chance yet to look at the implementation but I think you will need to update /make/common/CORE_PKGS.gmk for

Re: RFR 8064924: Update java.net.URL to work with modules

On 10/02/2015 16:20, Chris Hegarty wrote: On 10 Feb 2015, at 11:35, Alan Bateman wrote: On 09/02/2015 14:57, Chris Hegarty wrote: : Updated webrev [ spec and implementation] : http://cr.openjdk.java.net/~chegar/8064924/04/ The updated javadoc looks good. I haven't had a chance y

Re: RFR: JDK-8046893 - JNI exception pending in jdk/src/solaris/native/java/net: ExtendedOptionsImpl.c, PlainDatagramSocketImpl.c

On 18/02/2015 13:19, Mark Sheppard wrote: Hi please review the following small change http://cr.openjdk.java.net/~msheppar/8046893/webrev/ which addresses the parfait issue in https://bugs.openjdk.java.net/browse/JDK-8046893 This looks okay. -Alan

Re: RFR: JDK-8046901 - Check jdk/src/solaris/native/sun/nio for Parfait flagged uninitialized memory

On 18/02/2015 15:30, Mark Sheppard wrote: Hi please oblige and review the following changes http://cr.openjdk.java.net/~msheppar/8046901/webrev/ which address the parfait issues in https://bugs.openjdk.java.net/browse/JDK-8046901 pertaining to uninitialized memory in src/java.base/unix/nativ

Re: RFR: JDK-8046901 - Check jdk/src/solaris/native/sun/nio for Parfait flagged uninitialized memory

On 18/02/2015 15:45, Mark Sheppard wrote: Hi Alan, that's correct it's not an issue (false positive) as port is an out parameter, but the prescription was to initialize any flagged variables. I don't object to the change of course but I would have thought that it should be possible to flag

Re: [9] RFR of 8074937: ServerSocket.accept() API Descriptions should include past tense

On 19/03/2015 14:30, Brian Burkhalter wrote: Please review at your convenience. This a doc-only change. Issue:https://bugs.openjdk.java.net/browse/JDK-8074937 Patch:http://cr.openjdk.java.net/~bpb/8074937/webrev.00/ This is in effect an a

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

On 14/04/2015 17:24, Chris Hegarty wrote: The work done as part of JDK-8064924 [1] to introduce a new service type, java.net.spi.URLStreamHandlerProvider, provides a clean provider mechanism that will work well with modules. That part of the change should remain, but the removal of support to

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