JEP 321: HTTP Client (Standard)

Alan Bateman Alan.Bateman at oracle.com
Mon Dec 4 20:01:39 UTC 2017


On 04/12/2017 18:41, David Lloyd wrote:
> :
> Speaking *solely* in the interests of platform quality and integrity,
> I think that before _any_ high-level non-blocking/asynchronous
> protocol API is ever introduced into the platform, it would be an
> incredible waste to not have some kind of design consultation with
> other industry experts.  Now I'm not suggesting that a JDK API would
> have to be _agreeable_ to every expert, as we all know that is
> basically impossible; but at the very minimum, I am very confident
> that we can tell you what _doesn't_ work and the pitfalls we've found
> along the way, as well as what each of us would consider to be an
> ideal API, and that is information that has incredible value.
>
The HTTP client API has been an ongoing effort for several years, the 
original JEP goes back to 2014. It was initially available in the 
OpenJDK sandbox and in the JDK main-line before moving to an incubating 
module in 2016. I can't tell if you've been following this project or 
not but there has been lots of opportunity to try it out and provide 
feedback on both the API and implementation.

You mention general-purpose concepts such as ByteBufferReference and 
ByteBufferPool. Note that these are tiny implementation classes (150 
lines in total) and not exposed in the API. Promoting these to java.nio 
would be outside the scope of this API. If the buffer API were to add 
such concepts in the future then there is nothing to stop the HTTP 
client implementation making use in its implementation.

-Alan


More information about the net-dev mailing list