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: RFR: 8193034: Optimize URL.toExternalForm

[Chris Hegarty]

> On 5 Dec 2017, at 04:01, Martin Buchholz  wrote:
> 
> http://cr.openjdk.java.net/~martin/webrevs/jdk/URL.toExternalForm/

Since the motivation for this change is performance, do you have any
performance numbers / benchmarks that you can share?

-Chris.

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: RFR: 8193034: Optimize URL.toExternalForm

[Alan Bateman]

On 05/12/2017 04:01, Martin Buchholz wrote:
http://cr.openjdk.java.net/~martin/webrevs/jdk/URL.toExternalForm/ 


The style is interesting but I don't see anything obvious wrong.

-Alan

Re: JEP 321: HTTP Client (Standard)

[dalibor topic]

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 (as opposed
to other JDKs)


That's not quite correct. The jdk.incubator.httpclient module is part of 
Oracle JDK 9, as well. It has been part of the JDK 9 Early Access builds 
since about a year ago, afaik. The Early Access builds can be found at 
jdk.java.net, fwiw.



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.


This seems to be a more general criticism of the incubator module 
mechanism as defined in JEP 11, rather than directed at this API 
specifically. It wasn't raised on jdk-dev when JEP 11 was discussed 
about a year ago, fwiw.


I would take issue with the qualifier 'best' in the above, as the 
qualification offered for making best determinations is necessity, 
rather than expertise, for example. In some cases, both properties may 
hold, of course, but I don't think that's a valid assertion in general.


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment

Re: JEP 321: HTTP Client (Standard)

[David Lloyd]

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 who are
>> really in a position to try it out are those using OpenJDK (as opposed
>> to other JDKs)
>
> That's not quite correct. The jdk.incubator.httpclient module is part of
> Oracle JDK 9, as well. It has been part of the JDK 9 Early Access builds
> since about a year ago, afaik. The Early Access builds can be found at
> jdk.java.net, fwiw.

Sure, but that's all the same ecosystem.  An organization tied to,
say, the IBM JDK won't have access to these.

>> 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.
>
> This seems to be a more general criticism of the incubator module mechanism
> as defined in JEP 11, rather than directed at this API specifically. It
> wasn't raised on jdk-dev when JEP 11 was discussed about a year ago, fwiw.

Of course; sometimes a thing must be tried before the weaknesses are
apparent.  If we all designed perfect things from the start, we
wouldn't need standards and evolution. :)

-- 
- DML

Re: JEP 321: HTTP Client (Standard)

[dalibor topic]

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 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)


That's not quite correct. The jdk.incubator.httpclient module is part of
Oracle JDK 9, as well. It has been part of the JDK 9 Early Access builds
since about a year ago, afaik. The Early Access builds can be found at
jdk.java.net, fwiw.


Sure, but that's all the same ecosystem.  An organization tied to,
say, the IBM JDK won't have access to these.


Fwiw, IBM's OpenJ9 builds for JDK 9 would seem to include this incubator 
module as well. I'd naively assume the same to be the case for Azul's 
JDK 9 builds, etc.



This seems to be a more general criticism of the incubator module mechanism
as defined in JEP 11, rather than directed at this API specifically. It
wasn't raised on jdk-dev when JEP 11 was discussed about a year ago, fwiw.


Of course; sometimes a thing must be tried before the weaknesses are
apparent.  If we all designed perfect things from the start, we
wouldn't need standards and evolution. :)


Touché -

The sample size of one for modules going through the incubation module 
mechanism may still be too small for a categorical critique, though. ;)


cheers,
dalibor topic
--
 Dalibor Topic | Principal Product Manager
Phone: +494089091214  | Mobile: +491737185961


ORACLE Deutschland B.V. & Co. KG | Kühnehöfe 5 | 22761 Hamburg

ORACLE Deutschland B.V. & Co. KG
Hauptverwaltung: Riesstr. 25, D-80992 München
Registergericht: Amtsgericht München, HRA 95603

Komplementärin: ORACLE Deutschland Verwaltung B.V.
Hertogswetering 163/167, 3543 AS Utrecht, Niederlande
Handelsregister der Handelskammer Midden-Niederlande, Nr. 30143697
Geschäftsführer: Alexander van der Ven, Jan Schultheiss, Val Maher

 Oracle is committed to developing
practices and products that help protect the environment