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

La interfaz ICloneable no garantiza una clonación profunda; es posible que las clases que la implementan no se comporten en la forma prevista cuando se clonen. Las clases que implementan ICloneable y realizan solo clonaciones superficiales (se copia solo el objeto, lo que incluye las referencias a otros objetos) pueden provocar un comportamiento inesperado. Como la clonación profunda (se copia el objeto y todos los objetos de referencia) suele ser normalmente el comportamiento previsto de un método de clonación, el uso de la interfaz ICloneable es propenso a errores, por lo que debe evitarse.

Cuando una función clone() llama a una función que se puede sobrescribir, puede que el clon se quede en un estado parcialmente inicializado o que se dañe.

Ejemplo 1: la siguiente función clone() llama a un método que se puede sobrescribir.

  ...
  class User implements Cloneable {
    private String username;
    private boolean valid;
    public Object clone() throws CloneNotSupportedException {
      final User clone = (User) super.clone();
      clone.doSomething();
      return clone;
    }
    public void doSomething(){
      ...
    }
  }

Como la función doSomething() y su clase envolvente no son final, la función se puede sobrescribir, lo que podría dejar al objeto clonado clone en un estado parcialmente inicializado, lo que podría dar lugar a errores o que funcionase en torno a la lógica de forma inesperada.

Cuando se trabaja con primitivos boxed, al comparar la igualdad, debe llamarse al método equals() del primitivo boxed en vez de a los operadores == y !=. La especificación Java establece lo siguiente sobre las conversiones boxing:

"Si el valor p que se usa de referencia (boxed) es un entero literal de tipo entero entre -128 y 127, ambos inclusive; o el literal booleano true o false; o un carácter literal entre '\u0000' y '\u007f', ambos inclusive, a y b son los resultados de cualquier conversión boxing de p. Siempre se da el caso de que a == b."

Esto significa que si se usa un primitivo boxed (distinto de Boolean o Byte), solo se almacenará en la caché o se memorizará un rango de valores. En el caso de un subconjunto de valores, el uso de == o != devolverá el valor correcto. Para los demás valores fuera de dicho subconjunto, se devolverá el resultado de comparar las direcciones de los objetos.

Ejemplo 1: el siguiente ejemplo utiliza operadores de igualdad en primitivos boxed.

  ...
  Integer mask0 = 100;
  Integer mask1 = 100;
  ...
  if (file0.readWriteAllPerms){
    mask0 = 777;
  }
  if (file1.readWriteAllPerms){
    mask1 = 777;
  }
  ...
  if (mask0 == mask1){
    //assume file0 and file1 have same permissions
    ...
  }
  ...

El código en el Example 1 utiliza primitivos boxed Integer para intentar comparar dos valores int. Si mask0 y mask1 son iguales a 100, entonces mask0 == mask1 devolverá true. Sin embargo, cuando mask0 y mask1 son iguales a 777, mask0 == maske1 devolverá false, ya que dichos valores no están dentro del rango de valores almacenados en la caché para estos primitivos boxed.

Cuando se hace una comparación con NaN, siempre se evalúa como false, excepto en el caso del operador !=, que siempre se evalúa como true, puesto que NaN no está ordenado.

Ejemplo 1: el siguiente ejemplo intenta asegurarse de que una variable no es NaN.

  ...
  if (result == Double.NaN){
    //something went wrong
    throw new RuntimeException("Something went wrong, NaN found");
  }
  ...

Así se intenta comprobar que result no es NaN. Sin embargo, si se utiliza el operador == con NaN siempre da como resultado un valor de false, así que esta comprobación nunca produce la excepción.

Cuando el constructor llama a una función que se puede sobrescribir, el usuario malintencionado puede tener acceso a la referencia de this antes de que el objeto se inicialice por completo, lo que a su vez puede suponer vulnerabilidad.

Ejemplo 1: el siguiente ejemplo llama a un método que se puede sobrescribir.

  ...
  class User {
    private String username;
    private boolean valid;
    public User(String username, String password){
      this.username = username;
      this.valid = validateUser(username, password);
    }
    public boolean validateUser(String username, String password){
      //validate user is real and can authenticate
      ...
    }
    public final boolean isValid(){
      return valid;
    }
  }

