Hi All,
You might be thinking why I started writing the posts, related to the Java SE-6. This Idea came as part of my discussion with the friends. Because Java 9 is about to be released, but are we really using the features and implement effectively the answer is no. That's why I wanted to give the heads up at least we can keep in mind these are available.
When I jumped looked into this thought might be not that much bigger, on looking the release document found that's it's huge. In this post, I am going to quickly run through the changes happened in the Collections framework. While reading this document, came to know there are so much Which I need to concentrate on the basics. I will start writing those simpler basics for you and for my learning.I am adding some information I gathered in Java6 in collections frame work.
Let's try to Implement these in our daily coding.
These new collection interfaces are provided:
1.Deque a double ended queue, supporting element insertion and removal at both ends
This Deque can be used in our application, when you want to access the both the ends of the queus in the faster way, it has different methods that allows you to iterate without much effort. Unlike the List interface, this interface does not provide support for indexed access to elements.While Deque implementations are not strictly required to prohibit the insertion of null elements, they are strongly encouraged to do so. Users of any Deque implementations that do allow null elements are strongly encouraged not to take advantage of the ability to insert nulls. This is so because null is used as a special return value by various methods to indicated that the deque is empty.
When going through this API you will find confusing of difference between the add and offer.
1. Both are from different interfaces. add is from the collection, the offer is from the queue.
2. Add throws exception it is not able to add the element, where else the offer returns the false statement.
2.BlockingDeque
A Deque that additionally supports blocking operations that wait for the deque to become non-empty when retrieving an element, and wait for space to become available in the deque when storing an element.
3.NavigableSet<E>
A SortedSet extended with navigation methods reporting closest matches for given search targets. Methods lower, floor, ceiling, and higher return elements respectively less than, less than or equal, greater than or equal, and greater than a given element, returning null if there is no such element. A NavigableSet may be accessed and traversed in either ascending or descending order. The descendingSet method returns a view of the set with the senses of all relational and directional methods inverted. The performance of ascending operations and views is likely to be faster than that of descending ones.
4.NavigableMap<K,V>
A SortedMap extended with navigation methods returning the closest matches for given search targets. Methods lowerEntry, floorEntry, ceilingEntry, and higherEntry return Map.Entry objects associated with keys respectively less than, less than or equal, greater than or equal, and greater than a given key, returning null if there is no such key. Similarly, methods lowerKey, floorKey, ceilingKey, and higherKey return only the associated keys. All of these methods are designed for locating, not traversing entries.
A NavigableMap may be accessed and traversed in either ascending or descending key order. The descendingMap method returns a view of the map with the senses of all relational and directional methods inverted. The performance of ascending operations and views is likely to be faster than that of descending ones.
5.ConcurrentMap<K,V>
A Map providing additional atomic putIfAbsent, remove, and replace methods.
Memory consistency effects: As with other concurrent collections, actions in a thread prior to placing an object into a ConcurrentMap as a key or value happen-before actions subsequent to the access or removal of that object from the ConcurrentMap in another thread.
The following concrete implementation classes have been added:
1.ArrayDeque<E>
Resizable-array implementation of the Deque interface. Array deques have no capacity restrictions; they grow as necessary to support usage. They are not thread-safe; in the absence of external synchronization, they do not support concurrent access by multiple threads. Null elements are prohibited. This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue.
Most ArrayDeque operations run in amortized constant time. Exceptions include remove, removeFirstOccurrence, removeLastOccurrence, contains, iterator.remove(), and the bulk operations, all of which run in linear time.
2.ConcurrentSkipListSet<E>
A scalable concurrent NavigableSet implementation based on a ConcurrentSkipListMap. The elements of the set are kept sorted according to their natural ordering, or by a Comparator provided at set creation time, depending on which constructor is used.
3.ConcurrentSkipListMap<K,V>
A scalable concurrent ConcurrentNavigableMap implementation. The map is sorted according to the natural ordering of its keys, or by a Comparator provided at map creation time, depending on which constructor is used.
4.LinkedBlockingDeque<E>
An optionally-bounded blocking deque based on linked nodes.
The optional capacity bound constructor argument serves as a way to prevent excessive expansion. The capacity, if unspecified, is equal to Integer.MAX_VALUE. Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity.
5.AbstractMap.SimpleEntry<K,V>
An Entry maintaining a key and a value. The value may be changed using the setValue method. This class facilitates the process of building custom map implementations. For example, it may be convenient to return arrays of SimpleEntry instances in method Map.entrySet().toArray
6.AbstractMap.SimpleImmutableEntry<K,V>
An Entry maintaining an immutable key and value. This class does not support method setValue. This class may be convenient in methods that return thread-safe snapshots of key-value mappings.
These existing classes have been retrofitted to implement new interfaces:
1. LinkedList<E>
Linked list implementation of the List interface. Implements all optional list operations, and permits all elements (including null). In addition to implementing the List interface, the LinkedList class provides uniformly named methods to get, remove and insert an element at the beginning and end of the list. These operations allow linked lists to be used as a stack, queue, or double-ended queue.
The class implements the Deque interface, providing first-in-first-out queue operations for add, poll, along with other stack and deque operations.
2.TreeSet<E>
A NavigableSet implementation based on a TreeMap. The elements are ordered using their natural ordering, or by a Comparator provided at set creation time, depending on which constructor is used.
This implementation provides guaranteed log(n) time cost for the basic operations (add, remove and contains).
All of the operations perform as could be expected for a doubly-linked list. Operations that index into the list will traverse the list from the beginning or the end, whichever is closer to the specified index.
Most operations run in constant time (ignoring time spent blocking). Exceptions include remove, removeFirstOccurrence, removeLastOccurrence, contains, iterator.remove(), and the bulk operations, all of which run in linear time.
3.TreeMap<K,V>
A Red-Black tree based NavigableMap implementation. The map is sorted according to the natural ordering of its keys, or by a Comparator provided at map creation time, depending on which constructor is used.
Two new methods were added to the Collections utility class:
newSetFromMap(Map) - creates a general purpose Set implementation from a general purpose Map implementation.
There is no IdentityHashSet class, but instead, just use
Set<Object> identityHashSet=
Collections.newSetFromMap(
new IdentityHashMap<Object, Boolean>());
asLifoQueue(Deque) - returns a view of a Deque as a Last-in-first-out (Lifo) Queue.
Happy Learning !!!!! Keep watching for more basics .
You might be thinking why I started writing the posts, related to the Java SE-6. This Idea came as part of my discussion with the friends. Because Java 9 is about to be released, but are we really using the features and implement effectively the answer is no. That's why I wanted to give the heads up at least we can keep in mind these are available.
When I jumped looked into this thought might be not that much bigger, on looking the release document found that's it's huge. In this post, I am going to quickly run through the changes happened in the Collections framework. While reading this document, came to know there are so much Which I need to concentrate on the basics. I will start writing those simpler basics for you and for my learning.I am adding some information I gathered in Java6 in collections frame work.
Let's try to Implement these in our daily coding.
These new collection interfaces are provided:
1.Deque a double ended queue, supporting element insertion and removal at both ends
This Deque can be used in our application, when you want to access the both the ends of the queus in the faster way, it has different methods that allows you to iterate without much effort. Unlike the List interface, this interface does not provide support for indexed access to elements.While Deque implementations are not strictly required to prohibit the insertion of null elements, they are strongly encouraged to do so. Users of any Deque implementations that do allow null elements are strongly encouraged not to take advantage of the ability to insert nulls. This is so because null is used as a special return value by various methods to indicated that the deque is empty.
When going through this API you will find confusing of difference between the add and offer.
1. Both are from different interfaces. add is from the collection, the offer is from the queue.
2. Add throws exception it is not able to add the element, where else the offer returns the false statement.
2.BlockingDeque
A Deque that additionally supports blocking operations that wait for the deque to become non-empty when retrieving an element, and wait for space to become available in the deque when storing an element.
3.NavigableSet<E>
A SortedSet extended with navigation methods reporting closest matches for given search targets. Methods lower, floor, ceiling, and higher return elements respectively less than, less than or equal, greater than or equal, and greater than a given element, returning null if there is no such element. A NavigableSet may be accessed and traversed in either ascending or descending order. The descendingSet method returns a view of the set with the senses of all relational and directional methods inverted. The performance of ascending operations and views is likely to be faster than that of descending ones.
4.NavigableMap<K,V>
A SortedMap extended with navigation methods returning the closest matches for given search targets. Methods lowerEntry, floorEntry, ceilingEntry, and higherEntry return Map.Entry objects associated with keys respectively less than, less than or equal, greater than or equal, and greater than a given key, returning null if there is no such key. Similarly, methods lowerKey, floorKey, ceilingKey, and higherKey return only the associated keys. All of these methods are designed for locating, not traversing entries.
A NavigableMap may be accessed and traversed in either ascending or descending key order. The descendingMap method returns a view of the map with the senses of all relational and directional methods inverted. The performance of ascending operations and views is likely to be faster than that of descending ones.
5.ConcurrentMap<K,V>
A Map providing additional atomic putIfAbsent, remove, and replace methods.
Memory consistency effects: As with other concurrent collections, actions in a thread prior to placing an object into a ConcurrentMap as a key or value happen-before actions subsequent to the access or removal of that object from the ConcurrentMap in another thread.
The following concrete implementation classes have been added:
1.ArrayDeque<E>
Resizable-array implementation of the Deque interface. Array deques have no capacity restrictions; they grow as necessary to support usage. They are not thread-safe; in the absence of external synchronization, they do not support concurrent access by multiple threads. Null elements are prohibited. This class is likely to be faster than Stack when used as a stack, and faster than LinkedList when used as a queue.
Most ArrayDeque operations run in amortized constant time. Exceptions include remove, removeFirstOccurrence, removeLastOccurrence, contains, iterator.remove(), and the bulk operations, all of which run in linear time.
2.ConcurrentSkipListSet<E>
A scalable concurrent NavigableSet implementation based on a ConcurrentSkipListMap. The elements of the set are kept sorted according to their natural ordering, or by a Comparator provided at set creation time, depending on which constructor is used.
3.ConcurrentSkipListMap<K,V>
A scalable concurrent ConcurrentNavigableMap implementation. The map is sorted according to the natural ordering of its keys, or by a Comparator provided at map creation time, depending on which constructor is used.
4.LinkedBlockingDeque<E>
An optionally-bounded blocking deque based on linked nodes.
The optional capacity bound constructor argument serves as a way to prevent excessive expansion. The capacity, if unspecified, is equal to Integer.MAX_VALUE. Linked nodes are dynamically created upon each insertion unless this would bring the deque above capacity.
5.AbstractMap.SimpleEntry<K,V>
An Entry maintaining a key and a value. The value may be changed using the setValue method. This class facilitates the process of building custom map implementations. For example, it may be convenient to return arrays of SimpleEntry instances in method Map.entrySet().toArray
6.AbstractMap.SimpleImmutableEntry<K,V>
An Entry maintaining an immutable key and value. This class does not support method setValue. This class may be convenient in methods that return thread-safe snapshots of key-value mappings.
These existing classes have been retrofitted to implement new interfaces:
1. LinkedList<E>
Linked list implementation of the List interface. Implements all optional list operations, and permits all elements (including null). In addition to implementing the List interface, the LinkedList class provides uniformly named methods to get, remove and insert an element at the beginning and end of the list. These operations allow linked lists to be used as a stack, queue, or double-ended queue.
The class implements the Deque interface, providing first-in-first-out queue operations for add, poll, along with other stack and deque operations.
2.TreeSet<E>
A NavigableSet implementation based on a TreeMap. The elements are ordered using their natural ordering, or by a Comparator provided at set creation time, depending on which constructor is used.
This implementation provides guaranteed log(n) time cost for the basic operations (add, remove and contains).
All of the operations perform as could be expected for a doubly-linked list. Operations that index into the list will traverse the list from the beginning or the end, whichever is closer to the specified index.
Most operations run in constant time (ignoring time spent blocking). Exceptions include remove, removeFirstOccurrence, removeLastOccurrence, contains, iterator.remove(), and the bulk operations, all of which run in linear time.
3.TreeMap<K,V>
A Red-Black tree based NavigableMap implementation. The map is sorted according to the natural ordering of its keys, or by a Comparator provided at map creation time, depending on which constructor is used.
Two new methods were added to the Collections utility class:
newSetFromMap(Map) - creates a general purpose Set implementation from a general purpose Map implementation.
There is no IdentityHashSet class, but instead, just use
Set<Object> identityHashSet=
Collections.newSetFromMap(
new IdentityHashMap<Object, Boolean>());
asLifoQueue(Deque) - returns a view of a Deque as a Last-in-first-out (Lifo) Queue.
Happy Learning !!!!! Keep watching for more basics .
No comments:
Write comments