<i18n dev> RFR: 8161203: ResourceBundle.getBundle performance regression

Masayoshi Okutsu masayoshi.okutsu at oracle.com
Fri Jul 22 04:07:15 UTC 2016

Hi Peter,

Thank you for your suggestion. Actually CacheKey is used for storing 
information required to load resource bundles during a 
ResourceBundle.getBundle call. The current CacheKey usage may be too 
tricky and cause some maintenance problems. I will file a separate issue 
on that problem. I wanted to work on some clean up of the CacheKey 
usage, but I haven't had a chance.


On 7/21/2016 10:13 PM, Peter Levart wrote:
> Hi Masayoshi,
> Previously the CacheKey::clone() method cleared a reference to 
> 'providers' in the clone making the provides unreachable from the 
> clone and making the clone unable to obtain providers. Now you also 
> reset the 'providersChecked' flag which makes the clone be able to 
> re-obtain the providers. This is dangerous as the clone is used as a 
> key in the cache and is strongly reachable from the cache. A slight 
> future modification of code could unintentionally produce a class 
> loader leak. To prevent that, I would somehow mark the clone so that 
> any attempt to invoke getProviders() on the clone would throw 
> IllegalStateException.
> Regards, Peter
> On 07/21/2016 06:14 AM, Masayoshi Okutsu wrote:
>> Hi,
>> Please review the fix for JDK-8161203. The fix is to lazily load 
>> ResourceBundleProviders. It's not necessary to load providers before 
>> cache look-up.
>> Issue:
>> https://bugs.openjdk.java.net/browse/JDK-8161203
>> Webrev:
>> http://cr.openjdk.java.net/~okutsu/9/8161203/webrev.01
>> Thanks,
>> Masayoshi

More information about the i18n-dev mailing list