JVM’s shutdown sequence has two phases.

1. All registered shutdown hooks are started in some unspecified order and allowed to run concurrently until they finish.
2. All un-invoked finalizers are run if finalization-on-exit has been enabled.

After the above two phases are complete, java virtual machine halts.

Its not a complicated exercise, but a less known feature of java. You might require this to release critical resources in the event of unexpected JVM shutdown. You use finally in a try block to release resources and that is completely different.

Just a single line of code will register with the hook of JVM shutdown. You use, Runtime class to register the thread.

System.getRuntime().addShutdownHook(<thread instance>);

• If you register multiple threads with shutdown hook, all those threads will be run in parallel on shutdown. If you wish to run them in a sequence, then you need to have only one thread registered and have your custom logic controlled within that.
• If you are shutting down the VM using Runtime.getRuntime().halt, this will not invoke the shutdown hook. It will abruptly shutdown all running process and close the show.

Example Code for JVM Shutdown Hook

public class JVMShutdownHookTest {
  public static void main(String[] args) {
    JVMShutdownHook jvmShutdownHook = new JVMShutdownHook();
    Runtime.getRuntime().addShutdownHook(jvmShutdownHook);
    System.out.println("JVM Shutdown Hook Registered.");
    System.out.println("Pre exit.");
    System.exit(0);
    System.out.println("Post exit.");
  }

  private static class JVMShutdownHook extends Thread {
    public void run() {
      System.out.println("JVM Shutdown Hook: Thread initiated.");
    }
  }
}

Output:
JVM Shutdown Hook Registered.
Pre exit.
JVM Shutdown Hook: Thread initiated.

In the above program, I manualy call the System.exit() and make the JVM to shutdown. Once the System.exit is invoked the phase I of shutdown sequence is initiated and that starts then registered thread ‘jvmShutdownHook’ and then halts the JVM.

Runtime.runFinalizersOnExit() method is almost similar to addShutdownHook() but its depreciated in 1.2

In case if you are wondering on how to detect the web context shutdown in application server scenarios, you can use ServletContextListner

When shutdown hook will NOT be initiated

There is no guarantee that always the shutdown hooks will run. There might be a devastating crash of the whole system and JVM might crash due to it. In similar circumstances there is no guarantee that shut down hooks will invoke the thread. Similarly if native OS kills the JVM process then this shutdown hook sequence will not be initiated. Therefore in all cases when the JVM is shutdown abnormally the hook will not be initiated.

Note:

• You cannot register a shutdown hook after a shutdown is intiated. That is, if you try to register a thread to shutdown hook from within another thread that is already registered with the hook you will get IllegalStateException.
• You can use Runtime.getRuntime().halt(status); to halt JVM abruptly after the shutdown sequence is initiated.

• Behaviour of writeReplace and readResolve methods are same for both Serializable and Externalizable objects. writeReplace allows to nominate a replacement object to be written to the stream. readResolve method allows to designate a replacement object for the object just read from the stream.
• In most real time scenarios, you can use Serializable and write your own custom implementation for serialization by providing readObject and writeObject.

You may need Externalizable,

1. If you are not happy with the way java writes/reads objects from stream.
2. Special handling for supertypes on object construction during serialization.

Apart from the above definition there are quite  a few things to learn from this serialVersionUID. As per javadocs, following is format of serialVersionUID:

serialVersionUID Syntax

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

• serialVersionUID is a static final field. You can assign any number of your choice to it. Later I will explain the significance of these two statements.

Why serialVersionUID?

Lets start with annoying warning message you get in your IDE when you declare a class as Serializable.

The serializable class Lion does not declare a static final serialVersionUID field of type long

Most of us used to ignore this message as we always do for a warning. My general note is, always pay attention to the java warning messages. It will help you to learn a lot of fundamentals.

serialVersionUID is a must in serialization process. But it is optional for the developer to add it in java source file. If you are not going to add it in java source file, serialization runtime will generate a serialVersionUID and associate it with the class. The serialized object will contain this serialVersionUID along with other data.

Even though serialVersionUID is a static field, it gets serialized along with the object. This is one exception to the general serialization rule that, “static fields are not serialized”.

How serialVersionUID is generated?

serialVersionUID is a 64-bit hash of the class name, interface class names, methods and fields. Serialization runtime generates a serialVersionUID if you do not add one in source. Refer this link for the algorithm to generate serialVersionUID.

It is advised to have serialVersionUID as unique as possible. Thats why the java runtime chose to have such a complex algorithm to generate it.

If you want help in generating it, jdk tools provides a tool named serialver. Use serialver -show to start the gui version of the tool as shown below.

How serialVersionUID works?

When an object is serialized, the serialVersionUID is serialized along with the other contents.

Later when that is deserialized, the serialVersionUID from the deserialized object is extracted and compared with the serialVersionUID of the loaded class.

If the numbers do not match then, InvalidClassException is thrown.

If the loaded class is not having a serialVersionUID declared, then it is automatically generated using the same algorithm as before.

Strongly recommended to declare serialVersionUID

Javadocs says,

“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”

Now you know why we should declare a serialVersionUID.

