JDK-8277628 : Spec for InetAddressResolverProvider::get() throwing error or exception could be clearer
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 18
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2021-11-23
  • Updated: 2021-12-14
  • Resolved: 2021-12-07
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 18 JDK 19
18 b27Fixed 19Fixed
Related Reports
Relates :  
JDK-8263693 - JEP 418: Internet-Address Resolution SPI
Description
From the spec : InetAddressResolverProvider::get(InetAddressResolverProvider.Configuration configuration)

  "Any error or exception thrown by this method is considered as a failure of InetAddressResolver instantiation and will be propagated to the calling thread."
  
Need a clarification regarding the phrase "propagated to the calling thread."
 
 Technically, the invocation of the InetAddressResolverProvider::get() done by the JDK implementation as a result of application/test invoking one of the methods resulting in lookup operations.
 
 Is it right expectation that "The application/test" receives the exception or error thrown by the InetAddressResolverProvider::get() ?
 
   OR 
   
 Is There is a possibility that JDK implementation interpret "the exception or error thrown by the InetAddressResolverProvider::get()" and returns OR throws something as stated by the respective look up operation methods? 
 
Currently the spec looks ambiguous in this context.
Comments
Changeset: c609b5d3 Author: Aleksei Efimov <aefimov@openjdk.org> Date: 2021-12-07 15:42:02 +0000 URL: https://git.openjdk.java.net/jdk/commit/c609b5d3d7a3d08e489c2c9ed40c42bcb5bd2147
07-12-2021
[~aefimov] That looks fine for me. Thanks for clarifying this in documentation.
04-12-2021
Hi [~kganapureddy] We're planning to clarify wording in `InetAddressResolverProvider::get` and in `InetAddressResolverProvider` class-level javadoc. "the calling thread" will be changed to something like: "the caller of the method that triggered the lookup operation". Since this change looks like a clarification it is not planned to log a CSR for that. If you have any concerns with it, please, let me know.
03-12-2021
[~dfuchs]Thanks. So it's a right expectation that "The application/test" receives the exception or error thrown by the InetAddressResolverProvider::get(). Do we need to change the phrase "calling thread" to more explicit something like "implementations don't interpret the exception or error would be propagated to the caller".
23-11-2021
The intent is to say that we don't rewrap exceptions or errors thrown by the provider, so anything the provider throws would raise to the caller. Also because the provider will not be set, the next lookup operation will cause InetAddress to attempt calling ` InetAddressResolverProvider::get` again - which is likely to result in the same exception being thrown again.
23-11-2021
I don't think the spec is ambiguous but I do agree "calling thread" is a bit strange in this context, would be clearer as just "caller".
23-11-2021