Java Generics

Generics was added in Java 5 to provide compile-time type checking and removing risk of ClassCastException that was common while working with collection classes. The whole collection framework was re-written to use generics for type-safety. Let’s see how generics help us using collection classes safely.

In the heart of generics is “type safety“. What exactly is type safety? It’s just a guarantee by compiler that if correct Types are used in correct places then there should not be any ClassCastException in runtime. A usecase can be list of Integer i.e. List. If you declare a list in java like List, then java guarantees that it will detect and report you any attempt to insert any non-integer type into above list.
Another important term in java generics is “type erasure“. It essentially means that all the extra information added using generics into sourcecode will be removed from bytecode generated from it. Inside bytecode, it will be old java syntax which you will get if you don’t use generics at all. This necessarily helps in generating and executing code written prior java 5 when generics were not added in language.

Let’s understand with an example.

List list = new ArrayList();   list.add(1000);     //works fine   list.add("mukesh"); //compile time error;

When you write above code and compile it, you will get below error: “The method add(Integer) in the type List is not applicable for the arguments (String)“. Compiler warned you. This exactly is generics sole purpose i.e. Type Safety.

Second part is getting byte code after removing second line from above example. If you compare the bytecode of above example with/without generics, then there will not be any difference. Clearly compiler removed all generics information. So, above code is very much similar to below code without generics.

List list = new ArrayList();

 

list.add(1000);  


In generic code, the question mark (?), called the wildcard, represents an unknown type. A wildcard parameterized type is an instantiation of a generic type where at least one type argument is a wildcard. Examples of wildcard parameterized types are Collection, List, Comparator and Pair. The wildcard can be used in a variety of situations: as the type of a parameter, field, or local variable; sometimes as a return type (though it is better programming practice to be more specific). The wildcard is never used as a type argument for a generic method invocation, a generic class instance creation, or a supertype.
Having wild cards at difference places have different meanings as well. e.g.

• Collection denotes all instantiations of the Collection interface regardless of the type argument.
• List denotes all list types where the element type is a subtype of Number.
• Comparator denotes all instantiations of the Comparator interface for type argument types that are supertypes of String.

A wildcard parameterized type is not a concrete type that could appear in a new expression. It just hints the rule enforced by java generics that which types are valid in any particular scenario where wild cards have been used.
For example, below are valid declarations involving wild cards:

Collection coll = new ArrayList(); //OR Listextends Number> list = new ArrayList(); //OR Pair pair = new Pair();

And below are not valid uses of wildcards, and they will give compile time error.

Listextends Number> list = new ArrayList();  //String is not subclass of Number; so error //OR Comparatorsuper String> cmp = new RuleBasedCollator(new Integer(100)); //String is not superclass of Integer

Wildcards in generics can be unbounded as well as bounded. Let’s identify the difference in various terms.

Unbounded wildcard parameterized type

A generic type where all type arguments are the unbounded wildcard “?” without any restriction on type variables. e.g.

ArrayList  list = new ArrayList();  //or ArrayList  list = new ArrayList();  //or ArrayList  list = new ArrayList();

Bounded wildcard parameterized type

Bounded wildcards put some restrictions over possible types, you can use to instantiate a parametrized type. This restriction is enforced using keywords “super” and “extends”. To differentiate more clearly, let’s devide them into upper bounded wildcards and lower bounded wildcards.

Upper bounded wildcards

For example, say you want to write a method that works on List, List, and List; you can achieve this by using an upper bounded wildcard e.g. you would specify List. Here Integer, Double are subtypes of Number class. In layman’s terms, if you want generic expression to accept all subclasses of a particular type, you will use upper bound wildcard using “extends” keyword.

