Iterator

Iterator is a universal iterator as we can apply it to any Collection object. By using Iterator, we can perform both read and remove operations. It is improved version of Enumeration with additional functionality of remove-ability of a element.

Iterator object can be created by calling iterator() method present in Collection interface.

Iterator has four method for traversal. hasNext(), next(), remove() and forEachRemainin()
ListIterator is only applicable for List collection implemented classes like arraylist, linkedlist etc. It provides bi-directional iteration.

ListIterator must be used when we want to enumerate elements of List. This cursor has more functionality(methods) than iterator.

ListIterator object can be created by calling listIterator() method present in List interface.
ListIterator has six additional methods for traversal. hasPrevious(). previous(), add(E e), nextIndex(), previousIndex() and set(E e)

Fail-Fast Iterators

Fail-Fast systems abort operation as-fast-as-possible exposing failures immediately and stopping the whole operation.

Fail-fast iterators in Java don’t play along when the underlying collection gets modified.

• Collections maintain an internal counter called modCount. Each time an item is added or removed from the Collection, this counter gets incremented.
• When iterating, on each next() call, the current value of modCount gets compared with the initial value. If there’s a mismatch, it throws ConcurrentModificationException which aborts the entire operation.
• Default iterators for Collections from java.util package such as ArrayList, HashMap, etc. are Fail-Fast.

The Fail-Fast behavior isn’t guaranteed to happen in all scenarios as it’s impossible to predict behavior in case of concurrent modifications. These iterators throw ConcurrentModificationException on a best effort basis.

If during iteration over a Collection, an item is removed using Iterator‘s remove() method, that’s entirely safe and doesn’t throw an exception.However, if the Collection‘s remove() method is used for removing an element, it throws an exception.

Please see demonstration of fail fast iterator on below github link
https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/collections/iterator/example1

Lets consider an example of using an Iterator over an ArrayList

1. The ArrayList extends a class known as a AbstractList and it also implements List
2. The AbstractList contains in itself a protected transient int variable named modCount
3. As we add and remove elements, this variable is accordingly updated
4. When we call the iterator() on the ArrayList, it internally creates an instance of a Subclass Itr (implementation of Iterator and an inner class to AbstractList) which stores the value of modCount (at that point when iterator() was called) in a local Variable named expectedModCount
5. So the iterator before performing any action, compares the expectedModCount to the ModCount and accordingly actions  

Fail-Safe Iterators

These iterators create a clone of the actual Collection and iterate over it. If any modification happens after the iterator is created, the copy still remains untouched. Hence, these Iterators continue looping over the Collection even if it’s modified.

However, it’s important to remember that there’s no such thing as a truly Fail-Safe iterator. The correct term is Weakly Consistent.

That means, if a Collection is modified while being iterated over, what the Iterator sees is weakly guaranteed. This behavior may be different for different Collections and is documented in Javadocs of each such Collection.

The Fail-Safe Iterators have a few disadvantages, though:

1. One disadvantage is that the Iterator isn’t guaranteed to return updated data from the Collection, as it’s working on the clone instead of the actual Collection.
2. Another disadvantage is the overhead of creating a copy of the Collection, both regarding time and memory.

Iterators on Collections from java.util.concurrent package such as ConcurrentHashMap, CopyOnWriteArrayList, etc. are Fail-Safe in nature.

Please see demonstration of fail safe iterator on below github link

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/collections/iterator/example2

Lets consider an example of CopyOnWriteArrayList

1. The CopyOnWriteArrayList does not extend the AbstractList but directly implements List
2. When the iterator() method on this collection is called, it created a new instance of an COWIterator (inner class to CopyOnWriteArrayList and implementation of ListIterator) and stores a copy (snapshot at that point of time) of the underlying array i.e. Object[] array which the ArrayList uses internally to store the elements
3. Then all operations of the iterator are performed on this snapshot and not on the actual collection 

