Friday, July 15, 2011

A 04: 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.
CLASS LOADER reloadable? Explanation
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)
Extensions No 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)
Bootstrap
(primordial)
(rt.jar, i18.jar)
Extensions
(lib/ext)
System
(-classpath)
Sibling1
classloader
Sibling2
classloader
JVM class loaders
Classes loaded by Bootstrap class loader have no visibility into classes
loaded by its descendants (ie Extensions and Systems class loaders).
The classes loaded by system class loader have visibility into classes loaded
by its parents (ie Extensions and Bootstrap class loaders).
If there were any sibling class loaders they cannot see classes loaded by
each other. They can only see the classes loaded by their parent class
loader. For example Sibling1 class loader cannot see classes loaded by
Sibling2 class loader
Both Sibling1 and Sibling2 class loaders have visibilty into classes loaded
by their parent class loaders (eg: System, Extensions, and Bootstrap)
Class loaders are hierarchical and use a delegation model when loading a class. Class loaders request their
parent to load the class first before attempting to load it themselves. When a class loader loads a class, the child
class loaders in the hierarchy will never reload the class again. Hence uniqueness is maintained. Classes loaded
by a child class loader have visibility into classes loaded by its parents up the hierarchy but the reverse is not true
as explained in the above diagram.
Important: Two objects loaded by different class loaders are never equal even if they carry the same values, which mean a
class is uniquely identified in the context of the associated class loader. This applies to singletons too, where each class
loader will have its own singleton. [Refer Q45 in Java section for singleton design pattern]
Explain static vs. dynamic class loading?
Static class loading Dynamic class loading
Classes are statically loaded with Java’s
“new” operator.
class MyClass {
public static void main(String args[]) {
Car c = new Car();
}
}
Dynamic loading is a technique for programmatically invoking the functions of a
class loader at run time. Let us look at how to load classes dynamically.
Class.forName (String className); //static method which returns a Class
The above static method returns the class object associated with the class
name. The string className can be supplied dynamically at run time. Unlike the
static loading, the dynamic loading will decide whether to load the class Car or
the class Jeep at runtime based on a properties file and/or other runtime
Java
14
conditions. Once the class is dynamically loaded the following method returns an
instance of the loaded class. It’s just like creating a class object with no
arguments.
class.newInstance (); //A non-static method, which creates an instance of a
class (i.e. creates an object).
Jeep myJeep = null ;
//myClassName should be read from a properties file or Constants interface.
//stay away from hard coding values in your program. CO
String myClassName = "au.com.Jeep" ;
Class vehicleClass = Class.forName(myClassName) ;
myJeep = (Jeep) vehicleClass.newInstance();
myJeep.setFuelCapacity(50);
A NoClassDefFoundException is
thrown if a class is referenced with
Java’s “new” operator (i.e. static loading)
but the runtime system cannot find the
referenced class.
A ClassNotFoundException is thrown when an application tries to load in a
class through its string name using the following methods but no definition for the
class with the specified name could be found:
􀂃 The forName(..) method in class - Class.
􀂃 The findSystemClass(..) method in class - ClassLoader.
􀂃 The loadClass(..) method in class - ClassLoader.

Thursday, July 14, 2011

New Annotation Feature of Java 5.0


A article for annotation of Java 5 from http://www.devx.com/Java/Article/27235/1954?pf=true

What Are Annotations?
In short, annotations are metadata or data about data. Annotations are said to annotate a Java element. An annotation indicates that the declared element should be processed in some special way by a compiler, development tool, deployment tool, or during runtime.

Annotations can be analyzed statically before and during compile time. Annotations will likely be used before compile time mainly to generate supporting classes or configuration files.For example, a code generator (XDoclet, for example) can use annotation data in an EJB implementation class to generate EJB interfaces and deployment descriptors for you, reducing both your effort and the error rate. The average developer will probably not be writing code-generation tools, so these annotation types are likely to be used out-of-the-box rather than authored anew.

Annotations will also be used for compile-time checking such as to produce warnings and errors for different failure scenarios. An example of an annotation that is used at compile time is the new @Deprecated annotation, which acts the same as the old @deprecated JavaDoc tag.

Annotations can be useful at runtime as well. Using annotations you could mark code to behave in a particular way whenever it is called.For example, you could mark some methods with a @prelog annotation.

