On Mon, Dec 4, 2017 at 2:01 PM, Alan Bateman <alan.bate...@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
