-
Bug
-
Resolution: Unresolved
-
P3
-
8, 11, 17, 21, 25
-
None
com.sun.beans.util.Cache#get()/#create() should be revisited as several issues have been found with it:
* Thread safety issues:
https://github.com/openjdk/jdk/pull/23845#issuecomment-2691383449
The existing optimistic fast path can avoid the lock, with the assumption that garbage collection of the cache values are rare. It is fine. However these plain access do require that the cached values to be thread safe and support safe publication.
Given the huge complexity of this cache and confusions around it, I recommend checking out jdk.internal.util.ReferencedKeyMap, which is already exported to java.desktop module.
* In the current state, data is implicitly added to the cache, documentation is inconsistent
https://github.com/openjdk/jdk/pull/23845#discussion_r1975870725
create should be made protected to indicate it is not intended to be called, but only overridden.
The preexisting code called create to reuse the creation mechanism without going through the cache - such usage is dubious. Per my experience, similar conditional caches are better implemented by enclosing the logic into the cache structure and use a common endpoint to access, so we have one universal site to determine the conditionality of caching. In this case, such a condition is better included in the Cache class itself, and the create method should not be publicly exposed.
* Thread safety issues:
https://github.com/openjdk/jdk/pull/23845#issuecomment-2691383449
The existing optimistic fast path can avoid the lock, with the assumption that garbage collection of the cache values are rare. It is fine. However these plain access do require that the cached values to be thread safe and support safe publication.
Given the huge complexity of this cache and confusions around it, I recommend checking out jdk.internal.util.ReferencedKeyMap, which is already exported to java.desktop module.
* In the current state, data is implicitly added to the cache, documentation is inconsistent
https://github.com/openjdk/jdk/pull/23845#discussion_r1975870725
create should be made protected to indicate it is not intended to be called, but only overridden.
The preexisting code called create to reuse the creation mechanism without going through the cache - such usage is dubious. Per my experience, similar conditional caches are better implemented by enclosing the logic into the cache structure and use a common endpoint to access, so we have one universal site to determine the conditionality of caching. In this case, such a condition is better included in the Cache class itself, and the create method should not be publicly exposed.
- relates to
-
JDK-8344892 beans/finder/MethodFinder.findMethod incorrectly returns null
-
- Resolved
-