hg: jdk8/tl/jdk: 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators
Changeset: f8b3ab514564 Author:psandoz Date: 2013-10-01 12:19 +0200 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f8b3ab514564 8024408: Specifications for Collection/List/Set/SortedSet.spliterator() need to document if all the (subclass) instances are required to return SIZED spliterators Reviewed-by: alanb ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Set.java ! src/share/classes/java/util/SortedSet.java ! test/java/util/Spliterator/SpliteratorCharacteristics.java
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
Taken feedback on board. New webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952.2/webrev/ I've managed to get confirmation from original submitter that this works ok for them. regards, Sean. On 20/09/2013 11:29, Seán Coffey wrote: Dmitry, You're right. I was cautious in moving the code up but since we're pointing at FileDescriptor Objs, we should be ok. Daniel Fuchs has pointed out another issue. Null delegate being passed into impl.accept if dealing with a custom socketImpl! It should just be impl.accept(s); I'll get this corrected and tested. Thanks for pointers. Sean. On 20/09/13 10:20, Dmitry Samersoff wrote: Sean, It might be possible to set s.fd to delegate.fd before call to impl.accept and therefore merge if instanceOf block. -Dmitry On 2013-09-20 00:21, Seán Coffey wrote: Looking for review on recently reported issue. Issue seen on windows when a custom socketImpl is in use. bug report : https://bugs.openjdk.java.net/browse/JDK-8024952 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952/webrev/ Regards, Sean.
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
On 01/10/2013 13:37, Daniel Fuchs wrote: Hi Seán, This looks simpler and better :-) However I wonder, do you still need to catch NPE in CustomSocketImplFactory.main ? Daniel, Since I'm only creating a dummy socketImpl to test the classcastexception, no real networking stack is in place here. I'm catching the NPE that would be thrown from the native Java_java_net_TwoStacksPlainSocketImpl_socketAccept function since the underlying socket passed to it is null. C:\tmp>java CustomSocketImplFactory Created Socket[addr=null,port=0,localport=0] Exception in thread "main" java.lang.NullPointerException: socket is null at java.net.TwoStacksPlainSocketImpl.socketAccept(Native Method) Regards, Sean. Or is that going to hide future bugs? best regards -- daniel (not a reviewer)
hg: jdk8/tl/jdk: 8024707: TransformerException : item() return null with node list of length != 1
Changeset: bf52ea6bd9eb Author:aefimov Date: 2013-10-01 17:15 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/bf52ea6bd9eb 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea + test/javax/xml/jaxp/parsers/8024707/TestFunc.java + test/javax/xml/jaxp/parsers/8024707/XSLT.java + test/javax/xml/jaxp/parsers/8024707/in.xml + test/javax/xml/jaxp/parsers/8024707/test.xsl
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
On 10/1/13 3:09 PM, Seán Coffey wrote: Since I'm only creating a dummy socketImpl to test the classcastexception, no real networking stack is in place here. I'm catching the NPE that would be thrown from the native Java_java_net_TwoStacksPlainSocketImpl_socketAccept function since the underlying socket passed to it is null. C:\tmp>java CustomSocketImplFactory Created Socket[addr=null,port=0,localport=0] Exception in thread "main" java.lang.NullPointerException: socket is null at java.net.TwoStacksPlainSocketImpl.socketAccept(Native Method) That's what I would have expected from your previous changeset. But you're no longer passing null - right? Now you're passing an instance of CustomSocketImpl. So where does the NPE come from? Could it be because you should be calling: ServerSocket.setSocketImplFactory(new CustomSocketImplFactory()); and not: Socket.setSocketImplFactory(new CustomSocketImplFactory()); ? Or should you call both? best regards, -- daniel Regards, Sean. Or is that going to hide future bugs? best regards -- daniel (not a reviewer)
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
On 10/1/13 1:53 PM, Seán Coffey wrote: Taken feedback on board. New webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952.2/webrev/ I've managed to get confirmation from original submitter that this works ok for them. regards, Sean. Hi Seán, This looks simpler and better :-) However I wonder, do you still need to catch NPE in CustomSocketImplFactory.main ? Or is that going to hide future bugs? best regards -- daniel (not a reviewer) On 20/09/2013 11:29, Seán Coffey wrote: Dmitry, You're right. I was cautious in moving the code up but since we're pointing at FileDescriptor Objs, we should be ok. Daniel Fuchs has pointed out another issue. Null delegate being passed into impl.accept if dealing with a custom socketImpl! It should just be impl.accept(s); I'll get this corrected and tested. Thanks for pointers. Sean. On 20/09/13 10:20, Dmitry Samersoff wrote: Sean, It might be possible to set s.fd to delegate.fd before call to impl.accept and therefore merge if instanceOf block. -Dmitry On 2013-09-20 00:21, Seán Coffey wrote: Looking for review on recently reported issue. Issue seen on windows when a custom socketImpl is in use. bug report : https://bugs.openjdk.java.net/browse/JDK-8024952 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952/webrev/ Regards, Sean.
hg: jdk8/tl/jaxp: 8024707: TransformerException : item() return null with node list of length != 1
Changeset: 84a2b2ee6fc6 Author:aefimov Date: 2013-10-01 17:14 +0400 URL: http://hg.openjdk.java.net/jdk8/tl/jaxp/rev/84a2b2ee6fc6 8024707: TransformerException : item() return null with node list of length != 1 Reviewed-by: joehw, lancea ! src/com/sun/org/apache/xml/internal/dtm/ref/DTMAxisIterNodeList.java
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
On 01/10/2013 14:51, Daniel Fuchs wrote: On 10/1/13 3:09 PM, Seán Coffey wrote: Since I'm only creating a dummy socketImpl to test the classcastexception, no real networking stack is in place here. I'm catching the NPE that would be thrown from the native Java_java_net_TwoStacksPlainSocketImpl_socketAccept function since the underlying socket passed to it is null. C:\tmp>java CustomSocketImplFactory Created Socket[addr=null,port=0,localport=0] Exception in thread "main" java.lang.NullPointerException: socket is null at java.net.TwoStacksPlainSocketImpl.socketAccept(Native Method) That's what I would have expected from your previous changeset. But you're no longer passing null - right? Now you're passing an instance of CustomSocketImpl. So where does the NPE come from? Could it be because you should be calling: ServerSocket.setSocketImplFactory(new CustomSocketImplFactory()); and not: Socket.setSocketImplFactory(new CustomSocketImplFactory()); ? The original bug stemmed from a custom socket Impl interacting with the JDK ServerSocket Impl. If I move both Socket and ServerSocket factory implementations over to use the custom Impl, the testcase doesn't get to walk through the JDK serverSocket code and the ClassCastException is not seen. The NPE seen is coming from down in the native stack when the JDK ServerSocket is running through accept request (from our client socket). I don't think it's an issue for this case. line 611 : http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/src/windows/native/java/net/TwoStacksPlainSocketImpl.c regards, Sean. Or should you call both? best regards, -- daniel Regards, Sean. Or is that going to hide future bugs? best regards -- daniel (not a reviewer)
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
On 10/1/13 4:50 PM, Seán Coffey wrote: On 01/10/2013 14:51, Daniel Fuchs wrote: On 10/1/13 3:09 PM, Seán Coffey wrote: Since I'm only creating a dummy socketImpl to test the classcastexception, no real networking stack is in place here. I'm catching the NPE that would be thrown from the native Java_java_net_TwoStacksPlainSocketImpl_socketAccept function since the underlying socket passed to it is null. C:\tmp>java CustomSocketImplFactory Created Socket[addr=null,port=0,localport=0] Exception in thread "main" java.lang.NullPointerException: socket is null at java.net.TwoStacksPlainSocketImpl.socketAccept(Native Method) That's what I would have expected from your previous changeset. But you're no longer passing null - right? Now you're passing an instance of CustomSocketImpl. So where does the NPE come from? Could it be because you should be calling: ServerSocket.setSocketImplFactory(new CustomSocketImplFactory()); and not: Socket.setSocketImplFactory(new CustomSocketImplFactory()); ? The original bug stemmed from a custom socket Impl interacting with the JDK ServerSocket Impl. If I move both Socket and ServerSocket factory implementations over to use the custom Impl, the testcase doesn't get to walk through the JDK serverSocket code and the ClassCastException is not seen. The NPE seen is coming from down in the native stack when the JDK ServerSocket is running through accept request (from our client socket). I don't think it's an issue for this case. line 611 : http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/src/windows/native/java/net/TwoStacksPlainSocketImpl.c regards, Sean. Thanks Seán. You convinced me. -- daniel Or should you call both? best regards, -- daniel Regards, Sean. Or is that going to hide future bugs? best regards -- daniel (not a reviewer)
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
The changes look fine to me. -Chris. On 10/01/2013 12:53 PM, Seán Coffey wrote: Taken feedback on board. New webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952.2/webrev/ I've managed to get confirmation from original submitter that this works ok for them. regards, Sean. On 20/09/2013 11:29, Seán Coffey wrote: Dmitry, You're right. I was cautious in moving the code up but since we're pointing at FileDescriptor Objs, we should be ok. Daniel Fuchs has pointed out another issue. Null delegate being passed into impl.accept if dealing with a custom socketImpl! It should just be impl.accept(s); I'll get this corrected and tested. Thanks for pointers. Sean. On 20/09/13 10:20, Dmitry Samersoff wrote: Sean, It might be possible to set s.fd to delegate.fd before call to impl.accept and therefore merge if instanceOf block. -Dmitry On 2013-09-20 00:21, Seán Coffey wrote: Looking for review on recently reported issue. Issue seen on windows when a custom socketImpl is in use. bug report : https://bugs.openjdk.java.net/browse/JDK-8024952 webrev : http://cr.openjdk.java.net/~coffeys/webrev.8024952/webrev/ Regards, Sean.
hg: jdk8/tl/jdk: 2 new changesets
Changeset: 8cfb2bddd95e Author:mduigou Date: 2013-09-30 15:50 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/8cfb2bddd95e 7057785: Add note about optional support of recursive methods for self-referential Collection/Map Reviewed-by: scolebourne, darcy, mduigou Contributed-by: Stephen Colebourne ! src/share/classes/java/util/Collection.java ! src/share/classes/java/util/Map.java Changeset: f2e2326f787b Author:mduigou Date: 2013-10-01 10:23 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/f2e2326f787b 8025067: Unconditionally throw NPE if null op provided to Arrays.parallelPrefix Reviewed-by: henryjen, chegar, psandoz ! src/share/classes/java/util/Arrays.java ! test/java/util/Arrays/ParallelPrefix.java
hg: jdk8/tl/jdk: 8025686: Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support
Changeset: c32ab940a183 Author:mduigou Date: 2013-10-01 10:37 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/c32ab940a183 8025686: Update jdk repo netbeans projects to support NetBeans 7.4 for Java 8 support Reviewed-by: lancea, chegar ! make/netbeans/common/java-data-native.ent ! make/netbeans/common/java-data-no-native.ent
Re: RFR : 8024952 : ClassCastException in PlainSocketImpl.accept() when using custom socketImpl
Sean,
The fix looks good for me but the code might be better readable if you
inverse the condition.
if (!(s instanceof PlainSocketImpl)) {
impl.accept(s)
return;
}
... rest of the code
-Dmitry
On 2013-10-01 18:54, Daniel Fuchs wrote:
> On 10/1/13 4:50 PM, Seán Coffey wrote:
>>
>> On 01/10/2013 14:51, Daniel Fuchs wrote:
>>> On 10/1/13 3:09 PM, Seán Coffey wrote:
Since I'm only creating a dummy socketImpl to test the
classcastexception, no real networking stack is in place here. I'm
catching the NPE that would be thrown from the native
Java_java_net_TwoStacksPlainSocketImpl_socketAccept function since the
underlying socket passed to it is null.
C:\tmp>java CustomSocketImplFactory
Created Socket[addr=null,port=0,localport=0]
Exception in thread "main" java.lang.NullPointerException: socket is
null
at java.net.TwoStacksPlainSocketImpl.socketAccept(Native
Method)
>>>
>>> That's what I would have expected from your previous changeset.
>>>
>>> But you're no longer passing null - right? Now you're passing
>>> an instance of CustomSocketImpl.
>>>
>>> So where does the NPE come from? Could it be because you should
>>> be calling:
>>>ServerSocket.setSocketImplFactory(new CustomSocketImplFactory());
>>> and not:
>>>Socket.setSocketImplFactory(new CustomSocketImplFactory()); ?
>> The original bug stemmed from a custom socket Impl interacting with the
>> JDK ServerSocket Impl. If I move both Socket and ServerSocket factory
>> implementations over to use the custom Impl, the testcase doesn't get to
>> walk through the JDK serverSocket code and the ClassCastException is not
>> seen.
>>
>> The NPE seen is coming from down in the native stack when the JDK
>> ServerSocket is running through accept request (from our client socket).
>> I don't think it's an issue for this case.
>>
>> line 611 :
>> http://hg.openjdk.java.net/jdk8/tl/jdk/file/tip/src/windows/native/java/net/TwoStacksPlainSocketImpl.c
>>
>>
>>
>> regards,
>> Sean.
>
> Thanks Seán. You convinced me.
>
> -- daniel
>
>>> Or should you call both?
>>>
>>> best regards,
>>>
>>> -- daniel
>>>
>>>
Regards,
Sean.
>
> Or is that going to hide future bugs?
>
> best regards
>
> -- daniel (not a reviewer)
>>>
>>
>
--
Dmitry Samersoff
Oracle Java development team, Saint Petersburg, Russia
* I would love to change the world, but they won't give me the sources.
JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
Hello net-dev members, Please review this proposed fix at your convenience. Summary When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. Issue https://bugs.openjdk.java.net/browse/JDK-8010371 Webrev http://cr.openjdk.java.net/~bpb/8010371 If this fix appears acceptable I will file a CCC request. Thanks, Brian
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
On 01/10/2013 11:31, Brian Burkhalter wrote: Hello net-dev members, Please review this proposed fix at your convenience. Summary When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. Issue https://bugs.openjdk.java.net/browse/JDK-8010371 Webrev http://cr.openjdk.java.net/~bpb/8010371 So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and errno set to EAGAIN? I also wonder if the EAGAIN means the underlying syscall has been interrupted, in which case the normal thing to do is to retry. -Alan
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
On Oct 1, 2013, at 11:50 AM, Alan Bateman wrote: > On 01/10/2013 11:31, Brian Burkhalter wrote: >> Hello net-dev members, >> >> Please review this proposed fix at your convenience. >> >> Summary >> When looking up a host and an EAGAIN error is encountered, throw an instance >> of the new HostLookupException subclass of UnknownHostException. >> >> Issue >> https://bugs.openjdk.java.net/browse/JDK-8010371 >> >> Webrev >> http://cr.openjdk.java.net/~bpb/8010371 >> >> > So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and errno > set to EAGAIN? It seems a bit unclear to me and to depend on which system one is on. There is also the possibility apparently of it returning EAI_AGAIN. It might be best to test both the return value and if that is EAI_SYSTEM to test errno. > I also wonder if the EAGAIN means the underlying syscall has been > interrupted, in which case the normal thing to do is to retry. The approach I initially was going to take was to retry once after a short wait and then fail with the proposed exception if the retry failed. This webrev was intended to provoke discussion such as this is the first time I have looked at this part of the code base and it is not clear how to actually test this situation. Brian
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
On Oct 1, 2013, at 11:59 AM, Brian Burkhalter wrote: > It seems a bit unclear to me and to depend on which system one is on. There > is also the possibility apparently of it returning EAI_AGAIN. It might be > best to test both the return value and if that is EAI_SYSTEM to test errno. I updated the webrev http://cr.openjdk.java.net/~bpb/8010371/ with changes in the test of the return value of getaddrinfo for Unix Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. Brian
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
Alan, getaddrinfo is actually a shell around couple of different calls, so for getaddrinfo EAGAIN usually means that it can't rich nameserver, not the interrupted syscall. EAI_SYSTEM means that one of underlaying calls (e.g. gethostbyname) returns an error. Under Windows, getaddrinfo never returns EAI_SYSTEM, but can set WSA code other that one returned by getaddrinfo - i.e. it's recomended to use WSAGetLastError. So I'm OK with this fix. -Dmitry On 2013-10-01 22:50, Alan Bateman wrote: > On 01/10/2013 11:31, Brian Burkhalter wrote: >> Hello net-dev members, >> >> Please review this proposed fix at your convenience. >> >> Summary >> When looking up a host and an EAGAIN error is encountered, throw an >> instance of the new HostLookupException subclass of UnknownHostException. >> >> Issue >> https://bugs.openjdk.java.net/browse/JDK-8010371 >> >> Webrev >> http://cr.openjdk.java.net/~bpb/8010371 >> >> > So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and > errno set to EAGAIN? I also wonder if the EAGAIN means the underlying > syscall has been interrupted, in which case the normal thing to do is to > retry. > > -Alan -- Dmitry Samersoff Oracle Java development team, Saint Petersburg, Russia * I would love to change the world, but they won't give me the sources.
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
On 01/10/13 19:59, Brian Burkhalter wrote: On Oct 1, 2013, at 11:50 AM, Alan Bateman wrote: On 01/10/2013 11:31, Brian Burkhalter wrote: Hello net-dev members, Please review this proposed fix at your convenience. Summary When looking up a host and an EAGAIN error is encountered, throw an instance of the new HostLookupException subclass of UnknownHostException. Issue https://bugs.openjdk.java.net/browse/JDK-8010371 Webrev http://cr.openjdk.java.net/~bpb/8010371 So is getaddrinfo returning EAGAIN or is it failing with EAI_SYSTEM and errno set to EAGAIN? It seems a bit unclear to me and to depend on which system one is on. There is also the possibility apparently of it returning EAI_AGAIN. It might be best to test both the return value and if that is EAI_SYSTEM to test errno. I also wonder if the EAGAIN means the underlying syscall has been interrupted, in which case the normal thing to do is to retry. The approach I initially was going to take was to retry once after a short wait and then fail with the proposed exception if the retry failed. I'm not sure about the short wait. I know the submitter claims that it worked after 50ms, but I don't think we could generalise that behavior in the library. Maybe, there is value in repeating immediately, though it is less likely the temporary condition will have resolved. Michael This webrev was intended to provoke discussion such as this is the first time I have looked at this part of the code base and it is not clear how to actually test this situation. Brian
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
On Oct 1, 2013, at 1:25 PM, Michael McMahon wrote: >> The approach I initially was going to take was to retry once after a short >> wait and then fail with the proposed exception if the retry failed. > > I'm not sure about the short wait. I know the submitter claims that it worked > after 50ms, but I don't > think we could generalise that behavior in the library. Maybe, there is value > in repeating immediately, though > it is less likely the temporary condition will have resolved. It does seem better to let the calling code retry if it wants based on the class of the exception. Brian
hg: jdk8/tl/jdk: 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java
Changeset: 84e7f6685319 Author:ksrini Date: 2013-10-01 15:40 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/84e7f6685319 8025342: NLS: unsupported translation format in jar/pack/DriverResource.java Reviewed-by: naoto, mfang ! src/share/classes/com/sun/java/util/jar/pack/Driver.java ! src/share/classes/com/sun/java/util/jar/pack/DriverResource.java
hg: jdk8/tl/jdk: 8022701: Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError
Changeset: d90928a89af5 Author:drchase Date: 2013-09-27 13:32 -0400 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/d90928a89af5 8022701: Accessibility checking: InvocationTargetException is thrown instead of IllegalAccessError Summary: Inserted code to convert specific exceptions, case-by-case, plus a test. Reviewed-by: jrose, twisti ! src/share/classes/java/lang/invoke/MethodHandleNatives.java + test/java/lang/invoke/8022701/BogoLoader.java + test/java/lang/invoke/8022701/InvokeSeveralWays.java + test/java/lang/invoke/8022701/Invoker.java + test/java/lang/invoke/8022701/MHIllegalAccess.java + test/java/lang/invoke/8022701/MethodSupplier.java
hg: jdk8/tl: 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification
Changeset: 187a759c08ba Author:alanb Date: 2013-10-02 04:21 +0100 URL: http://hg.openjdk.java.net/jdk8/tl/rev/187a759c08ba 8006843: org.w3c.dom.events.UIEvent.getView is specified to return type that is not in the Java SE specification Reviewed-by: mduigou, tbell ! common/makefiles/javadoc/CORE_PKGS.gmk
hg: jdk8/tl/jdk: 8025123: SNI support in Kerberos cipher suites
Changeset: 3fca37c636be Author:xuelei Date: 2013-10-01 20:25 -0700 URL: http://hg.openjdk.java.net/jdk8/tl/jdk/rev/3fca37c636be 8025123: SNI support in Kerberos cipher suites Reviewed-by: weijun, xuelei Contributed-by: Artem Smotrakov ! src/share/classes/sun/security/ssl/ClientHandshaker.java ! src/share/classes/sun/security/ssl/Handshaker.java ! src/share/classes/sun/security/ssl/KerberosClientKeyExchange.java ! src/share/classes/sun/security/ssl/krb5/KerberosClientKeyExchangeImpl.java ! test/sun/security/krb5/auto/SSL.java
Re: JDK 8 RFR 8010371: getaddrinfo can fail with EAI_SYSTEM/EAGAIN, causes UnknownHostException to be thrown
On 01/10/2013 12:46, Brian Burkhalter wrote: : I updated the webrev http://cr.openjdk.java.net/~bpb/8010371/ with changes in the test of the return value of getaddrinfo for Unix Inet 4 and 6 and Windows Inet 6. The usual testing is in progress. Brian This looks better, although I think I would reverse re-write the expressions to "if (error = ...)". One thing to consider is whether this condition is really worth introducing HostLookupException, particularly when it doesn't include additional information (except to distinguish it from its supertype). If a new exception is really needed then maybe it could add the error message obtained from gai_strerror, alternatively maybe you could considered setting the cause of the UHE to something like an IOException with the translation of the error. -Alan.
