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 Mark --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@tomcat.apache.org For additional commands, e-mail: dev-h...@tomcat.apache.org
