netty-tcnative-parent下各子项目jar差异及openssl依赖问题

各JAR包定位差异 #

构建生成的5个JAR包并非功能完全一致，上层API对齐的只有3个带static后缀的分发包，其余两个是基础依赖包，具体分工如下：

• netty-tcnative-classes-2.0.52.Final.jar：纯Java层核心定义包，只包含公共接口、抽象类、Java层通用逻辑，没有任何原生（JNI）实现，是其余所有tcnative组件的依赖基础，单独引入无法提供SSL能力。
• netty-tcnative-2.0.52.Final.jar：动态链接版本的JNI实现包，仅包含Java和原生SSL库对接的胶水代码，没有内置SSL实现，运行时必须依赖系统环境预装的OpenSSL/LibreSSL动态链接库，适合需要统一管控系统级SSL版本、批量打安全补丁的生产环境。
• netty-tcnative-boringssl-static-2.0.52.Final.jar：静态打包BoringSSL实现的分发包，内置了全主流平台（Windows/Linux/macOS，覆盖x86_64、aarch64等常见架构）编译好的原生二进制，运行时自动识别当前平台加载对应库，无额外系统依赖，开箱即用，这也是绝大多数示例默认使用它的核心原因——不会出现本地库加载失败的环境问题，且是Netty官方测试覆盖最充分的版本。
• netty-tcnative-openssl-static-2.0.52.Final.jar：静态打包标准OpenSSL实现的分发包，上层API和boringssl-static完全一致，仅底层链接的SSL栈是官方OpenSSL版本。
• netty-tcnative-libressl-static-2.0.52.Final.jar：静态打包LibreSSL实现的分发包，上层API和前两个static包对齐，底层使用OpenBSD团队维护的LibreSSL分支。

三个带static后缀的包功能定位完全一致，都是给Netty提供高性能原生SSL能力，仅底层静态编译的SSL实现存在差异，可以在保证API兼容的前提下互相替换。

netty-tcnative-openssl-static的环境依赖要求 #

使用这个包不需要提前在运行环境安装OpenSSL。
包名里的static后缀就已经标明：对应的OpenSSL原生库已经通过静态编译的方式，和JNI对接代码一起打包进了JAR内部，支持的平台下会自动完成临时解压、库加载的全流程，不会去读取系统路径下的OpenSSL动态库。
只有使用不带static后缀的netty-tcnative-2.0.52.Final.jar时，才必须要求系统提前安装版本匹配的OpenSSL/LibreSSL动态库。

补充提示：如果没有特殊的SSL合规要求、或者指定要使用OpenSSL/LibreSSL特定特性的场景，优先选择netty-tcnative-boringssl-static即可，兼容性问题最少。

内容的提问来源于stack exchange，提问作者WarmSunshine