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.