On Mon, Dec 4, 2017 at 3:56 PM, David Lloyd <david.ll...@redhat.com> wrote: > 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
I see my error, this is a non-public interface. Nonetheless, I'm not sure that it's really safe to say that this is ready. Has there been _any_ external feedback on this API? -- - DML
