Java库运行时与编译时间 [英] Java Libraries Runtime vs Compile Time
问题描述
当使用Tomcat作为应用程序服务器设置Java Web应用程序时，我经常对库可用时感到困惑。通过对Stack Overflow的一些讨论，我已经知道一些库（.jar）文件在运行时可用，而其他库在编译时可用。通常我会收到错误，并通过反复尝试解决它们，将jar文件放在不同的目录中，直到应用程序运行或编译。最近我向我指出，您可以通过WEB-INF / lib文件夹在运行时使.jar库可用。我开始思考这个问题，有几个问题。过去我已经阅读了这个话题，还没有找到一个将信息放在一个容易理解和保留的上下文中的资料。
When setting up a Java web application using Tomcat as an application server I often get confused about when libraries are available. Through some discussion on Stack Overflow, I have learned that some libraries (.jar) files are available at runtime, while others are available at compile time. Often I will get errors and will resolve them by trial and error, placing jar files in different directories until the application runs or compiles. It was recently pointed out to me that you can make .jar libraries available at runtime via the WEB-INF/lib folder. I started thinking about this and had a few question. I have read up on this topic in the past and haven't found a source that puts the information into a context I easily understand and retain.
-
是否有可以为项目设置的编译时类路径和运行时类路径？
Is there a compile time classpath and a runtime classpath you can set for a project?
a。类路径甚至是在运行时讨论库的适用术语？
a. Is classpath even an applicable term for discussing libraries available at runtime?
WEB-INF / lib是使库在运行时可用的唯一方法？ Tomcat中的lib文件夹在运行时是可用的吗？
Is WEB-INF/lib the only way to make libraries available at runtime? What about the lib folder in Tomcat is this available at runtime?
这个类与加载器有什么关系？我知道创建了类加载器的层次结构。这些严格适用于运行时操作？
How does this relate to classloaders? I know that a hierarchy of classloaders is created. Are these strictly for Runtime operations?
推荐答案
编译类路径是类路径用于编译您的Java源文件（使用 javac -cp ... 或您的IDE）。源文件中引用的每个类都必须存在于编译类路径中，否则编译器会抱怨找不到该类。
The compile classpath is the classpath used to compile your Java source files (using javac -cp ..., or your IDE). Every class referenced in the source file must be present in the compile classpath, else the compiler will complain that it can't find the class.
您可以使用它们运行程序（使用 java -cp ... ）。显然，源代码直接依赖的库应该在运行时类路径中。但这不是全部。如果您直接依赖CoolLibrary.jar，而这个库在内部依赖于Guava.jar，那么Guava.jar也必须在运行时类路径中，尽管编译时不需要。
Once you have compiled the classes, you can run a program using them (using java -cp ...). Obviously, the libraries on which your source code depends directly should be in the runtime classpath. But that's not all. If you depend directly on CoolLibrary.jar, and this library internally depends on Guava.jar, then Guava.jar must also be in the runtime classpath, although it was not needed when compiling.
Webapps有点特别。 servlet规范指定用于执行webapp的类路径由部署的webapp的WEB-INF / classes目录以及WEB-INF / lib中包含的所有jar组成。所有的webapps都可以访问由Tomcat直接提供的本机servlet和JSP jar。实际上，Tomcat的内部类（如servlet-api接口的实现类）也可用于webapp，但依靠这些类并不是一个好主意，因为它将把webapp绑定到tomcat。
Webapps are a bit special. The servlet specification specifies that the classpath used to execute the webapp is composed by the WEB-INF/classes directory of the deployed webapp, and of all the jars contained in WEB-INF/lib. All the webapps also have access to the native servlet and JSP jars, which are directly provided by Tomcat. In reality, Tomcat's internal classes (like the implementation classes of the servlet-api interfaces) are also available to the webapp, but relying on these classes is not a good idea, since it would tie your webapp to tomcat.
在webapp的情况下，谈论运行时类路径有点简单。实际上，每个webapp的类都由tomcat的特定类加载器动态加载。而这个webapp类加载器是tomcat类加载器的一个子代。因此，理论上，您可以直接将webapp jar放在Tomcat的类路径中，但这意味着所有的webapps将共享这些库，并且您将解除部署和重新部署webapps的问题。每个webapp拥有一个特定的类加载器的目标是能够在同一个JVM中使用依赖Guava 11.0的应用程序，另一个依赖Guava 12.0的应用程序。
Talking of the runtime classpath, in the case of a webapp, is a bit of a simplification. In reality, every webapp's classes are loaded dynamically by a specific classloader by tomcat. And this webapp classloader is a child of the tomcat's classloader. So, in theory, you could place the webapp jars in Tomcat's classpath directly, but this would mean that all the webapps would share these libraries, and that you would have problems undeploying and redeploying webapps. The goal of having a specific classloader per webapp is to be able to have, in the same JVM, an app relying on Guava 11.0, and another one relying on Guava 12.0, for example.
有关tomcat类加载器的更多信息，请参阅文档。
For more information about tomcat classloaders, read the documentation.
这篇关于Java库运行时与编译时间的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