Another way to use annotations at runtime is to use Aspect-Oriented Programming (AOP). AOP uses pointcuts—sets of points configured to executed aspects. You could define a pointcut that will execute an aspect for an annotated method. My guess is that developers would be more likely to write their own runtime annotation types than they would annotation types used for code generation and compile-time checking. Still, writing and understanding the code that accesses the annotations (the annotation consumer) at runtime is fairly advanced.

Annotating Code
Annotations fall into three categories: normal annotations, single member annotations, and marker annotations (see Table 1). Normal and single member annotations can take member values as arguments when you annotate your code.

1. Normal Annotations—Annotations that take multiple arguments. The syntax for these annotations provides the ability to pass in data for all the members defined in an annotation type.
Example: @MyNormalAnnotation(mem1="val1", mem2="val2") public void someMethod() { ... }

2. Single Member Annotations—An annotation that only takes a single argument has a more compact syntax. You don't need to provide the member name.
Example: @MySingleMemberAnnotation("a single value") public class SomeClass { ... }

3.Marker Annotations—These annotations take no parameters. They are used to mark a Java element to be processed in a particular way.
Example: @Deprecated public void doWork() { ... }

Any Java declaration can be marked with an annotation. That is, an annotation can be used on a: package, class, interface, field, method, parameter, constructor, enum (newly available in Java 1.5), or local variable. An annotation can even annotate another annotation. Such annotations are called meta-annotations.

Packages annotations are also allowed, but because packages are not explicitly declared in Java, package annotations must be declared in a source file called package-info.java in the directory containing the source files for the package.

