JEP 321: HTTP Client (Standard)

2017-12-04 Thread mark . reinhold
New JEP Candidate: http://openjdk.java.net/jeps/321 - Mark

Re: JEP 321: HTTP Client (Standard)

2017-12-04 Thread 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 re

Re: JEP 321: HTTP Client (Standard)

2017-12-04 Thread 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.n

Re: JEP 321: HTTP Client (Standard)

2017-12-04 Thread 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 consult

Re: JEP 321: HTTP Client (Standard)

2017-12-04 Thread 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

Re: JEP 321: HTTP Client (Standard)

2017-12-04 Thread 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/asynchronou

Re: JEP 321: HTTP Client (Standard)

2017-12-04 Thread 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 ByteBufferRefe

Re: JEP 321: HTTP Client (Standard)

2017-12-04 Thread 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 Byte

Re: JEP 321: HTTP Client (Standard)

2017-12-04 Thread 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.

RFR: 8193034: Optimize URL.toExternalForm

2017-12-04 Thread Martin Buchholz
http://cr.openjdk.java.net/~martin/webrevs/jdk/URL.toExternalForm/

RE: 8193034: Optimize URL.toExternalForm

2017-12-04 Thread Langer, Christoph
Hi Martin, I think the new code is more compact and readable which makes it nice. I reviewed it to check that the result is still the same as before. However, I can’t assess if it is acceptable from a performance point of view and would defer this assessment to some other reviewer. But apart fr