RFR: 8328821: Map.of() derived view collection mutators should throw UnsupportedOperationException [v9]

[Stuart Marks]

On Thu, 27 Feb 2025 19:43:34 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Update test/jdk/java/util/Collection/MOAT.java
>    
>    Co-authored-by: Chen Liang <liach at openjdk.org>
>  - Update copyright year
>    
>    and add the bug number to the modified test
>  - Update unmodifiable map javadoc
>  - Also throw UOE for mutators on keySet() and values()
>    
>    and add more test coverage to MOAT.
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - Check m.entrySet().hashCode() in MOAT
>  - Merge remote-tracking branch 'origin/master' into JDK-8328821-make-clear-consistent
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/25f63eb1...d83ca7f3

I've moved it from `25` to `tbd`. That means that it isn't committed to go into 25, but that also doesn't mean that it _won't_ go into 25. In practice I don't think makes much difference which release it goes in. I understand the sentiment of not wanting impact 25 because it's an LTS release. But there are regular bugfix updates for the LTS releases, so if this were integrated in 25 and if people did encounter problems with it, they could be fixed quickly. On the other hand, if it went into a non-LTS release, fewer people run those, so it might take a while for any hypothetical problem to actually surface.

Ideally, though, we'd generate some evidence that would give us some confidence that the change wouldn't likely cause problems, in which case we could put it into any release. I still intend to do some analysis at some point that will tell us one way or another. (Yes, we will reach that point eventually, though I'm sorry that it's taken so long!)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2691690170