[Skip to content]

2.8. Java

Lets you control all Java related settings.

Figure 2.33. Java settings page

Java settings page

2.8.1. Source compatibility

Lets you specify the Java platform compliance level.

Table 2.5. Compliance levels

LevelDescription
Java SE 6 assert and enum are recognized as reserved keywords. Section 2.8.5, “Insert @Override annotation” may be enabled to have missing annotations inserted for overridden and implemented methods
J2SE 5.0assert and enum are recognized as reserved keywords. Section 2.8.5, “Insert @Override annotation” may be enabled to have missing annotations inserted for overridden methods
J2SE 1.4assert is recognized as a reserved keyword
J2SE 1.3assert and enum are valid identifiers that can be used to name variables and/or methods

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.

2.8.2. Keep on same line

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

Example 2.9. Standard single if block

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

Example 2.10. Compact single if block

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

if

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

Since 1.2

Example 2.11. Standard if/else block

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

Example 2.12. Compact if of if/else block

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.

Example 2.13. Standard else of if/else block

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

Example 2.14. Compact else if block

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

Example 2.15. Compact if block

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

Example 2.16. Standard else block

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

Example 2.17. Compact else block

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

Enable for

You can narrow the scope for the above mentioned options by selecting whether all statements should be printed on one line when possible or only throw or return statements.

Since 1.2

Example 2.18. All statements on same line

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

Example 2.19. Only throw and return statements on same line

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

2.8.3. Insert parentheses

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.

Example 2.20. How is this expression evaluated?

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

Example 2.21. How is this expression evaluated? (continued)

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

Example 2.22. Throw statement

if ( condition )
    throw new IllegalStateException();

Example 2.23. Throw statement with parentheses

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

Example 2.24. return statement

if ( condition)
    return true;

Example 2.25. return statement with parentheses

if ( condition)
    return ( true );

2.8.4. Miscellaneous

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.

Example 2.26. Array brackets after type

int[] a;

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

Example 2.27. Array brackets after identifier

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.

Example 2.28. Mixed array notation with equal dimensions

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

Jalopy would print the above example as

Example 2.29. Mixed array notation with equal dimensions after formatting

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.

Example 2.30. Mixed array notation with different dimensions

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

Example 2.31. Multi-variable

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

Example 2.32. Splitted multi-variable

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:

  • the abstract modifier of interface declarations (see Java Language specification, section 9.1.1).

    public abstract interface Fooable { }
    
  • the abstract and public modifiers of method declarations in interfaces (see the Java Language specification, section 9.4).

    public interface Fooable {
        public abstract reportFoo();
    }
    
  • the final modifier of method declarations that are either declared private or members of class or enum declarations that are declared final (see the Java Language specification, section 8.4.3.3).

    public class Foo {
        private final performFooOperation() { }
    }
    
    public final class AnotherFoo {
        public final performAnotherFooOperation() { }
    }
    
  • the public, static and final modifiers of field declarations in interfaces (see the Java Language specification, section 9.3).

    public interface Foo {
        public static final int FOO_CONSTANT = 1;
    }
    

Since 1.5

2.8.5. Code Generation

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.

Example 2.33. Serial version UID

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

Example 2.34. @Override annotation

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

Example 2.35. Parameter declaration

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

Example 2.36. Finalized parameter declaration

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

Example 2.37. Local variable

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

Example 2.38. Finalized local variable

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

Example 2.39. Class without constructor

public class Watch {
}

Example 2.40. Class with default constructor

public class Watch {
    public Watch() {
    }
}