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