Java Programming Guidelines

This section covers issues related to Java coding and performance. The guidelines outlined are not specific to GlassFish Server, but are general rules that are useful in many situations. For a complete discussion of Java coding best practices, see the Java Blueprints.

The following topics are addressed here:

• Avoid Serialization and Deserialization

• Use StringBuilder to Concatenate Strings

• Assign null to Variables That Are No Longer Needed

• Declare Methods as final Only If Necessary

• Declare Constants as static final

• Avoid Finalizers

• Declare Method Arguments final

• Synchronize Only When Necessary

• Use DataHandlers for SOAP Attachments

Avoid Serialization and Deserialization

Serialization and deserialization of objects is a CPU-intensive procedure and is likely to slow down your application. Use the transient keyword to reduce the amount of data serialized. Additionally, customized readObject() and writeObject() methods may be beneficial in some cases.

Use StringBuilder to Concatenate Strings

To improve performance, instead of using string concatenation, use StringBuilder.append().

String objects are immutable – that is, they never change after creation. For example, consider the following code:

String str = "testing";
str = str + "abc";
str = str + "def";

The compiler translates this code as:

String str = "testing";
StringBuilder tmp = new StringBuilder(str);
tmp.append("abc");
str = tmp.toString();
StringBulder tmp = new StringBuilder(str);
tmp.append("def");
str = tmp.toString();

This copying is inherently expensive and overusing it can reduce performance significantly. You are far better off writing:

StringBuilder tmp = new StringBuilder("testing");
tmp.append("abc");
tmp.append("def");
String str = tmp.toString();

Assign null to Variables That Are No Longer Needed

Explicitly assigning a null value to variables that are no longer needed helps the garbage collector to identify the parts of memory that can be safely reclaimed. Although Java provides memory management, it does not prevent memory leaks or using excessive amounts of memory.

An application may induce memory leaks by not releasing object references. Doing so prevents the Java garbage collector from reclaiming those objects, and results in increasing amounts of memory being used. Explicitly nullifying references to variables after their use allows the garbage collector to reclaim memory.

One way to detect memory leaks is to employ profiling tools and take memory snapshots after each transaction. A leak-free application in steady state will show a steady active heap memory after garbage collections.

Declare Methods as final Only If Necessary

Modern optimizing dynamic compilers can perform inlining and other inter-procedural optimizations, even if Java methods are not declared final. Use the keyword final as it was originally intended: for program architecture reasons and maintainability.

Only if you are absolutely certain that a method must not be overridden, use the final keyword.

Declare Constants as static final

The dynamic compiler can perform some constant folding optimizations easily, when you declare constants as static final variables.

Avoid Finalizers

Adding finalizers to code makes the garbage collector more expensive and unpredictable. The virtual machine does not guarantee the time at which finalizers are run. Finalizers may not always be executed, before the program exits. Releasing critical resources in finalize() methods may lead to unpredictable application behavior.

Declare Method Arguments final

Declare method arguments final if they are not modified in the method. In general, declare all variables final if they are not modified after being initialized or set to some value.

Synchronize Only When Necessary

Do not synchronize code blocks or methods unless synchronization is required. Keep synchronized blocks or methods as short as possible to avoid scalability bottlenecks. Use the Java Collections Framework for unsynchronized data structures instead of more expensive alternatives such asjava.util.HashTable.

Use DataHandlers for SOAP Attachments

Using a javax.activation.DataHandler for a SOAP attachment will improve performance.

JAX-RPC specifies:

• A mapping of certain MIME types to Java types.

• Any MIME type is mappable to a javax.activation.DataHandler .

As a result, send an attachment (.gif or XML document) as a SOAP attachment to an RPC style web service by utilizing the Java type mappings. When passing in any of the mandated Java type mappings (appropriate for the attachment’s MIME type) as an argument for the web service, the JAX-RPC runtime handles these as SOAP attachments.

For example, to send out an image/gif attachment, use java.awt.Image, or create a DataHandler wrapper over your image. The advantages of using the wrapper are:

• Reduced coding: You can reuse generic attachment code to handle the attachments because the DataHandler determines the content type of the contained data automatically. This feature is especially useful when using a document style service. Since the content is known at runtime, there is no need to make calls to attachment.setContent(stringContent, "image/gif"), for example.

• Improved Performance: Informal tests have shown that using DataHandler wrappers doubles throughput for image/gif MIME types, and multiplies throughput by approximately 1.5 for text/xml or java.awt.Image for image/* types.