Java Core

1. What are Java Annotations:

– Java Annotations are metadata which are adding to Java elements. An annotation indicates that the declared element should be processed in some special way by a compiler, development tool, deployment tool, or during runtime.

2. Create a Java Annotation (Annotation type) :

– Annotations types are blueprints for annotations, similar to how a class is the blueprint for an object.

– Example define a annotation:

public @interface MyAnnotation {
   String doSomething();

– Example annotate your code (Annotation):

@MyAnnotation("do something")
public void myMethod() {..}

– There are three type of annotation type:

+ Marker Annotation: doesn’t have any arguments.


public @interface MyAnnotation {}


public void mymethod() {...}

+ Single Anntation: only have one argument.


public @interface MyAnnotation {
    String doSomething();


@MyAnnotation ("What to do")
public void mymethod() {...}

+ Normal Annotation : have multiple argument.

– Example:

public @interface MyAnnotation {
   String doSomething();
   int count();


@MyAnnotation (doSomething="What to do", count=1)
public void mymethod() {...}

3. Rules of Thumb for defining annotation type:

– Annotation declaration should start with an ‘at’ sign like @, following with an interface keyword, following with the annotation name.

– Method declarations should not have any parameters.

– Method declarations should not have any throws clauses.

– Return types of the method should be one of the following:

  • primitives
  • String
  • Class
  • enum
  • array of the above types

4. 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

5. 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

6. 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

* Reference from



Most probably, a lot of Java developers have seen OutOfMemory error one time or other. However these errors come in different forms and shapes. The more common is: “Exception in thread “main” java.lang.OutOfMemoryError: Java heap space” and indicates that the Heap utilization has exceeded the value set by -Xmx. This is not the only error message, of this type, however.
One more interesting flavor of the same error message, less common but hence even more troublesome is: “java.lang.OutOfMemoryError: PermGen space”. Most of the memory profiler tools are unable to detect this problem, so it is
even more troublesome and therefor – interesting.
To understand this error message and fix it, we have to remember that, for optimized, more efficient garbage-collecting Java Heap is managed in generations – memory segments holding objects of different ages. Garbage collection algorithms in each generation are different. Objects are allocated in a generation for younger objects – the Young Generation, and because of infant mortality most objects die there. When the young generation fills up it causes a Minor Collection. Assuming high infant mortality, minor collections are garbage-collected frequently. Some surviving objects are moved to a Tenured Generation. When the Tenured Generation needs to be collected there is a Major Collection that is often much slower because it involves all live objects. Each generation contains variables of different length of life and different GC policies are applied to them.
There is a third generation too – Permanent Generation. The permanent generation is special because it holds meta-data describing user classes (classes that are not part of the Java language). Examples of such meta-data are objects describing
classes and methods and they are stored in the Permanent Generation. Applications with large code-base can quickly fill up this segment of the heap which will cause java.lang.OutOfMemoryError: PermGen no matter how high your -Xmx and how much memory you have on the machine.
Sun JVMs allow you to resize the different generations of the heap, including the permanent generation. On a Sun JVM (1.3.1 and above) you can configure the initial permanent generation size and the maximum permanent generation size.

To set a new initial size on Sun JVM use the -XX:PermSize=64m option when starting the virtual machine. To set the maximum permanent generation size use -XX:MaxPermSize=128m option. If you set the initial size and maximum size to equal values you may be able to avoid some full garbage collections that may occur if/when the permanent generation needs to be resized. The default values differ from among different versions but for Sun JVMs upper limit is typically 64MB.
Some of the default values for Sun JVMs are listed below.

JDK 1.3.1_06 Initial Size Maximum Size
Client JVM 1MB 32MB
Server JVM 1MB 64MB
JDK 1.4.1_01 Initial Size Maximum Size
Client JVM 4MB 64MB
Server JVM 4MB 64MB
JDK 1.4.2 Initial Size Maximum Size
Client JVM 4MB 64MB
Server JVM 16MB 64MB
JDK 1.5.0 Initial Size Maximum Size
Client JVM 8MB 64MB
Server JVM 16MB 64MB

Following is a JSP code you can use to monitor memory utilization in different generations (including PermGen):

<%@ page import=”*” %>
<%@ page import=”java.util.*” %>
<title>JVM Memory Monitor</title>
Iterator iter = ManagementFactory.getMemoryPoolMXBeans().iterator();
while (iter.hasNext()) {
MemoryPoolMXBean item = (MemoryPoolMXBean);

<table border=”0″ width=”100%”>
<tr><td colspan=”2″ align=”center”><h3>Memory MXBean</h3></td></tr>
width=”200″>Heap Memory Usage</td><td><%=
<tr><td>Non-Heap Memory
<tr><td colspan=”2″>&nbsp;</td></tr>
<tr><td colspan=”2″ align=”center”><h3>Memory Pool MXBeans</h3></td></tr>
Iterator iter = ManagementFactory.getMemoryPoolMXBeans().iterator();
while (iter.hasNext()) {
MemoryPoolMXBean item = (MemoryPoolMXBean);
<tr><td colspan=”2″>
<table border=”0″ width=”100%” style=”border: 1px #98AAB1 solid;”>
<tr><td colspan=”2″ align=”center”><b><%= item.getName() %></b></td></tr>
<tr><td width=”200″>Type</td><td><%= item.getType() %></td></tr>
<tr><td>Usage</td><td><%= item.getUsage() %></td></tr>
<tr><td>Peak Usage</td><td><%= item.getPeakUsage() %></td></tr>
<tr><td>Collection Usage</td><td><%= item.getCollectionUsage() %></td></tr>
<tr><td colspan=”2″>&nbsp;</td></tr>


As of JBoss v3.2.8/4.0.2, the ServerInfo MBean registered under the name
jboss.system:type=ServerInfo has been enhanced with a new operation
listMemoryPools(boolean fancy) that presents information about the
memory pools managed by the JVM.