今天,我很惊讶(可能是由于缺乏经验)发现您可以,而且实际上很有用,将一个空路径(字面意思是一个空字符串)传递给 ClassLoader.getResources
, IE。ClassLoader.getSystemClassLoader().getResources("")
.通过一些测试,这会返回我的应用程序 .class
所在的一个或两个目录。文件实时(并且不包括第 3 方包的目录)。 (用法示例:Get all of the Classes in the Classpath。)
据推测,这是因为 Java System ClassLoader 是加载我自己的应用程序类的三个 ClassLoader 之一(参见 http://www.oracle.com/technetwork/articles/javase/classloaders-140370.html ),所以返回的 URL 指向我的应用程序类文件的目录也就不足为奇了。
但是空字符串为什么以及如何实现这一点?我没有发现它记录在案。这个空路径是更常见的 Java 约定的派生词吗?它肯定不是 Linux - 你不能 cd
进入 bash 中的空路径。如果有人可以帮助我理解这一点,我将不胜感激。
在另一个注释中,我注意到 getResources(".")
达到同样的目的。
添加评论讨论
public class myTest {
public static void main(String[] args) throws Exception {
ClassLoader classLoader = ClassLoader.getSystemClassLoader();
URL[] urls = ((URLClassLoader) classLoader).getURLs();
for (int n = 0; n < urls.length; n++)
System.out.println(urls[n]); //lists external.jar
Enumeration<URL> roots = classLoader.getResources(".");
while (roots.hasMoreElements()) {
URL url = roots.nextElement();
System.out.println("getResources: " + url); //does not list external.jar
}
}
}
要执行的命令:
java -cp ".:external.jar" myTest
最佳答案
为什么 getResources(String)
当给定资源名称“”或“。”时,调用匹配所有作为目录的类路径条目?
我只能推测。对于它的值(value),我认为这是特定 ClassLoader
的实现细节.方式“”和“。”然而,从文件系统用户的角度来看,处理资源名称还是有些直观的。
...如何?
默认的 OpenJDK 应用程序 ClassLoader
(也称为系统 ClassLoader
),sun.misc.Launcher$AppClassLoader
, 是 URLClassLoader
具有包含“java.class.path”系统属性值的 URL 搜索路径的后代。其getResources
(getResource
以及)方法最终委托(delegate)给 sun.misc.URLClassPath$FileLoader.getResource(String, boolean)
,它执行以下操作:
url = new URL(getBaseURL(), ParseUtil.encodePath(name, false));
...
file = new File(dir, name.replace('/', File.separatorChar)); // dir is the equivalent of getBaseURL()'s path component
...
if (file.exists()) {
return new sun.misc.Resource() {
...
public URL getURL() { return url; } // eventually returned by the ClassLoader
}
}
抛开所有的 URL 解析,资源名称本质上被视为相对文件系统路径,并针对加载程序的搜索路径条目“绝对化”。因此
name
""或 "."的参数匹配搜索路径条目本身。换句话说,所有顶级类路径条目都被匹配并返回,就好像它们都位于同一个根目录下一样。请注意,这不适用于 JAR 类路径条目,而是由 sun.misc.URLClassPath$JarLoader
处理。 .为什么不这些
getResources
调用也匹配 JAR 类路径条目?以及为什么 URLClassLoader.getURLs()
返回的数组中包含此类路径条目? API 方面...
这是两种不相关的方法,每一种都有不同的目的。有时它们“只是碰巧”产生相同或相似的输出——但它们的规范在任何地方都没有暗示任何形式的行为相互一致性。
getResources
, 根据 URLClassLoader
对术语“资源”的具体定义被指定为在其搜索路径下返回文件、目录或 JAR 条目。当搜索路径条目表示目录时,它也恰好返回搜索路径条目本身的事实没有被其规范解决,因此应该被视为实现细节(也可能是轻微的规范违规)而不是依赖.同样,它不返回 JAR 搜索路径条目这一事实虽然与前者不一致,但并不违反其规范。getURLs
另一方面,返回在实例化时提供的确切 1 搜索路径条目。执行方面...
不像
sun.misc.URLClassPath$FileLoader
,如前所述,它根据每个搜索路径条目的文件系统路径解析资源名称,sun.misc.URLClassPath$JarLoader
通过 JarFile.getEntry(name)
尝试直接匹配,对于“”,最有可能的“。”,条目名称,显然失败了。但即使两者 URLClassPath.Loader
s 以相同的方式解释资源名称,事情不会按预期进行,因为嵌入式 JAR 文件系统不支持根目录的概念。那么我应该如何检索所有类路径条目呢?
独立于系统
ClassLoader
实际上,使用类似的东西String[] classPathEntries = System.getProperty("java.class.path").split(File.pathSeparator);
,最好在您的
main
早期方法,在任何第三方代码有机会修改属性之前。ClassLoader.getSystemClassLoader()
返回类型为 java.lang.ClassLoader
.我们如何(确定地)知道返回的实例是 sun.misc.Launcher$AppClassLoader
? 我们真的没有。系统类加载器是依赖于实现和可替换的。一如既往,我们所能做的就是测试,例如,
try {
ClassLoader sysCl = ClassLoader.getSystemClassLoader();
// not using single-arg Class.forName, since it would use the ClassLoader of this class,
// which, in the worst-case scenario of being a non-delegating loader, could attempt to load AppClassLoader itself
if (Class.forName("sun.misc.Launcher$AppClassLoader", false, sysCl).isAssignableFrom(sysCl.getClass())) {
// default implementation, _most likely_ a URLClassLoader subclass
}
else {
// System ClassLoader overridden, or not on OpenJDK
}
}
catch (ReflectiveOperationException roe) {
// most likely not on OpenJDK
}
,并采取相应措施。
1 这可能并不总是成立,例如,当搜索路径条目“重叠”(一个是另一个的父级)或应用安全约束时;引用
sun.misc.URLClassPath
的来源具体情况。
关于Java 空路径约定,尤其是 ClassLoader.getResources 中使用的约定,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/45624909/