将外部jar放在JAVA_HOME / lib / ext目录中是件坏事吗？
我们有一个在JRE环境中运行的应用程序。 该应用程序使用一些外部jar，我们已将它们放在JAVA_HOME / lib / ext文件夹中。 这对我们来说已经有好几年了，但最近一位新的程序员加入了我们的团队，并且似乎强调这是一件多么糟糕的事情。 在我进一步深入了解这个开发人员之前，我无法理解为什么并且我正在尝试做一些研究。 这里有什么我想念的吗？
是的 – 这是一件坏事。 想一想：应用程序依赖于JRE和一些额外的jar子。 如果您更新JRE怎么办？ 然后你必须记住将文件复制到新的JRE中。 如果您需要在新系统上设置应用程序，该怎么办？ 您必须在那里复制应用程序，然后还记得将外部jar复制到该系统上的JRE中。
如果您只是将应用程序与所需的外部jar一起正确打包，那么这两个问题都不会成为问题。 如果你没有看到这个，那么也许这根本不是问题。 但你仍然应该感谢新人分享他的意见。
除了weiji（新JVM版本的打包和升级）的答案之外，还有其他风险。
如果您在任何应用程序中使用安全管理器，则默认情况下， ext中的库通常具有更多function – 它们的处理方式与系统库非常相似。 在执行安全规则的意义上，您需要确保您可以信任这些类。 作者是否仔细考虑了他们正确曝光的内容？ 如果这些类不使用访问控制来更改安全上下文，那么您不必担心这一点，但是您知道它们是否执行（例如，提供对文件的访问并使用AccessController的方法，是否确保调用者是否具有正确的文件权限？）
您的所有应用程序都可以使用完全相同的库版本吗？ 当您需要更新该库（而不仅仅是JVM）时会发生什么？ 你会破坏你的任何申请吗？ 你需要重新测试一切。 ext中的库由扩展类加载器加载，由于父代理，它具有比普通（即CLASSPATH）加载器更高的优先级，因此保证应用程序使用这些库，并且单个应用程序无法覆盖ext中的库具有不同的版本。
如果要跨应用程序共享库，为什么不提供单独的公共库文件夹，以便可以单独配置应用程序（CLASSPATH）以进行引用。 然后，如果你有一个应用程序和一个库的问题，你可以切换到不同版本的库或只是为了那个，把它放在CLASSPATH的早期（如果可行，你必须测试它，因为可能有其他依赖问题）。 这将允许您对每个应用程序进行更多的单独控制。 但是，将所有必需的库与应用程序捆绑在一起是最安全的，因为您可以重新测试并将库升级到各个应用程序。
此外，看起来JEP-220表面上贬低了这种行为，并采用了一些任意方式来“替换它”以及其他一些行为。