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

Lets you selectively choose what actions should be performed during inspection.

Obey the general contract when overriding equals

Checks whether the body of a equals method contains a throw statement that would violate the equals contract. Only applies if the method body does contain more than one statement; thus, if the method body consists of a single throw statement, we assume you know what you do and leave it alone. For more information see Effective Java [Bloch01], Item 7, pp. 32.

Don’t substitute another type for Object

Don’t substitute another type for Object in the equals declaration The equals method should not be overloaded.

public boolean equals(MyClass o) {
    ...
}

For a detailed discussion see Effective Java [Bloch01], Item 7, pp. 35.

Always override hashCode when you override equals

Failure to do so will result in a violation of the general contract for Object#hashCode, which will prevent the class from functioning properly in conjunction with all hash-based collections, including HashMap and HashSet. For a detailed discussion see Effective Java [Bloch01], Item 8, pp. 36.

Always override toString

It might be quite useful for diagnostic purposes to have objects generating interesting information with toString. This way you can easily use logging techniques to track programs execution.

System.out.println("Failed to connect: " + phoneNumber);

For a detailed discussion see Effective Java [Bloch01], Item 9, pp. 42.

Use interfaces only to define types

Interfaces should say something about what a client can do with instances of the class. It is inappropriate to define an interface for any other purpose. When enabled, Jalopy warns about uses of the so-called constant interfaces pattern, i.e. an interface that only consists of constants.

public interface PysicalConstants {

    /** Boltzmann constant (J/K) */
    double BOLTZMANN_CONSTANT = 1.3806503e-23;

    /** Mass of the electron (kg) */
    double ELECTRON_MASS = 9.10938188e-31;
}

For a detailed discussion see Effective Java [Bloch01], Item 89, pp. 89.

Replace structures with classes

Degenerated classes consisting solely of data fields are loosely equivalent to C structures, but should not be used as they do not offer the benefits of encapsulation.

public class Point {
    public float x;
    public float y;
}

For a detailed discussion see Effective Java [Bloch01], Item 19, pp. 97.

Return zero-length arrays, not nulls

There is really no reason to ever return null from an array-valued method instead of returning a zero-length array. For a detailed discussion see Effective Java [Bloch01], Item 27, pp. 134.

Adhere to custom naming conventions

Following a naming convention aids readability and maintenance as confusion and irritation is avoided. For a detailed discussion see Effective Java [Bloch01], Item 38, pp. 165.

Refer to objects by their interfaces

When possible, always use the interface type for parameters, return values, variables and fields as your program will be much more flexible. When enabled, Jalopy will print warnings when the different Java collection implementations are used directly.

List subscribers = new ArrayList();

ArrayList subscribers = new ArrayList();

For a detailed discussion see Effective Java [Bloch01], Item 34, pp. 156.

Never declare that a method “throws Exception”

It is usually bad practise to declare that a method throws Exception because it obscures any other exception that may be thrown in the same context and denies any guidance to the programmer conceding the exceptions that the method is capable of throwing. For a detailed discussion see Effective Java [Bloch01], Item 44, pp. 181.

Never declare that a method “throws Throwable”

It is usually bad practise to declare that a method throws Throwable because it obscures any other exception that may be thrown in the same context and denies any guidance to the programmer conceding the exceptions that the method is capable of throwing. For a detailed discussion see Effective Java [Bloch01], Item 44, pp. 181.

Don’t ignore exceptions

An empty catch block defeats the purpose of exceptions. At the very least, the catch block should contain a comment explaining why it is appropriate to ignore the exception.

try {
    ...
} catch (SomeException ex) {
}

For a detailed discussion see Effective Java [Bloch01], Item 47, pp. 187.

Never invoke wait outside a loop

Always use the wait loop idiom to invoke the wait method. Never invoke it outside of a loop as the loop serves to test the condition before and after waiting ensuring liveness and safety For a detailed discussion see Effective Java [Bloch01], Item 50, pp. 201.

