The try-with-resources statement introduced in Java SE 7 is particularly suited to situations that use Closeable resources, such as streams. The try-with-resources statement is a try statement that declares one or more resources. A resource is an object that must be closed after the program is finished with it. The try-with-resources statement ensures that each resource is closed at the end of the statement. Any object that implements java.lang.AutoCloseable, which includes all objects which implement java.io.Closeable, can be used as a resource.

The following example reads the first line from a file using an instance of BufferedReader.

static String readFirstLineFromFile(String path) throws IOException {
 try (BufferedReader br = new BufferedReader(new FileReader(path))) {
  return br.readLine();
 }
}

In this example, the resource declared in the try-with-resources statement is a BufferedReader. The declaration statement appears within parentheses immediately after the try keyword. The class BufferedReader, in Java SE 7 and later, implements the interface java.lang.AutoCloseable. Because the BufferedReader instance is declared in a try-with-resource statement, it will be closed regardless of whether the try statement completes normally or abruptly (as a result of the method BufferedReader.readLine throwing an IOException).

A thread in Java can be in one of the following states:

1. NEW: A thread that has not yet started is in this state.
2. RUNNABLE: A thread executing in the Java virtual machine is in this state.
3. BLOCKED: A thread that is blocked waiting for a monitor lock is in this state.
4. WAITING: A thread that is waiting indefinitely for another thread to perform a particular action is in this state.
5. TIMED_WAITING: A thread that is waiting for another thread to perform an action for up to a specified waiting time is in this state.
6. TERMINATED: A thread that has exited is in this state.

A thread can be in only one state at a given point in time. These states are virtual machine states which do not reflect any operating system thread states.

The HotSpot JVM contains several garbage collectors. They are:

1. Serial GC : The serial collector is the default for client style machines in Java SE 5 and 6. With the serial collector, both minor and major garbage collections are done serially (using a single virtual CPU).  In addition, it uses a mark-compact collection method.
2. Parallel GC : The parallel garbage collector uses multiple threads to perform the young generation garbage collection. By default on a host with N CPUs, the parallel garbage collector uses N garbage collector threads in the collection.
3. CMS Collector : The Concurrent Mark Sweep (CMS) collector collects the tenured generation. It attempts to minimize the pauses due to garbage collection by doing most of the garbage collection work concurrently with the application threads.
4. G1 Garbage Collector : The Garbage First or G1 garbage collector is available in Java 7 and is designed to be the long term replacement for the CMS collector. The G1 collector is a parallel, concurrent, and incrementally compacting low-pause garbage collector that has quite a different layout from the other garbage collectors described above.

A thread dump is a list of all the Java threads that are currently active in a Java Virtual Machine (JVM).

It is highly recommended to take more than 1 thread dump. A good practice is to take multiple thread dumps at a regular interval. There are several ways to take thread dumps from a JVM:

1. Get the PID of your java process. The first piece of information you will need to be able to obtain a thread dump is your java process’s PID. The JDK ships with the jps command which lists all java process ids.
2. Request a Thread Dump from the JVM using jstack option. It prints thread dumps to the command line console. This tool is available as part of JDK since 5.0

Java allows to define a class inside another class much like a variable and a method. This is called as Nested class.

class OuterClass {
...
 class NestedClass {
 ...
 }
}

Nested classes help in logical grouping of classes that are only used in one place, they provide increased encapsulation. This will help to write a more readable and maintainable code. Nested classes could be of one of the four types:

1. 1. Static Nested Classes –  Are static members of a class like static variables and methods.  And like static class methods, a static nested class cannot refer directly to instance variables or methods defined in its enclosing class: it can use them only through an object reference.

1. 1. Inner Classes – Are classes defined as members of a class. An inner class is associated with an instance of its enclosing class and has direct access to that object’s methods and fields. Also, because an inner class is associated with an instance, it cannot define any static members itself.

1. 1. Local Classes – Are classes declared within a block of code and are visible only within that block, just as any other method variable.

1. 1. Anonymous Classes – Are local classes without a name. Anonymous classes enable you to make your code more concise. They enable you to declare and instantiate a class at the same time. Typically used when there is a need to use the class only once.