Comparable and Comparator

Comparable

Comparable implementations provide a natural ordering for a class, which allows objects of that class to be sorted automatically. 

While sorting Collections, the Collection Framework gives us an algorithm which does the natural sorting for us.

Collections.sort(l);

Lets say if we have a Collection<Name> list = new ArrayList<>() and Name does not implement Comparable, then Collections.sort(list) will throw a ClassCastException.

The sort() method provided by the Collections class is to be only used when the elements of the collection can be compared

Writing Your Own Comparable Types

The Comparable interface consists of the following method.

public interface Comparable<T> {
    public int compareTo(T o);
}

The compareTo method compares the receiving object with the specified object and returns a negative integer, 0, or a positive integer depending on whether the receiving object is less than, equal to, or greater than the specified object. If the specified object cannot be compared to the receiving object, the method throws a ClassCastException.

Points to remember when we are implementing Comparable - this will make lives easier for a developer

1. Try and make sure the Class is Immutable
2. Make sure the Constructor is checking on NPE - throw NPE sooner the better
3. Override hashcode and equals - to make sure the contract is in place
4. Override toString so that the object is printed in human readable form

Refer to this github link for demonstration
https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/collections/comparable/example1

Using Comparable interface, we can sort the elements of:

1. String objects
2. Wrapper class objects, for example Integer, Long etc
3. User defined custom objects (Preferably Immutable objects)

To reverse the order of sorting, you can the method provided by the Collections class - reverseOrder(); This utility method returns a Comparator that imposes the reverse of the natural ordering on a collection of objects that implement the Comparable interface.

What if you want to sort some objects in an order other than their natural ordering? Or what if you want to sort some objects that don't implement Comparable and you dont have access to its source code?

Comparator

To do either of the above things, you'll need to provide a Comparator — an object that encapsulates an ordering. Like the Comparable interface, the Comparator interface consists of a single method.

public interface Comparator<T> {
    int compare(T o1, T o2);
}

The compare method compares its two arguments, returning a negative integer, 0, or a positive integer depending on whether the first argument is less than, equal to, or greater than the second. If either of the arguments has an inappropriate type for the Comparator, the compare method throws a ClassCastException.

Much of what was said about Comparable applies to Comparator as well. Writing a compare method is nearly identical to writing a compareTo method, except that the former gets both objects passed in as arguments. The compare method has to obey the same four technical restrictions as Comparable's compareTo method for the same reason — a Comparator must induce a total order on the objects it compares.

Please have a look at the example demonstrated on the below github link

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/collections/comparator/example1

 Comparator Vs Comparable

The Comparable interface is a good choice when used for defining the default ordering or, in other words, if it’s the main way of comparing objects.

Then, we must ask ourselves why use a Comparator if we already have Comparable?

There are several reasons why:

Sometimes, we can’t modify the source code of the class whose objects we want to sort, thus making the use of Comparable impossible
Using Comparators allows us to avoid adding additional code to our domain classes
We can define multiple different comparison strategies which isn’t possible when using Comparable

Cloneable

Cloning is a process of creating an exact copy of an existing object in the memory. 

In java,clone() method of java.lang.Object class is used for cloning process. This method creates an exact copy of an object on which it is called through field-by-field assignment and returns the reference of that object. 

Not all the objects in java are eligible for cloning process. The objects which implement Cloneable interface are only eligible for cloning process. Cloneable interface is a marker interface which is used to provide the marker to cloning process.

Shallow Copy vs Deep Copy

It’s very simple that if the object has only primitive fields or Immutable fields, then obviously you will go for shallow copy but if the object has references to other objects, then based on the requirement shallow copy or deep copy should be chosen. What I mean here is, if the references are not modified anytime, and then there is no point in going for deep copy. You can just opt shallow copy. But if the references are modified often, then you need to go for deep copy. Again there is no hard and fast rule; it all depends on the requirement.