Not only declaring a serialVersionUID is sufficient. You must do the following two things carefully. Otherwise it defeats the purpose of having the serialVersionUID.

serialVersionUID should be maintained. As and when you change anything in the class, you should upgrade the serailVersionUID.
Try your best to declare a unique serialVersionUID.

Demonstrate serialVersionUID

Initial class to be serialized has a serialVersionUID as 1L.

import java.io.Serializable;

public class Lion implements Serializable {

  private static final long serialVersionUID = 1L;
  private String sound;

  public Lion(String sound) {
    this.sound = sound;
  }

  public String getSound() {
    return sound;
  }

}

Test serialVersionUID:

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

public class SerialVersionUIDTest {

  public static void main(String args[]) throws IOException, ClassNotFoundException {
    Lion leo = new Lion("roar");
    // serialize

    System.out.println("Serialization done.");
    FileOutputStream fos = new FileOutputStream("serial.out");
    ObjectOutputStream oos = new ObjectOutputStream(fos);
    oos.writeObject(leo);

    // deserialize
    FileInputStream fis = new FileInputStream("serial.out");
    ObjectInputStream ois = new ObjectInputStream(fis);
    Lion deserializedObj = (Lion) ois.readObject();
    System.out.println("DeSerialization done. Lion: " + deserializedObj.getSound());
  }
}

Output:

Serialization done.
DeSerialization done. Lion: roar

Now change serialVersionUID to 2L in Lion class.

  private static final long serialVersionUID = 2L;

Comment the “serialize” block (4 lines of code) in SerialVersionUIDTest. Now run it and you will get the following exception.

1. Serialized Lion with serialVersionUID with 1L.
2. Changed serialVersionUID to 2L and compiled and loaded the class.
3. Deserialize the already serialized object and load it with the latest class.
4. We get exception as serialVersionUID is not matching.

Exception in thread "main" java.io.InvalidClassException: Lion; local class incompatible: <strong>stream classdesc serialVersionUID = 1, local class serialVersionUID = 2</strong>
	at java.io.ObjectStreamClass.initNonProxy(Unknown Source)
	at java.io.ObjectInputStream.readNonProxyDesc(Unknown Source)
	at java.io.ObjectInputStream.readClassDesc(Unknown Source)
	at java.io.ObjectInputStream.readOrdinaryObject(Unknown Source)
	at java.io.ObjectInputStream.readObject0(Unknown Source)
	at java.io.ObjectInputStream.readObject(Unknown Source)
	at SerialVersionUIDTest.main(SerialVersionUIDTest.java:21)

Java Version SE 7

Code named Dolphin and released on July 28, 2011.

New features in Java SE 7

• Strings in switch Statement
• Type Inference for Generic Instance Creation
• Multiple Exception Handling
• Support for Dynamic Languages
• Try with Resources
• Java nio Package
• Binary Literals, underscore in literals
• Diamond Syntax
• Automatic null Handling

Java Version SE 6

Code named Mustang and released on December 11, 2006.

New features in Java SE 6

• Scripting Language Support
• JDBC 4.0 API
• Java Compiler API
• Pluggable Annotations
• Native PKI, Java GSS, Kerberos and LDAP support.
• Integrated Web Services.
• Lot more enhancements.

J2SE Version 5.0

Code named Tiger and released on September 30, 2004.

New features in J2SE 5.0

• Generics
• Enhanced for Loop
• Autoboxing/Unboxing
• Typesafe Enums
• Varargs
• Static Import
• Metadata (Annotations)
• Instrumentation

J2SE Version 1.4

Code named Merlin and released on February 6, 2002 (first release under JCP).

New features in J2SE 1.4

• XML Processing
• Java Print Service
• Logging API
• Java Web Start
• JDBC 3.0 API
• Assertions
• Preferences API
• Chained Exception
• IPv6 Support
• Regular Expressions
• Image I/O API

J2SE Version 1.3

Code named Kestrel and released on May 8, 2000.

New features in J2SE 1.3

• Java Sound
• Jar Indexing
• A huge list of enhancements in almost all the java area.

J2SE Version 1.2

Code named Playground and released on December 8, 1998.

New features in J2SE 1.2

• Collections framework.
• Java String memory map for constants.
• Just In Time (JIT) compiler.
• Jar Signer for signing Java ARchive (JAR) files.
• Policy Tool for granting access to system resources.
• Java Foundation Classes (JFC) which consists of Swing 1.0, Drag and Drop, and Java 2D class libraries.
• Java Plug-in
• Scrollable result sets, BLOB, CLOB, batch update, user-defined types in JDBC.
• Audio support in Applets.

JDK Version 1.1

Released on February 19, 1997

New features in JDK 1.1

• JDBC (Java Database Connectivity)
• Inner Classes
• Java Beans
• RMI (Remote Method Invocation)
• Reflection (introspection only)

JDK Version 1.0

Codenamed Oak and released on January 23, 1996.

Wishing you a happy new year!

Before install you should be aware of couple of things.

1. Which package I need to install
2. Is that package already installed in my linux box

Which Package to Install?

