This class contains an instance final field that is initialized to a compile-time static value. Consider making the field static.

This field is never used.  Consider removing it from the class.

If r is a java.util.Random, you can generate a random number from 0 to n-1 using r.nextInt(n), rather than using (int)(r.nextDouble() * n).

Creating temporary primitive wrapper objects only for String conversion is inefficient. Instead, the static toString() method of those primitive wrapper classes should be used.

For example, the following code:

new Integer(myInteger).toString();  // Non-Compliant

should be refactored into:

Integer.toString(myInteger);      // Compliant

Using checked exceptions forces method callers to deal with errors, either by propagating them or by handling them. This makes those exceptions fully part of the API of the method.

To keep the complexity for callers reasonable, methods should not throw more than one kind of checked exception.

The following code:

public void delete() throws IOException, SQLException {      // Non-Compliant
  /* ... */
}

should be refactored into:

public void delete() throws SomeApplicationLevelException {  // Compliant
  /* ... */
}

Overriding methods are not checked by this rule and are allowed to throw several checked exceptions.

The program is dereferencing a public or protected field that does not seem to ever have a non-null value written to it. Unless the field is initialized via some mechanism not seen by the analysis, dereferencing this value will generate a null pointer exception.

The software uses an HTTP request parameter to construct a pathname that should be within a restricted directory, but it does not properly neutralize sequences such as ".." that can resolve to a location that is outside of that directory. See http://cwe.mitre.org/data/definitions/23.html for more information.

FindBugs looks only for the most blatant, obvious cases of relative path traversal. If FindBugs found any, you almost certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about relative path traversal, you should seriously consider using a commercial static analysis or pen-testing tool.

Found a call to a method which will perform a byte to String (or String to byte) conversion, and will assume that the default platform encoding is suitable. This will cause the application behaviour to vary between platforms. Use an alternative API and specify a charset name or Charset object explicitly.

Return of boolean literal statements wrapped into if-then-else ones should be simplified.

For example, the following code:

if (someBooleanMethod()) {    // Non-Compliant
  return true;
} else {
  return false;
}

should be refactored into:

return someBooleanMethod();   // Compliant

and, the following code:

if (someBooleanMethod()) {    // Non-Compliant
  return false;
} else {
  return true;
}

should be refactored into:

return !someBooleanMethod();  // Compliant

Returning from a finally block suppresses the propagation of any unhandled Throwable which was thrown in the try or catch block.

The following code snippet illustrates this rule. The developer expects to get "ERROR" in the console whereas "OK" is displayed.

public static void main(String[] args) {
  try {
    doSomethingWhichThrowsException();
    System.out.println("OK");
  } catch (RuntimeException e) {
    System.out.println("ERROR");
  }
}

public static void doSomethingWhichThrowsException() {
  try {
    throw new RuntimeException();
  } finally {
    /* ... */
    return;                                        // Non-Compliant - prevents the RuntimeException from being propagated
  }
}

The arguments to this method call seem to be in the wrong order. For example, a call Preconditions.checkNotNull("message", message) has reserved arguments: the value to be checked is the first argument.

Sharing some coding conventions is a key point to make it possible for a team to efficiently collaborate. This rule make it mandatory to place closing curly braces on the same line that next else, catch or finally keywords.

The following code snippet illustrates this rule:

public void myMethod() {
  if(something) {
    executeTask();
  } else if (somethingElse) {          // Compliant
    doSomethingElse();
  }
  else {                               // Non-Compliant
     generateError();
  }

  try {
    generateOrder();
  } catch (Exception e) {              // Compliant
    log(e);
  }
  finally {                            // Non-Compliant
    closeConnection();
  }
}

Sharing some coding conventions is a key point to make it possible for a team to efficiently collaborate. This rule make it mandatory to place right curly braces at the beginning of lines of code.

The following code snippet illustrates this rule:

public void myMethod() {
  if(something) {
    executeTask();}                   // Non-Compliant
  else if (somethingElse) {
    doSomethingElse();
  }                                   // Compliant

  try {
    generateOrder();
  } finally {                         // Compliant
    closeConnection();
  }                                   // Compliant

  try {
    generateOrder();
  } finally {                         // Compliant
    closeConnection(); }              // Non-Compliant
}

The code creates an SQL prepared statement from a nonconstant String. If unchecked, tainted data from a user is used in building this String, SQL injection could be used to make the prepared statement do something unexpected and undesirable.

Constructors and methods receiving arrays should clone objects and store the copy. This prevents that future changes from the user affect the internal functionality.

This code creates a database connect using a blank or empty password. This indicates that the database is not protected by a password.

This code creates a database connect using a hardcoded, constant password. Anyone with access to either the source code or the compiled code can easily learn the password.

This code constructs an HTTP Cookie using an untrusted HTTP parameter. If this cookie is added to an HTTP response, it will allow a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information.

FindBugs looks only for the most blatant, obvious cases of HTTP response splitting. If FindBugs found any, you almost certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously consider using a commercial static analysis or pen-testing tool.

This code directly writes an HTTP parameter to an HTTP header, which allows for a HTTP response splitting vulnerability. See http://en.wikipedia.org/wiki/HTTP_response_splitting for more information.

FindBugs looks only for the most blatant, obvious cases of HTTP response splitting. If FindBugs found any, you almost certainly have more vulnerabilities that FindBugs doesn't report. If you are concerned about HTTP response splitting, you should seriously consider using a commercial static analysis or pen-testing tool.

This code directly writes an HTTP parameter to JSP output, which allows for a cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

FindBugs looks only for the most blatant, obvious cases of cross site scripting. If FindBugs found any, you almost certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool.

The method invokes the execute method on an SQL statement with a String that seems to be dynamically generated. Consider using a prepared statement instead. It is more efficient and less vulnerable to SQL injection attacks.

This code directly writes an HTTP parameter to Servlet output, which allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

FindBugs looks only for the most blatant, obvious cases of cross site scripting. If FindBugs found any, you almost certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool.

This code directly writes an HTTP parameter to a Server error page (using HttpServletResponse.sendError). Echoing this untrusted input allows for a reflected cross site scripting vulnerability. See http://en.wikipedia.org/wiki/Cross-site_scripting for more information.

FindBugs looks only for the most blatant, obvious cases of cross site scripting. If FindBugs found any, you almost certainly have more cross site scripting vulnerabilities that FindBugs doesn't report. If you are concerned about cross site scripting, you should seriously consider using a commercial static analysis or pen-testing tool.

This method contains a self assignment of a local variable, and there is a field with an identical name. Assignment appears to have been ; e.g.

  int foo;
  public void setFoo(int foo) {
    foo = foo;
  }

The assignment is useless. Did you mean to assign to the field instead?

This rule is deprecated, use squid:S1226 instead.

This code contains a sequence of calls to a concurrent abstraction (such as a concurrent hash map). These calls will not be executed atomically.