Java Annotation

By -
Annotations on Annotations(Meta Annotation)

J2SE 5.0 provides four annotations in the java.lang.annotation package that are used only when writing annotations:

    @Documented—Whether to put the annotation in Javadocs
    @Retention—When the annotation is needed
    @Target—Places the annotation can go
    @Inherited—Whether subclasses get the annotation

These four annotations are used while creating custom Annotations and are called Meta Annotations.

The Target annotation

The target annotation indicates the targeted elements of a class in which the annotation type will be applicable. It contains the following enumerated types as its value:

     @Target(ElementType.TYPE)—can be applied to any element of a class
     @Target(ElementType.FIELD)—can be applied to a field or property
     @Target(ElementType.METHOD)—can be applied to a method level annotation
     @Target(ElementType.PARAMETER)—can be applied to the parameters of a method
     @Target(ElementType.CONSTRUCTOR)—can be applied to constructors
     @Target(ElementType.LOCAL_VARIABLE)—can be applied to local variables
     @Target(ElementType.ANNOTATION_TYPE)—indicates that the declared type itself is an annotation type


The Retention annotation

The retention annotation indicates where and how long annotations with this type are to be retained. There are three values:

RetentionPolicy.SOURCE—Annotations with this type will be by retained only at the source level and will be ignored by the compiler
RetentionPolicy.CLASS—Annotations with this type will be by retained by the compiler at compile time, but will be ignored by the VM
RetentionPolicy.RUNTIME—Annotations with this type will be retained by the VM so they can be read only at run-time


The Documented annotation

The documented annotation indicates that an annotation with this type should be documented by the javadoc tool.
By default, annotations are not included in javadoc. But if @Documented is used, it then will be processed by javadoc-like tools and the annotation type information will also be included in the generated document.

The Inherited annotation

In general annotations are not inherited by child classes from parent classes.

1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
@Documented
@Target(ElementType.METHOD)
@Retention(RetentionPolicy.RUNTIME)
public @interface MyAnnotation{
    String loggerName();
}

@MyAnnotation
class Super {
  @Oneway public void foo() {

  }
}

class Sub extends Super {
  public void foo() {
  
  }
}


Above case Sub does not have the MyAnnotation annotation.
If an annotation type has the meta-annotation @Inherited  then an annotation of that type on a class will cause the annotation to be inherited by sub-classes. So, in the example above, if the MyAnnotation type had the @Inherited attribute, then Sub  would have the MyAnnotation annotation.




Comments

Post a Comment

Popular posts from this blog

Converting Java Map to String

By -
Java Collections framework, String manipulation etc is something that we often encounter in Development process. For processing collections (like checking null/empty, Intersection, Disjunction) We do have some of the very use full libraries. Some of the Collection related libraries are Apche Commons Collections and Google  Collections(Guava). Problem Use Case This article explains how to convert a Java Map to String(and vice versa) using different libraries and technique. One way is to use StringBuilder(Or String) and loop though the Map and build the String by applying some sort of separator ( for key:value and entry). Here we have to take care of the null value etc. Without Any Library If we want to convert the map to a String with key value separator and also individual entry seperator in the resulting String, we have to write code for that. For a simple Map, we have to iterate though the map, take care of the null values etc. Following is a sample to get String built
Read more

Difference between volatile and synchronized

By -
volatile is a field modifier, while synchronized modifies code blocks and methods. So we can specify three variations of a simple accessor using those two keywords: int i1; int geti1() {return i1;} volatile int i2; int geti2() {return i2;} int i3; synchronized int geti3() {return i3;} geti1() accesses the value currently stored in i1 in the current thread . Threads can have local copies of variables, and the data does not have to be the same as the data held in other threads. In particular, another thread may have updated i1 in it's thread, but the value in the current thread could be different from that updated value. In fact Java has the idea of a "main" memory, and this is the memory that holds the current "correct" value for variables. Threads can have their own copy of data for variables, and the thread copy can be different from the "main" memory. So in fact, it is possible for the "main"
Read more

Invoking EJB deployed on a remote machine

By -
Invoking EJB deployed on a remote machine In case we are calling remote ejb( ejb deployed on remote machines), The JNDI lookup might lookup like, Properties env = new Properties(); env.put(Context.INITIAL_CONTEXT_FACTORY, "org.jnp.interfaces.NamingContextFactory"); env.put(Context.PROVIDER_URL, "XX.XXX.XX.XX:1099"); env.put("java.naming.factory.url.pkgs", "org.jboss.naming:org.jnp.interfaces"); Context ctx = new InitialContext(env); If we are calling local ejb then we can simply create InitialContext without any parameters. Like, Context ctx = new InitialContext();
Read more