Hi,
Yes, that report probably should not have been closed as it is
definitely an issue.
I will re-open it.
Michael
On 22/06/2020 16:39, Sebastian Stenzel wrote:
Certain users of my software run into problems with HttpClient.newHttpClient()
on JDK 14.0.1 and I don't feel like I can handle it properly without catching
Errors.
Calling said method fails when encountering Selector.open(), which in its
Windows-specific implementation relies on loopback-TCP connections. These
connections can, of course, be blocked by the OS or, as in the case of my user,
by some anti-malware tool.
I can't argue whether it is good or bad implementing the selector the way it is, however
I'm pretty sure that commenting exceptions being "unlikely" without further
explanation isn't exactly the best practice for this case:
https://github.com/openjdk/jdk/blob/5adfaa39866f3127000f0779158c65afe1d24007/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java#L309-L314
<https://github.com/openjdk/jdk/blob/5adfaa39866f3127000f0779158c65afe1d24007/src/java.net.http/share/classes/jdk/internal/net/http/HttpClientImpl.java#L309-L314>
Since my related bug report (JDK-8247996) was turned down (maybe the tester
forgot to or chose not to block the socket connection), I'd like to ask if it
is at least possible to document the fact that creating an HttpClient can have
the side effect of instantaneously creating a loopback connection. I would
prefer to even throw a checked exception, but this would break the API.
Happy to create a PR, but I'd like to do this the right way, therefore starting
this discussion.