Como la función validateUser y la clase no son final, significa que se pueden sobrescribir y, en consecuencia, al inicializar una variable en la subclase que sobrescribe dicha función, será posible eludir la funcionalidad validateUser. Por ejemplo:

  ...
  class Attacker extends User{
    public Attacker(String username, String password){
      super(username, password);
    }
    public boolean validateUser(String username, String password){
      return true;
    }
  }
  ...
  class MainClass{
    public static void main(String[] args){
      User hacker = new Attacker("Evil", "Hacker");
      if (hacker.isValid()){
        System.out.println("Attack successful!");
      }else{
        System.out.println("Attack failed");
      }
    }
  }

El código en el Example 1 imprime "¡Ataque satisfactorio!" porque la clase Attacker sobrescribe la función validateUser(), llamada desde el constructor de la superclase User, y Java comprobará primero la subclase en busca de funciones llamadas desde el constructor.

Un gran número de individuos con talento han dedicado mucho tiempo a sopesar formas de hacer funcionar el bloqueo de doble comprobación para mejorar el rendimiento. Ninguno de ellos lo ha logrado.

Ejemplo 1: a primera vista parece que el siguiente fragmento de código logra la protección de los subprocesos, al mismo tiempo que evita la sincronización innecesaria.

if (fitz == null) {
  synchronized (this) {
    if (fitz == null) {
      fitz = new Fitzer();
    }
  }
}
return fitz;

El programador desea garantiza que solo se asigne el objeto Fitzer(), pero no desea pagar el coste de la sincronización cada vez que se llame al código. A este giro se le conoce como bloqueo de doble comprobación.

Por desgracia, no funciona y se pueden asignar varios objetos Fitzer(). Consulte la declaración "El bloqueo de doble comprobación está roto" para obtener más información [1].

Los usuarios malintencionados pueden duplicar deliberadamente nombres de clase para hacer que un programa ejecute código malicioso. Por este motivo, los nombres de clase no son buenos identificadores de tipo y no deben usarse como fundamento para otorgar confianza a un objeto determinado.

Ejemplo 1: El siguiente código determina si confiar o no en una entrada de un objeto inputReader en función de su nombre de clase. Si un usuario malintencionado es capaz de suministrar una implementación de inputReader que ejecute comandos maliciosos, el código no puede diferenciar entre las versiones benignas y maliciosas del objeto.

if (inputReader.getClass().getName().equals("com.example.TrustedClass")) {
   input = inputReader.getInput();
   ...
}

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

Este campo ha sido anotado con FortifyNonNegative, que se usa para indicar que los valores negativos no están permitidos.

En PL/SQL, el valor de NULL es indeterminado. No es igual a ningún valor, ni incluso a otro valor NULL. Además, un valor null nunca es igual a otro valor.

Ejemplo 1: la siguiente instrucción siempre será falsa.

checkNull BOOLEAN := x = NULL;

Ejemplo 2: la siguiente instrucción siempre será falsa.

checkNotNull BOOLEAN := x != NULL;

Este programa usa == o != para comparar la igualdad de dos cadenas; es decir, compara la igualdad de dos objetos, no de sus valores. Hay muchas probabilidades de que dos referencias nunca sean iguales.

Ejemplo 1: nunca debe tomarse la siguiente rama.

  if (args[0] == STRING_CONSTANT) {
      logger.info("miracle");
  }

Los operadores == y != solo se comportarán según lo previsto cuando se utilicen para comparar cadenas dentro de objetos iguales. La forma más común para que esto ocurra es que las cadenas sean internas. De este modo, las cadenas se añaden a un grupo de objetos que la clase String mantiene. Una vez que la cadena se interna, todos los usos de dicha cadena emplearán el mismo objeto y los operadores de igualdad se comportarán según lo previsto. Todos los literales de cadena y las constantes con valor de cadena se internan automáticamente. Otras cadenas pueden internarse manualmente llamando String.intern(), lo que devolverá una instancia canónica de la cadena actual, creando una si fuera necesario.

Después de que un subproceso señale otros a la espera de una exclusión mutua, este debe desbloquear la exclusión mutua llamando pthread_mutex_unlock() antes de que otro subproceso empiece a ejecutarse. Si el subproceso que señala no puede desbloquear la exclusión mutua, la llamada pthread_cond_wait() del segundo subproceso no volverá y el subproceso no se ejecutará.

