> On 4 Dec 2015, at 01:58, Stuart Marks <[email protected]> wrote:
>
> Small refresh here: after some consultation with Brian Goetz and John Rose,
> I've updated the class doc text covers immutability and value-based. They now
> say,
>
> * They are structurally immutable. Elements cannot be added, removed, or
> replaced. Attempts to do so result in UnsupportedOperationException. However,
> if the contained elements are themselves mutable, this may cause the List's
> contents to appear to change.
>
> [and similar for Set and Map]
>
> * They are value-based. Callers should make no assumptions about the identity
> of the returned instances. Factories are free to create new instances or
> reuse existing ones. Therefore, identity-sensitive operations on these
> instances (reference equality (==), identity hash code, and synchronization)
> are unreliable and should be avoided.
>
> --
>
> I still need an official OpenJDK Reviewer.
>
+1
This is purely a suggestion, take it or leave it: you could use a static import
for Objects.requireNonNull, that makes the current code marginally easier on
the eyes (i know this area is likely to change).
List/Set/Map/MOAT
—
Update the license header date to 2015.
Map
—
1689 * The key and the value must not be null. Calling {@link
Entry#setValue Entry.setValue()}
s/null/{@code null}
Paul.
