JEP 321: HTTP Client (Standard)

[David Lloyd]

On Mon, Dec 4, 2017 at 10:17 AM,  <mark.reinhold at oracle.com> wrote:
> New JEP Candidate: http://openjdk.java.net/jeps/321

I have concerns.

This will be the first public, NIO-based, asynchronous/non-blocking
network protocol API introduced into the JDK proper, _ever_.

First, I want to note that the API seems to bear no resemblance
whatsoever with the asynchronous NIO.2 API.  Now I'm no fan of that
API as it stands for a couple of reasons, but nevertheless it calls
into question either the validity of the HTTP API as it stands, or the
scope of reusability of the NIO.2 API.

With that items put aside: there are a wide variety of mature,
non-blocking network protocol implementations out there, with
literally thousands of years of experience distributed amongst their
authors, maintainers, supporters, and communities, none of which were
used as a model.  There was, as far as I can see, no kind of study of
existing non-blocking approaches in Java, and their strengths and
weaknesses; there was no round table of engineers with experience in
this field, talking about what works and what doesn't work.

Some new, seemingly general-purpose, concepts are introduced by the
code base, for example: ByteBufferReference, and ByteBufferPool.  Are
these strategies that should be promoted to NIO proper?  If not, then
are they _really_ right for this particular use case, particularly if,
for some reason, a _second_ non-blocking network protocol API might be
introduced some day, probably duplicating these concepts?

Making this thing be the first real platform NIO-based asynchronous
network protocol API, yet being completely removed from the previous
NIO.2 asynchronous APIs and any other existing stable, mature API,
should be done very carefully and deliberately, and perhaps most
importantly, incrementally: first, establish a non-blocking byte
stream API that makes sense generally, and bring that into NIO
(NIO.3?); then, perhaps, enhancements to byte buffers to better
support efficient pooling.  By the time that point is reached, it is
hopefully rapidly becoming obvious that this is not something that
should be taken lightly.

I believe that most third-party implementations are taken less lightly
than this seems to have been.  I and my team have been developing an
asynchronous/non-blocking NIO library for ten years now, and while I'm
proud of our work and the discoveries we've made, I am realistic about
the fact that it's still pretty far from as good as it could be (not
in the least part due to existing platform limitations), certainly far
from something I'd say "hey let's standardize this as is".  I think
that to standardize something of this type that was just written over
the past 18-odd months reflects, to put it kindly, some pretty
incredible confidence that I wish I shared.

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.

Talking about introducing the first-ever non-blocking protocol API
into the platform, at _this_ stage, seems premature and needlessly
risky.  I would suggest that maybe it's best for the API to stick to
blocking I/O, at least for now.  Or else, take it outside of the
platform, and let it mature in the wild where it can evolve without an
overbearing concern for compatibility for a decade or so (no, I'm not
kidding).  As long as this thing lives in the JDK, but isn't
standardized, it's probably not going to be used heavily enough to
really feel out its weak points.  And once it's in, its ability to
evolve is severely hampered by compatibility constraints.

I feel like it is impossible to over-emphasize the difficulty of the
problem of non-blocking I/O when it comes to interactions with user
programs.  Though the fruits of such an effort are probably small in
terms of API surface, the complexity is hard: hard enough that it is,
in my mind, a project of a larger scale, maybe JSR scale.  And the
benefit is potentially large: large enough that it could change the
landscape of other specifications and network applications.  Or at
least, I think so, which is why I've spent so many years of my life in
pursuit of such a thing.

-- 
- DML