3

该类以非常具体的方式java.util.logging.Logger定位ResourceBundle实例。我有兴趣了解类加载行为。

丢弃缓存等，首先Logger该类尝试使用上下文类加载器（这很好，也是我所期望的）。

如果该类加载器无法加载ResourceBundle（使用ResourceBundle#getBundle(String, Locale, ClassLoader)call），则接下来使用系统类加载器。这让我有点困惑；我假设调用者的类加载器将是下一个。这是一种优化，还是为了处理一些特定的用例，或者......？

最后，如果系统类加载器无法加载ResourceBundle，则推断调用堆栈（！）被遍历，并且该堆栈中的每个类都被挖掘为其类加载器，并依次尝试每个类。

对于我遇到或必须编写的所有各种类加载场景，这个对我来说最没有意义。我怀疑这与Logger' 对任何给定系统的潜在中心性有关，但我欢迎任何解释为什么选择这个特定算法。

（另外，一个不值得自己输入的附带问题：在 JVM 中是否存在上下文类加载器所在的任何情况null？）

4

1 回答 1

1

我的猜测是他们正在考虑以一种方式支持J2EE 类加载器层次结构及其在每个应用程序服务器中的不同实现。

此外，如果我们检查JavaDoc，我们有

作为初始实现中的临时转换功能，如果 Logger 无法从 ContextClassLoader 或 SystemClassLoader 中找到 ResourceBundle，Logger 还将向上搜索类堆栈并使用连续调用 ClassLoaders 来尝试定位 ResourceBundle。（这个调用栈搜索是为了让容器过渡到使用 ContextClassLoaders 并且很可能在未来的版本中被移除。）

于 2013-03-06T11:49:22.150 回答