Questions? Don’t hesitate to ask. We love to help!

Lets you specify the Java platform compliance level.

It is highly recommended to avoid strings that have become reserved keywords when targeting older Java releases. It’s therefore probably a good idea to stick with at least J2SE 5.0 compliance.

Lets you print certain statements on just one line when possible, i.e. if they don’t exceed the maximal line length.

Single if

When enabled, prints single if statements in one line when possible.

Since 1.2

if (cond)                                |
    return getMagicNumber();             |
                                         |
...                                      |

if (cond) return getMagicNumber();       |
                                         |
...                                      |

if

When enabled, prints the if part of if/else statements in one line when possible.

Since 1.2

if (cond)                                |
    return getMagicNumber();             |
else                                     |
    return -1                            |

if (cond) return getMagicNumber();       |
else                                     |
    return -1;                           |

Please note that when the if part has been printed on one line, the following else if or else part always starts on a new line.

else if

When enabled, prints the else if part of if/else statements in one line when possible.

if (cond1)                                                 |
    return getMagicNumber();                               |
else if (cond2)                                            |
    throw new IllegalStateException();                     |

if (cond1)                                                 |
    return getMagicNumber();                               |
else if (cond2) throw new IllegalStateException();         |

Please note that when the else if part has been printed on one line, the following else part always starts on a new line.

Since 1.2

if (cond1)                                                 |
    return getMagicNumber();                               |
else if (cond2) throw new IllegalStateException();         |
else                                                       |
    return 0;                                              |

else

When enabled, prints the else part of if/else statements on one line when possible.

Since 1.2

if (cond1)                                                 |
    return getMagicNumber();                               |
else if (cond2)                                            |
    throw new IllegalStateException();                     |
else                                                       |
    return 0                                               |

if (cond1)                                                 |
    return getMagicNumber();                               |
else if (cond2)                                            |
    throw new IllegalStateException();                     |
else return 0;                                             |

if (true) return result; 
else if (false) System.out.println("unexpected condition"); 
else throw new Error();

if (true) return result;
else if (false)
    System.out.println("unexpected condition");
else throw new Error();

Lets you insert superfluous parentheses automatically to avoid any doubts about how an expression is evaluated.

Multiple expressions

When enabled, Jalopy inserts parentheses around expressions that involve more than two terms in order to clarify their precedence. It is always good advise to use more parentheses than you think you need. They may not be required, but they add clarity and don’t cost anything.

int result = 12 + 4 % 3 * 7 / 8;

int result = 12 + (4 % 3 * 7 / 8);

throw expression

Lets you insert parentheses around the throw expression to treat the statement like a function call.

Since 1.6

if ( condition )
    throw new IllegalStateException();

if ( condition )
    throw ( new IllegalStateException() );

return expression

Lets you insert parentheses around the return expression to treat the statement like a function call.

Since 1.6

if ( condition)
    return true;

if ( condition)
    return ( true );

Only format Javadoc comments

When enabled, only Javadoc comments are formatted according to the current Javadoc settings. Any surrounding source code is left untouched. When you enable this option, the GUI switches its mode and hides all non-Javadoc related options. In order to display the full set of options again, you have to disable the Javadoc-only option. You can control the style of Javadoc comments through the Javadoc settings pages.

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;

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

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 final modifier to parameters

To prevent accidental changes to method parameters, it’s often considered good practice to add the final modifier to the parameters. This way no insidious bugs that erroneously changes the value of your parameters may happen.

Since 1.9.4

public void doSomething(int i, int j) {
    ...
}

public void doSomething(final int i, final int j) {
    ...
}

Please note that the final modifier is only inserted if a parameter value is not already reassigned. So apart from using a specialized tool, this might actually be a handy way to detect such cases. Also, for method prototypes in interfaces or abstract methods nothing gets inserted.

Insert final modifier to local variables

Similar as with method parameters, reassigning variables is often considered a code smell, because then the method does at least two different things, though every method should ideally only do exactly one thing.

Since 1.9.4

public void doSomething(Data input) {
   Value result = calc(input);
   ...
}

public void doSomething(Data input) {
   final Value result = calc(input);
   ...
}

Please note that the final modifier is only inserted if a variable is not already reassigned. So this might actually be a handy way to detect such cases apart from using a specialized tool.

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() {
    }
}