What is VOLATILE in Java?

Java provides weaker form of synchronization called ‘volatile variable’ to ensure any update to variable is propagated to all other threads. Locking guarantees both visibility and atomicity but volatile only guarantees visibility.

The Visibility effect of volatile variables extends beyond the value of the volatile variable itself. When thread A writes to a volatile variable and subsequently thread B reads that same variable, the values of all variables that were visible to A prior to writing to volatile variable become visible to B after reading the volatile variable. So writing to a volatile variable works like entering into a synchronized block. However its not recommended to rely on volatile variables too heavily for visibility as it makes code more fragile and hard to understand.

Volatile variables are not thread safe for 64 bit operations as they are Non-atomic. Using volatile for 32 bit operations are fine but when you use it with 64 bit numeric variables, like double and long, JVM is permitted to divide 62 bit read or write operation into two 32 bit read or write operation. If read and writes are happening in two different threads its possible reader might read 32 bit updated value and 32 bit old value and overall unexpected dirty value as volatile doesn't guarantee atomicity. 

For atomic read-modify-write support Java provide 9 different flavors of Atomic Variables/References which can be used to overcome above problem.

New Features in Java 7 : multi catch and multi throws Exceptions

Java 7 Introduced 2 brilliant features for Exceptions which can help to remove lots of boilerplate code in your project.  These features are
1. Multi catch Exceptions
2. Multi throws Exceptions

Prior to Java 7 one catch block can handle only one exception.

public void method(){
        try {
            // Some code that can throw one of catch exceptions
        } catch (Exception1 e) {
            e.printStackTrace();
        } catch (Exception2 e) {
            e.printStackTrace();
        } catch (Exception3 e) {
            e.printStackTrace();
        }
  }

But sometimes you handle more than of these exception in similar way so you end up repeating same catch block code for all exception.
From Java 7 one catch block can handle multiple exceptions with the help of pipes. So the same code will become like:

public void method(){
        try {
            // Some code that can throw one of catch exceptions
        } catch (Exception1 e | Exception2 e | Exception3 e) {
            e.printStackTrace();
             // If required you can define your exception handler and hadle exceptions as per there type in          
              handler
        }
    }


Second nice feature is multiple exceptions in throws section as method signature. Consider if you have just one Exception catch block for re-throw but you want to throw different type of exceptions to give user more granular access to thrown exception, prior to Java 7 you can not do so.
For example in below Example lets say if you want to tell user what ll type of exception this method can throw you can not do. You can only put top exception in hierarchy throw from method into method signature:

public void method(int i ) throws Exception {  // Can not tell FirstException or SecondException
        try {
            if(i<0){
                throw new FirstException();
            } else {
                throw new SecondException();
            }
             
        } catch (Exception e) {
            throw e;
        }
 }

Earlier it was not allowed/possible to put FirstException and SecondException together in Throws section of method signature. But from Java 7 compile has started doing more inclusive type checking so you can do that now which makes your method signature much more clear:

public void method(int i ) throws FirstException, SecondException{
        try {
            if(i<0){
                throw new FirstException();
            } else {
                throw new SecondException();
            }
             
        } catch (Exception e) {
            throw e;
        }
 }

Serializing Child with Parent not Serializable

This is interesting to see when you serialize a child which has one of the parent not serializable, on deserialization constructor of that parent class gets called.

In Given example while deserialization constructor of GrandParent will be called.

Note: While deserialization it calls only the default constructor of such parent. If non-serializable parent lack default constructor it will throw exception for "no valid constructor".

class Grandparent {
// must need default constructor
    public Grandparent() {
        System.out.println("A");
    }
}

 class Parent extends Grandparent implements Serializable {
    public Parent() {
        System.out.println("B");
    }
}
 class Child extends Parent {
    public Child() {
        System.out.println("C");
    }
}


public class TestSerialization{
    public static void main(String args[]) throws IOException, ClassNotFoundException {
        System.out.println("Serialization ....");
        ObjectOutputStream out = new ObjectOutputStream( new FileOutputStream("/object"));
        out.writeObject(new Child());
        System.out.println("Now Deserialization ....");
        ObjectInputStream in = new ObjectInputStream( new FileInputStream("/object"));
        Object obj = in.readObject();
        System.out.print(obj + " -- " + obj.getClass());
    }
}

OUTPUT
----------


Serialization ....
A
B
C
Now Deserialization ....
A
co.uk.sample.Child@d2906a -- class co.uk.sample.Child

TestNG vs JUnit

Here are some features of TestNG which is not available in Junit

