Hi Masayoshi,
Just a thought. What if RB.clearCache(classLoader) was specified as
equivalent to RB.clearCache(classLoader.getUnnamedModule()) ?
I think that would be backwards compatible...
Regards, Peter
On 08/02/2016 05:30 PM, Masayoshi Okutsu wrote:
Hi Peter,
Thanks for bringing up the
Hi Peter,
Thanks for bringing up the semantics issue of clearCache. You are right.
There's some semantics change in clearCache(ClassLoader). Let me look
into it.
The format field-related changes look good to me.
Thanks,
Masayoshi
On 8/1/2016 11:10 PM, Peter Levart wrote:
Hi Masayosh, Alan,
Hi Masayosh, Alan,
Thanks for looking at the change.
I suppose application containers are already accustomed to invoke
ResourceBundle.clearCache(ClassLoader) when undeploying an application
so that the corresponding ClassLoader can get GCed right away. But
there's a change in the semantics of
Hi Peter,
The change (ResourceBundle part) looks very good to me. There's a simple
workaround for the problem -- call
ResourceBundle.clearCache(ClassLoader). So I don't know how serious the
problem is, though. I still like this change.
Yes, the comment in ReferenceTest should be removed.
Th
On 22/07/2016 14:13, Peter Levart wrote:
:
The changes are very straightforward. They preserve the general
structure of the logic. I renamed the CacheKey nested class to
LoadSession as it now only functions as a mutable object passed around
the methods while executing the getBundle() process
On 07/22/2016 10:46 AM, Peter Levart wrote:
Hi Masayoshi,
Here's a preview of work to migrate ResourceBundle caching to using
ClassLoaderValue utility:
http://cr.openjdk.java.net/~plevart/jdk9-dev/ResourceBundle.cleanup/webrev.04/
The changes are very straightforward. They preserve the gene
Hi Masayoshi,
Thinking of how the ResourceBundle caching is implemented, I think it
has a serious flaw. The cache is currently the following:
private static final ConcurrentMap cacheList
...where the CacheKey is an object which contains WeakReference(s) to
the caller's ClassLoader and Module
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.
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
p
On 21/07/2016 05:14, 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/~
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
11 matches
Mail list logo
