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