1. Method Dependency: In Junit execution of test methods is depends on order of string literals in method name. Its hard to maintain the ordering and its not visible if there is any dependency of one method on other method. On the Other hand in TestNG you can mention dependency using dependsOnMethods.

@Test ( dependsOnMethods = "testPreSettlement" )

public void testSettlement(){ ... }

In this case if first method fails, second method doesn't go in fail status but you will see it as skipped.

2. Parametric Testing (DDT): As data driven test framework TestNG  has feature of parametric testing where you can pass parameter to a test method using configuration. Junit needs more code to use this feature.

@testng.parameters value="param1, param2"

public void testSettlement(){ ... }

You can configure this in test suite file as below:

<!DOCTYPE suite SYSTEM "http://beust.com/testng/testng-1.0.dtd">

<suite name="settlement">

 <test name="testSettlement">

  <parameter name="param1" value="Admin"/>

  <parameter name="param2" value="2"/>

  <classes> 

   <class name="co.uk.SettlementTest"/>

  </classes>

 </test> 

</suite>

3. Ordering/Prioritiesing Test cases: In TestNG you can use Priority annotation to put ordering between test cases.

@Retention(java.lang.annotation.RetentionPolicy.RUNTIME)

@Target({ElementType.METHOD, ElementType.TYPE})

public @interface Priority { int value() default 0; }

For Example

@Priority(-1)

@Test

public void testSettlement(){ ... }

4. Grouping Tests and Repeatability:  In TestNg you can group tests, even configure number of times you want to execute particular test case. You can also set timeout for executing test method.

@Test(threadPoolSize = 4, invocationCount = 5,  timeOut = 10000, groups = { "functional"})

Sample Socket Connection Example

Telnet Server Implementation Code:

class TelnetServer {

   private final ServerSocket serverSocket = new ServerSocket(4444);

   public void start(){

      try {

            log.info("Starting server on port " + serverSocket.getLocalPort());

            System.out.println("Starting server on port " + serverSocket.getLocalPort());

            while (isRunning && serverSocket != null) {

                log.info("Waiting for client connection!");

                System.out.println("Waiting for client connection!");

                Socket socket = serverSocket.accept();

                log.info("Creating new telnet client connection");

                System.out.println("Creating new client connection");

                connManager.createConnection(socket);// Create a thread to handle socket 

            }

        }

   }

}

ConnectionHandler Implementation Code:

class ConnectionHandler implements Runnable{

private final Socket socket;

public ClientConnection(){

          socket = new Socket("localhost", 4444);

}

@Override

public void run()

 try {

            iStream = new DataInputStream(socket.getInputStream());

            oStream = new DataOutputStream(socket.getOutputStream());

            out = new PrintWriter(socket.getOutputStream(), true);

            cmdContext = CommandContext.createInstance(new File("."),                               

            socket.getLocalAddress().getHostName(), socket.getInetAddress().toString());

            cmdExecutor = new CommandExecutor();

            System.out.println(cmdContext);

            while ((line = iStream.readUTF()) != null && !line.equals(".")) {

                input = input + line;

                System.out.println("Command Received: " + line);

                out.print(input);

                oStream.writeUTF(getCommandResponse(cmdContext, cmdExecutor, line));

             }

         }

    }

}

*********************************************************

TelnetClient implementation :

public class TelnetClient {

    public static void main(String args[]) throws Exception {

        Socket soc = new Socket("localhost", 4444);

        String Command;

        DataInputStream din = new DataInputStream(soc.getInputStream());

        DataOutputStream dout = new DataOutputStream(soc.getOutputStream());

        BufferedReader br = new BufferedReader(new InputStreamReader(System.in));

        System.out.println("Welcome to Telnet Client");

        System.out.println("< Telnet Prompt >");

        while ((Command = br.readLine()) != null && !Command.equals(".")) {

            dout.writeUTF(Command);//sends command to server

            System.out.println(din.readUTF()); //gets the response of server

        }

        soc.close();

        din.close();

        dout.close();

        br.close();

    }

}

Serialize Array in Java

For Serializing Array we can use ObjectOutputStream/ObjectInputStream classes.

NOTE: An ObjectInputStream deserializes primitive data and objects previously written using an ObjectOutputStream.


