When comparing objects, developers usually want to compare properties of objects. However, calling equals() on a class (or any super class/interface) that does not explicitly implement equals() results in a call to the equals() method inherited from java.lang.Object. Instead of comparing object member fields or other properties, Object.equals() compares two object instances to see if they are the same. Although there are legitimate uses of Object.equals(), it is often an indication of buggy code.

Example 1:

public class AccountGroup
{
	private int gid;

	public int getGid()
	{
		return gid;
	}

	public void setGid(int newGid)
	{
		gid = newGid;
	}
}
...
public class CompareGroup
{
	public boolean compareGroups(AccountGroup group1, AccountGroup group2)
	{
		return group1.equals(group2);   //equals() is not implemented in AccountGroup
	}
}

The Java Language Specification states that it is a good practice for a finalize() method to call super.finalize() [1].

Example 1: The following method omits the call to super.finalize().

protected void finalize() {
  discardNative();
}

Code Correctness: Incorrect Serializable Method Signature issues occur when a serializable class creates a serialization or deserialization function but does not follow the correct signatures:

  private void writeObject(java.io.ObjectOutputStream out) throws IOException;
  private void readObject(java.io.ObjectInputStream in) throws IOException, ClassNotFoundException;
  private void readObjectNoData() throws ObjectStreamException;

Deviating from the method signatures that serialization requires may mean that the method is never called during serialization/deserialization, leading to incomplete serialization/deserialization, or could mean that untrusted code could gain access to the objects.
In the case that there are exceptions that are not thrown, it may mean that serialization/deserialization fails and crashes the application or potentially even fails quietly such that objects may be only partially constructed correctly, leading to flaws that can be extremely difficult to debug. The caller should catch these exceptions such that incorrect serialization/deserialization can be handled properly without a crash or partially constructed objects.

Forwarding an HttpServletRequest, redirecting an HttpServletResponse, or flushing the servlet's output stream buffer causes the associated stream to commit. Any subsequent buffer resets or stream commits, such as additional flushes or redirects, will result in IllegalStateExceptions.

Furthermore, Java servlets allow data to be written to the response stream using either ServletOutputStream or PrintWriter, but not both. Calling getWriter() after having called getOutputStream(), or vice versa, will also cause an IllegalStateException.



At runtime, an IllegalStateException prevents the response handler from running to completion, effectively dropping the response. This can cause server instability, which is a sign of an improperly implemented servlet.

Example 1: The following code redirects the servlet response after its output stream buffer has been flushed.

public class RedirectServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        OutputStream out = res.getOutputStream();
        ...
        // flushes, and thereby commits, the output stream
        out.flush();
        out.close();        // redirecting the response causes an IllegalStateException
        res.sendRedirect("http://www.acme.com");
    }
}

Example 2: Conversely, the following code attempts to write to and flush the PrintWriter's buffer after the request has been forwarded.

public class FlushServlet extends HttpServlet {
    public void doGet(HttpServletRequest req, HttpServletResponse res) throws ServletException, IOException {
        ...
        // forwards the request, implicitly committing the stream
        getServletConfig().getServletContext().getRequestDispatcher("/jsp/boom.jsp").forward(req, res);
        ...

        // IllegalStateException; cannot redirect after forwarding
        res.sendRedirect("http://www.acme.com/jsp/boomboom.jsp");

        PrintWriter out = res.getWriter();

        // writing to an already-committed stream will not cause an exception,
        // but will not apply these changes to the final output, either
        out.print("Writing here does nothing");

        // IllegalStateException; cannot flush a response's buffer after forwarding the request
        out.flush();
        out.close();
    }
}

In most cases, setting the Content-Length header of a request indicates a developer is interested in
communicating the length of the POST data sent to the server. However, this header should be 0 or a
positive integer.

Example 1: The following code will set an incorrect Content-Length.

  URL url = new URL("http://www.example.com");
  HttpURLConnection huc = (HttpURLConnection)url.openConnection();
  huc.setRequestProperty("Content-Length", "-1000");

In most cases, a call to toString() on an array indicates a developer is interested in returning the contents of the array as a String. However, a direct call to toString() on an array will return a string value containing the array's type and hashcode in memory.
Example 1: The following code will output [Ljava.lang.String;@1232121.

String[] strList = new String[5];
...
System.out.println(strList);

The annotation FortifyDangerous has been applied to this field. This is used to indicate that it is dangerous and all uses should be examined for safety.