‘Generally’ we use sun’s (oracle) jdk. If you do not have precondition on which package, then use sun’s package. FOSS equivalent alternative for sun JDK is openjdk.

To know the list of jdk packages available for you to install, use the following command:

$ dpkg-query -l '*jdk*'

Is java already installed in my linux?

$ which java 

or

$ java -version

Above two commands is the easiest way to identify if java is installed in your linux. But this will work only if you have installed jdk using standard means and the path are setup correctly.

Otherwise,

• If you know the exact package name, you can use following command:

$ dpkg-query -W -f='${Status} ${Version}\n' sun-java6-jdk

in the above command, sun-java6-jdk is the package name.

If your jdk is not installed you will get the following response:
“No packages found matching sun-java6-jdk.”

or you can use the following command to get a detailed output

$ dpkg -s sun-java6-jdk

Java Installed but path not set or don’t know the path

Use the following commands to know the path of jdk installation

 $ sudo updatedb
$ locate java 

Install Jdk

As of the time of writing this article sun’s package is not available in the partner repositories. Therefore you will not be able to do live installation using defalut repositories.

Either, you need to add additional repository to your list or download package from available site and install it offline.

Method 1: Live Install

You need a live internet connection. Run the following commands sequentially.

$ sudo apt-get install python-software-properties

$ sudo add-apt-repository ppa:sun-java-community-team/sun-java6

$ sudo apt-get update

$ sudo apt-get install sun-java6-jdk

Method 2: Download and Install

http://archive.canonical.com/pool/partner/s/sun-java6/

This url has list of Sun’s packages available. Download the appropriate package and use the following command:

 $ sudo dpkg -i package.deb 

After this, your JAVA_HOME will be:

JAVA_HOME="/usr/lib/jvm/java-6-sun-1.6.0.06"

Wishing you Merry Christmas!

One of my reader was asked a quesion in an interview on how to customize the serialization behaviour and this article serves as an answer for that question.

In general there are three approaches to serialization in java:

1. Implement Serializable and use default protocol.
2. Implement Serializable and get a chance to modify the default protocol.
3. Implement Externalizable and write your own protocol to implement serailization.

Here protocol means, the way (process or approach) object is serialized and de-serialized.

We have seen enough about using the default protocol to implement serialization and how instances are created during serialization. In this current article we shall see about modifying the default protocol.

import java.io.Serializable;

public class Lion implements Serializable {
  private String sound;
  public Lion() {
    System.out.println("Lion's constructor invoked.");
    setSound("roar");
  }
  public String getSound(){
    return sound;
  }
  public void setSound(String sound){
    this.sound = sound;
  }
}

Above is a simple java class which we are going to use to demonstrate serialization. First let use do simple straight forward serialization and then make the customization in step 2.

import java.io.FileInputStream;
import java.io.FileOutputStream;
import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;

public class JavaSerialize {

  public static void main(String args[]) throws IOException, ClassNotFoundException {
    Lion leo = new Lion();
    // serialize
    System.out.println("Serialization done.");
    FileOutputStream fos = new FileOutputStream("serial.out");
    ObjectOutputStream oos = new ObjectOutputStream(fos);
    oos.writeObject(leo);

    // deserialize
    FileInputStream fis = new FileInputStream("serial.out");
    ObjectInputStream ois = new ObjectInputStream(fis);
    Lion deserializedObj = (Lion) ois.readObject();
    System.out.println("DeSerialization done. Lion: " + deserializedObj.getSound());
  }
}

Output:

Lion's constructor invoked.
Serialization done.
DeSerialization done. Lion: roar

Above class just uses the standard mechanism and demonstrates serialization using Lion class.

Customize Java Serialization

We know Serializable is a java marker interface. When a class implements Serializable interface it gives information to the JVM that the instances of these classes can be serialized. Along with that, there is a special note to the JVM

look for following two methods in the class that implements Serializable. If found invoke that and continue with serialization process else directly follow the standard serialization protocol.

So this gives us a chance to write these two methods insided the Class that implements Serializable and you get a hook to the serialization process. You can write your custom code inside these two methods and customize the standard behaviour of serialization.

• private void writeObject(ObjectOutputStream out) throws IOException;
• private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException;

I have modified the Lion class to include these two methods and on the fly I change a property of Lion to demonstrate this. This is not overriding or overloading methods and this is a mechanism provided by serialization. These two included methods are declared private but JVM can access the private methods of an object. There is no change to the class that does the serialization and de-serialization.

import java.io.IOException;
import java.io.ObjectInputStream;
import java.io.ObjectOutputStream;
import java.io.Serializable;

public class Lion implements Serializable {
  private String sound;
  public Lion() {
    System.out.println("Lion's constructor invoked.");
    setSound("roar");
  }
  public String getSound(){
    return sound;
  }
  public void setSound(String sound){
    this.sound = sound;
  }

  private void writeObject(ObjectOutputStream out) throws IOException {
    setSound("meow");
    out.defaultWriteObject();
  }

  private void readObject(ObjectInputStream in) throws IOException, ClassNotFoundException {
    in.defaultReadObject();
  }
}

Output:

Lion's constructor invoked.
Serialization done.
DeSerialization done. Lion: meow