Insert serial version UID

Common sense dictates to declare an explicit serial version UID in every serializable class to eliminate the serial version UID as a potential source of incompatibility (with the additional benefit of a small performance gain). When this option is enabled and the class directly derives from either java.io.Serializable or java.io.Externalizable, Jalopy inserts a serial version UID for the class.

import java.io.Serializable;

public class Coordinate implements Serializable {
    private final static long serialVersionUID = -8973068452784520619L;

    ...
}

You can choose whether you want to have a default serial version UID added or whether the serial version id should be generated from the actual class content. Please note that when choosing the latter, you need to make sure that the source file has been compiled before formatting is applied, because here the serial version UID is computed from the byte code.

Insert @Override annotation

When enabled, formatting automatically adds the @Override marker annotation for methods that override a method from a superclass. The @Override annotation (introduced with J2SE 5.0) greatly reduces the chance of accidentally overloading when you really want to override. The @Override annotation tells the compiler that you intend to override a method from a superclass. If you don’t get the parameter list quite right so that you’re really overloading the method name, the compiler emits a compile-time error. It’s therefore good practice to always use the annotation when you override a method to eliminate potential bugs.

Since 1.8

public class Parent {
  int i = 0;
  void doSomething (int k) {
    i = k;
  }
}

class Child extends Parent {
  @Override
  void doSomething (long k) {
    i = 2 * k;
  }
}

This option is only available if the Java compliance level is set to J2SE 5.0 or higher. The chosen compliance level affects the scope of the annotation. With J2SE 5.0, annotations may only be inserted for methods that override a method in a super class. But since Java SE 6.0, the override annotation is also allowed to annotate methods that implement an interface. Depending on the chosen compliance level, Jalopy therefore performs the corresponding action.

Insert logging conditional

Typically, logging systems have a method that submits a logging message like

logger.debug("some message: " + someVar);

This is fine, but if the debug level is set such that this message will NOT display, then time is wasted doing the string marshalling. Thus, the preferred way to do this is

if (logger.isDebugEnabled()) {
    logger.debug("some message: " + someVar);
}

which will only use CPU time if the log message is needed. Enabling this switch will ensure that every logging call with the debug level set will be enclosed with the conditional expression.

Use this feature with care! The current implementation only supports the Jakarta Log4J toolkit and is somewhat weak in that every method call named debug is treated as a logging call which could be incorrect in your application. However, it works fine for the l7dlog calls.

Insert implicit constructor

If you don’t define a constructor for a class, a default parameterless constructor is automatically created by the compiler. To make this provision more visible, you can let Jalopy insert the implicit constructor automatically for top-level classes.

Since 1.9.3

public class Watch {
}

public class Watch {
    public Watch() {
    }
}