Re: JEP 321: HTTP Client (Standard)

[David Lloyd]

On Thu, Dec 7, 2017 at 8:32 AM, Chris Hegarty  wrote:
> David,
>
> On 07/12/17 13:14, David Lloyd wrote:
>>
>> On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman 
>> wrote:
>>>
>>> This thread is getting a little off-topic but...
>>
>>
>> Getting it back on topic again:
>>
>>> Proposal for the standard module name: java.net.httpclient. Proposal for
>>> the standard package name: java.net.http.
>>
>>
>> I think it would be better if both the module and the package were
>> "java.net.http.client", for two reasons.  Firstly, it is important to
>> align the package and module name whenever possible; I don't think
>> there's a compelling reason here (or most anywhere else) not to do so.
>> Secondly, it is not unreasonable to expect that the future may bring
>> other HTTP-related APIs that are not necessarily client-specific.
>>
>> Relatedly, it may be wise to rename "HttpRequest" and "HttpResponse"
>> to "HttpClientRequest" and "HttpClientResponse", respectively.
>
>
> I agree that symmetry between the module name and package name is
> desirable. If the module / package name contains `client`, then it is
> effectively redundant in the type name ( unless there are many types
> being imported from other unrelated HTTP libraries ).

HttpRequest and HttpResponse are very common names for both client and
server libraries.  I would not consider it odd for a server to have
HttpRequest for incoming requests; if the client also uses HttpRequest
for its outbound requests, then a bunch of annoying qualification will
be going on.

It seems redundant, but the namespacing of the package and the class
serve different purposes: the package is to reserve space for other
specs, the class is to avoid conflict with servers.

> The JEP does make a proposal on the module and package name, but I think
> a discussion on naming will be needed. I'm not sure that we need to
> decide that now, but your point has been noted.

OK.


-- 
- DML

Re: JEP 321: HTTP Client (Standard)

[Chris Hegarty]

James,


On 07/12/17 00:19, James Roper wrote:
> ...
> Your reading is correct. In my experience, it varies wildly by use case.
> In the technology I work with (Akka), we do exactly this, we have
> ByteStrings (essentially immutable byte buffer), and flow control is
> done on the number of ByteStrings, not the number of bytes in those
> strings. Generally, in reading, the size of ByteStrings is limited by a
> configurable amount, for example, 8kb. And then Akka's flow control
> will, by default, keep up to 8 ByteStrings in flight in its asynchronous
> processing pipeline. So we have a maximum buffer size of 64kb per
> connection. For most HTTP use cases, this is fine, something reading an
> HTTP message body might be collecting those buffers up to a maximum size
> of 100kb by default, and then parsing the buffer (eg, as json). So it's
> within the tolerances of what the amount of memory that the user expects
> to use per request. If the data read in to the buffers were very small,
> this would be due to the client trickle feeding the server - care must
> be taken on the server to ensure that if 8kb buffers are allocated for
> reads, but only a small amount of data is read, that these large buffers
> are released, and the small data copied to a small buffer.
>
> I think where it can possible cause a problem is if for some reason
> something sending data is only generating small byte buffer chunks, but
> there's a long (and expensive) pipeline for the chunks to go through
> before they get written out. This is not a use case that we see that
> often, but I have seen it. The solution there is to either increase the
> number of elements in flight in the stream (most reactive streams
> implementations allow this to be done trivially), or to put an
> aggregating buffer in the middle before the expensive processing (again,
> streaming implementations such as RxJava, Reactor or Akka streams
> provide straight forward stages to do this).

Part of the feedback [1] we received to date has resulted in the
addition of a buffering subscriber [2], that buffers data before
delivering it to a downstream subscriber. The buffering subscriber
guarantees to deliver a given number of bytes of data to each invocation
of the downstream's `onNext`, except for the final invocation, just
before `onComplete` is invoked. This lead us to the realization that an
aggregate of byte buffers is more flexible, it allows for, but does not
require, accumulation where it makes sense.

We encountered similar issues with trickling small amounts of data, some
of which are described in 8186750 [3]. We settled on a a similar
solution, accumulate below a certain threshold. This can be important in
cases where the data is framed, like in HTTP/2.