public class GenericsExample {    public static void main(String[] args)    {       //List of Integers       List ints = Arrays.asList(1,2,3,4,5);       System.out.println(sum(ints));               //List of Doubles       List doubles = Arrays.asList(1.5d,2d,3d);       System.out.println(sum(doubles));               List strings = Arrays.asList("1","2");       //This will give compilation error as :: The method sum(List) in the       //type GenericsExample is not applicable for the arguments (List)       System.out.println(sum(strings));            }         //Method will accept    private static Number sum (Listextends Number> numbers){       double s = 0.0;       for (Number n : numbers)          s += n.doubleValue();       return s;    } }

Lower bounded wildcards

If you want a generic expression to accept all types which are “super” type of a particular type OR parent class of a particular class then you will use lower bound wildcard for this purpose, using ‘super’ keyword.
In below given example, I have created three classes i.e. SuperClass, ChildClass and GrandChildClass. There relationship is shown in code below. Now, we have to create a method which somehow get a GrandChildClass information (e.g. from DB) and create an instance of it. And we want to store this new GrandChildClass in an already existing list of GrandChildClasses.
Here problem is that GrandChildClass is subtype of ChildClass and SuperClass as well. So any generic list of SuperClasses and ChildClasses is capable of holding GrandChildClasses as well. Here we must take help of lower bound wildcard using ‘super‘ keyword.

package test.core;   import java.util.ArrayList; import java.util.List;   public class GenericsExample {    public static void main(String[] args)    {       //List of grand children       List grandChildren = new ArrayList();       grandChildren.add(new GrandChildClass());       addGrandChildren(grandChildren);               //List of grand childs       List childs = new ArrayList();       childs.add(new GrandChildClass());       addGrandChildren(childs);               //List of grand supers       List supers = new ArrayList();       supers.add(new GrandChildClass());       addGrandChildren(supers);    }         public static void addGrandChildren(Listsuper GrandChildClass> grandChildren)    {       grandChildren.add(new GrandChildClass());       System.out.println(grandChildren);    } }   class SuperClass{      } class ChildClass extends SuperClass{      } class GrandChildClass extends ChildClass{      }

What is not allowed to do with Generics?

a) You can’t have static field of type
b) You can not create an instance of T
c) Generics are not compatible with primitives in declarations
d) You can’t create Generic exception class,

Abstract Class vs Interface

Abstract class

Abstract classes are created to capture common characteristics of subclasses. It can not be instantiated, it can be only used as super class by its subclasses. Abstract classes are used to create template  for its sub classes down the hierarchy. 

Abstract is object oriented. It offer the basic data an 'object' should have and/or functions it should be able to do. It concerns on the object's basic characteristic, what it has and what it can do. Hence objects which inherit the same abstract share the basic characteristics (generalization).

Interface

An interface is a collection of abstract methods. A class implements an interface, thereby inheriting the abstract methods of the interface. So it is kind of signing a contract, you agree that if you implement this interface, then you have to use its methods. It is just a pattern, it can not do anything itself. 

Interface is functionality oriented. It defines functionalities an object should have. Regardless what object it is, as long as it can do this and that (functionalities defined in interface), it's fine. It ignores any other things. An object/class can contain several (group of) functionalities, hence it is possible for a class to implement multiple interfaces.

 

When to use Abstract class and interface:

• If you have a lot of methods and want default implementation for some of them, then go with abstract class
• If you want to implement multiple inheritance then you have to use interface. As java does not support multiple inheritance, subclass can not extend more than one class but you can implement multiple interface so you can use interface for that.
• If your base contract keeps on changing, then you should use abstract class, as if you keep changing your base contract and use interface, then you have to change all the classes which implements that interface.

Semaphores in Java

 A Semaphore is a thread synchronization construct that can be used either to send signal  between threads to avoid missed signals, or to guard a critical section like you would with a lock. Java 5 comes with semaphore implementations in the java.util.concurrent package so you don't have to implement your own semaphores.
Still, it can be useful to know the theory behind their implementation and use.

Java 5 comes with a built-in Semaphore so you don't have to implement your own.   

Simple SemaphoreHere is a simple Semaphore implementation:

public class Semaphore {
  private boolean signal = false;

  public synchronized void take() {
    this.signal = true;
    this.notify();
  }

  public synchronized void release() throws InterruptedException{
    while(!this.signal) wait();
    this.signal = false;
  }

}

The take() method sends a signal which is stored internally in the Semaphore.
The release() method waits for a signal. When received the signal flag is cleared again and the release() method exited. 

Using a semaphore like this you can avoid missed signals. You will call take() instead of notify() and release() instead of wait(). If the call to take() happens before the call to release() the thread calling release() will still know that take() was called, because the signal is stored internally in the signal variable. This is not the case with wait() and notify().

The names take() and release() may seem a bit odd when using semaphore for signaling. The names origin from the use of semaphores as locks, as explained
  
Using Semaphores for Signaling

Semaphore semaphore = new Semaphore();
SendingThread sender = new SendingThread(semaphore);
ReceivingThread receiver = new ReceivingThread(semaphore);
receiver.start();
sender.start();

public class SendingThread {
Semaphore semaphore = null;

  public SendingThread(Semaphore semaphore){
    this.semaphore = semaphore;
  }

  public void run(){
    while(true){
      //do something, then signal
      this.semaphore.take();

    }
  }
}


public class RecevingThread {
Semaphore semaphore = null;

 public ReceivingThread(Semaphore semaphore){
 this.semaphore = semaphore;
  }

 public void run(){
 while(true){
 this.semaphore.release();
 //receive signal, then do something...
    }
  }
}

Counting Semaphore
The Semaphore implementation in the previous section does not count the number of signals sent to it by take() method calls. We can change the Semaphore to do so. This is called a counting semaphore.
Here is a simple implementation of a counting semaphore:


