Since I was the one that brought up a question about OpenJSSE on the User Mailing List several weeks ago, just wanted to bring up to your attention that there are quirks of OpenJSSE that people are discovering. I was able to get TC85 to run with OpenJSSE but admitting haven’t done extensive testing. For example this thread [1]. There are also other projects (such as OkHttp http client) that have ran into specificities on running with OpenJSSE.
[1] https://github.com/openjsse/openjsse/issues/10#issuecomment-533318077 (sorry for top posting, Outlook doesn’t make it easy) From: Rémy Maucherat <r...@apache.org> Sent: Thursday, September 19, 2019 5:02 AM To: Tomcat Developers List <dev@tomcat.apache.org> Subject: Re: Better support for OpenJSSE? On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <ma...@apache.org<mailto:ma...@apache.org>> wrote: 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 was a bit worried about that too. 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 +1 Personally I wouldn't use OpenJSSE over tomcat-native (performance ? long term support ?), but since it's only about making the Tomcat code a bit more flexible that works for me. Rémy