Avoid thread groups

As thread groups are largely obsolete, don’t use them. They don’t provide much in the way of useful functionality, and much of the functionality they do provide is flawed. For a detailed discussion see Effective Java [Bloch01], Item 53, pp. 211.

Avoid empty finally blocks

Empty finally blocks are of no use and may indicate programmer errors.

Writer writer = new BufferedWriter(new FileWriter(file));

try {
    write.write(data);
} catch (IOException ex) {
    System.err.println("file could not be written: " + file);
} finally {
}

The programmer certainly wanted to close the Writer in the finally block to ensure that allocated system resources will be freed.

Add NOI18N comment for string literals

Enabling this check will cause warnings for all string literals without associated /* NOI18N */ comment. Internationalizing Java applications is often done with nifty tools that use marker comments to indicate that a given string literal should not be considered for localization. Most tools (at least the ones I know of) use trailing single-line comments which may not be very robust for processing with a formatting tool such as Jalopy. In contrast the author uses a multi-line comment of the form /* NOI18N */ that gets directly placed after a string literal and will therefore always stuck with it.

FileDialog dialog = new FileDialog(this,
    ResourceBundle.getBundle(BUNDLE_NAME)
    .getString("BTN_SAVE_AS", FileDialog.SAVE); //$NON-NLS-1$

This trailing comment could be easily moved away from its string literal during formatting which would result in an unwanted notice on successive internationalization runs.

FileDialog dialog =
    new FileDialog(this,
                   ResourceBundle.getBundle(BUNDLE_NAME).
                                  getString("BTN_SAVE_AS",
                   FileDialog.SAVE); //$NON-NLS-1$

FileDialog dialog =
    new FileDialog(this,
                   ResourceBundle.getBundle(BUNDLE_NAME).
                                  getString("BTN_SAVE_AS" /* NOI18N */),
                   FileDialog.SAVE);

Add informative comment for collection fields

When not using strong-typed collections (a.k.a. Java Generics), it is best to document the object type of the items hold by a collection. When enabled, Jalopy checks for the existence of such comments and warns when they are missing.

private List _favorableTypes = new ArrayList(20); // List of <String>

Warn about lines that exceed the maximal line length

When enabled, prints a warning for every line that was not printed in between the maximal line length.

throw new IllegalArgumentException(                           |
    "condition must be one of WHEN_IN_FOCUSED_WINDOW or WHEN_FOCUSED");
                                                              |

Suppress within //J- //J+ pragma comments

When enabled, no warnings are printed for code sections enclosed with pragma comments.

Since 1.8

//J-
throw new IllegalArgumentException(                           |
    "condition must be one of WHEN_IN_FOCUSED_WINDOW or WHEN_FOCUSED");
//J+                                                          |

The Change Naming Pattern dialog lets you interactively craft a valid regular expression for a naming check.

Figure 2.99. Change Naming Pattern

Regex

The Regex text field is where you have to insert the regular expression. This text field initially contains the current pattern for the list item that is under construction.

Jalopy uses Java’s build-in regular expression engine which is roughly equivalent with Perl 5 regular expressions. The syntax is explained here: http://java.sun.com/javase/6/docs/api/java/util/regex/Pattern.html. For a more precise description of the behavior of regular expression constructs consult Mastering Regular Expressions [Friedl97]. The defined pattern must match exactly.

String

The String text field is where you have to enter a string that should be matched by the specified regular expression. This text field is initially empty.

Test

Once you have edited the two text fields you may want to use the Test button to perform a pattern matching test in order to make sure that the specified regex matches as desired. You will be informed about the match status and can decide whether you want to alter your pattern and/or test string and restart the procedure.

Figure 2.100. Successful regex test

Figure 2.101. Failed regex test

Change

If you are finished editing the regular expression, you can press the Change button to take over.

Cancel

You can always use the Cancel button to cancel editing at any time. The dialog will be closed and no changes applied to the list.