public class CountingSemaphore {
  private int signals = 0;

  public synchronized void take() {
    this.signals++;
    this.notify();
  }

  public synchronized void release() throws InterruptedException{
    while(this.signals == 0) wait();
    this.signals--;
  }

}


Bounded Semaphore
The CoutingSemaphore has no upper bound on how many signals it can store. We can change the semaphore implementation to have an upper bound, like this:

public class BoundedSemaphore {
  private int signals = 0;
  private int bound   = 0;

  public BoundedSemaphore(int upperBound){
    this.bound = upperBound;
  }

  public synchronized void take() throws InterruptedException{
    while(this.signals == bound) wait();
    this.signals++;
    this.notify();
  }

  public synchronized void release() throws InterruptedException{
    while(this.signals == 0) wait();
    this.signals--;
    this.notify();
  }
}

Notice how the take() method now blocks if the number of signals is equal to the upper bound. Not until a thread has called release() will the thread calling take() be allowed to deliver its signal, if the Bounded Semaphore has reached its upper signal limit.

Using Semaphores as Locks

 It is possible to use a bounded semaphore as a lock. To do so, set the upper bound to 1, and have the call to take() and release() guard the critical section. Here is an example:

BoundedSemaphore semaphore = new BoundedSemaphore(1);

...

semaphore.take();

try{
  //critical section
} finally {
  semaphore.release();
}

In contrast to the signaling use case the methods take() and release() are now called by the same thread. Since only one thread is allowed to take the semaphore, all other threads calling take() will be blocked until release() is called. The call to release() will never block since there has always been a call to take() first.

You can also use a bounded semaphore to limit the number of threads allowed into a section of code. For instance, in the example above, what would happen if you set the limit of the BoundedSemaphore to 5?

5 threads would be allowed to enter the critical section at a time. You would have to make sure though, that the thread operations do not conflict for these 5 threads, or you application will fail.

The relase() method is called from inside a finally-block to make sure it is called even if an exception is thrown from the critical section.

Read More 

Java 7 features
How to Reset Arraylist In Java
How HashMap Work in Java
Why wait (), notify () and notifyAll () must be called from synchronized block or method in Java
XPath to locate Information in XML
Internals of Garbage Collector
Reference Type in Java
Different Ways to Create ObjectClass Loaders in Java
Producer Consumer Problem
Why String is Final in Java
Singleton Class using Enum
JSON tutorial
Exceptional Handling in Java  

Race Condition in Java

A race condition is a special condition that may occur inside a critical section. A critical section is a section of code that is executed by multiple threads and where the sequence of execution for the threads makes a difference in the result of the concurrent execution of the critical section.

When the result of multiple threads executing a critical section may differ depending on the sequence in which the threads execute, the critical section is said to contain a race condition. The term race condition stems from the metaphor that the threads are racing through the critical section, and that the result of that race impacts the result of executing the critical section. 

Critical Sections

Running more than one thread inside the same application does not by itself cause problems. The problems arise when multiple threads access the same resources. For instance the same memory (variables, arrays, or objects), systems (databases, web services etc.) or files.
In fact, problems only arise if one or more of the threads write to these resources. It is safe to let multiple threads read the same resources, as long as the resources do not change.
Here is a critical section Java code example that may fail if executed by multiple threads simultaneously: 

 public class Counter {

     protected long count = 0;

     public void add(long value){
         this.count = this.count + value;
     }
  }

Imagine if two threads, A and B, are executing the add method on the same instance of the Counter class. There is no way to know when the operating system switches between the two threads. The code in the add() method is not executed as a single atomic instruction by the Java virtual machine. Rather it is executed as a set of smaller instructions, similar to this:

1. Read this.count from memory into register.
2. Add value to register.
3. Write register to memory.

Observe what happens with the following mixed execution of threads A and B: 

this.count = 0;

   A:  Reads this.count into a register (0)
   B:  Reads this.count into a register (0)
   B:  Adds value 2 to register
   B:  Writes register value (2) back to memory. this.count now equals 2
   A:  Adds value 3 to register
   A:  Writes register value (3) back to memory. this.count now equals 3

The two threads wanted to add the values 2 and 3 to the counter. Thus the value should have been 5 after the two threads complete execution. However, since the execution of the two threads is interleaved, the result ends up being different.
In the execution sequence example listed above, both threads read the value 0 from memory. Then they add their i ndividual values, 2 and 3, to the value, and write the result back to memory. Instead of 5, the value left in this.count will be the value written by the last thread to write its value. In the above case it is thread A, but it could as well have been thread B. 

Race Conditions in Critical Sections

The code in the add() method in the example earlier contains a critical section. When multiple threads execute this critical section, race conditions occur.
More formally, the situation where two threads compete for the same resource, where the sequence in which the resource is accessed is significant, is called race conditions. A code section that leads to race conditions is called a critical section.

