Details
-
Sub-task
-
Resolution: Fixed
-
P3
-
None
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 alsoJDK-8015656 and JDK-4802647.
The specification for immutable List, Map, and Set should be changed to require this behavior.
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
The specification for immutable List, Map, and Set should be changed to require this behavior.
Attachments
Issue Links
- relates to
-
JDK-8159527 Collections mutator methods should all be marked as optional operations
-
- Resolved
-
-
-
- Closed
-
-
-
- Closed
-
-
JDK-7042037 Make NavigableSet's contract permit immutable implementations
-
- Closed
-
-
-
- Closed
-