Follow Techotopia on Twitter

On-line Guides
All Guides
eBook Store
iOS / Android
Linux for Beginners
Office Productivity
Linux Installation
Linux Security
Linux Utilities
Linux Virtualization
Linux Kernel
System/Network Admin
Scripting Languages
Development Tools
Web Development
GUI Toolkits/Desktop
Mail Systems
Eclipse Documentation

How To Guides
General System Admin
Linux Security
Linux Filesystems
Web Servers
Graphics & Desktop
PC Hardware
Problem Solutions
Privacy Policy




Thinking in Java
Prev Contents / Index Next

Optimization guidelines

  • Avoid sacrificing code readability for performance.
  • Performance should not be considered in isolation. Weigh the amount of effort required versus the advantage gained.
  • Performance can be a concern in big projects but is often not an issue for small projects.
  • Getting a program to work should have a higher priority than delving into the performance of the program. Once you have a working program you can use the profiler to make it more efficient. Performance should be considered during the initial design/development process only if it is determined to be a critical factor.
  • Do not make assumptions about where the bottlenecks are. Run a profiler to get the data.
  • Whenever possible try to explicitly discard an instance by setting it to null. This can sometimes be a useful hint to the garbage collector. The size of the program matters. Performance optimization is generally valuable only when the size of the project is large, it runs for a long time and speed is an issue.
  • static final variables can be optimized by the JVM to improve program speed. Program constants should thus be declared as static and final. Doclets

    Although it might be a bit surprising to think of a tool that was developed for documentation support as something that helps you track down problems in your programs, doclets can be surprisingly useful. Because a doclet hooks into the javadoc parser, it has information available to that parser. With this, you can programmatically examine the class names, field names, and method signatures in your code and flag potential problems.

    The process of producing the JDK documentation from the Java source files involves the parsing of the source file and the formatting of this parsed file by using the standard doclet. You can write a custom doclet to customize the formatting of your javadoc comments. However, doclets allow you to do far more than just formatting the comment because a doclet has available much of the information about the source file that’s being parsed.

    You can extract information about all the members of the class: fields, constructors, methods, and the comments associated with each of the members (alas, the method code body is not available). Details about the members are encapsulated inside special objects, which contain information about the properties of the member (private, static, final etc.). This information can be helpful in detecting poorly written code, such as member variables that should be private but are public, method parameters without comments, and identifiers that do not follow naming conventions.

    Javadoc may not catch all compilation errors. It will spot syntax errors, such as an unmatched brace, but it may not catch semantic errors. The safest approach is to run the Java compiler on your code before attempting to use a doclet-based tool.

    The parsing mechanism provided by javadoc parses the entire source file and stores it in memory in an object of class RootDoc. The entry point for the doclet submitted to javadoc is start(RootDoc doc). It is comparable to a normal Java program’s main(String[] args). You may traverse through the RootDoc object and extract the necessary information. The following example shows how to write a simple doclet; it just prints out all the members of each class that was parsed:

    // Doclet that prints out all members of the class.
    import com.sun.javadoc.*;
    public class PrintMembersDoclet {
      public static boolean start(RootDoc root) {
        ClassDoc[] classes = root.classes();
        return true;
      private static void processClasses(ClassDoc[] classes) {
        for(int i = 0; i < classes.length; i++) {
      private static void processOneClass(ClassDoc cls) {
        FieldDoc[] fd = cls.fields();
        for(int i = 0; i < fd.length; i++)
        ConstructorDoc[] cons = cls.constructors();
        for(int i = 0; i < cons.length; i++)
        MethodDoc[] md = cls.methods();
        for(int i = 0; i < md.length; i++)
      private static void processDocElement(Doc dc) {
        MemberDoc md = (MemberDoc)dc;
        System.out.print(" " +;
        else if(md.isConstructor())
    } ///:~

    You can use the doclet to print the members like this:

    javadoc -doclet PrintMembersDoclet -private

    This invokes javadoc on the last argument in the command, which means it will parse the file. The -doclet option tells javadoc to use the custom doclet PrintMembersDoclet. The -private tag instructs javadoc to also print private members (the default is to print only protected and public members).

    RootDoc contains a collection of ClassDoc that holds all the information about the class. Classes such as MethodDoc, FieldDoc, and ConstructorDoc contain information regarding methods, fields, and constructors, respectively. The method processOneClass( ) extracts the list of these members and prints them.

    You can also create taglets, which allow you to implement custom javadoc tags. The JDK documentation presents an example that implements a @todo tag, which displays its text in yellow in the resulting Javadoc output. Search for “taglet” in the JDK documentation for more details.
    Thinking in Java
    Prev Contents / Index Next

   Reproduced courtesy of Bruce Eckel, MindView, Inc. Design by Interspire