> One issue that I'm not sure about is the consequences of using direct
> buffers with regards to garbage collection. If direct buffers are never
> copied onto the heap, and are never reused, lets say you're just
> implementing a proxy passing buffers through from one connection to
> another, then the heap usage of the application may be very small, and
> this could mean that garbage collection is done very infrequently. As I
> understand it, this can result in direct buffers staying around for a
> long time, and possibly causing the system to run out of memory. Does
> anyone have any experience with that, and how to deal with it? We don't
> generally have this problem in Akka because we always copy our buffers
> onto the heap into an immutable structure, so even if we do use direct
> buffers and don't reuse them, our heap usage grows at least as fast as
> our direct buffer usage grows, which means total memory usage won't
> exceed twice the size of the heap since eventually garbage collection
> will clean both up.

We found that performance / throughput is far more dependent on factors
other than direct buffers, for example in HTTP/2 the connection / stream
window, and frame sizes have a significant impact. Given the prevalence
of HTTPS, the data on and off the wire requires encryption and
decryption, much of which does not appear to benefit from being in
direct buffers. Additionally, buffer management becomes tricky when a
single buffer can contain multiple HTTP/2 frames, slicing, tracking,
etc, is required to avoiding copying, if the intent is to support reuse
of the buffer. Much of our experiments with direct buffers did not yield
any obvious benefit, and as such the implementation we have today only
uses heap buffers. That said, the API does not preclude the use of
direct buffers, or the addition of more advanced buffer management in
the future.

Alan has already covered some of the recent improvements to freeing
direct buffers.

-Chris.

[1] https://bugs.openjdk.java.net/browse/JDK-8184285
[2] 
http://cr.openjdk.java.net/~chegar/httpclient/javadoc/api/jdk/incubator/http/HttpResponse.BodySubscriber.html#buffering(jdk.incubator.http.HttpResponse.BodySubscriber,int)

[3] 

Re: JEP 321: HTTP Client (Standard)

[Chris Hegarty]

David,

On 07/12/17 13:14, David Lloyd wrote:

On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman  wrote:

This thread is getting a little off-topic but...


Getting it back on topic again:


Proposal for the standard module name: java.net.httpclient. Proposal for the 
standard package name: java.net.http.


I think it would be better if both the module and the package were
"java.net.http.client", for two reasons.  Firstly, it is important to
align the package and module name whenever possible; I don't think
there's a compelling reason here (or most anywhere else) not to do so.
Secondly, it is not unreasonable to expect that the future may bring
other HTTP-related APIs that are not necessarily client-specific.

Relatedly, it may be wise to rename "HttpRequest" and "HttpResponse"
to "HttpClientRequest" and "HttpClientResponse", respectively.


I agree that symmetry between the module name and package name is
desirable. If the module / package name contains `client`, then it is
effectively redundant in the type name ( unless there are many types
being imported from other unrelated HTTP libraries ).

The JEP does make a proposal on the module and package name, but I think
a discussion on naming will be needed. I'm not sure that we need to
decide that now, but your point has been noted.

-Chris.

Re: JEP 321: HTTP Client (Standard)

[David Lloyd]

On Thu, Dec 7, 2017 at 5:53 AM, Alan Bateman  wrote:
> This thread is getting a little off-topic but...

Getting it back on topic again:

> Proposal for the standard module name: java.net.httpclient. Proposal for the 
> standard package name: java.net.http.

I think it would be better if both the module and the package were
"java.net.http.client", for two reasons.  Firstly, it is important to
align the package and module name whenever possible; I don't think
there's a compelling reason here (or most anywhere else) not to do so.
Secondly, it is not unreasonable to expect that the future may bring
other HTTP-related APIs that are not necessarily client-specific.

Relatedly, it may be wise to rename "HttpRequest" and "HttpResponse"
to "HttpClientRequest" and "HttpClientResponse", respectively.


-- 
- DML

Re: JEP 321: HTTP Client (Standard)

[Chris Hegarty]

> On 4 Dec 2017, at 23:09, David Lloyd  wrote:
>> ...
> 
> Thanks.  If you don't mind answering one more question: is there any
> possibility to intercept authentication completely? 

As with HttpURLConnection, if no Authenticator is set then, application code 
should be able to manually inspect and set the appropriate headers to perform 
authentication.