Ejemplo 1: el código siguiente señala otro subproceso a la espera de una exclusión mutua llamando pthread_cond_signal(), pero no puede desbloquear la exclusión mutua en la que espera el otro subproceso.

   ...
   pthread_mutex_lock(&count_mutex);

   // Signal waiting thread
   pthread_cond_signal(&count_threshold_cv);
   ...

Este campo ha sido anotado con FortifyNonZero, que se usa para indicar que cero no es un valor permitido.

Esta expresión siempre será no nula porque hace referencia a un puntero de función más que al valor devuelto de la función.

Ejemplo 1: la condicional siguiente nunca se disparará. El predicado getChunk == NULL siempre será falso porque getChunk es el nombre de una función definida en el programa.

  if (getChunk == NULL)
    return ERR;

Como las variables locales están asignadas en la pila, cuando un programa devuelve un puntero a una variable local, se devuelve una dirección de pila. Es probable que la siguiente llamada de función vuelva a utilizar esta misma dirección de pila y, por lo tanto, sobrescriba el valor del puntero, que ya no corresponde a la misma variable porque el marco de pila de una función queda invalidado cuando vuelve. En el mejor de los casos, esto provocará que el valor del puntero cambie de forma inesperada. En muchos casos provoca el bloqueo del programa la próxima vez que se desreferencia el puntero. El problema puede ser difícil de depurar porque la causa del mismo a menudo está muy alejada del síntoma.

Ejemplo 1: la función siguiente devuelve una dirección de pila.

char* getName() {
  char name[STR_MAX];
  fillInName(name);
  return name;
}

Por definición, no es posible anular los métodos estáticos, ya que pertenecen a la clase más que a una instancia de la clase. Sin embargo, hay casos en los que parece que el método estático se anuló en una subclase, lo que podría provocar confusión y que se llamase a la versión incorrecta del método.

Ejemplo 1: el siguiente ejemplo intenta definir una API para autenticar a los usuarios.

class AccessLevel{
  public static final int ROOT = 0;
  //...
  public static final int NONE = 9;
}
//...
class User {
  private static int access;
  public User(){
    access = AccessLevel.ROOT;
  }
  public static int getAccessLevel(){
    return access;
  }
  //...
}
class RegularUser extends User {
  private static int access;
  public RegularUser(){
    access = AccessLevel.NONE;
  }
  public static int getAccessLevel(){
    return access;
  }
  public static void escalatePrivilege(){
    access = AccessLevel.ROOT;
  }
  //...
}
//...
class SecureArea {
  //...
  public static void doRestrictedOperation(User user){
    if (user instanceof RegularUser){
      if (user.getAccessLevel() == AccessLevel.ROOT){
        System.out.println("doing a privileged operation");
      }else{
        throw new RuntimeException();
      }
    }
  }
}

A primera vista, parece que el código está bien. Sin embargo, como estamos llamando al método getAccessLevel() en la instancia user y no en las clases User o RegularUser, la condición siempre devolverá true y se llevará a cabo la operación restringida aunque se utilice instanceof para entrar en esta parte del bloque if/else.

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.

La especificación de serialización de objetos Java permite que los desarrolladores definan manualmente los campos serializables para una clase en la matriz serialPersistentFields. Esta característica solo funcionará si serialPersistentFields se declara como private, static y final.

Ejemplo 1: La siguiente declaración de serialPersistentFields no se utilizará para definir campos Serializable porque no es private, static y final.

class List implements Serializable {
public ObjectStreamField[] serialPersistentFields = { new ObjectStreamField("myField", List.class) };
...
}

Llamar a Object.equals() en una matriz es casi siempre un error, ya que comprobará la igualdad de las direcciones de las matrices, en vez de la igualdad de los elementos de las matrices, y debería reemplazarse por java.util.Arrays.equals().

Ejemplo 1: el siguiente ejemplo intenta comprobar dos matrices utilizando la función Object.equals().

...
  int[] arr1 = new int[10];
  int[] arr2 = new int[10];
  ...
  if (arr1.equals(arr2)){
    //treat arrays as if identical elements
  }
...

Esto casi siempre resultará en código que nunca se ejecuta, a menos que en algún momento se asigne una matriz a otra.