You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tomcat.apache.org by Rainer Jung <ra...@kippdata.de> on 2019/09/19 08:27:57 UTC
Better support for OpenJSSE?
The people from Azul have backported JSSE from Java 11 to Java 8 as an
additional provider. It is called OpenJSSE and available under
https://github.com/openjsse/openjsse
They moved packages underneath org.openjsse. OpenJSSE provides eg. TLS
1.3 and ALPN. So using OpenJSSE allows to use TLS 1.3 and HTTP/2 in TC 8
even when running under Java 8.
For those who want to experiment:
- the source code of OpenJSSE is relatively small and builds quickly
with maven.
- you can activate it in Tomcat using eg.
# Adjust the path to your OpenJSSE jar
CLASSPATH=${CATALINA_BASE}/ext/openjsse-1.1.0.jar
# See below for the contents of this file
CATALINA_OPTS=-Djava.security.properties=${CATALINA_BASE}/conf/java.security
and the new java.security file should contain one line like:
security.provider.4=org.openjsse.net.ssl.OpenJSSE
The number 4 has to be replaced by whatever number is used in your
original JVM java.security file for the provider
com.sun.net.ssl.internal.ssl.Provider. On Linux it is most often number
4, on Solaris number 6. Java 9+ uses the name SunJSSE instead of
com.sun.net.ssl.internal.ssl.Provider in the file java.security.
After that TLS 1.3 should be available. So no need for any changes in TC
to support that. But:
For HTTP/2 there is another change possible. We currently detect ALPN
availability by looking at the JVM version. If it is >= 9, we assume
ALPN, if it is smaller, we do not test for ALPN.
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. 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.
Regards,
Rainer
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Better support for OpenJSSE?
Posted by Rainer Jung <ra...@kippdata.de>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Better support for OpenJSSE?
Posted by Rainer Jung <ra...@kippdata.de>.
Am 23.09.2019 um 12:56 schrieb Rémy Maucherat:
> On Mon, Sep 23, 2019 at 12:42 PM Rainer Jung <rainer.jung@kippdata.de
> <ma...@kippdata.de>> wrote:
>
> Hi dev@, hi George,
>
> Am 20.09.2019 um 01:36 schrieb George Stanchev:
> > 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)
>
> I answered on tc-users to your test observations (warnings). IMHO they
> are not OpenJSSE related.
>
> Concerning the GH issue, I did not yet see any similar problems, at
> least not for TC 9. When using the security manager I added
>
> grant codeBase "file:/path/to/openjsse.jar" {
> permission java.security.AllPermission;
> };
>
> to catalina.policy and again observed no problems.
>
> My updated patch implementing the ALPN check in the normal compat
> classes is here:
>
> http://home.apache.org/~rjung/patches/tc9-openjsse-v2.patch
>
> I will now check the unit tests for changed behavior.
>
> What would be interesting to know, is whether Graal supports the ALPN
> methods or not, so that I can check/implement the correct behavior of
> the new isAlpnSupported() ind GraalCompat. It looks a bit strange, that
> currently GraalCompat only overwrites one method from JreCompat whereas
> Jre9Compat overwrites all of them.
>
>
> Graal still only does Java 8 at the moment :) So no ALPN, but OTOH Java
> 8 doesn't otherwise cause too many problems.
> Graal works with tomcat-native/OpenSSL and HTTP/2 works fine there.
Thanks Rémy, so I'll add fixed no-support for JSSE based ALPN into
GraalCompat in the next version of my patch.
> Rémy
>
>
> Regards,
>
> Rainer
>
> > *From:*Rémy Maucherat <remm@apache.org <ma...@apache.org>>
> > *Sent:* Thursday, September 19, 2019 5:02 AM
> > *To:* Tomcat Developers List <dev@tomcat.apache.org
> <ma...@tomcat.apache.org>>
> > *Subject:* Re: Better support for OpenJSSE?
> >
> > On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <markt@apache.org
> <ma...@apache.org>
> > <mailto:markt@apache.org <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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
Re: Better support for OpenJSSE?
Posted by Rémy Maucherat <re...@apache.org>.
On Mon, Sep 23, 2019 at 12:42 PM Rainer Jung <ra...@kippdata.de>
wrote:
> Hi dev@, hi George,
>
> Am 20.09.2019 um 01:36 schrieb George Stanchev:
> > 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)
>
> I answered on tc-users to your test observations (warnings). IMHO they
> are not OpenJSSE related.
>
> Concerning the GH issue, I did not yet see any similar problems, at
> least not for TC 9. When using the security manager I added
>
> grant codeBase "file:/path/to/openjsse.jar" {
> permission java.security.AllPermission;
> };
>
> to catalina.policy and again observed no problems.
>
> My updated patch implementing the ALPN check in the normal compat
> classes is here:
>
> http://home.apache.org/~rjung/patches/tc9-openjsse-v2.patch
>
> I will now check the unit tests for changed behavior.
>
> What would be interesting to know, is whether Graal supports the ALPN
> methods or not, so that I can check/implement the correct behavior of
> the new isAlpnSupported() ind GraalCompat. It looks a bit strange, that
> currently GraalCompat only overwrites one method from JreCompat whereas
> Jre9Compat overwrites all of them.
>
Graal still only does Java 8 at the moment :) So no ALPN, but OTOH Java 8
doesn't otherwise cause too many problems.
Graal works with tomcat-native/OpenSSL and HTTP/2 works fine there.
Rémy
>
> Regards,
>
> Rainer
>
> > *From:*Rémy Maucherat <re...@apache.org>
> > *Sent:* Thursday, September 19, 2019 5:02 AM
> > *To:* Tomcat Developers List <de...@tomcat.apache.org>
> > *Subject:* Re: Better support for OpenJSSE?
> >
> > On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <markt@apache.org
> > <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
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
> For additional commands, e-mail: dev-help@tomcat.apache.org
>
>
Re: Better support for OpenJSSE?
Posted by Rainer Jung <ra...@kippdata.de>.
Hi dev@, hi George,
Am 20.09.2019 um 01:36 schrieb George Stanchev:
> 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)
I answered on tc-users to your test observations (warnings). IMHO they
are not OpenJSSE related.
Concerning the GH issue, I did not yet see any similar problems, at
least not for TC 9. When using the security manager I added
grant codeBase "file:/path/to/openjsse.jar" {
permission java.security.AllPermission;
};
to catalina.policy and again observed no problems.
My updated patch implementing the ALPN check in the normal compat
classes is here:
http://home.apache.org/~rjung/patches/tc9-openjsse-v2.patch
I will now check the unit tests for changed behavior.
What would be interesting to know, is whether Graal supports the ALPN
methods or not, so that I can check/implement the correct behavior of
the new isAlpnSupported() ind GraalCompat. It looks a bit strange, that
currently GraalCompat only overwrites one method from JreCompat whereas
Jre9Compat overwrites all of them.
Regards,
Rainer
> *From:*Rémy Maucherat <re...@apache.org>
> *Sent:* Thursday, September 19, 2019 5:02 AM
> *To:* Tomcat Developers List <de...@tomcat.apache.org>
> *Subject:* Re: Better support for OpenJSSE?
>
> On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <markt@apache.org
> <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
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org
RE: Better support for OpenJSSE?
Posted by George Stanchev <Ge...@microfocus.com>.
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 <re...@apache.org>
Sent: Thursday, September 19, 2019 5:02 AM
To: Tomcat Developers List <de...@tomcat.apache.org>
Subject: Re: Better support for OpenJSSE?
On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <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
Re: Better support for OpenJSSE?
Posted by Rémy Maucherat <re...@apache.org>.
On Thu, Sep 19, 2019 at 12:01 PM Mark Thomas <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
Re: Better support for OpenJSSE?
Posted by Mark Thomas <ma...@apache.org>.
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-unsubscribe@tomcat.apache.org
For additional commands, e-mail: dev-help@tomcat.apache.org