Olaf Heimburger's Blog

Memory Leaks? We have a Garbage Collector!

True. Java comes with a Garbage Collector and makes reclaiming of heap space easier. On the other hand, Java offers a number of features, which, if used carelessly, can be the root for your memory leak nightmares.

Simple and Tempting

Since JDK 1.1 we have a quick, simple and tempting tool within the Core Language to create our own memory leaks. It doesn't matter whether we build server or standalone applications. This tool is called Inner Class. Together with its twin Anonymous Class both are very efficient in creating memory leaks.

public class Outer {
  class Inner {
  }
}

How is this?

Every non-static Inner Class has an implicit reference to its surrounding class. Anonymous Classes are similar. To successfully create a memory leak simply pass an Inner Class object to a method which keeps references to the provided objects and you're done.

Why?

Suppose you implement something like a cache. Next follow the execution path to a local object which stores some of its inner class objects into the cache. After the local object was out of scope, it won't be garbage collected anymore! The inner class object in the cache holds a reference to the surrounding object and that one is still referenceable and therefore not a candidate for garbage collection anymore. The same is true for anonymous classes!

How to prevent this style of Memory Leaks?

• If you're about to use Inner Classes or Anonymous Classes think carefully. Don't use Anonymous Classes until you're very sure and can prove that they are not causing a Memory Leak.
• Use a static Inner Class to get rid of the implicit outer class reference.

The JNDI context

In Java EE you have to use the JNDI context to lookup objects. This works quite well in many cases. To start with you have to obtain an InitialContext which uses some configuration information on how to connect to the real host. This information is provided either directly through a Properties collection or a jndi.properties file from the class path.

Default Constructor InitialContext within the Container

If you use the InitialContext within the Container you can usually use the InitialContext default constructor. This creates the context for the surrounding container.

Default Constructor InitialContext in a Client

If your using the default constructor for the InitialContext, you can provide a jndi.properties file in your class path to hint the constructor to the real host. This is quite easy to use and highly configurable.

Choke Point

As long as you stay in one environment everything works smooth and fine. But things get difficult if  you want to connect to a different Java EE container from within a container. How? Simply consider a helper method getting information from the JNDI context through InitialContext() and an explicit connection with InitialContext(props). While the your application/facade connects to the correct container, the helper method takes the information from the container it is located in... If both contexts are supposed to connect to the same container this doesn't work correctly anymore. Not convinced? Give it some thoughts...

Maybe some of you have already wondered what this is.

JAR File

A JAR file is a Java Archive based on the popular ZIP file specification from PKWARE. If a JAR file includes a META-INF directory, the contents will be interpreted by the JVM.

META-INF/MAINFEST.MF

The MANIFEST.MF is used to define extensions and package information for the JAR file.

Manifest Name Value Pairs

The Manifest file can contain a number of Name Value pairs in the form of name: value. Each of theses pairs is delimited by a newline. Popular names are Main-Class or Class-Path.

The Trick

If your application consists of a number of JAR files and you have different entry points, aka Main Classes, you can save a lot of maintenance time by packaging everything as usual and create special JAR files for the entry points.

Sample MANIFEST.MF

Here is a MANIFEST.MF snippet taken from OC4J to explain this:

Manifest-Version: 1.0
Created-By: 1.3.1 (Sun Microsystems, Inc.)
Main-Class: com.evermind.client.orion.Oc4jAdminConsole
Class-Path: oc4j.jar

This way, you refer to the Main Class packaged somewhere in the Class Path (ie. oc4j.jar in this case). You'll find this snippet in the MANIFEST.MF of admin.jar.

It is important to note that the Class Path is relative to the working directory of the JAR file.

Usage

Using such a JAR file is easy (shown for OC4J's admin.jar):

java -jar admin.jar