JDK-8165396 : remove dependency on AbstractList, AbstractCollection, AbstractMap
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Priority: P4
  • Status: Open
  • Resolution: Unresolved
  • Submitted: 2016-09-03
  • Updated: 2021-08-05
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
Other
tbdUnresolved
Related Reports
Relates :  
JDK-8272042 - java.util.ImmutableCollections$Map1 and MapN should not be @ValueBased
Description
The immutable lists are currently based on the AbstractList. This made bringup of the collection quick and easy. Unfortunately, this class includes a protected field modCount, which of course isn't used in the immutable collections. This takes up extra space in every instance. There are similar issues for Set and Map.

It would be nice to refactor things to avoid this. An alternative would be to have something like AbstractImmutableList etc. that had the algorithms but not the extra space. The mutator method implementations would also throw UOE unconditionally instead of deferring to mutators that might or might not be overridden in subclasses. This implementation could also be shared with dependent collections like subList(), entrySet(), etc. derived from immutable collections.
Comments
I've been aware of the risk of data races from cached stateless view objects for many years. Compare with view objects in JDK-8232642. They are technically data races in C++ but should be safe (only barely!) in Java due to Out Of Thin Air guarantees. I tend to agree that just returning a new view object every time is better with current hotspot implementation. But some bad user code surely has bugs where they assume that view objects are identical.
05-08-2021
Another issue is with the concept of being value-based. See JDK-8272042. AbstractMap contains these fields which cache instances of the key set and values collection after they're created the first time. (Hm, it also occurs to me that writing these fields can result in a data race; since the unmodifiable collections are intended to be thread-safe.) It's unclear whether caching these is useful. Since the key set and values collection are mostly just algorithms, for the unmodifiable collections they too can be value-based. It might be reasonable simply to create new instances for these each time keySet() or values() is called.
05-08-2021
Related work would remove the need for using iterators for a variety of bulk operations such as containsAll().
14-06-2021
It's probably reasonable to disconnect the Map implementations from AbstractMap, not for space reasons (though that does help in the case of Map1). A better reason is to avoid iterator-based algorithms in AbstractMap, whose keySet and values collections are based on AbstractSet and AbstractCollection. These delegate to the containing Map implementation for things like size() and contains(), but other methods use iterators. This is probably most useful for implementing optimized spliterators.
19-11-2020
The dependency on AbstractList was removed by JDK-8193128. There isn't really a problem depending on AbstractCollection. AbstractMap contains two fields to store cached keySet and values collections. It's unclear whether it's necessary to remove these.
22-05-2018