Preventing Race Conditions

To prevent race conditions from occurring you must make sure that the critical section is executed as an atomic instruction. That means that once a single thread is executing it, no other threads can execute it until the first thread has left the critical section.
Race conditions can be avoided by proper thread synchronization in critical sections. Thread synchronization can be achieved using a synchronized block of Java code. Thread synchronization can also be achieved using other synchronization constructs like locks or atomic variables like java.util.concurrent.atomic.AtomicInteger

Critical Section Throughput

For smaller critical sections making the whole critical section a synchronized block may work. But, for larger critical sections it may be beneficial to break the critical section into smaller critical sections, to allow multiple threads to execute each a smaller critical section. This may decrease contention on the shared resource, and thus increase throughput of the total critical section.
Here is a very simplified Java code example to show what I mean: 

public class TwoSums {
    
    private int sum1 = 0;
    private int sum2 = 0;
    
    public void add(int val1, int val2){
        synchronized(this){
            this.sum1 += val1;   
            this.sum2 += val2;
        }
    }
}

Notice how the add() method adds values to two different sum member variables. To prevent race conditions the summing is executed inside a Java synchronized block. With this implementation only a single thread can ever execute the summing at the same time.
However, since the two sum variables are independent of each other, you could split their summing up into two separate synchronized blocks, like this: 

public class TwoSums {
    
    private int sum1 = 0;
    private int sum2 = 0;
    
    public void add(int val1, int val2){
        synchronized(this){
            this.sum1 += val1;   
        }
        synchronized(this){
            this.sum2 += val2;
        }
    }
}

Now two threads can execute the add() method at the same time. One thread inside the first synchronized block, and another thread inside the second synchronized block. This way threads will have to wait less for each other to execute the add() method.

Read More  Java 7 features How to Reset Arraylist In Java How HashMap Work in Java Why wait (), notify () and notifyAll () must be called from synchronized block or method in Java XPath to locate Information in XML Internals of Garbage Collector Reference Type in Java Different Ways to Create ObjectClass Loaders in Java Producer Consumer Problem Why String is Final in Java Singleton Class using Enum JSON tutorial Exceptional Handling in Java

How would you improve performance of a Java application?

Pool valuable system resources like threads, database connections, socket connections etc. Emphasize on reuse of threads from a pool of threads. Creating new threads and discarding them after use can adversely affect performance. Also consider using multi-threading in your single-threaded applications where possible to enhance performance. Optimize the pool sizes based on system and application specifications and requirements. Having too many threads in a pool also can result in performance and scalability problems due to consumption of memory stacks (i.e. each thread has its own stack. Refer Q34, Q42 in Java section) and CPU context switching (i.e. switching between threads as opposed to doing real computation.).

Minimize network overheads by retrieving several related items simultaneously in one remote invocation if possible. Remote method invocations involve a network round-trip, marshaling and unmarshaling of parameters, which can cause huge performance problems if the remote interface is poorly designed.

Most applications need to retrieve data from and save/update data into one or more databases. Database calls are remote calls over the network. In general data should be lazily loaded (i.e. load only when required as opposed to pre-loading from the database with a view that it can be used later) from a database to conserve memory but there are use cases (i.e. need to make several database calls) where eagerly loading data and caching can improve performance by minimizing network trips to the database. Data can be eagerly loaded with a help of SQL scripts with complex joins or stored procedures and cached using third party frameworks or building your own framework.

Now the Question arises How would you refresh your cache?
 Following strategies can be used:

1. Timed cache strategy where the cache can be replenished periodically (i.e. every 30 minutes, every hour etc). This is a simple strategy applicable when it is acceptable to show dirty data at times and also the data in the database does not change very frequently.

2. Dirty check strategy where your application is the only one which can mutate (i.e. modify) the data in the database. You can set a “isDirty” flag to true when the data is modified in the database through your application and consequently your cache can be refreshed based on the “isDirty” flag.

How would you refresh your cache if your database is shared by more than one application?
You could use one of the following strategies:

1. Database triggers: You could use database triggers to communicate between applications sharing the same database and write pollers which polls the database periodically to determine when the cache should be refreshed.

2. XML messaging :- To communicate between other applications sharing the same database or separate databases to determine when the cache should be refreshed.

Read More 

Java 7 features
How to Reset Arraylist In Java
How HashMap Work in Java
Why wait (), notify () and notifyAll () must be called from synchronized block or method in Java
XPath to locate Information in XML
Internals of Garbage Collector
Reference Type in Java
Different Ways to Create ObjectClass Loaders in Java
Producer Consumer Problem
Why String is Final in Java
Singleton Class using Enum
JSON tutorial
Exceptional Handling in Java