java.util.logging.Logger类以非常具体的方式定位ResourceBundle个实例。我有兴趣了解类加载行为。
放弃缓存等，首先Logger班级尝试使用context classloader（这很好，我期待的）。
如果该类加载器无法加载ResourceBundle（使用ResourceBundle#getBundle(String, Locale, ClassLoader) call），则接下来使用系统类加载器。那对我来说有点令人费解;我假设调用者的类加载器将成为下一个。这是一个优化，还是处理某些特定用例，或者......？
最后，如果系统类加载器无法加载ResourceBundle，则会推导出推断的调用堆栈（！），并且该堆栈中的每个类都是为其类加载器挖掘的，并且每个其中的那些是依次尝试的。
对于我遇到或不得不写的所有各种类加载场景，这个对我来说最不合适。我怀疑这与Logger对任何给定系统的潜在中心性有关，但我欢迎任何有关为何选择此特定算法的解释。
（另外，附带问题不值得自己输入：JVM中context classloader是null是否有任何情况？）
答案 0 :(得分：1)
我的猜测是他们正在考虑在每个应用服务器中支持J2EE classloader层次结构及其不同的实现。
此外，如果我们检查JavaDoc我们有
作为初始实现中的临时转换功能，如果Logger无法从ContextClassLoader或SystemClassLoader找到ResourceBundle，则Logger还将搜索类堆栈并使用连续调用ClassLoader来尝试查找ResourceBundle。 （此调用堆栈搜索是允许容器转换为使用ContextClassLoaders，并且很可能在将来的版本中删除。）