Hi, I will try to summary all the options here 1. No support for HTTP/2 + SSL at all, if users want to run SSL they must stick with HTTP/1.1 2. Set Java requirement to 9 and use ALPN implementation of JDK 9 3. If users want to use HTTP/2, we will notice about license problem then download and use Conscrypt library. Of course that we still test the Conscrypt implementation in tests.
On Wed, Nov 28, 2018 at 1:06 AM Shawn Heisey <apa...@elyograg.org> wrote: > On 11/27/2018 3:32 AM, Uwe Schindler wrote: > > I'd like to bring one thing into attention: This library conscrypt is > ASF2-licensed, but the JAR files contain binary versions of an OpenSSL fork > named BoringSSL. I'd recommend to check the licensing, because OpenSSL > licenses are a bit strange (some BSD fork, also ASF2, but some code is > still outdated - I am not sure what the fork actually uses). I have the > feeling we should include ASF legal department. > > > > Nevertheless, I am not 100% sure if conscrypt should really be inclued > by default in SolrJ. As SolrJ is a client library for Solr and can be used > by external projects, there is the problem of incompatibilities with the > native C code included. E.g., if one uses SolrJ with IBM J9 or other Java > versions different from openjdk. So I'd be careful. My question is: Do we > really need that library. To me it looks like it improves speed only, or is > there something that requires its use? > > As you might know ... full and proper http/2 support with Java 8 > requires the conscrypt library. With Java 9 or higher, the > functionality is provided natively by Java. If I remember right, what > conscrypt provides that Java 8 lacks is ALPN. > > If there are license issues with conscrypt, perhaps it might make sense > to require a newer major version of Java instead ... but I think that > upgrading the project's Java requirement to 9, 10, or 11 probably > requires a wider discussion. Lucene probably has no burning need for it > right now. I have no idea whether there are language features in Java > 9+ that we as a group are wanting to use. Another point for > consideration is that the effective EOL for Java 8 is fast approaching, > and EOL dates have already come and gone for 9 and 10. > > Thanks, > Shawn > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- *Best regards,* *Cao Mạnh Đạt* *D.O.B : 31-07-1991Cell: (+84) 946.328.329E-mail: caomanhdat...@gmail.com <caomanhdat...@gmail.com>*
