在java_home/lib/ext目录中放置外部jar是件坏事吗?

是的-这是件坏事。考虑一下:应用程序依赖于JRE和一些额外的JAR。如果您更新了JRE怎么办?然后您必须记住将文件复制到新的JRE中。如果需要在新系统上设置应用程序怎么办?您必须将应用程序复制到那里,然后还要记住将外部JAR复制到该系统上的JRE中。

如果您只是将应用程序与它需要的外部JAR正确地打包在一起,那么这两个问题就不会是问题。如果你看不到这一点,那么也许这根本不是问题。但是你还是应该感谢这个新来的人分享他的意见。

除了Weiji的回答(打包和升级到新的JVM版本),还有其他的风险。

如果在任何应用程序中使用安全管理器,则 提取 默认情况下,它们通常具有更多的功能——它们的处理方式与系统库非常相似。您需要确保您可以信任这些类,从实施安全规则的意义上说。作者们是否思考了他们正确暴露的内容?如果这些类不使用访问控制来更改安全上下文,那么您不必担心这一点,但是您知道它们是否这样做(例如,提供对文件的访问并使用AccessController的方法,它是否确保调用方具有正确的文件权限?)

您的所有应用程序都可以使用完全相同版本的库吗?当需要更新该库(不仅仅是JVM)时会发生什么?你会破坏你的申请吗?你需要重新测试所有的东西。图书馆在 提取 由扩展类加载器加载,由于父类委托,该加载器的优先级高于普通(即类路径)加载器,因此保证应用程序可以使用这些加载器,并且单个应用程序无法重写中的库。 提取 使用不同的版本。

如果要在应用程序之间共享库,为什么不提供一个单独的公用库文件夹,应用程序可以单独配置(类路径)以引用该文件夹。然后,如果一个应用程序和一个库有问题,您可以切换到另一个版本的库,或者只针对该版本,将其放在类路径的前面(如果可以,您也必须测试这个版本,因为可能存在其他依赖性问题)。这将允许您对每个应用程序拥有更多单独的控制。但是,将所有必需的库与应用程序捆绑在一起是最安全的,因为您可以重新测试并将库升级部署到单个应用程序。

而且看起来 JEP-220 表面上是用一些武断的手段来贬低这种行为,用一些其他的行为来“可能取代它”。