There are two types of enterprise beans defined in EJB 3.x:

1. 1. Session Bean – Performs a task for a client, encapsulates the business logic of the application. Session beans are of three types:

              (a). Stateless Session Bean: A stateless session bean does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the bean’s instance variables may contain a state specific to that client but only for the duration of the invocation. When the method is finished, the client-specific state should not be retained.

             (b). Stateful Session Bean: In a stateful session bean, the instance variables represent the state of a unique client/bean session. If the client completes all the operations on the bean, the session ends and the state disappears.

             (c). Singleton Session Bean: A singleton session bean is instantiated once per application and exists for the lifecycle of the application. Singleton session beans are designed for circumstances in which a single enterprise bean instance is shared across and concurrently accessed by clients.

2. 2. Message Driven Bean – Acts as an asynchronous message consumer. This type of bean normally acts as a JMS (Java Message Service) message listener.

The difference between stateless session beans and message-driven beans are:

1. The most visible difference between message-driven beans and session beans is that clients do not access message-driven beans through interfaces.
2. Message driven bean has only a bean class whereas stateless session bean can have an interface and a bean class.
3. Clients cannot interact with message-driven bean directly, they can interact indirectly by sending messages to JMS Queue or Topic.
4. Message-driven beans process multiple JMS messages asynchronously, rather than processing a serialized sequence of method calls like session beans.

There are three states in the life cycle of a stateful session bean:

1. Does not exist
2. Method ready
3. Passive

Initially the bean is in does not exist state. The client initiates the life cycle of the stateful session bean by obtaining the reference of the bean. The container creates an instance of the bean and performs dependency injection, if any. After this, the container invokes the method annotated with @PostConstruct annotation if present in the bean. The bean is now in the method ready state to have its business methods invoked by the client.

During its life time in the method ready state, the container may passivate the bean by moving it from memory to secondary storage. The bean is said to be in passive state. The container invokes the method annotated with @PrePassivate, if any, immediately before passivation. If a client invokes a business method on the bean while it is in the passive stage, the container activates the bean, calls the method annotated with @PostActivate, if any, and then moves it to the ready stage.

At the end of the lifecycle, the client invokes a method annotated @Remove (which is optional), and the container calls the method annotated @PreDestroy, if any. The bean’s instance is then ready for garbage collection. The life cycle of stateful session bean can be understood with the following diagram.

The life cycle of a stateless session bean has two states:

1. Does not exist
2. Method ready pool

The container typically creates and maintains a pool of stateless session beans, marking the beginning of the stateless session bean’s lifecycle. The container performs any dependency injection and then invokes the method annotated @PostConstruct, if it exists. The bean is now ready to have its business methods invoked by a client. At the end of the lifecycle, the container calls the method annotated with @PreDestroy, if it exists. The bean’s instance is then ready for garbage collection.

The life cycle of stateless session bean can be understood with the following diagram.

During the lifetime of a stateful session bean, there may be periods of inactivity, when the bean instance is not servicing methods from the client. To conserve resources, the container can passivate the bean instance while it is inactive by preserving its conversational state and evicting the bean instance from memory. When the client becomes active, the container may activate the instance by populating it with its preserved conversational state. This is referred to as passivation and activation in the life cycle of stateful session bean.

During passivation, the instance fields are read and then written to the secondary storage associated with the EJB object. Only the non-transient serializable instance fields are preserved. When a bean is about to be passivated, the method annotated with @PrePassivate is invoked, alerting the bean instance that it is about to enter the passive state. At this time, the bean instance should close any open resources and set all nontransient, non-serializable fields to null. When the stateful session bean has been successfully passivated, the instance is evicted from memory; it is destroyed.

When the client makes a request on an EJB object whose bean is passivated, the container activates the instance. When the bean is activated the new instance is populated with the preserved state. When a bean’s conversational state has been successfully activated, the method annotated with @PostActivate is invoked. The bean instance should open any resources needed and initialize the value of any transient fields within the method with @PostActivate annotation. Once this is complete, the bean is back in the Method-Ready state and available to service client requests delegated by the EJB object.