Am 19.09.2019 um 12:01 schrieb Mark Thomas:
On 19/09/2019 09:27, Rainer Jung wrote:
<snip/>
I made a patch to detect ALPN support at runtime using reflection.
Please have a look. Feedback welcome, whether we want to include that or
whether we want to stick with the simpler approach we currently use.
Past experience suggests a lot of users will be on Java 8 for quite some
time. I think it makes sense to support this.
Of
course the windows for Java 8 plus OpenJSSE is getting smaller over
time, and users could also use tcnative to get TLS 1.3 and HTTP/2. On
the other hand integration of OpenJSSE is pretty simple and some users
don't like native code in their JVM (and its maintenance). IMHO support
for OpenJSSE (including HTTP/2) would be a nice addition.
My TC 9 patch is available under:
http://home.apache.org/~rjung/patches/tc9-openjsse.patch
It moves the ALPN detection from classes Jre(9)Compat to class TLS in
the same package and uses the same approach that we use for other
runtime detection. It needs to make one method accessible, because under
Java 9+ the implementation class SSLEngineImpl is no longer a public
class. Since it is accessed normally via SSLEngine, direct method calls
still work, but reflective calls no longer.
Currently TLS.java is only used by the unit tests.
We only need to use reflection on Java 8 since we know ALPN is available
on Java 9 onwards.
The module system adds additional restrictions to calling
setAccessible() that might cause problems in the future.
I wonder if a cleaner solution might be:
- Move isTlsv13Available to TesterSupport and deprecate TLS.java
- Add isAlpnAvailable() to JreCompat where:
- Java 7 (for 8.5.x) hard codes to false
- Java 8 uses reflection
- Java 9 hard codes to true
As long as we only talk about OpenJSSE I like the above. We can vary it,
once more solutions come into play that might change behavior for Java
below or above 8. But probably that will never happen.
I can provide an updated version of the patch for review later today.
Thanks for your feedback. Any other opinion?
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org
For additional commands, e-mail: dev-h...@tomcat.apache.org
