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