public class SerializeArray {
    public static void main(String[] args) {

        String[][] twoD = new String[][]{new String[]{"Alex", "Hyde"},
                new String[]{"Rohan", "Disuza"}};

        String[][] newTwoD = null; // will deserialize to this

        System.out.println("Before serialization");
        for (String[] arr : twoD) {
            for (String val : arr) {
                System.out.println(val);
            }
        }

        try {
            FileOutputStream fos = new FileOutputStream("test.dat");
            ObjectOutputStream oos = new ObjectOutputStream(fos);
            oos.writeObject(twoD);

            FileInputStream fis = new FileInputStream("test.dat");
            ObjectInputStream iis = new ObjectInputStream(fis);
            newTwoD = (String[][]) iis.readObject();

        } catch (Exception e) {

        }

        System.out.println("After serialization");
        for (String[] arr : newTwoD) {
            for (String val : arr) {
                System.out.println(val);
            }
        }
    }
}

When finally block is NOT called?

Finally block is NOT called in following conditions

• If the JVM exits while the try or catch code is being executed, then the finally block may not execute. This may happen due to System.exit() call.
• if the thread executing the try or catch code is interrupted or killed, the finally block may not execute even though the application as a whole continues.
• If a exception is thrown in finally block and not handled then remaining code in finally block may not be executed.
• If there is infinite loop, or deadlock then also finally block will not get executed

Is Java Pass by Reference or Pass by Value?

Java always pass by value. It confuses when we pass an object reference in method call and method implementation changes objects attributes. When we see these changes after returning from method call it feels like java use pass by reference but its not true. Java uses pass by value and mthod try to change value it will not reflect after call. Changing value means re-initianciation . The first case is referenced values got mutated but it was still pass by value.

It goes like this:

public void foo(User user) {
  user.name.equals("Mayank"); // true
  user = new User("Mike");
  d.name.equals("Mike"); // true
}

User user1 = new User("Mayank");
foo(user1);
user1.name.equals("Mayank"); // still true

In this example user1.name will still be "Mayank". "user" is not overwritten in the function as the object reference is passed by value.

Likewise:

public void foo(USer user) {
  user.name.equals("Mayank"); // true
  user.setname("Mike");
}

User user1 = new Use("Mayank");
foo(user1);

user1.name.equals("Mayank"); // Not true anymore as name got mutated 

user1.name.equals("Mike"); // true

For further details please see this link
http://stackoverflow.com/questions/40480/is-java-pass-by-reference

String vs StringBuffer vs StringBuilder

The main difference between the three most commonly used String classes as follows.

• StringBuffer and StringBuilder objects are mutable whereas String class objects are immutable.
• StringBuffer class implementation is synchronized while StringBuilder class is not synchronized. 

Note: If you keep forgetting which one is synchronized which one is not remember StringBuilder is just implmentation of builder pattern so the other is Synchronized which is StringBuffer

• Concatenation operator "+" is internally implemented by Java using StringBuilder.

Note: For more details see this link

http://stackoverflow.com/questions/11408427/how-does-the-string-class-override-the-operator

Criteria to choose among String, StringBuffer and StringBuilder

• If the Object value will not change in a scenario use String Class because a String object is immutable.
• If the Object value can change and will only be modified from a single thread, use a StringBuilder because StringBuilder is unsynchronized(means faster).
• If the Object value may change, and can be modified by multiple threads, use a StringBuffer because StringBuffer is thread safe(synchronized).

Mutable or Immutable

What are immutable classes?

Immutable classes are the one whose objects visible attributes can not be changed once instantiated.

How to make class immutable?

To make a class immutable adhere followings :

1. Make class final

2. Make all fields final

3. Class should not have any Mutator method ( setter methods)

4. Don't leek any references of class attributes. (For getter of references create new object i.e. deep cloning, return new instance of referenced object.

What are the benefits of immutable?

1. Can be used as Cache:  

As immutable objects don't change their state or values its safest cache that can be used across without any danger of corruption.

2. Thread safety by Immutability:

Immutable objects are inherently thread safe and can be shared across multiple threads safely.

3. Can be used for implementing Flyweight Design Pattern:

The Flyweight pattern employs a factory method to dispense references to immutable fine-grained objects and uses sharing to keep the object count down by only having a single instance of the object instead of keep creating instance of these objects through out application. For example String. 

4. Good keys for hashing:

Immutable objects are best way to define keys for any hashing data structure. They are memory leek free otherwise due to mutation keys can make associated values not reachable and cause memory leek. In fact we should always use immutable keys.

For example, consider a Person bean with an value-based equals method:

Map<Person, String> map = ...
Person p = new Person();
map.put(p, "Hey, there!");
p.setName("Daniel");
map.get(p); // => null

The Person instance gets "lost" in the map when used as a key because it's hashCode and equality were based upon mutable values. Those values changed outside the map and all of the hashing became obsolete. 

Why Immutable class needs to be final?

