If you'd follow Java SE 9 mailing lists, you'd know that it won't be
part of Java SE 9 distribution.
Http Client will be distributed as an incubator module to gather
community feedback and soften some edges in the API.
Regards,
Pavel
On 14/04/2017 12:04, Markus KARG wrote:
> If you are right with Java SE 9, the question is, what Oracle's plans with the new http Client is? Is it ready to be used?
>
> -----Original Message-----
> From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
> Sent: Freitag, 14. April 2017 11:44
> To: jsr370-experts_at_jax-rs-spec.java.net
> Subject: Re: HTTP PATCH on the client
>
> This will most likely stop working when running on Java SE 9 on module path, since it removes (well, almost) the possibility to access private fields on classes provided by the platform.
>
> Anyway, let's keep the API in current state (patch methods on the client
> side) for now, since there are no major objections in doing that.
>
> Thanks for your responses.
> Pavel
>
>
> On 13/04/2017 19:27, Markus KARG wrote:
>> I think it should actually be possible to do http PATCH with HttpUrlConnection when it is patched in the way Jersey does it already. Using that patch Jersey Client is able to do SEARCH and PROPFIND, so it should also do PATCH.
>>
>> -Markus
>>
>> -----Original Message-----
>> From: Pavel Bucek [mailto:pavel.bucek_at_oracle.com]
>> Sent: Donnerstag, 13. April 2017 16:13
>> To: jsr370-experts_at_jax-rs-spec.java.net
>> Subject: HTTP PATCH on the client
>>
>> Dear experts,
>>
>> as you might know, we recently introduced support for @PATCH and corresponding methods in the Client part of the API.
>>
>> There is one catch - HttpUrlConnection doesn't support making PATCH requests.
>>
>> Its known JDK issue and it won't be fixed. HttpUrlConnection was supposed to be replaced by HttpClient in Java SE 9, but .. that won't happen and it wouldn't fix our issue, since JAX-RS 2.1 implementation is stuck on Java SE 8 for now.
>>
>> That doesn't mean PATCH on the client cannot be implemented, the only
>> issue is that the implementation would need to use something else than
>> HttpUrlConnection, implying that there must be some other HTTP (client
>> side) framework involved, or it could be re-implemented using standard Java networking API.
>>
>> Jersey already has some means how to overcome that limitation, but by default we still do use HttpUrlConnection.
>>
>> Sergey, what about CXF? Do you use HttpUrlConnection on the client side?
>>
>> Does anyone else know how is this handled in other implementations?
>>
>> We still could support @PATCH on the server side without having it on the client, so dropping that part is certainly an option, but we'd like to hear your thoughts.
>>
>> Thanks and regards,
>> Pavel
>>
>>
>