Shallow Copy

Whenever we use default implementation of clone method we get shallow copy of object means it create new instance and copy all the field of object to that new instance and return it as object type we need to explicitly cast it back to our original object. This is shallow copy of the object. clone() method of the object class support shallow copy of the object. If the object contains primitive as well as non-primitive or reference type variable In  shallow copy, the cloned object also refers to the same object to which the original object refers as only the object references gets copied and not the referred objects themselves. That's why the name shallow copy or shallow cloning in Java. If only primitive type fields or Immutable objects are there then there is no difference between shallow and deep copy in Java.

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/cloneable/example1

Deep Copy

Whenever we need our own meaning of a copy and don't use default implementation we call it as deep copy, whenever we need deep copy of the object we need to implement it according to our need. So for deep copy we need to ensure all the member class also implement the Cloneable interface and override the clone() method of the object class. After that we override the clone() method in all those classes even in the classes where we have only primitive type members otherwise we would not be able to call the protected clone() method of Object class on the instances of those classes inside some other class. It’s typical restriction of the protected access. 

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/cloneable/example2

How to implement Deep Copy?

The first and foremost way is already mentioned in the above github link. There are a couple of drawbacks of using this approach

1. Every Reference class needs to implement Cloneable and override the clone method
2. What if the class has final fields (they are only initialized through Constructor) and clone does not call the constructor
3. If a class is implementing Clonebale, then all its superclasses also need to define the clone method or inherit it form their parents, else super.clone() will fail

If you dont want to go this route then there are two ways on you can create a Deep Copy

1. Creating your own implementation
2. Using an external Library

Creating your own Implementation

1. Serialization
   We can serialize the object and then deserialize it, this would give us the copy of the original object, but this also has drawbacks
1. still need to implement Serializable
2. Wont be able to modify final fields
3. Serialization process is slower than cloning
   
   https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/cloneable/example4
2. Copy Constuctor
   This overcomes every design issue that comes with calling the clone method.Here we dont even need to implement any interface
   
   https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/cloneable/example3

Using an external Library

We can also opt for external libraries like below

• BeanUtils.cloneBean(object) - this creates a shallow clone similar to Object.clone()
• SerializationUtils.clone(object) - this created a deep clone; but all classes need to implement Serializable
  
  https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/cloneable/example5

Serialization

To Serialize an object means, to convert its state to a byte stream (which can be moved over a network, persisted on a file drive, persisted in a Data base) so that the byte stream can be reverted back into a copy of the object. A Java object is Serializable  if its class or any of its superclasses implements the Serializable interface or its subinterface i.e. the Externalizable.

Classes that do not implement this interface will not have any of their state serialized or deserialized. All subtypes of a serializable class are themselves serializable. 

The serialization interface has no methods or fields and serves only to identify the semantics of being serializable.

The default serialization mechanism for an object writes 

• the class of the object
• the class signature
• the values of all non-transient and non-static fields - this includes references to other objects (except in transient or static fields) to be written also (only if they are implementing Serializable interface or its subinterface)

Multiple references to a single object are encoded using a reference sharing mechanism so that graphs of objects can be restored to the same shape as when the original was written. 

Deserialization is the process of converting the serialized form of an object back into a copy of the object.

 What if a class implements Serializable but it's parent class does not?

• To allow subtypes of non-serializable classes to be serialized, the subtype may assume responsibility for saving and restoring the state of the supertype's public, protected, and (if accessible) package fields. The subtype may assume this responsibility only if the class it extends has an accessible no-arg constructor to initialize the class's state. It is an error to declare a class Serializable if this is not the case. The error will be detected at runtime.
• During deserialization, the fields of non-serializable classes will be initialized using the public or protected no-arg constructor of the class. A no-arg constructor must be accessible to the subclass that is serializable. The fields of serializable subclasses will be restored from the stream.

