Ao comparar objetos, os desenvolvedores geralmente desejam comparar propriedades de objetos. No entanto, chamar equals() em uma classe (ou qualquer superclasse/interface) que não implemente equals() explicitamente resulta em uma chamada para o método equals() herdada de java.lang.Object. Em vez de comparar campos membros de objetos ou outras propriedades, o Object.equals() compara duas instâncias de objeto para ver se elas são iguais. Embora existam usos legítimos de Object.equals(), muitas vezes isso é uma indicação de um código com bug.

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

A Especificação da Linguagem Java afirma que é uma boa prática um método finalize() chamar super.finalize() [1].

Exemplo 1: O seguinte método omite a chamada para super.finalize().

protected void finalize() {
  discardNative();
}

Integridade do código: Problemas de Assinatura de Método Serializável Incorreta ocorrem quando uma classe serializável cria uma função de serialização ou desserialização, mas não segue as assinaturas corretas:

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

O desvio de assinaturas de método exibidas pela serialização pode significar que o método nunca será chamado durante a serialização/desserialização, provocando serializações/desserializações incompletas, ou pode significar que um código não confiável pode obter acesso aos objetos.
No caso em que existem exceções não lançadas, isso pode significar que a serialização/desserialização falhará e travará o aplicativo ou que ela até mesmo pode falhar silenciosamente de forma que os objetos possam ser apenas parcialmente construídos corretamente, levando a falhas que podem ser extremamente difíceis de depurar. O chamador deve capturar essas exceções de forma que a serialização/desserialização incorreta possa ser tratada adequadamente sem travamentos ou objetos parcialmente construídos.

Encaminhar um HttpServletRequest, redirecionar uma HttpServletResponse ou descarregar o fluxo de saída do servlet faz com que o fluxo associado seja confirmado. Quaisquer redefinições de buffer ou confirmações de fluxo subsequentes, como descarregamentos ou redirecionamentos adicionais, resultarão em IllegalStateExceptions.

Além disso, servlets Java permitem que dados sejam gravados no fluxo de resposta usando ServletOutputStream ou PrintWriter, mas não ambos. Chamar getWriter() depois de ter chamado getOutputStream(), ou vice-versa, também causará uma IllegalStateException.



Em tempo de execução, uma IllegalStateException impede que o manipulador de resposta seja executado até sua conclusão, eliminando eficientemente a resposta. Isso pode causar instabilidade no servidor, o que é um sinal de um servlet inadequadamente aplicado.

Exemplo 1: O código a seguir redireciona a resposta do servlet após o descarregamento do seu buffer de fluxo de saída.

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

Exemplo 2: Por outro lado, o código a seguir tenta gravar e descarregar o buffer de PrintWriter depois que a solicitação foi encaminhada.

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

Na maioria dos casos, a configuração do cabeçalho Content-Length de um pedido indica que um programador está interessado na
comunicação do tamanho dos dados POST enviados ao servidor. No entanto, esse cabeçalho deverá ser 0 ou um
número inteiro positivo.

Exemplo 1: O código a seguir definirá um Content-Length incorreto.

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

Na maioria dos casos, uma chamada para toString() em um array indica que um desenvolvedor está interessado em retornar o conteúdo do array como um String. No entanto, uma chamada direta para toString() em um array retornará um valor de string contendo o tipo do array e o código hash na memória.
Exemplo 1: O seguinte código gerará [Ljava.lang.String;@1232121.

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

A anotação FortifyDangerous foi aplicada a esse campo. Ela é usada para indicar que o método é perigoso, e todos os seus usos devem ser examinados quanto à segurança.