Jersey 2.34 with HTTPS and PATCH method fails with error when run with JDK 16

[ceharris]

Configuration:

• JAX-RS client API
• Jersey 2.34 as the JAX-RS provider
• REST service utilizing HTTPS and the PATCH method
• JDK 16

This configuration implies that the default HttpsUrlConnection is used as the connector.

When making a PATCH request to the REST service with this configuration, the PATCH request fails with the stack trace shown below. JDK versions up to and including JDK 15.0.2 work successfully with the same configuration. Could work around using a different connector, if willing to use Jersey-specific API to specify the connector implementation.

Stack trace:

javax.ws.rs.ProcessingException: Unable to make field private final sun.net.www.protocol.https.DelegateHttpsURLConnection sun.net.www.protocol.https.HttpsURLConnectionImpl.delegate accessible: module java.base does not "opens sun.net.www.protocol.https" to unnamed module @76e041cf

	at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:309)
	at org.glassfish.jersey.client.JerseyInvocation.lambda$invoke$1(JerseyInvocation.java:675)
	at org.glassfish.jersey.client.JerseyInvocation.call(JerseyInvocation.java:697)
	at org.glassfish.jersey.client.JerseyInvocation.lambda$runInScope$3(JerseyInvocation.java:691)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:292)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:274)
	at org.glassfish.jersey.internal.Errors.process(Errors.java:205)
	at org.glassfish.jersey.process.internal.RequestScope.runInScope(RequestScope.java:390)
	at org.glassfish.jersey.client.JerseyInvocation.runInScope(JerseyInvocation.java:691)
	at org.glassfish.jersey.client.JerseyInvocation.invoke(JerseyInvocation.java:674)
       [snip]
Caused by: java.lang.reflect.InaccessibleObjectException: Unable to make field private final sun.net.www.protocol.https.DelegateHttpsURLConnection sun.net.www.protocol.https.HttpsURLConnectionImpl.delegate accessible: module java.base does not "opens sun.net.www.protocol.https" to unnamed module @76e041cf
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:357)
	at java.base/java.lang.reflect.AccessibleObject.checkCanSetAccessible(AccessibleObject.java:297)
	at java.base/java.lang.reflect.Field.checkCanSetAccessible(Field.java:177)
	at java.base/java.lang.reflect.Field.setAccessible(Field.java:171)
	at org.glassfish.jersey.client.internal.HttpUrlConnector$3.run(HttpUrlConnector.java:493)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:554)
	at org.glassfish.jersey.client.internal.HttpUrlConnector.setRequestMethodViaJreBugWorkaround(HttpUrlConnector.java:480)
	at org.glassfish.jersey.client.internal.HttpUrlConnector._apply(HttpUrlConnector.java:324)
	at org.glassfish.jersey.client.internal.HttpUrlConnector.apply(HttpUrlConnector.java:266)
	at org.glassfish.jersey.client.ClientRuntime.invoke(ClientRuntime.java:297)
	... 52 more

[ceharris]

Could also work around by specifying the HTTP method in a request header, but the REST service in this case has no such support. 😞

[jansupol]

Sorry this is a well-known issue. HttpUrlConnection supports only HTTP 1.1 methods, HTTP patch is not supported. Jersey used reflection to set JDK internals to accept HTTP Patch. Starting with JDK 16, it is no longer possible to modify JDK internals by reflection, and the default Jersey HttpUrlConnection no longer can support HTTP Patch.

[rsmith20]

Are there plans to switch over to the newer client api (java.net.http)? This seems to indicate it as the only way forward https://bugs.openjdk.java.net/browse/JDK-8207840. Or is it possible to get Jersey to not default to HttupUrlConnection?

[jansupol]

Jersey supports multiple 3rd party HTTP clients. See Connectors. For Jersey 2.x we also support Helidon Connector (based on Netty Http Client).

The new Java Client API is for JDK 11+, only. We would like to focus on it after Jersey 3.1.0 is out.