NOTE: When traversing a graph, an object may be encountered that does not support the Serializable interface. In this case the NotSerializableException will be thrown and will identify the class of the non-serializable object.

When an object is serialized, information that identifies its class is recorded in the serialized stream. However, the class's definition ("class file") itself is not recorded. It is the responsibility of the system that is deserializing the object to determine how to locate and load the necessary class files. 

What if I want don't want Java to handle Serialization?

The Java platform specifies a default way by which serializable objects are serialized. A (Java) class can override this default serialization and define its own way of serializing objects of that class. The Object Serialization Specification describes object serialization in detail.

Classes that require special handling during the serialization and deserialization process must implement special methods with these exact signatures: 

• private void readObject(java.io.ObjectInputStream stream) throws IOException, ClassNotFoundException {}
• private void writeObject(java.io.ObjectOutputStream stream) throws IOException {}
• private void readObjectNoData() throws ObjectStreamException {}

DataOutput Interface

The DataOutput interface provides for converting data from any of the Java primitive types to a series of bytes and writing these bytes to a binary stream. There is also a facility for converting a String into modified UTF-8 format and writing the resulting series of bytes.

For all the methods in this interface that write bytes, it is generally true that if a byte cannot be written for any reason, an IOException is thrown.

There is something known as serialVersionUID; What is it? When to use it? How to use it?

The serialization runtime associates with each serializable class a version number, called a serialVersionUID, which is used during deserialization to verify that the sender and receiver of a serialized object have loaded classes for that object that are compatible with respect to serialization. If the receiver has loaded a class for the object that has a different serialVersionUID than that of the corresponding sender's class, then deserialization will result in an InvalidClassException. A serializable class can declare its own serialVersionUID explicitly by declaring a field named "serialVersionUID" that must be static, final, and of type long:

 ANY-ACCESS-MODIFIER static final long serialVersionUID = 42L;

If a serializable class does not explicitly declare a serialVersionUID, then the serialization runtime will calculate a default serialVersionUID value for that class based on various aspects of the class, as described in the Java(TM) Object Serialization Specification. However, it is strongly recommended that all serializable classes explicitly declare serialVersionUID values, since the default serialVersionUID computation is highly sensitive to class details that may vary depending on compiler implementations, and can thus result in unexpected InvalidClassExceptions during deserialization. Therefore, to guarantee a consistent serialVersionUID value across different java compiler implementations, a serializable class must declare an explicit serialVersionUID value. It is also strongly advised that explicit serialVersionUID declarations use the private modifier where possible, since such declarations apply only to the immediately declaring class--serialVersionUID fields are not useful as inherited members. Array classes cannot declare an explicit serialVersionUID, so they always have the default computed value, but the requirement for matching serialVersionUID values is waived for array classes.

Examples demonstrating all the concepts of Serialization have been commited the below githib repo

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/serialization

Enumerations

Enums

• An enum type is a special data type that enables for a variable to be a set of predefined constants
• Enums should be used any time one needs to represent a fixed set of constants.

More Info on Enums

• The enum declaration defines a class (called an enum type). The enum class body can include methods and other fields. The compiler automatically adds some special methods when it creates an enum. For example, they have a static values method that returns an array containing all of the values of the enum in the order they are declared.
  
  
• All enums implicitly extend java.lang.Enum. Because a class can only extend one, the Java language does not support multiple inheritance of state, and therefore an enum cannot extend anything else.
  
• The constructor for an enum type must be package-private or private access. It automatically creates the constants that are defined at the beginning of the enum body. You cannot invoke an enum constructor yourself.

Why Enumerations?

1. Way of naming things – It’s real easy to identify things. We do not need to use a collection to store data.
2. Type Safe – We can’t compare to a wrong type. Which can happen with Strings.
3. Limits Input – if we could restrict the input coming into the method, things can become quite easier.
4. Groups things into a Set
5. Iterable - if utilized properly, then unnecessary if conditions and switch cases can be avoided

