Lets you control all Java related settings.
Lets you specify the Java platform compliance level. This setting currently only affects the handling of reserved keywords.
Choosing "J2SE 5.0" means that assert and enum will be recognized as reserved keywords.
Choosing "J2SE 1.4" means that only assert will be recognized as a reserved keyword.
Choosing "J2SE 1.3" means that the above mentioned strings are valid identifiers that can be used for variable and/or method names.
It is highly recommended to avoid strings that have become reserved keywords when targeting older Java releases, so you might always want to choose the most recent Java version here to enable compatibilty with future releases.
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
When enabled, prints the if part of if/else statements in one line when possible.
Since 1.2
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.11. Standard else of if/else block
if (cond1) | return getMagicNumber(); | else if (cond2) | throw new IllegalStateException(); |
Example 2.12. 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.13. 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.14. Standard else block
if (cond1) | return getMagicNumber(); | else if (cond2) | throw new IllegalStateException(); | else | return 0 |
Example 2.15. Compact else block
if (cond1) | return getMagicNumber(); | else if (cond2) | throw new IllegalStateException(); | else return 0; |
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
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 needed, but they add clarity and don't cost anything.
throw expression
Lets you insert parentheses around the throw expression to treat the statement like a function call.
Since 1.6
Example 2.21. 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
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.
But C/C++ programmers may expect them to appear after the identifier instead.
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.
Jalopy would print the above example as
Example 2.27. 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.
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
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
Example 2.31. @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; } }
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
Controls the handling of curly braces (the Java block delimiters).
Lets you define how the enclosing block delimiters - open and closing curly brace - are printed. You can either choose from a predefined set of common styles or build one on your own. The brace style can either be configured individually for each block construct (details view) or one global style used (global view).
Use global style
Defines wether one brace style should be used for all block elements. When disabled, a combo box appears that lets you define the desired brace style for the different block elements individually.
Since 1.6
Configure style for
Lets you choose the block construct whose brace style should be configured. Select an item to display the available brace style options for the chosen block construct.
This option is only available when the global brace style check box is disabled.
Since 1.6
Choose from common style
Lets you choose a pre-configured brace style. Choosing a style will adjust all individual brace style options accordingly.
The available styles are:
-
C style
Activates the C brace style. This style is sometimes called "Allman style" or "BSD style" named for Eric Allman, a Berkeley hacker who wrote a lot of the BSD utilities in it.
-
Sun Java style
Activates the Sun brace style. Sometimes called "K&R style" named after Kernighan & Ritchie, because the examples in their famous "The C Programming Language" [Kernighan88] reference are formatted this way.
-
GNU style
Activates the GNU brace style. A brace style used throughout GNU EMACS and the Free Software Foundation code.
Synchronize with
Lets you synchronize the brace style of the currently selected block construct with the brace style of another one. Select an item to have the brace style options updated accordingly.
This option is only available when the global brace style check box is disabled.
Since 1.6
Lets you configure the line wrapping options.
Line break before left brace
When enabled, a line break gets printed before the left curly brace.
Line break after right brace
When enabled, a line break gets printed after the left curly brace (when possible).
Treat class/method blocks different
It is common in the Java developer community to have the opening brace at the end of the line of the keyword for all types of blocks (Sun brace style). One may find the C++ convention of treating class/interface and method/constructor blocks different from other blocks useful. With this option you can achieve exactly that: if enabled, class/interface and method/constructor blocks are then always printed in C brace style (line break before left brace).
Example 2.39. Sun brace style
class VolkswagenBeetle extends AbstractAutomobile { public void tootHorn() { if (isNull) { throwConstraintViolated(); } else { updateValue(); } } }
Example 2.40. Sun brace style, but class/method block treat different
class VolkswagenBeetle extends AbstractAutomobile { public void tootHorn() { if (isNull) { throwConstraintViolated(); } else { updateValue(); } } }
This option is only available when the global brace style check box is enabled.
Treat class/method blocks different if wrapped
Enabling this option forces a line break before the opening brace for class/interface or method/constructor blocks (C style), if either the parameter list spawns several lines and a throws clause follows, or one of the possible clauses (extends, implements, throws) was wrapped.
This option is only available when the global brace style check box is enabled.
Treat statement blocks different if wrapped
Using the Sun brace style can make it hard to identify the start of the block body. The recommended workaround is to increase indentation for the expression statements during line wrap (see "Block continuation indentation").
But it may be easier to change the style of the block brace for such cases. Enabling this option does exactly that: It forces a line break before the opening brace for block statements (if/for/while etc.), if the statement expression could not be printed in just one line.
Since 1.7
Example 2.41. Wrapped block statement (Sun brace style)
if (((x > 0) && (y > 0)) || ((x < 0) && (y < 0))
&& ((x > y) || (x < -y))) {
reverseCourse();
}
Example 2.42. Wrapped block statement - left curly brace treated different
if (((x > 0) && (y > 0)) || ((x < 0) && (y < 0))
&& ((x > y) || (x < -y)))
{
reverseCourse();
}
This option is only available when the global brace style check box is enabled or the style for Statements is currently configured.
Strictly obey brace style
When "Prefer wrap after assignments" and "Wrap before left curly brace" are enabled, a line break may be printed before the left curly brace of array initializers if the intializer does not fit into one line. But one might prefer to leave the curly brace in the same line as the variable declaration to obey the general brace style. With this option you can decide what you favor most: consistent brace style or consistent wrapping after assignments.
Please note that this option is only available, if line breaks should be printed before left curly braces and either a global brace style used or the brace style for arrays is configured.
Since 1.8
Lets you adjust the indentation white space for curly braces individually.
Before left brace
Defines the amount of blank space that should be printed before the left curly brace.
Before right brace
Defines the amount of blank space that should be printed before the right curly brace.
After right brace
Defines the amount of blank space that should be printed after the right curly brace.
Controls miscellaneous brace options.
Per definition braces are superfluous on single statements, but it is a common recommendation that braces should be always used in such cases. With this option, you can specify whether missing braces for single statements should be inserted for the control statements if, for, while and do-while and labeled statements inside switch blocks.
if...else
When enabled, braces are inserted around the body of if...else statements when necessary.
Example 2.51. Brace insertion for if statements
if (true) break; else return;
would become
if (true) { break; } else { return; }
for
When enabled, braces are inserted around the body of for statements when necessary.
Example 2.52. Brace insertion of for statements
for (int i = 0; i < count; i++) System.out.println(i);
would become
for (int i = 0; i < count; i++) { System.out.println(i); }
while
When enabled, braces are inserted around the body of while statements when necessary.
Example 2.53. Brace insertion for while statements
while (!isDone)
doSomething();
would become
while (!isDone) {
doSomething();
}
do...while
When enabled, braces are inserted around the body of do...while statements when necessary.
Example 2.54. Brace insertion for do...while statements
do something(); while (condition);
would become
do { something(); } while (condition);
switch
When enabled, braces are inserted around the body of labeled statements inside switch blocks when necessary.
Please note that braces are only inserted if the statement is not empty!
Since 1.4
Example 2.55. Brace insertion for labeled statements
switch (c) { case 'a': case 'b': System.out.println(); break; }
would become
switch (c) { case 'a': case 'b': { System.out.println(); break; } }
Only insert when statement takes more than one line
When enabled, brace inseration only happens when the block statement takes more than just one line to print.
Since 1.8
Take the following example with two block statements:
Example 2.56. Missing braces
if (arg == null) for (int i = 0; i < 10; i++) System.out.println("arg " + i);
Enabling brace insertion for if and for statements would normally yield:
Example 2.57. Inserted braces
if (arg == null) { for (int i = 0; i < 10; i++) { System.out.println("arg " + i); } }
You see braces inserted for both block statements.
But when you enabled the multi-line option, you will get:
Example 2.58. Inserted braces limited to multi-line statements
if (arg == null) { for (int i = 0; i < 10; i++) System.out.println("arg " + i); }
The statement of the if-block happens to be another block statement which is printed in two lines here, therefore the braces are inserted for the if-statement. The for-statement on the other hand does not have any braces inserted, because here the block can be printed in just one line.
It is permissible to remove braces in case they are superfluous. This not only applies to the control statements if, for, while and do-while, but also to every block in general (remember a block is just a sequence of statements, local class declarations and local variable declaration statements within braces).
Note that the insert and remove braces options are mutually exclusive.
if..else
When enabled, braces around the body of if...else statements are removed when possible.
Example 2.59. Brace removal for if statements
if (true) { break; } else { return; }
would become
if (true) break; else return;
for
When enabled, braces around the body of for statements are removed when possible.
Example 2.60. Brace removal of for statements
for (int i = 0; i < count; i++) { System.out.println(i); }
would become
for (int i = 0; i < count; i++) System.out.println(i);
while
When enabled, braces around the body of while statements are removed when possible.
Example 2.61. Brace removal for while statements
while (!isDone) {
doSomething();
}
would become
while (!isDone)
doSomething();
do...while
When enabled, braces around the body of do...while statements are removed when possible.
Example 2.62. Brace removal for do...while statements
do { something(); } while (condition);
would become
do something(); while (condition);
switch
When enabled, braces are removed around the body of labeled statements inside switch blocks when possible.
Since 1.8
Example 2.63. Brace removal for switch
switch (c) { case 'a': case 'b': { System.out.println(); break; } }
would become
switch (c) { case 'a': case 'b': System.out.println(); break; }
Blocks
When enabled, arbitrary block braces are removed when possible.
Allows you to print statement blocks in just one line when possible, i.e. when the block only contains one statement and does not exceed the maximal line length.
Please note that white space before a compacted block is not controlled by your general brace settings, but with the "Space before braces" option.
Methods
When enabled, method and constructor bodies will be printed in one line when possible.
Since 1.2
Single if
When enabled, single if statement bodies will be printed in one line when possible.
Since 1.2
if
When enabled, statement bodies of the if the part of if/else statement will be printed in one line when possible.
Since 1.2
Example 2.69. Standard if/else block
if (cond) { | return getMagicNumber(); | } else { | return -1 | }
Example 2.70. Compact if of if/else block
if (cond) { return getMagicNumber(); } | else { | return -1; | } |
Please note that when the if block has been compacted, the following else if or else statement always starts on a new line.
else if
When enabled, prints else if statement bodies of if/else statements in one line when possible.
Example 2.71. Standard else of if/else block
if (cond1) { | return getMagicNumber(); | } else if (cond2) { | throw new IllegalStateException(); | } |
Example 2.72. Compact else if block
if (cond1) { | return getMagicNumber(); | } else if (cond2) { throw new IllegalStateException(); } |
Please note that when the else if block has been compacted, the following else statement always starts on a new line.
Since 1.2
Example 2.73. Compact if block
if (cond1) { | return getMagicNumber(); | } else if (cond2) { throw new IllegalStateException(); } | else { | return 0; | } |
else
When enabled, prints else statement bodies in one line when possible.
Since 1.2
Example 2.74. Standard else block
if (cond1) { | return getMagicNumber(); | } else if (cond2) { | throw new IllegalStateException(); | } else { | return 0 | } |
Example 2.75. Compact else block
if (cond1) { | return getMagicNumber(); | } else if (cond2) { | throw new IllegalStateException(); | } else { return 0; } |
Arrays
When enabled, array initializers will be printed in one line when possible.
Since 1.7
Enums
When enabled, enum declaration bodies will be printed in one line when possible.
Since 1.4
Enum constants
When enabled, enum constants will be printed in one line when possible. This option is only useful if you use constant-specific methods in your enums.
Since 1.4
Example 2.80. Enum constants with constant specific methods
public enum Operation { | PLUS { | double eval(double x, double y) { | return x + y; | } | }, | MINUS { | double eval(double x, double y) { | return x - y; } | }, | TIMES { | double eval(double x, double y) { | return x * y; | } | }, | | // Do arithmetic op represented by this constant | abstract double eval(double x, double y); | } |
Example 2.81. Compact enum constants with constant specific methods
public enum Operation { | PLUS { double eval(double x, double y) { return x + y; } }, | MINUS { double eval(double x, double y) { return x - y; } }, | TIMES { double eval(double x, double y) { return x * y; } }, | | // Do arithmetic op represented by this constant | abstract double eval(double x, double y); | } |
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 and return statements.
Since 1.2
When enabled, all statements are compacted when possible.
Example 2.82. All statements on same line
if (true) { return result; } else if (false) { System.out.println("unexpected condition"); } else { throw new Error(); }
When enabled, only throw and return statements are compacted when possible. All other statements are printed in normal block style.
Controls how empty braces should be printed.
Cuddle braces
Prints both braces on one line right after the declaration or statement.
You can control the amount of white space that is printed before the left curly brace. See "Cuddled braces indent" for more information.
Obey brace style
Causes the left curly brace of the empty brace block to be positioned according to the current brace style settings. Depending on the style, the left brace is either printed directly after an element or will have a line break printed before.
This option is only available when Cuddle braces is enabled.
Since 1.7
Insert empty statement
Inserts an empty statement to make it obvious for the reader that the empty braces are intentional.
Please note that this option does not apply for class/interface and method/constructor bodies, but is only used for control statements and blocks.
Lets you control the insertion of trailing comments after a closing brace to assist matching corresponding braces. Such comments are called identifying comments.
Class
Lets you insert identifying comments for class declarations.
Since 1.3
Example 2.88. Identifying class comment
public class Foo { public String getName() { return ...; } ... } // end class Foo
Interface
Lets you enable the insertion of identifying comments for interface declarations.
Since 1.3
Example 2.89. Identifying interface comment
public interface Fooable { public String getName(); ... } // end interface Fooable
Constructor
Lets you enable the insertion of identifying comments for constructor declarations.
Since 1.3
Example 2.90. Identifying constructor comment
public class Foo { public Foo() { super(); } // end ctor Foo ... }
Method
Lets you enable the insertion of identifying comments for method declarations.
Since 1.3
Example 2.91. Identifying method comment
public class Foo { public void getName() { return _name; } // end method getName ... }
if...else
Lets you enable the insertion of identifying comments for if/else statement blocks.
Since 1.3
Example 2.92. Identifying if-else comment
if (true) { ... } // end if if (true) { ... } else if (false) { ... } // end if-else if (true) { ... } else if (false) { ... } else { ... } // end if-else
while
Lets you enable the insertion of identifying comments for while statement blocks.
Since 1.3
for
Lets you enable the insertion of identifying comments for for statement blocks.
Since 1.3
switch
Lets you enable the insertion of identifying comments for switch statement blocks.
Since 1.8
try...catch...finally
Lets you enable the insertion of identifying comments for try/catch/finally blocks.
Since 1.3
Example 2.96. Identifying try-catch comment
try { ... } catch (Throwable ex) { ... } // end try-catch try { ... } catch (IOException ex) { ... } finally { ... } // end try-catch-finally try { ... } finally { ... } // end try-finally
synchronized
Lets you enable the insertion of identifying comments for synchronized statement blocks.
Since 1.3