Built-in Annotations
Java 1.5 comes packaged with seven pre-built annotations.

  • java.lang.Override,

  • java.lang.Deprecated,

  • java.lang.SuppressWarning,
    (The follows are meta-annotation.)

  • java.lang.annotation.Documented,

  • java.lang.annotation.Inherited,

  • java.lang.annotation.Retention,

  • java.lang.annotation.Target

    Declaring Annotation Types
    Now that you've learned a little about the annotations that come packaged with Java 1.5, you can move on to declaring your own annotation types.

    Here is a sample annotation type:
    
    public @interface MyAnnotationType {
        int someValue();
        String someOtherValue();
        String yesSomeOtherValue() default "[blank]";
    
    }


    The annotation consumers are the development tools, the compiler, or a runtime library that accesses the annotation data you created when you annotated your Java code.

    An example of how you can access your code during runtime using the reflection API.
    
    // The Annotation Type
    import java.lang.annotation.Retention;
    import static java.lang.annotation.RetentionPolicy.RUNTIME;
    
    @Retention(RUNTIME) 
    public @interface GreetsTheWorld {
         public String value();
    }
    
    // The Annotated Class
    @GreetsTheWorld("Hello, class!") 
    public class HelloWorld {
         
         @GreetsTheWorld("Hello, field!") 
         public String greetingState;
    
         @GreetsTheWorld("Hello, constructor!") 
         public HelloWorld() {
         }
    
         @GreetsTheWorld("Hello, method!") 
         public void sayHi() {
         }
    }
    
    // The Annotation Consumer
    import java.lang.reflect.Constructor;
    import java.lang.reflect.Field;
    import java.lang.reflect.Method;
    
    public class HelloWorldAnnotationTest
    {
      public static void main( String[] args ) throws Exception
      {
        //access the class annotation
        Class clazz = HelloWorld.class;
        System.out.println( clazz.getAnnotation( GreetsTheWorld.class ) );
    
        //access the constructor annotation
        Constructor constructor =
                clazz.getConstructor((Class[]) null);
        System.out.println(
                constructor.getAnnotation(GreetsTheWorld.class));
    
        //access the method annotation
        Method method = clazz.getMethod( "sayHi" );
        System.out.println(method.getAnnotation(GreetsTheWorld.class));
    
        //access the field annotation
        Field field = clazz.getField("greetingState");
        System.out.println(field.getAnnotation(GreetsTheWorld.class));
      }
    }

  • Why use Map.entrySet() instead of Map.keySet()?


    (From http://www.coderanch.com/t/382487/Java-General/java/Why-use-Map-entrySet)

    If you just need keys, use keySet(). If you just need values, use values(). If you're going to use keys and values in your subsequent code, then you're best off using entrySet().

    I frequently see people do this without entrySet(), and it usually looks something like this:

    for (Iterator it = map.keySet().iterator(); it.hasNext(); ) {
    Foo key = (Foo) it.next();
    Bar value = (Bar) map.get(key);
    // now do something with key and value
    }

    This works, but it's making the JVM do extra work for no good reason. Every time you call get() you're making the JVM spend time doing a hashcode lookup, or navigating a tree and evaluating a comparator. These operations may be fast, or not, but why do them if you don't have to? A Map.Entry gives you both key and value, together, in the most efficient manner possible.

    for (Iterator it = map.entrySet().iterator(); it.hasNext(); ) {
    Map.Entry e = (Map.Entry) it.next();
    Foo key = (Foo) e.getKey();
    Bar value = (Bar) e.getValue();
    // now do something with key and value
    }


    Under JDK 5 and later it's a little nicer:

    for (Map.Entry e : map.entrySet()) {
    Foo key = e.getKey();
    Bar value = e.getValue();
    // now do something with key and value
    }

    puzzles

    3 litres and 5 litres containers puzzle

    Puzzle: You have two container - one can contain exactly 3 litres of water and the other can contain exactly 5 litres of water. How many minimum steps will you take to get exactly 4 litres of water without using any other container? You can assume the availability of sufficient quantity of water.


    Solution: Find below the steps:-

    • Step #1: fill the 5 litres container (3L - 0, 5L - 5)
    • Step #2: fill the 3 litres container with the filled 5 litres container (3L - 3, 5L - 2)
    • Step #3: empty the just filled 3 litres container (3L -0, 5L - 2)
    • Step #4: transfer the 2 litres of water left in 5 litres container into 3 litres container (3L - 2, 5L - 0)
    • Step #5: fill the 5 litres container (3L - 2, 5L - 5)
    • Step #6: fill the 3 litres container (having 2L currently) using just filled 5 litres container (3L - 3, 5L - 4)
    So in a minimum of 6 steps you get exactly 4L of water in the 5 litres container.

    Choosing the Most Specific Method - Tricky Overloading



    Choosing the Most Specific Method - Tricky Overloading

    REF:http://geekexplains.blogspot.com/2009/06/choosing-most-specific-method-tricky.html

    Choosing the Most Specific Method - Tricky Method Overloading

    Let's start with looking at a code-segment and try to think of the output/error, it would produce when compiled/executed and subsequently we'll discuss the behavior of code.

    
    public class NullTest {
    
       public static void method(Object obj){
         System.out.println("method with param type - Object");
       }
     
       public static void method(String obj){
         System.out.println("method with param type - String");
       }
     
       public static void main(String [] args){
         method(null);
       }
    }

    So, what do you expect as the output here? Before thinking about the output, do you really expect the code to compile successfully? Well... yeah, the code will compile and run fine as opposed to anyone who might have sensed an ambiguity here - we'll see the reason soon.

    Since the methods are overloaded, the resolution will be done at compile-time only. Which method do you see being bind here - the one with parameter type 'Object' or the one with parameter type 'String' and why? Of course, the compiler can't bind two methods with one call, so on what basis would it pick the most suitable? Which method would be picked, is evident from the output given below:-

    
    method with param type - String

    Any guesses for why a special treatment is being given to 'String' here? Well... it's not actually for 'String' class specifically, but any sub-class would get a preference over the super class in such a situation. But, why? Because JLS (Section: 15.12.2.5) allows this. It clearly says:

    "If more than one member method is both accessible and applicable to a method invocation, it is necessary to choose one to provide the descriptor for the run-time method dispatch. The Java programming language uses the rule that the most specific method is chosen."

    As you easily deduce that the compiler should be able to pick 'the most specific', failing which it will throw a compile-time error. Let's understand it with the below code-segment which doesn't compile because the compiler can't pick 'the most specific' here.

    
    public class NullTest {
    
       public static void method(Object obj){
         System.out.println("method with param type - Object");
       }
     
       public static void method(String str){
         System.out.println("method with param type - String");
       }
     
       public static void method(StringBuffer strBuf){
         System.out.println("method with param type - StringBuffer");
       }
     
       public static void main(String [] args){
         method(null); //... compile-time error!
       }
    }

    Why is the compiler not able to pick 'the most specific' here - because both String and StringBuffer are are sub-classes of the Object class, but without being in the same inheritance hierarchy. For finding 'the most specific' method, the compiler needs to find a method having the parameter type, which is a sub-class of the parameter types of all other overloaded methods.

    This holds true for overloaded methods having more than one parameters as well. The compiler would pick 'the most specific' by looking which method is having at least one of its parameter types as a clear sub-class of the corresponding parameter type and other parameter types being either the same or clear sub-classes, in all other overloaded methods. If it can find one, good, otherwise it will throw a compile-time error. For example:

    
    public class NullTest {
    
     public static void method(Object obj, Object obj1){
       System.out.println("method with param types - Object, Object");
     }
    
     public static void method(String str, Object obj){
       System.out.println("method with param types - String, Object");
     }
    
     public static void main(String [] args){
       method(null, null);
     }
    }
    
    Output
    
    method with param types - String, Object

    In this case the compiler can easily pick 'the most specific' as the method having parameter types (String, Object) as the other overloaded method is having its parameter types as (Object, Object) - clearly 'String' is a subclass of 'Object' and the other parameter is of same type, so the method with parameter types (String, Object) can be picked with ease. But, the below code would throw a compile-time error as none of the methods satisfy the condition for being picked as 'the most specific' method.

    
    public class NullTest {
    
     public static void method(Object obj, String obj1){
       System.out.println("method with param types - Object, String");
     }
    
     public static void method(String str, Object str1){
       System.out.println("method with param types - String, Object");
     }
    
     public static void main(String [] args){
       method(null, null); //... compile-time error!
     }
    }

    What is the difference between abstraction and encapsulation?


    • Abstraction focuses on the outside view of an object (i.e. the interface) Encapsulation (information hiding) prevents clients from seeing it’s inside view, where the behavior of the abstraction is implemented.
    • Abstraction solves the problem in the design side while Encapsulation is the Implementation.
    • Encapsulation is the deliverables of Abstraction. Encapsulation barely talks about grouping up your abstraction to suit the developer needs.

    Tuesday, July 12, 2011

    What is the difference between JDK and JRE?


    What is the difference between JDK and JRE?
    The JRE is the Java RunTime Environment that is a plug-in needed for running java programs. The JRE is an implementation of the Java Virtual Machine which actually executes Java programs.
    The JDK is the Java Development Kit for Java application developers. The JDK is bundle of software which contains one (or more) JRE's along with the various development tools like the Java source compilers, bundling and deployment tools, debuggers, development libraries, etc.

    Spring Tutorial


    Spring interview question: http://www.developersbook.com/

    http://static.springsource.org/docs/Spring-MVC-step-by-step/overview.html#overview-whats-covered

    http://java9s.com/

    http://www.theserverside.com/news/1364527/Introduction-to-the-Spring-Framework




    String pool in java

    public class DemoStringCreation {

      public static void main (String args[]) {
        String str1 = "Hello"; 
        String str2 = "Hello";
        System.out.println("str1 and str2 are created by using string literal.");   
        System.out.println("    str1 == str2 is " + (str1 == str2)); 
        System.out.println("    str1.equals(str2) is " + str1.equals(str2)); 

       
        String str3 = new String("Hello"); 
        String str4 = new String("Hello");
        System.out.println("str3 and str4 are created by using new operator.");   
        System.out.println("    str3 == str4 is " + (str3 == str4)); 
        System.out.println("    str3.equals(str4) is " + str3.equals(str4)); 
       
        String str5 = "Hel"+ "lo"; 
        String str6 = "He" + "llo";
        System.out.println("str5 and str6 are created by using string
    constant expression.");   
        System.out.println("    str5 == str6 is " + (str5 == str6)); 
        System.out.println("    str5.equals(str6) is " + str5.equals(str6));

        String s = "lo";
        String str7 = "Hel"+ s; 
        String str8 = "He" + "llo";
        System.out.println("str7 is computed at runtime.");          
        System.out.println("str8 is created by using string constant
    expression.");   
        System.out.println("    str7 == str8 is " + (str7 == str8)); 
        System.out.println("    str7.equals(str8) is " + str7.equals(str8));
       
      }
    }
    The output result is:
    str1 and str2 are created by using string literal.
        str1 == str2 is true
        str1.equals(str2) is true
    str3 and str4 are created by using new operator.
        str3 == str4 is false
        str3.equals(str4) is true
    str5 and str6 are created by using string constant expression.
        str5 == str6 is true
        str5.equals(str6) is true
    str7 is computed at runtime.
    str8 is created by using string constant expression.
        str7 == str8 is false
        str7.equals(str8) is true
    The creation of two strings with the same sequence of letters without the use of the new keyword will create pointers to the same String in the Java String literal pool. The String literal pool is a way Java conserves resources.

    REF:

    Friday, July 1, 2011