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.
