Cuando se trata de comparar objetos, los desarrolladores normalmente quieren comparar propiedades de objetos. No obstante, llamar a equals() en una clase (o una superclase/interfaz) que no implemente explícitamente equals() resulta en una llamada al método equals() heredado de java.lang.Object. En lugar de comparar campos de miembros de objetos u otras propiedades, Object.equals() compara dos instancias de objetos para ver si son las mismas. Aunque estos son usos legítimos de Object.equals(), a menudo es indicativo de que el código contiene errores.

Ejemplo 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
	}
}

Java Language Specification indica que es recomendable que un método finalize() llame a super.finalize() [1].

Ejemplo 1: el siguiente método omite la llamada a super.finalize().

protected void finalize() {
  discardNative();
}

Corrección del código: se producen problemas de firma incorrecta del método serializable cuando una clase serializable crea una función de serialización o deserialización pero no sigue las firmas correctas:

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

Una desviación de las firmas del método que requiere la serialización puede provocar que nunca se llame al método durante la serialización o deserialización. Esto supondría una serialización o deserialización incompleta o podría permitir que un código que no es de confianza obtenga acceso a los objetos.
En el caso de que se produzcan excepciones no arrojadas, puede significar que la serialización o deserialización está fallando y bloqueando la aplicación o que podría incluso fallar discretamente. En tal caso, los objetos se crearían correctamente solo en parte y se producirían errores muy difíciles de depurar. El autor de la llamada deberá filtrar estas excepciones de manera que la serialización o deserialización incorrectas puedan tratarse correctamente sin la presencia de bloqueos o de objetos creados parcialmente.

Enviar una HttpServletRequest, redirigir una HttpServletResponse o vaciar el flujo de salida del servlet provoca la confirmación del flujo asociado. Todo restablecimiento de búfer o confirmación de flujo, como los vaciados o los redireccionamientos adicionales, provocarán una IllegalStateExceptions.

Además, los servlets de Java permiten que los datos se escriban en el flujo de respuesta empleando ServletOutputStream o PrintWriter, pero no ambos. Llamar getWriter() después de haber llamado getOutputStream(), o viceversa, también provocará una IllegalStateException.



En tiempo de ejecución, una IllegalStateException impide que el controlador de respuesta se ejecute hasta la finalización, entregando la respuesta de forma eficaz. Esto puede causar inestabilidad en el servidor, señal de que un servlet se ha implementado incorrectamente.

Ejemplo 1: el código siguiente redirige la respuesta del servlet después de que su búfer de flujo de salida se haya vaciado.

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");
    }
}

Ejemplo 2: por otra parte, el código siguiente intenta escribir en el búfer de PrintWriter y vaciarlo después de que la solicitud se haya enviado.

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();
    }
}

En la mayoría de los casos, la configuración del encabezado Content-Length de una solicitud indica que el desarrollador está interesado en
comunicar la longitud de los datos POST enviados al servidor. No obstante, este encabezado debe ser 0 o un
número entero positivo.

Ejemplo 1: el siguiente código establecerá un encabezado Content-Length incorrecto.

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

En la mayoría de los casos, una llamada a toString() en una matriz indica que un desarrollador está interesado en devolver el contenido de la matriz como cadena. Sin embargo, una llamada directa para toString() en una matriz devolverá un valor de cadena que contiene el tipo de matriz y el código hash en memoria.
Ejemplo 1: el siguiente código proporcionará como salida [Ljava.lang.String;@1232121.

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

La anotación FortifyDangerous ha sido aplicada a este campo. Se utiliza para indicar que es peligroso y, por motivos de seguridad, todos los usos deben examinarse.