java.util.logging.Logger 使用非常具体的 ResourceBundle 加载行为。为什么？

Question

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

丢弃缓存等，首先 Logger 类尝试使用 context classloader (这很好，也是我所期望的)。

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

最后，如果系统类加载器无法加载 ResourceBundle，则会遍历推断的调用堆栈 (!)，并为其类加载器挖掘该堆栈中的每个类，然后依次尝试其中的每一个。

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

(此外，附带的问题并不值得自己进入:JVM 中是否存在 context classloader 为 null 的情况？)

Answer 1

我的猜测是他们正在考虑支持 J2EE classloader层次结构及其在每个应用程序服务器中的不同实现。

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

As a temporary transition feature in the initial implementation, if the Logger is unable to locate a ResourceBundle from the ContextClassLoader or SystemClassLoader the Logger will also search up the class stack and use successive calling ClassLoaders to try to locate a ResourceBundle. (This call stack search is to allow containers to transition to using ContextClassLoaders and is likely to be removed in future versions.)