[ELY-2026] Use reflection to pass through the new methods if they are now available on the SSLEngine, SSLParameters, and SSLSocket APIs. #1448
Conversation
… now available on the SSLEngine, SSLParameters, and SSLSocket APIs.
…cols to support a subset of the previously configured set.
| throw new UnsupportedOperationException(); | ||
| } | ||
|
|
||
| static void setApplicationProtocols(SSLParameters parameters, String[] protocols) { | ||
| if (SSLPARAMETERS_SET_APPLICATION_PROTOCOLS != null) { | ||
| try { | ||
| SSLPARAMETERS_SET_APPLICATION_PROTOCOLS.invoke(parameters, (Object) protocols); |
There was a problem hiding this comment.
Does this work or should it be new Object[] {protocols}?
There was a problem hiding this comment.
Yeah this works, I found the same in the Undertow code as well. The main point was to stop the protocols array itself being seen as an array of arguments - when I test this Undertow is setting an array of three Strings.
There was a problem hiding this comment.
Right yeah. It seemed like it may work, I've just never tried it this way is all :)
|
One thing I've done in the past is to generate "stub" classes to compile against. This basically amounts to creating a version of the class with the expected topography, where all the concrete methods are empty (or marked "native") and then adding that to the class path (e.g. as a provided dependency). This adds some complexity to the build, but usually makes up for it by dramatically simplifying the resultant code. It might be worth exploring in the future if reflection proves too slow or hard to maintain. |
https://issues.redhat.com/browse/ELY-2026
Under ELY-1979 we did attempt a number of different approaches to implement these methods directly and avoid the use of reflection, unfortunately as the project is built using Java 11 but targeting Java 8 the Java 11 compiler does not agree that these methods are present in Java 8.
We could consider a more complex build that compiles using two different JDKs but that seems overly complex, another option could be to split out an "accessor" class into another project which is built using the latest Java 8 (and has no plans to move to Java 11 soon) but that seems over complex.
Users of Java 9 or later will automatically get the JDKSpecific implementation that uses direct access.