What is Garbage Collection in Java ?

What is Garbage ?

Java provides the means to create an object, but the language doesn't provide the means to destroy the object explicitly.

As long as the reference to an object is present in the program , JVM ensures that the object exists.

1. If Java provided the means to destroy the object , it would produce unpredictable result if program calls any method on the reference of the object (destroyed already) because reference still existed. In this case these reference are called dangling reference.

Reference ---------------------> Dead or Destroyed Object = Dangling Reference

So Java eliminates dangling reference problem by disallowing the destruction of objects explicitly.

2. If Java provided the means to destroy objects explicitly then program would need to keep track all the objects created and destroyed which are no longer used . In this scenario if program somehow lose the track of object it has created the that object cannot be destroyed. And if the object is never destroyed , the memory used by the object cannot be reused by the program causes memory leak.

A program that loses track of objects before it destroys them suffers from a memory leak . If we run a program that has a memory leak for a very long time, it is quite possible that it will exhaust all the available memory and eventually fail because no new objects can be created.

An unreferenced object is called garbage  and the process of finding all the unreferenced objects and reclaiming the storage is called garbage collection .

EJB 3.0 Features in Detail

EJB 3.0 Features

We have already discussed features in EJB 3.0 in the previous post (EJB Features) , so in this post we will discuss features in details so we can understand them easily.

1. ( Deployment descriptor - optional )

Now we can create our EJB application without deployment descriptor XML file by using java metadata annotations for EJB. Annotation were introduced in J2SE 5.0 , are used to simplify the Enterprise Java Beans.


In EJB 3.0 , beans are simple POJO (plain old java object) with annotation, annotation processor creates the deployment descriptor at runtime. The developer doesn't have to maintain multiple files for one bean. For example, the following code shows how to define a simple stateless session bean:

/* Example class for Stateless session */
@Stateless
public class MySessionBean implements MyBean{
    public String getMessage(){
        return "Test Message";
    }
}

/* Example class for Business Interface */
@Remote
public interface MyBean{
    public String getMessage();
}

@Stateless annotation mark the MySessionBean as stateless session bean.

@Remote  annotation mark the MyBean as business interface.

2. Remote Interface are not mandatory to write

Note : Its is not mandatory to write Remote interface in EJB 3.0 we can use @Remote in the bean class itself to let the container generate the business interface,
as in the following example:

@Stateless
@Remote
public class MessageStoreBean{
public String getMessage(){
     return "Test Message";
   }

}

In the above example, the bean class doesn't implement the business interface, and uses @Remote instead. This makes development much easier than in previous versions. EJB 3.0 provides annotations for every type of metadata previously addressed by deployment descriptors, so no XML descriptor is needed and you can deploy your beans simply by deploying a plain old .jar
into your application server.

3. Callback Methods and Listener Classes

In EJB 3.0 , bean developer does not need to implement callback methods which were there in EJB 2.1 like ejbCreate(), ejbPassivate(), ejbActivate(). 

Now we have freedom to make any method as callback using some callback annotations in the bean class itself.

/* Callback method defined inside a bean class */ 
@Stateful 
public class TestBean {
     private int var;
     public int method(){}

     @PreDestroy testMethod(){}
 }

Listener classes: We can create listener classes instead of creating callback methods in the bean, only the difference is in the method signature A callback method defined in a listenerclass must take a Object as a parameter, which is not needed when the callback is in the bean itself.
Here's an example

/* Callback method defined inside a Listener class*/
 public class CustomListener{
     @PrePassivate public testMethod(Object obj){
         // Statements
     } }
 /* Adds callback listener to bean class */
 @CallbackListener
 CustomListener
 @stateful
 public class TestBean{
     private int var;
     public void getPrice(){}
 }

Enterprise Java Beans Features

Enterprise Java Beans

                                                             The Enterprise Java Beans architecture is an architecture for the development and deployment of component-based business applications. 

What is component based business applications ? 

                            Application which emphasizes the "Separation of Concerns" in respect to other wide range functionality.Its a reuse based approach to defining, implementing and composing loosely coupled independent component into systems. With regard to system-wide co-ordination, components communicate with each other via interfaces. When a component offers services to the rest of the system, it adopts a provided interface that specifies the services that other components can utilize, and how they can do so.

EJB applications are:

• Scalable
• Transactional
• Multi user secure
• Can be deployed on any application server as a distributed application
• provides various system level service like security,transaction etc.

Various features are introduced in new versions of EJB , some brief points are given as:

Features in EJB 3.0 :

• Annotation used to annotate EJB application, for simplifying developer's task
• Eliminating the need for developer to provide an EJB deployment descriptor.
• JNDI access through the use of annotation,lookup and DI mechanism
• The required business interface for a session bean can be a plain Java interface rather than an EJBObject, EJBLocalObject, or java.rmi.Remote interface
• Elimination of the requirement for home interfaces for session beans.
• An interceptor facility for session beans and message-driven beans.
• Reduction of the requirements for usage of checked exceptions.
• Elimination of the requirement for the implementation of callback interfaces.

Features in EJB 3.1 :

                                   EJB 3.1 has many more features and is even easier to use,lets look into these.

• Optional Session Bean Business Interfaces
• Global JNDI Names
• Singleton Session Beans
• Asynchronous Session beans
• Easy packaging
• EJB 3.1 Embeddable Container