Package java9.util

Provides a Java 8 backport of the JEP 269: Convenience Factory Methods for Collections that were introduced in Java 9.

See: Description

Class Summary

Class	Description
Lists	A place for the implementations of the new Java 9 static interface methods in the List interface specified in JEP 269 "Unmodifiable List Static Factory Methods".
Maps	A place for the implementations of the new Java 9 static interface methods in the Map interface specified in JEP 269 "Unmodifiable Map Static Factory Methods".
Objects	This class consists of static utility methods for operating on objects, or checking certain conditions before operation.
Sets	A place for the implementations of the new Java 9 static interface methods in the Set interface specified in JEP 269 "Unmodifiable Set Static Factory Methods".

Package java9.util Description

Provides a Java 8 backport of the JEP 269: Convenience Factory Methods for Collections that were introduced in Java 9.

Unmodifiable collections

An unmodifiable collection is a collection, all of whose mutator methods are specified to throw UnsupportedOperationException. Such a collection thus cannot be modified by calling any methods on it. For a collection to be properly unmodifiable, any view collections derived from it must also be unmodifiable. For example, if a List is unmodifiable, the List returned by List.subList is also unmodifiable.

An unmodifiable collection is not necessarily immutable. If the contained elements are mutable, the entire collection is clearly mutable, even though it might be unmodifiable. For example, consider two unmodifiable lists containing mutable elements. The result of calling list1.equals(list2) might differ from one call to the next if the elements had been mutated, even though both lists are unmodifiable. However, if an unmodifiable collection contains all immutable elements, it can be considered effectively immutable.

Value-based Classes

Some classes, such as java.util.Optional, are value-based. Instances of a value-based class:

• are final and immutable (though may contain references to mutable objects);
• have implementations of equals, hashCode, and toString which are computed solely from the instance's state and not from its identity or the state of any other object or variable;
• make no use of identity-sensitive operations such as reference equality (==) between instances, identity hash code of instances, or synchronization on an instances's intrinsic lock;
• are considered equal solely based on equals(), not based on reference equality (==);
• do not have accessible constructors, but are instead instantiated through factory methods which make no committment as to the identity of returned instances;
• are freely substitutable when equal, meaning that interchanging any two instances x and y that are equal according to equals() in any computation or method invocation should produce no visible change in behavior.

A program may produce unpredictable results if it attempts to distinguish two references to equal values of a value-based class, whether directly via reference equality or indirectly via an appeal to synchronization, identity hashing, serialization, or any other identity-sensitive mechanism. Use of such identity-sensitive operations on instances of value-based classes may have unpredictable effects and should be avoided.

Since:

9