When to use Enumeration?

1. As much as possible
2. Anytime constraining input is beneficial
3. In place of string constants
4. In place of integers used as types – for eg month. Using integers to identify months. Can be easily done if we store them as enums

Enumerations Are Classes

Enums are full functional classes

• It gives us a values method
• Constructor – every enum has a default constructor, but we can add parameterized constructors
• Members
• Use it as a Singleton
• Use it as a Factory

I have demonstrated the below concepts on my github repo

1. Usage of basic Enum
2. Using Enum as a Singleton
3. Using Enum as a Factory

The link to the github repo is below

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/enumerations

Overloading and Overriding

Overloading

• Method overloading is always enforced at Compile time
  
• Overloading has nothing to do with Polymorphism but, it being enforced at compile time, makes it quite much similar to what static polymorphism achieves.

Method Overloading Rules

Method overloading comes with some rules, some being mandatory and some being optional.

Two or more methods are said to be Overloaded if they follow the below MANDATORY rules

1. They must have the same method name
2. They must have different arguments - this can either be
• Different type of arguments
• Different number of arguments
• Combination of both

And if both mandatory rules are applied on the methods, then they may or may not

1. Have different return types
2. Have different access modifiers
3. Throw different types of checked and unchecked exceptions

Method overloading also works with inheritance. If the parent class has a method and the child class also has a method following the two mandatory rules, then these two methods are said to be overloaded as the child class by default inherits all the methods from the parent class (till they are not overridden); the parent class methods are invisible but yes they do exist.

For examples for Overloading, please refer to the below github link

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/overloading/example1

Method Overloading with Autoboxing and Widening

There are two types of parameters that a method can take

• Primitive data types
• Wrapper data types - Also referred to Reference types

In case of method overloading, the compiler searches for the method with the same data type(s)

• in case the same primitive data type is not found in any method definition, then it moves to the next wider primitive data type
• if we are using a Wrapper data type and the compiler is not able to find it, then it will start searching a method having corresponding primitive data type - if that is also not found, then it will look for a wider primitive data type (it will not go next wider Wrapper data type)
• If we are using a Wrapper data type and the compiler is not able to find it, then if a method exists with a data type of its parent class, then it will not go for corresponding primitive data type method, rather it will go with the method with the Parent data type 

Examples for all above scenarios will be found on the below link on github

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/overloading/autoboxing/widening

Overriding

• When we extend a class, by default all the methods which are visible to the child class are automatically/by default visible to child class. Such methods are referred to as Derived methods.
  Now if the child class does not want to use any specific behavior of the parent class, it can simply define that method by its own (making sure that the method signature remains intact) and give its own behavior. This is known as overriding.
  
• Method overriding is referred to as dynamic polymorphism, as the JVM decides at runtime what behavior is to be called for - this is a concept known as Realization at runtime.

Method Overriding Rules

Similar to overloading, overriding also comes with some rules.

The overriding method must follow the below MANDATORY rules

1. Should have the same method name
2. Should have the same argument list
3. Should have the same return type - but starting Java 5, the return type can also be a subclass
4. Must not have a more restrictive access modifier -> if parent has the return type as protected, then the child cannot have private
5. Must not throw a new or broader checked exception

And if the overriding method is following all the above rules

1. It can have a less restrictive access modifier
2. Can throw a narrower checked exception

For overriding examples, please refer to below github link

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/polymorphism/example1

Polymorphism

Polymorphism - Many forms

There are two components of Polymorphism

1. code is dependent on an interface/parent class
2. behavior of code is determined at runtime by the actual class implementing that interface/parent class

Hence, we can define polymorphism as - the ability, at run time or dynamically, for that code to be able to call whatever method is implemented by the class that inherits from the base class.

The point of polymorphism is that you can subclass a class and the objects implementing those subclasses will have different behaviors for the same methods defined in the superclass (and overridden in the subclasses). 

