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 m
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 ByteStr
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.ht
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 m
On 07/12/2017 00:19, James Roper wrote:
:
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
Sidenote: a byte is an 8-bit buffer chunk.
:-)
--
Cheers,
√
On Dec 7, 2017 01:19, "James Roper" wrote:
> On 7 December 2017 at 06:58, David Lloyd wrote:
>
>> On Wed, Dec 6, 2017 at 6:31 AM, Chris Hegarty
>> wrote:
>
>
> [snip]
>
>
>> > The primary motivation for the use byte buffers, as des
On 7 December 2017 at 06:58, David Lloyd wrote:
> On Wed, Dec 6, 2017 at 6:31 AM, Chris Hegarty
> wrote:
[snip]
> > The primary motivation for the use byte buffers, as described above, is
> > to provide maximum flexibility to an implementation to avoid copying
> > and buffering of data.
>
>
On Wed, Dec 6, 2017 at 6:31 AM, Chris Hegarty wrote:
> Viktor,
>
> The reference to byte buffer pools is not relevant here. They were
> introduced as a performance optimization that allowed better reuse of
> byte buffers between the socket channel and the SSL engine, in the
> implementation. That'
Thanks for those clarifcations, Chris, I really appreciate it!
--
Cheers,
√
On Dec 6, 2017 13:31, "Chris Hegarty" wrote:
> Viktor,
>
> I would like to address your first comment only, as your question is
> directed to someone else.
>
> > On 6 Dec 2017, at 10:01, Viktor Klang wrote:
> > ..
> >
Viktor,
I would like to address your first comment only, as your question is
directed to someone else.
> On 6 Dec 2017, at 10:01, Viktor Klang wrote:
> ..
> I think you raise some valid concerns, particularly with the byte buffer
> pools.
The conversation got off to a bad start as there was a
Hi David,
I think you raise some valid concerns, particularly with the byte buffer
pools.
That said, I'm interested in knowing whether your concerns extend to choice
of using the JDK9 Flow API for handling asynchronous IO?
Cheers,
√
(Adding my colleague, James Roper, to the conversation)
On De
On 05.12.2017 14:48, David Lloyd wrote:
On Tue, Dec 5, 2017 at 5:48 AM, dalibor topic wrote:
On 04.12.2017 22:56, David Lloyd wrote:
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
On Tue, Dec 5, 2017 at 5:48 AM, dalibor topic wrote:
> On 04.12.2017 22:56, David Lloyd wrote:
>>
>> 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
On 04.12.2017 22:56, David Lloyd wrote:
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
> 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 a
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 it
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.
> 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 Byte
> 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 ByteBufferRefe
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/asynchronou
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
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 consult
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.n
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 re
24 matches
Mail list logo
