JEP 321: HTTP Client (Standard)

[David Lloyd]

On Mon, Dec 4, 2017 at 2:01 PM, Alan Bateman <Alan.Bateman at oracle.com> wrote:
> 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.

I've had opportunity to give feedback, perhaps, though the API always
seemed incomplete.  At least nobody (that I saw) sent out a message
saying "Here it is, it's all done, what do you think?".  I've
certainly never had opportunity to try it out: given its status as an
incubating module present only in OpenJDK, the only people who are
really in a position to try it out are those using OpenJDK (as opposed
to other JDKs) with the flexibility to rewrite their use case if and
when the API changes status (being integrated or disappearing) or form
(evolving, presumably as a response to feedback), or people writing
throwaway applications for the sole purpose of testing this particular
API.  But those who are best able to make this kind of determination
are those who need to be able to immediately use the API, and rely
upon it indefinitely (for good or bad), which is definitely not the
case for anything incubated in the OpenJDK project.  Why take the risk
when you can use the Apache HTTP client instead?

The lack of feedback on a proposed standard should not be considered a
tacit endorsement of it - quite the opposite in fact.  It should be
considered overwhelming disinterest (i.e. there's nothing particularly
compelling about it), or at absolute best, insufficient information to
make a determination.  The burden should be on the proposer to
evangelize their idea and seek out feedback, rather than waiting for
interest to appear and feedback to come to them.

> 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.

Yes they are, currently - at least ByteBufferReference is at the heart of it:

http://hg.openjdk.java.net/jdk/jdk/file/6dcbdc9f99fc/src/jdk.incubator.httpclient/share/classes/jdk/incubator/http/AsyncConnection.java#l61

And that class relies directly on ByteBufferPool in its own API.

Unless the jdk/jdk branch does not reflect the latest incarnation of
this JEP, in which case I definitely haven't have been up to date with
it, despite following this list.

> 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.

See above.


-- 
- DML