> On Dec 12, 2016, at 7:10 AM, Peter Levart <[email protected]> wrote: > > : > Considering all this, I think class loader is not needed any more as the > CacheKey component. The distinction between scopes of system class loader > (when the caller is not a bootstrap class) and the RBClassLoader.INSTANCE > (when the caller is the bootstrap class) is also not needed any more since > the callerModule is now part of CacheKey. >
I believe this is true. I was tempted to remove class loader from the CacheKey at one point. Resource bundles are hard to diagnose and I don’t know how good our test cases are. I decided to leave it for the owner of resource bundles to clean this up. I filed a JBS issue to track this: https://bugs.openjdk.java.net/browse/JDK-8171139 <https://bugs.openjdk.java.net/browse/JDK-8171139> > I modified your patch (just ResourceBundle.java) to include all these > simplifications and some cleanup: > > > http://cr.openjdk.java.net/~plevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/ > > <http://cr.openjdk.java.net/%7Eplevart/jdk9-dev/8170772_ResourceBundle.caching/webrev.01/> > > > This modification also contains a re-interpretation of clearCache() methods. > Both existing clearCahe() methods together with the additional @since 9 > method contain the following wording: > > "Removes all resource bundles from the cache that have been loaded by the > caller's / given module..." > > What does it meant for a bundle to be loaded *by* some module? I think the > right interpretation is that this is the caller module (the one that invokes > ResourceBundle.getBundle() method). The module that calls > ResourceBundle.getBundle() is usually also the module that is responsible for > clearing the cache of entries that were cached by its loading requests, isn't > it? Good catch. I file https://bugs.openjdk.java.net/browse/JDK-8171140 <https://bugs.openjdk.java.net/browse/JDK-8171140>. I will look into it. Mandy