As overriding depends on having an instance of a class, a static method is not associated with any instance of a class - so the concept is not applicable for static methods.

Polymorphism is categorized in two forms

1. static polymorphism - Enforced at compile time; eg method overloading, operator overloading
2. dynamic polymorphism - Realization done at runtime; eg method overriding, concept of variable hiding

How Polymorphism works

• This occurs in classes which have an Is-A relationship, where the subclass overrides the behavior of the parent class and at runtime, the JVM dynamically changes the behavior
  
• Dynamic polymorphism is exhibited only in the objects behavior i.e. the methods, and NOT on the 
• state of the object
• behavior of the class
  
• If we define a member variable again in the subclass, then it would not be overriding the value from the parent, this phenomenon is referred to as hiding. The subclass will have access to both the variables (will have two variables with same name), but depends on how it would be accessed and it would be enforced at compile time rather than runtime. 

The above concepts have been demonstrated at below link.

https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/polymorphism/example1

ThreadLocal

What is ThreadLocal<T> ?

• This class provides thread-local variables
• Each thread has its own, independently initialized copy of the variable - unlike other variables defined in the class 
• These variables can be accessed either by their get or set method
• ThreadLocal instances are typically private static fields in classes that wish to associate state with a thread (e.g., a user ID or Transaction ID)

Syntax

ThreadLocal<T> threadLocalValue = new ThreadLocal<>();




How to use ThreadLocal<T> ?

ThreadLocal provides us with four methods

1. initialValue
   
• accessibility - protected
• return Type - T
  If the thread local variable has been initialized as an Integer
  ThreadLocal<Integer> threadLocalValue = new ThreadLocal<>(); Then the return type would be Integer
• No parameters
• Usage
• if a programmer wants to set an initial value (at the time of the object being initialized) this method would need to be overriden (by default it returns null)
• This method is at most called once
• either at time of initialization
• when the get method is called the first time, it internally calls this method to fetch the value (might be returned as null - the default value)
• if the set method is invoked, then the method initialValue will not be called

• 
  private static final AtomicInteger nextId = new AtomicInteger(0);
  private static final ThreadLocal<Integer> threadId =
      new ThreadLocal<Integer>() {
          @Override protected Integer initialValue() {
              return nextId.getAndIncrement();
      }
  };
  
  

• Alternate way to initialize the default value is by calling the static method withInitial - this takes input a Supplier to determine its initialValue
  
  

  private static final AtomicInteger nextId = new AtomicInteger(0);

  
  

  private static final ThreadLocal<Integer> threadId =
          ThreadLocal.withInitial(() -> nextId.getAndIncrement());
  
  
  

2.  get
   
• accessibility - public
• return Type - T - similar to intialValue
• No parameters
• Usage
• it returns the value of the current threads thread local variable
• if no value has been set, then the method initialValue is invoked - which may either return the default value - null or the value set during initialization

• threadId.get();
  
  

3. set
   
• accessibility - public
• return Type - void
• One Parameter - type T
• Usage
• to set the value for the current threads thread local variable
• if we are setting a value by overriding the method initialValue, then we might not need this method to set the value, but depends on the use case at hand

• threadId.set(1);
  
  

4. remove
   
• accessibility - public
• return Type - void
• No parameter
• Usage
• removes the value of the current threads thread local variable
• if we try and get the value, then the method initialValue would be invoked to fetch the default value

• threadId.remove();

How ThreadLocal internally works

ThreadLocal internally uses a Map to (ThreadLocalMap) store

• Key - the threadLocal variable
• Value - the value associate to the threadLocal Variable

This threadlocalMap is encapsulated inside the ThreadLocal class and is not accessible outside of it

For working examples, please refer to the below github repository
https://github.com/omerhashmininjago/java-programs/tree/master/src/main/java/com/demonstrate/concepts/threadlocal