-
Enhancement
-
Resolution: Fixed
-
P3
-
8
-
b08
-
generic
-
generic
| Issue | Fix Version | Assignee | Priority | Status | Resolution | Resolved In Build |
|---|---|---|---|---|---|---|
| JDK-8045645 | 8u25 | Mike Duigou | P3 | Resolved | Fixed | b01 |
| JDK-8040198 | 8u20 | Mike Duigou | P3 | Resolved | Fixed | b11 |
| JDK-8053873 | emb-8u26 | Mike Duigou | P3 | Resolved | Fixed | b17 |
In AbstractMap there are two volatile fields that are explicitly set to null as part of initialization.
This should be unnecessary since all fields are guaranteed to be null.
public abstract class AbstractMap<K,V> implements Map<K,V> {
...
/**
* Each of these fields are initialized to contain an instance of the
* appropriate view the first time this view is requested. The views are
* stateless, so there's no reason to create more than one of each.
*/
transient volatile Set<K> keySet = null;
transient volatile Collection<V> values = null;
...
}
There might be other similar instance in the JDK that could be fixed at the same time.
This should be unnecessary since all fields are guaranteed to be null.
public abstract class AbstractMap<K,V> implements Map<K,V> {
...
/**
* Each of these fields are initialized to contain an instance of the
* appropriate view the first time this view is requested. The views are
* stateless, so there's no reason to create more than one of each.
*/
transient volatile Set<K> keySet = null;
transient volatile Collection<V> values = null;
...
}
There might be other similar instance in the JDK that could be fixed at the same time.
- backported by
-
JDK-8040198 AbstractMap unnecessarily initializes two volatiles to null
-
- Resolved
-
-
-
- Resolved
-
-
-
- Resolved
-
- relates to
-
-
- Open
-
-
-
- Resolved
-