-Chris.

Re: JEP 321: HTTP Client (Standard)

[Alan Bateman]

On 04/12/2017 21:56, David Lloyd wrote:

:
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.
Incubator modules (JEP 11) is the means to get non-final APIs and 
features into the hands of developers. In this case, the HTTP client was 
an incubator module in JDK 9 and is proposed to continue (with a new 
implementation and some API refinements [1]) as an incubator module in 
JDK 10. So there has been lots of time to try out the API, send 
feedback, contribute, etc. Yes, the onus is on interested developers to 
get involved and there has been useful feedback on this mailing mail. If 
you read JEP 11 then you'll know that an API or feature can't stay in 
the incubator forever, it either moves forever or it is removed. In this 
case, the API has been through numerous iterations and is looking quite 
good, hence JEP 321 proposes to move it forward so that it can be 
promoted to a platform module.


-Alan.

[1] http://mail.openjdk.java.net/pipermail/net-dev/2017-November/011017.html

Re: JEP 321: HTTP Client (Standard)

[David Lloyd]

On Mon, Dec 4, 2017 at 5:01 PM, Chris Hegarty  wrote:
> On 4 Dec 2017, at 22:03, David Lloyd  wrote:
>
> ...
>
> 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?
>
>
> [ You can probably ignore my previous email, I sent it before receiving your
> reply. The confusion seems to have been resolved now. ]
>
> Yes, there has been external feedback on the API. I’ll dig it up, I need to
> trawl the net-dev archives and JIRA issues.
>
> For your, and others, reference, here is a snapshot of the latest API, built
> from the ‘http-client-branch’ of the sandbox:
>
>
> http://cr.openjdk.java.net/~chegar/httpclient/javadoc/api/jdk/incubator/http/package-summary.html

Thanks.  If you don't mind answering one more question: is there any
possibility to intercept authentication completely?  There does not
seem to be a lot of documentation about authentication in this API, or
what happens (for example) if there is no Authenticator.

-- 
- DML

Re: JEP 321: HTTP Client (Standard)

[Chris Hegarty]

> On 4 Dec 2017, at 22:03, David Lloyd  wrote:
>> ...
>> 
>>> 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?


[ You can probably ignore my previous email, I sent it before receiving your 
reply. The confusion seems to have been resolved now. ]

Yes, there has been external feedback on the API. I’ll dig it up, I need to 
trawl the net-dev archives and JIRA issues.

For your, and others, reference, here is a snapshot of the latest API, built 
from the ‘http-client-branch’ of the sandbox:

  
http://cr.openjdk.java.net/~chegar/httpclient/javadoc/api/jdk/incubator/http/package-summary.html
 


-Chris.

Re: JEP 321: HTTP Client (Standard)

[Chris Hegarty]

> On 4 Dec 2017, at 21:56, David Lloyd  wrote:
> ...
>> 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.


Sorry, before replying further, there is clearly some confusion here. As Alan 
already said, the above types are NOT part of the API, they are non-public 
implementation.

The ‘http-client-branch’ of the JDK sandbox [1] contains the very latest code.

-Chris.

[1] http://hg.openjdk.java.net/jdk/sandbox/branches

Re: JEP 321: HTTP Client (Standard)

[David Lloyd]

On Mon, Dec 4, 2017 at 3:56 PM, David Lloyd  wrote:
> On Mon, Dec 4, 2017 at 2:01 PM, Alan Bateman  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

Re: JEP 321: HTTP Client (Standard)

[David Lloyd]

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

Re: JEP 321: HTTP Client (Standard)

[Alan Bateman]

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

Re: JEP 321: HTTP Client (Standard)

[Norman Maurer]

Well put David,

I couldn’t agree more  I would even go this far and say this is not 
something I would include in the platform itself at all.

Bye
Norman


> Am 04.12.2017 um 19:41 schrieb David Lloyd :
> 
>> On Mon, Dec 4, 2017 at 10:17 AM,   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 

Re: JEP 321: HTTP Client (Standard)

[David Lloyd]

On Mon, Dec 4, 2017 at 10:17 AM,   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

JEP 321: HTTP Client (Standard)

[mark . reinhold]

New JEP Candidate: http://openjdk.java.net/jeps/321

- Mark