Checked & Unchecked Exception

1) Checked Exception is required to be handled by compile time while Unchecked Exception doesn't.
2) Checked Exception is direct sub-Class of Exception while Unchecked Exception are of Runtime Exception.
3) Checked Exception represent scenario with higher failure rate while Unchecked Exception are mostly programming mistakes.

Here are few examples of Unchecked Exception in Java library:

• NullPointerException
• ArrayIndexOutOfBound
• IllegalArgumentException
• IllegalStateException

Summary:
1. Both Checked and Unchecked Exception are handled using keyword try, catch and finally.
2. In terms of Functionality Checked and Unchecked Exception are same.
3. Checked Exception handling verified during compile time.
4. Unchecked Exception are mostly programming errors
5. JDK7 provides improved Exception handling code with catching multiple Exception in one catch block and reduce amount of boiler plate code required for exception handling in Java.

What is static and dynamic class loading in Java?

Static Class Loading: Creating objects and instance using new keyword is known as static class loading. The retrieval of class definition and instantiation of the object is done at compile time.

Using new operator you load classes statically in java.

public static void main(String[] args)
{
 Sample m = new Sample();
}

Dynamic Class Loading: Dynamic class loading is done when the name of the class is not known at compile time. Dynamic class loading also called as reflection.This can be achieved by invoking the Class loader functions programmatically. Typically we use Class.forName(String className) to get the class first and then we will call the newInstance() method on the returned class to get the instance.

For example if you want to get a instance of Sample class using dynamic class loading, you have to ...

Sample sample = null;
Class sampleClass = Class.forName("com.sample.Sample");
sample = (Sample) sampleClass.newInstance();
sample.doSomeThing();

Here in dynamic class loading ClassNotFoundException can be thrown if given Class loader doesn’t find the given Class name (com.sample.Sample) in the classpath. Class Loader looks for a given class in following sequence:

• The forName(..) method in the class called Class
• The findSystemClass(..) method in the class class called ClassLoader
• The loadClass(..) method in the class called ClassLoader

Java Class Loaders

        Class loaders are hierarchical. Classes are introduced into the JVM as they are referenced by name in a class that is already running in the JVM. So how is the very first class loaded? The very first class is specially loaded with the help of static main() method declared in your class. All the subsequently loaded classes are loaded by the classes, which are already loaded and running. A class loader creates a namespace. All JVMs include at least one class loader that is embedded within the JVM called the primordial (or bootstrap) class loader. Now let’s look at non-primordial class loaders. The JVM has hooks in it to allow user defined class loaders to be used in place of primordial class loader. Let us look at the class loaders created by the JVM.

Classloaders and their explaination -  

• Bootstrap (primordial) - No Loads JDK internal classes, java.* packages. (as defined in the  sun.boot.class.path system property, typically loads rt.jar and i18n.jar). Classes loaded by Bootstrap  class loader have no visibility into classes loaded by its descendants (i.e. Extensions and Systems  class loaders).

• Extensions - Loads jar files from JDK extensions directory (as defined in the java.ext.dirs system property – usually lib/ext directory of the JRE)

• System - No Loads classes from system classpath (as defined by the java.class.path property, which is set by the CLASSPATH environment variable or –classpath or –cp command line options). The classes loaded by system class loader have visibility into classes loaded by its parents (ie Extensions and Bootstrap class loaders).