JDK-8159404 : throw UnsupportedOperationException unconditionally for mutator methods
  • Type: Sub-task
  • Component: core-libs
  • Sub-Component: java.util:collections
  • Priority: P3
  • Status: Resolved
  • Resolution: Fixed
  • Submitted: 2016-06-14
  • Updated: 2017-05-17
  • Resolved: 2016-09-06
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.
JDK 9
9 b136Fixed
Related Reports
Relates :  
JDK-8159527 - Collections mutator methods should all be marked as optional operations
Relates :  
JDK-8015656 - (coll) unexpected NPE from removeAll causes JavaFX 8 build failure
Relates :  
JDK-8165389 - adjust special-purpose collections to throw UOE unconditionally on calls to mutators
Relates :  
JDK-7042037 - Make NavigableSet's contract permit immutable implementations
Relates :  
JDK-4802647 - (coll) NullPointerException not thrown by AbstractCollection.retainAll/removeAll
Description
The current implementations allow calling mutator methods if they don't actually perform any mutation. For example, Collection.removeIf(), addAll(), removeAll(), and Map.computeIfAbsent() are all no-ops if they are called with arguments that end up not actually attempting any mutation. Cases include removeIf() with a predicate that's never true for any contents, addAll() and removeAll() with an empty collection, and computeIfAbsent() in a variety of cases that end up being no-ops.

Permitting these edge cases to succeed is probably permitted by the specification, but it potentially makes calling code more brittle, since it can throw exceptions unexpectedly if input changes. It would probably be better to "fail-fast" and throw UOE for any method whose intent is to mutate, even if no actual mutation would be attempted.

See also JDK-8015656 and JDK-4802647.

The specification for immutable List, Map, and Set should be changed to require this behavior.
Comments
Defer to JDK 10: Rationale: Lack of resources: Unraveling the ramifications of this spec change will take some time and it is late in the release cycle to work them out. The existing implementations are mature and reasonably stable. Workaround: Current behavior is ok, exceptions are expected Release Note: No existing behavior is maintained
04-08-2016
An related cleanup (to be handled separately from this bug) is to audit the various collection interfaces (Collection, List, Set, Map, SortedSet, SortedMap, NavigableSet, NavigableMap) to ensure that all mutator methods are marked as optional. Most of them already are, but the newer methods, particularly default methods added in Java 8, are not. This is covered by JDK-8159527.
17-06-2016