Review Request JDK-8170772: ResourceBundle improper caching causes tools/javadoc tests intermittently
mandy.chung at oracle.com
Tue Dec 13 05:09:10 UTC 2016
> On Dec 12, 2016, at 7:10 AM, Peter Levart <peter.levart at gmail.com> 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:
> 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.
More information about the core-libs-dev