Only format Javadoc comments

When enabled, only Javadoc comments are formatted according to the current Javadoc settings. Any surrounding source code is left untouched.

Since 1.8

Array brackets after identifier

Lets you choose where the brackets of array types should be placed.

By default, Jalopy prints the square brackets right after the array type.

int[] a;

But C/C++ programmers may expect them to appear after the identifier instead.

int a[];

Note that Java allows some strange freedom in the way arrays can be defined. Array brackets may not only appear after either the type or an identifier, but a mixed style is also allowed (though not recommended).

Jalopy handles all styles well, but is only able to move the brackets if the dimension of all array declarators is equal.

float[] f[][], g[][], h[][];

Jalopy would print the above example as

float[][][] f, g, h;             // print brackets after type

float f[][][], g[][][], h[][][]; // print brackets after identifier

Mixed array declarators with different dimensions will be printed as-is.

float[][] f[][], g[][][], h[];

Split multi-variables

When enabled, multi-variables are split into several variable declarations. Otherwise multi-variables are kept and printed according to the current settings.

Since 1.0.1

BigInteger q = null, p = null, g = null;

BigInteger q = null;
BigInteger p = null;
BigInteger g = null;

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 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). If this switch is enabled and the class directly derives from either java.io.Serializable or java.io.Externalizable, Jalopy computes and inserts a serial version UID for the class.

Please note that this feature only works if the class has been compiled before formatting is applied, because the serial version UID is computed from the byte code.

Insert @Override

When enabled, automatically inserts 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;
  }
}

Remove redundant modifiers

The Java Language specification allows certain modifiers that are redundant and should be avoided. Enabling this option will ensure that these modifiers are removed where present.

The modifiers that will be removed are:

Since 1.5