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