For safety and security it is good practice to make class final when it is suppose to be immutable. It's not mandatory but avoids any hack or programming errors. Otherwise in extended sub classes or using anonymous class instances you can override getters and simulate mutability by returning changed values.

For example:

ImmutableClass object = new ImmutableClass(x, y){

     @Override

     public String getX(){

     return "Hello";

   }

}

Example of Immutable class:

class User implements Cloneable

{

    private String userName;

    private int userNode;

    User(String name, int node)

    {

        userName = name;

        userNode = node;

    }

    public String userName()

    {

        return userName;

    }

    public int getUserNode() {

        return userNode;

    }

    @Override

    protected Object clone() throws CloneNotSupportedException {

        return super.clone();

    }

    public User deepClone() {

        return new User(this.userName(), this.getUserNode());

    }

    @Override

    public String toString() {

        return String.format("User{userName='%s', userNode=%d}", userName, userNode);

    }

}

final class DiskDriveInfo implements Cloneable

{

    private final int driveSize;

    private final String volumeLabel;

    private final User driveShare;

    DiskDriveInfo(int size, String volLabel, User share)

    {

        driveSize = size;

        volumeLabel = volLabel;

        driveShare = share;

    }

    public int size()

    {

        return driveSize;

    }

    public String label()

    {

        return volumeLabel;

    }

    public User getUser() {

        // Dont use default clone method as it just creates a new reference to the same object so you will leek        reference here.

        //return (User) driveShare.clone();

        return driveShare.deepClone();

    }

    // This is just to show that you can write clone method but for immutable objects it has no use.

    @Override

    public Object clone() throws CloneNotSupportedException {

        return super.clone();

    }

    @Override

    public String toString() {

        return String.format("DiskDriveInfo{driveSize=%d, volumeLabel='%s', driveShare=%s}", driveSize, volumeLabel, driveShare);

    }

}

Atomic Classes in Java

From Java 5 onwards Java has added multiple thread safe atomic classes in 'java.util.concurrent' package which can be categories in followings:
1. Atomic class for atomic access to primitive types

• AtomicBoolean
• AtomicInteger
• AtomicLong
• AtomicReference

2. Atomic access to different arrays:

• AtomicIntegerArray
• AtomicLongArray
• AtomicReferenceArray

3. Atomic Field Updaters:  These classes are used to wrap up atomic access, via reflection, to volatile fields of another class.

• AtomicIntegerFieldUpdater
• AtomicLongFieldUpdater 
• AtomicReferenceFieldUpdater 

4.  Atomically integrate a boolean or integer with a reference field:

• AtomicMarkableReference 
• AtomicStampedReference

Why to use Calender not new Date(...)?

Originally, Date was intended to contain all logic concerning dates, but the API designers eventually realized that the API they had so far was woefully inadequate and could not be cleanly extended to deal correctly with issues such as timezones, locales, different calendars, daylight savings times, etc.

So they created Calendar to deal with all that complexity, and relegated Date to a simple timestamp, deprecating all its functionality that dealt with formatting, parsing and individual date fields.

BTW, internally these methods such as Date(int, int, int) constructor now call Calendar, so if you see a difference in speed, then you're doing something wrong when calling Calendar.

Synchronization, Volatile and Atomic ... together - when and why ?

Concurrent Coding:-

To exploit the power of multiprocessor systems, applications are generally structured using multiple threads. But as anyone who's written a concurrent application can tell you, simply dividing up the work across multiple threads isn't enough to achieve good hardware utilization -- you must ensure that your threads spend most of their time actually doing work, rather than waiting for more work to do, or waiting for locks on shared data structures.

Using Synchronization -

The traditional way to coordinate access to shared fields in the Java language is to use synchronization, ensuring that all access to shared fields is done holding the appropriate lock. With synchronization, you are assured (assuming your class is properly written) that whichever thread holds the lock that protects a given set of variables will have exclusive access to those variables, and changes to those variables will become visible to other threads when they subsequently acquire the lock. The downside is that if the lock is heavily contended (threads frequently ask to acquire the lock when it is already held by another thread), throughput can suffer, as contended synchronization can be quite expensive. (Public Service Announcement: uncontended synchronization is now quite inexpensive on modern JVMs.)

Another problem with lock-based algorithms is that if a thread holding a lock is delayed (due to a page fault, scheduling delay, or other unexpected delay), then no thread requiring that lock may make progress.

Using Volatile -                                                                                            

Volatile variables can also be used to store shared variables at a lower cost than that of synchronization, but they have limitations. While writes to volatile variables are guaranteed to be immediately visible to other threads, there is no way to render a read-modify-write sequence of operations atomic, meaning, for example, that a volatile variable cannot be used to reliably implement a mutex (mutual exclusion lock) or a counter.

