将JAR放入JVM库与项目库的差异及IngrianNAE部署疑问

咱们来好好梳理下把JAR放进JVM的ext目录和纳入项目库之间的核心差异，顺便帮你搞清楚为啥IngrianNAE-5.0.0.jar会给你带来这么多头疼的问题：

• 当你把JAR放到/usr/lib/jvm/java-8-oracle/jre/lib/ext/时，它归**JVM扩展类加载器（Extension ClassLoader）**管，这个加载器的优先级比项目用的应用程序类加载器要高。也就是说，JVM会优先加载ext目录里的类，哪怕项目依赖里有同名的类也会被覆盖。
• 这种方式下，这个JAR里的类对所有运行在该JVM上的应用都是全局可见的，不是只属于你的项目。要是其他应用也用到了不同版本的IngrianNAE，分分钟就会出现版本冲突。
• 回到你的问题：构建工具（比如Maven、Gradle）只会用应用程序类加载器处理项目里配置的依赖，根本不会去扫JVM的ext目录，所以构建时自然识别不到这个JAR——这就是为啥你构建环节找不到它，但运行时只有JVM里有这个JAR才能跑的原因。

• 把JAR丢到ext目录完全脱离了项目的构建生命周期。构建工具只能管理你在pom.xml、build.gradle这类配置里声明的依赖，或者项目lib目录、本地仓库里的JAR。
• 你说把它纳入项目构建还是有问题？大概率是没配置对：要么是没把这个JAR安装到本地Maven仓库（得用mvn install:install-file命令），要么是没在构建脚本里显式引用，也可能是这个JAR本身还有其他依赖没被你引入项目。

• 放在ext目录的JAR，你得在每一个运行项目的JVM环境里手动部署——要是你用了集群或者Docker这类容器化部署，那得确保所有环境的JVM ext目录都有这个JAR，版本还得完全一致，简直是运维噩梦。
• 而把JAR作为项目依赖的话，构建工具会自动把它打包到项目的JAR/WAR里，或者通过依赖管理工具自动分发，部署时只需要扔你的项目包就行，不用折腾JVM环境，维护起来省心太多。

• 正如前面说的，ext目录的JAR是全局的，要是你的项目要升级IngrianNAE版本，你得手动替换所有JVM环境里的ext目录下的JAR，而且如果其他应用依赖旧版本，直接就崩了。
• 项目库中的依赖是应用级隔离的，每个项目可以用自己需要的版本，互相不干扰，这也是现在Java项目依赖管理的最佳实践。

• 提个醒：从Java 9开始，ext目录已经被模块化系统废弃了，用它会收到警告，未来版本说不定就彻底移除了。哪怕你现在用的是Java 8，这种方式也不符合后续的Java规范，以后项目升级Java版本时，还得额外花精力改造。

给你的小建议 #

针对你的情况，我建议赶紧停止用ext目录的方式，把IngrianNAE-5.0.0.jar纳入项目的依赖管理：

• 如果这个JAR是公开的，直接在构建脚本里声明它的依赖坐标就行；
• 如果是内部私有JAR，先把它安装到本地Maven仓库（用mvn install:install-file -Dfile=IngrianNAE-5.0.0.jar -DgroupId=com.ingrian -DartifactId=nae -Dversion=5.0.0 -Dpackaging=jar这类命令），然后在项目里引用；
• 别忘了检查这个JAR是否还有其他依赖，确保所有依赖都正确引入到项目中。

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