Utilities in the Collections class

The collections class contains a number of other useful utilities (such as Table II):

Enumeration (Collection) produces the original style enumeration (enum) for the argument
Max (Collection), Min (Collection) produces the largest or smallest element in a natural comparison of objects within a set in an argument
Max (Collection,comparator), Min (collection,comparator) produces the largest or smallest element in a set with a comparer
ncopies (int n, Object o) returns an immutable list of length n, with all its handles pointing to O
Sublist (list,int min,int max) Returns a new list that is pushed back by the specified argument list. This list can be imagined as a "window" that starts at the point where the index is min, and ends in front of Max.

Enumeration (Collection)	Produces an Old-style enumeration for the argument.
Max (Collection) Min (Collection)	Produces the maximum or minimum element in the argument using the natural comparison method of the objects Ection.
Max (Collection, Comparator) Min (Collection, Comparator)	Produces the maximum or minimum element in the Collection using the Comparator.
ncopies (int n, Object o)	Returns an immutable List of size N whose handles all o.
Sublist (List, int min, int max)	Returns a new list backed by the specified argument list This is a Windows into this argument with Indexe s starting at min and stopping just before Max.

Table Two

Note that min () and Max () work with the collection object rather than with the list, so you don't have to worry about whether collection needs to be sorted (as noted earlier in the execution of a binarysearch ()- Binary search--before you must perform sort () on a list or an array.

1. Make collection or map immutable
Generally, it is more advantageous to create a "read Only" version of collection or map. The collections class allows us to achieve this goal by passing the original container into a method and returning it to a read-only version. There are four different forms of this method for collection (if you do not want to treat the collection as a more specific type), List, set, and map. The following example demonstrates the correct way to build a read-only version for them:
 

//: Readonly.java//Using The collections.unmodifiable methods package c08.newcollections; import java.util.*;
    public class ReadOnly {public static void main (string[] args) {Collection c = new ArrayList (); Collection1.fill (c);
    Insert useful Data C = collections.unmodifiablecollection (c); Collection1.print (c); Reading is OK//! C.add ("one");
    Can ' t change it List a = new ArrayList ();
    Collection1.fill (a);
    A = Collections.unmodifiablelist (a);
    Listiterator lit = A.listiterator (); System.out.println (Lit.next ()); Reading OK//! Lit.add ("one");
    Can ' t change it Set s = new HashSet ();
    Collection1.fill (s);
    s = Collections.unmodifiableset (s); Collection1.print (s); Reading OK//! S.add ("one");
    Can ' t change it Map m = new HashMap ();
    Map1.fill (M, map1.testdata1);
    m = Collections.unmodifiablemap (m); Map1.print (m); Reading OK//!
  M.put ("Ralph", "howdy!"); }
} ///:~

For each case, you must populate the container with valid data before you can formally change it to read-only. Once the load succeeds, the best practice is to replace the existing handle with a handle that is produced with a "cannot modify" call. This is an effective way to avoid changing the contents of the material without modification. On the other hand, the tool also allows us to keep the containers that can be modified in a class private, and to return a read-only handle to that container from a method call. This way, although we can modify it in the class, anyone else can read it.
Invoking the "not modified" method for a specific type does not result in a compile-time check, but once any change occurs, a unsupportedoperationexception violation is generated for the invocation of a method that modifies a particular container.

2. Synchronization of collection or map
The Synchronized keyword is a very important part of the "multithreading" mechanism. We will not discuss this mechanism in depth until the 14th chapter. Here, you just need to note that the collections class provides a way to automatically synchronize the entire container. Its syntax is similar to the "non-modifiable" approach:

: Synchronization.java
//Using The collections.synchronized methods
package c08.newcollections;
Import java.util.*;

public class Synchronization {public
  static void Main (string[] args) {
    Collection c = 
      Collections.synchronizedcollection (
        new ArrayList ());
    List List = Collections.synchronizedlist (
      new ArrayList ());
    Set s = collections.synchronizedset (
      new HashSet ());
    Map m = collections.synchronizedmap (
      new HashMap ());
  }
}///:~

In this case, we pass the new container directly through the appropriate "sync" method, which avoids inadvertently exposing the unsynchronized version.
The new collection also provides a mechanism to prevent multiple processes from simultaneously modifying a container's content. If you are repeatedly in a container, and other processes intervene and insert, delete, or modify an object in that container, there is a risk of conflict. We may have passed that object, possibly in front of us, and the size of the container has shrunk since we called size ()-we are facing a variety of possible dangers. In response to this problem, the new collection library integrates a set of mechanisms to identify any other modifications to the container that are outside the responsibility of our process. If there are other aspects of detection that are also ready to modify the container, a concurrentmodificationexception (concurrent modification of the violation) is immediately generated. We call this mechanism "immediate failure"-it does not use more sophisticated algorithms to detect problems "later", but to "immediately" create violations.