java 将外部 jars 放在 JAVA_HOME/lib/ext 目录中是件坏事吗?

声明:本页面是StackOverFlow热门问题的中英对照翻译,遵循CC BY-SA 4.0协议,如果您需要使用它,必须同样遵循CC BY-SA许可,注明原文地址和作者信息,同时你必须将它归于原作者(不是我):StackOverFlow 原文地址: http://stackoverflow.com/questions/2068961/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me): StackOverFlow

提示:将鼠标放在中文语句上可以显示对应的英文。显示中英文
时间:2020-10-29 19:14:11  来源:igfitidea点击:

Is putting external jars in the JAVA_HOME/lib/ext directory a bad thing?

javajar

提问by Elliott

We have an application which runs in a JRE environment. The application uses some external jars and we have been putting them in the JAVA_HOME/lib/ext folder. This has worked for us for years but recently a new programmer joined our team and seems emphatic that this is some how a bad thing to do. I can't understand why and I'm trying to do some research before I dig further with this developer. Is there something I'm missing here?

我们有一个在 JRE 环境中运行的应用程序。该应用程序使用了一些外部 jar,我们已将它们放在 JAVA_HOME/lib/ext 文件夹中。这对我们有用多年,但最近一位新程序员加入了我们的团队,似乎强调这是一件多么糟糕的事情。我不明白为什么,在与这个开发人员进一步挖掘之前,我正在尝试做一些研究。有什么我在这里想念的吗?

回答by weiji

Yes - it's a bad thing. Think about it: the application depends on the JRE and some extra jars. What if you update the JRE? Then you have to remember to copy the files into the new JRE. What if you need to set up the application on a new system? You have to copy the application there, and then also remember to copy the external jars into the JRE on that system.

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

Both those issues wouldn't be an issue at all if you just package the application properly together with the external jars it needs. If you don't see this, then maybe it's not an issue at all. But you should still be grateful for the new guy for sharing his opinion.

如果您只是将应用程序与其需要的外部 jar 正确打包在一起,那么这两个问题都不会成为问题。如果你没有看到这一点,那么也许这根本就不是问题。但是你仍然应该感谢这位新人分享了他的观点。

回答by Kevin Brock

In addition to the answer by weiji (packaging and upgrades to new JVM versions), there are other risks.

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

If you are using security manager in any of your applications, the libraries in extoften have a lot more capability by default - they are treated much like the system libraries. You need to be sure that you can trust, in the sense of enforcing security rules, these classes. Did the authors think through what they were exposing correctly? If these classes do not use access control to change the security context then you don't need to worry about this but do you know if they do or do not (e.g. a method that provides access to a file and uses AccessController, does it ensure that the caller has the right file permissions?)

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

Can all your applications use the exact same version of the library? What happens when you need to update that library (not just the JVM)? Will you break any of your applications? You will need to retest everything. The libraries in extare loaded by the extension class loader which, due to parent delegation, has higher precedence than the normal (i.e. CLASSPATH) loader so these are guaranteed to be used by your application and there is no way for an individual application to override the library in extwith a different version.

您的所有应用程序都可以使用完全相同版本的库吗?当您需要更新该库(不仅仅是 JVM)时会发生什么?你会破坏你的任何应用程序吗?您将需要重新测试所有内容。ext中的库由扩展类加载器加载,由于父级委托,它比普通(即 CLASSPATH)加载器具有更高的优先级,因此可以保证您的应用程序使用这些库,并且单个应用程序无法覆盖ext 中的库具有不同的版本。

If you want to share the libraries across your applications, why not instead provide a separate folder of common libraries that applications can be individually configured (CLASSPATH) to reference. Then if you have problems with one application and a library, you can switch to a different version of the libraries or just for that one, put it earlier in the CLASSPATH (if that works, you must test this too as there may be other dependency issues). This will allow you to have more individual control for each application. But then, bundling all the required libraries with your application is the safest as you can retest and roll-out library upgrades to individual applications.

如果您想在您的应用程序之间共享库,为什么不提供一个单独的公共库文件夹,应用程序可以单独配置 (CLASSPATH) 以引用这些库。然后,如果您对一个应用程序和一个库有问题,您可以切换到不同版本的库,或者仅针对那个版本,将其放在 CLASSPATH 的较早位置(如果可行,您也必须对此进行测试,因为可能存在其他依赖项)问题)。这将允许您对每个应用程序进行更多的单独控制。但是,将所有必需的库与您的应用程序捆绑在一起是最安全的,因为您可以对单个应用程序重新测试和推出库升级。

回答by Mykel Alvis

Also it looks like JEP-220is ostensibly deprecating this behavior with some arbitrary means to "possibly replace it" with some other behavior.

此外,看起来JEP-220表面上不赞成这种行为,并以某种任意方式用其他一些行为“可能替换它”。