Using Atomic - 

The first processors that supported concurrency provided atomic test-and-set operations, which generally operated on a single bit. The most common approach taken by current processors, including Intel and Sparc processors, is to implement a primitive called compare-and-swap, or CAS. (On Intel processors, compare-and-swap is implemented by the cmpxchg family of instructions. PowerPC processors have a pair of instructions called "load and reserve" and "store conditional" that accomplish the same goal; similar for MIPS, except the first is called "load linked.")

A CAS operation includes three operands -- a memory location (V), the expected old value (A), and a new value (B). The processor will atomically update the location to the new value if the value that is there matches the expected old value, otherwise it will do nothing. In either case, it returns the value that was at that location prior to the CAS instruction. (Some flavors of CAS will instead simply return whether or not the CAS succeeded, rather than fetching the current value.) CAS effectively says "I think location V should have the value A; if it does, put B in it, otherwise, don't change it but tell me what value is there now."

The natural way to use CAS for synchronization is to read a value A from an address V, perform a multistep computation to derive a new value B, and then use CAS to change the value of V from A to B. The CAS succeeds if the value at V has not been changed in the meantime.

Instructions like CAS allow an algorithm to execute a read-modify-write sequence without fear of another thread modifying the variable in the meantime, because if another thread did modify the variable, the CAS would detect it (and fail) and the algorithm could retry the operation. Listing 3 illustrates the behavior (but not performance characteristics) of the CAS operation, but the value of CAS is that it is implemented in hardware and is extremely lightweight (on most processors):

Concurrent algorithms based on CAS are called lock-free, because threads do not ever have to wait for a lock (sometimes called a mutex or critical section, depending on the terminology of your threading platform). Either the CAS operation succeeds or it doesn't, but in either case, it completes in a predictable amount of time.

Atomic variable classes

Until JDK 5.0, it was not possible to write wait-free, lock-free algorithms in the Java language without using native code. With the addition of the atomic variables classes in the java.util.concurrent.atomic package, that has changed. The atomic variable classes all expose a compare-and-set primitive (similar to compare-and-swap), which is implemented using the fastest native construct available on the platform (compare-and-swap, load linked/store conditional, or, in the worst case, spin locks). Nine flavors of atomic variables are provided in the java.util.concurrent.atomic package (AtomicInteger; AtomicLong;AtomicReference; AtomicBoolean; array forms of atomic integer; long; reference; and atomic marked reference and stamped reference classes, which atomically update a pair of values).

The atomic variable classes can be thought of as a generalization of volatile variables, extending the concept of volatile variables to support atomic conditional compare-and-set updates. Reads and writes of atomic variables have the same memory semantics as read and write access to volatile variables.

While the atomic variable classes might look superficially like the SynchronizedCounter example in Listing 1, the similarity is only superficial. Under the hood, operations on atomic variables get turned into the hardware primitives that the platform provides for concurrent access, such as compare-and-swap.

Atomic variables in java.util.concurrent

"Nearly all the classes in the java.util.concurrent package use atomic variables instead of synchronization, either directly or indirectly. Classes like ConcurrentLinkedQueue use atomic variables to directly implement wait-free algorithms, and classes like ConcurrentHashMap use ReentrantLock for locking where needed. ReentrantLock, in turn, uses atomic variables to maintain the queue of threads waiting for the lock."

Sample Code For CAS -

Code illustrating the behavior (but not performance) of compare-and-swap

public class SimulatedCAS { private int value; public synchronized int getValue() { return value; } public synchronized int compareAndSwap(int expectedValue, int newValue) { int oldValue = value; if (value == expectedValue) value = newValue; return oldValue; } }

Implementing a counter with compare-and-swap

public class CasCounter { private SimulatedCAS value; public int getValue() { return value.getValue(); } public int increment() { int oldValue = value.getValue(); while (value.compareAndSwap(oldValue, oldValue + 1) != oldValue) oldValue = value.getValue(); return oldValue + 1; } }

Integer Overflow and Underslow in Java...

You could imagine that when you have only 2 places you are counting (so adding 1 each time)

 00
 01
 10
 11 100

But the last one gets cut down to "00" again. So there is your "overflow". You're back at 00. Now depending on what the bits mean, this can mean several things, but most of the time this means you are going from the highest value to the lowest. (11 to 00)

So:

System.out.println(Integer.MAX_VALUE + 1 == Integer.MIN_VALUE);
System.out.println(Integer.MIN_VALUE - 1 == Integer.MAX_VALUE);

prints true twice.