No se recomienda a los desarrolladores crear las aplicaciones con API no documentadas u ocultas. No hay garantía de que Google no quite o cambie dichas API en el futuro y, por lo tanto, estas se deben evitar. También se debe evitar el uso de estos métodos o campos porque constituyen un riesgo y podrían dañar la aplicación.

El código intenta usar el objeto Camera una vez que se ha liberado. Todas las referencias adicionales al objeto Camera sin que se vuelva a adquirir el recurso generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código utiliza un botón de conmutación para activar o desactivar la vista previa de la cámara. Después de que el usuario pulse el botón una vez, la vista previa de la cámara se detiene y el recurso de cámara se libera. Sin embargo, si este pulsa de nuevo el botón, se llamará a startPreview() en el objeto Camera liberado anteriormente.

public class ReuseCameraActivity extends Activity {
  private Camera cam;

  ...
  private class CameraButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (toggle) {
              cam.stopPreview();
              cam.release();
          }
          else {
              cam.startPreview();
          }
          toggle = !toggle;
      }
  }
  ...
}

El código intenta usar el objeto multimedia una vez que se ha liberado. Todas las referencias adicionales al objeto multimedia sin que se vuelva a adquirir el recurso generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código usa un botón de pausa para activar o desactivar la reproducción multimedia. Después de que el usuario pulse el botón una vez, la canción o el vídeo actuales se detendrán temporalmente y se liberará el recurso de cámara. Sin embargo, si este pulsa de nuevo el botón, se llamará a start() en el recurso multimedia liberado anteriormente.

public class ReuseMediaPlayerActivity extends Activity {
  private MediaPlayer mp;

  ...
  private class PauseButtonListener implements OnClickListener {
      public void onClick(View v) {
          if (paused) {
              mp.pause();
              mp.release();
          }
          else {
              mp.start();
          }
          paused = !paused;
      }
  }
  ...
}

El código intenta usar el controlador de base de datos SQLite de Android una vez que se ha cerrado. Todas las referencias adicionales al controlador sin que se restablezca la conexión a la base de datos generarán una excepción y pueden provocar que se bloquee la aplicación si no se detecta la excepción.

Ejemplo 1: El siguiente código puede proceder de un programa que almacena temporalmente valores de usuario en la memoria caché, pero puede llamar a flushUpdates() para confirmar los cambios en el disco. El método cierra correctamente el controlador de base de datos tras escribir las actualizaciones en la base de datos. Sin embargo, cuando se llama de nuevo a flushUpdates(), se hace referencia de nuevo al objeto de base de datos sin reinicializarlo.

public class ReuseDBActivity extends Activity {
  private myDBHelper dbHelper;
  private SQLiteDatabase db;

  @Override
  public void onCreate(Bundle state) {
      ...
      db = dbHelper.getWritableDatabase();
      ...
  }
  ...

  private void flushUpdates() {
      db.insert(cached_data);     // flush cached data
      dbHelper.close();
  }
  ...
}

De forma predeterminada, los servidores de ASP.NET almacenan el objeto HttpSessionState, sus atributos y cualquier objeto al que hagan referencia en la memoria. Este modelo limita el estado de sesiones activas que puede alojar la memoria del sistema de un solo equipo. Para ampliar la capacidad más allá de estas limitaciones, los servidores se configuran con frecuencia para almacenar la información de estado de sesión, lo que permite ampliar la capacidad y efectuar la replicación entre varios equipos a fin de mejorar el rendimiento general. Para almacenar su estado de sesión, el servidor debe serializar el objeto HttpSessionState, para lo que es necesario que todos los objetos almacenados sean serializables.

Para poder serializar la sesión correctamente, todos los objetos que almacena la aplicación como atributos de sesión deben declarar el atributo [Serializable]. Además, si el objeto requiere métodos de serialización personalizados, también debe implementar la interfaz ISerializable.

Ejemplo 1: la siguiente clase se añade a sí misma a la sesión, pero como no es serializable, la sesión no se puede serializar correctamente.

public class DataGlob {
   String GlobName;
   String GlobValue;

   public void AddToSession(HttpSessionState session) {
     session["glob"] = this;
   }
}

La minimización mejora los tiempos de carga de páginas para las aplicaciones que incluyen archivos JavaScript al reducir su tamaño. La minimización hace referencia al proceso de eliminación de espacios en blanco, comentarios, signos de punto y coma, y llaves acortando el nombre de las variables locales y eliminando código inaccesible.

Ejemplo 1: en el siguiente código ASPX se incluye la versión no minimizada de la biblioteca jQuery de Microsoft:

...
<script src="http://applicationserver.application.com/lib/jquery/jquery-1.4.2.js" type="text/javascript"></script>
...

Las operaciones aritméticas no actúan del mismo modo en valores booleanos a como lo harían en valores integrales, lo que podría ocasionar un comportamiento inesperado.

Cuando los datos de una matriz de bytes se convierten en String, no se especifica lo que ocurrirá con los datos que quedan fuera del conjunto de caracteres correspondiente. Esto puede suponer una pérdida de datos o una disminución en el nivel de seguridad cuando se necesitan datos binarios para garantizar que se cumplen las medidas de seguridad apropiadas.

Ejemplo 1: el siguiente código convierte los datos en una cadena para crear un hash.

  ...
  FileInputStream fis = new FileInputStream(myFile);
  byte[] byteArr = byte[BUFSIZE];
  ...
  int count = fis.read(byteArr);
  ...
  String fileString = new String(byteArr);
  String fileSHA256Hex = DigestUtils.sha256Hex(fileString);
  // use fileSHA256Hex to validate file
  ...

Si el tamaño del archivo es menor que BUFSIZE, funcionará siempre y cuando la información de myFile se encuentre codificada igual que el conjunto de caracteres predeterminado. Sin embargo, si utiliza una codificación diferente o es un archivo binario, se perderá información. A su vez, esto provocará que el hash de SHA resultante no sea de confianza y que sea más fácil causar conflictos, especialmente si hay algún dato fuera del conjunto de caracteres predeterminado que se represente con el mismo valor, como un signo de interrogación.

No hay forma de especificar qué subproceso se activará con llamadas para notify().

Ejemplo 1: en el código siguiente, notifyJob() llama notify().

public synchronized notifyJob() {
flag = true;
notify();
}
...
public synchronized waitForSomething() {
while(!flag) {
    try {
        wait();
    }
    catch (InterruptedException e)
    {
        ...
    }
}
...
}

En es caso, el desarrollador pretende activar el subproceso que llama wait(), pero es posible que notify() notifique un subproceso diferente al previsto.

Si hay varios subprocesos intentando obtener el bloqueo de un recurso, llamar sleep() mientras se mantiene un bloqueo podría causar que todos los demás subprocesos esperen a que el recurso se libere, lo que podría dar lugar a un rendimiento degradado y un interbloqueo.

Ejemplo 1: el código siguiente llama sleep() mientras mantiene un bloqueo.

ReentrantLock rl = new ReentrantLock();
...
rl.lock();
Thread.sleep(500);
...
rl.unlock();

En la mayoría de los casos, una llamada directa a un método run() del objeto Thread indica un error. El programador tenía intención de iniciar un nuevo subproceso de control, pero llamó accidentalmente a run() en lugar de a start(), por lo que el método run() se ejecutará en el subproceso de control del autor de la llamada.

Ejemplo 1: el siguiente extracto de un programa de Java llama por error a run() en lugar de a start().

    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };

  thr.run();

En la mayoría de los casos, una llamada directa a un método stop() de un objeto Thread es un error. El programador pretende detener la ejecución de un subproceso pero no es consciente de que esa no es la mejor forma de detener un subproceso. La función stop() en Thread produce una excepción ThreadDeath en cualquier lugar del objeto Thread, lo que puede dejar a los objetos en un estado de incoherencia y filtrar recursos. Hace mucho que esta API está en desuso debido a que no es segura por naturaleza.

Ejemplo 1: el siguiente extracto de un programa de Java llama por error a Thread.stop().

  ...
  public static void main(String[] args){
    ...
    Thread thr = new Thread() {
      public void run() {
        ...
      }
    };
    ...
    thr.start();
    ...
    thr.stop();
    ...
  }

Al parecer, el programador previó implementar para esta clase la interfaz Cloneable, ya que implementa un método llamado clone(). Sin embargo, la clase no implementa la interfaz Cloneable y el método clone() no se comportará correctamente.

Ejemplo 1: llamar clone() para esta clase dará lugar a una CloneNotSupportedException.

public class Kibitzer {
  public Object clone() throws CloneNotSupportedException {
    ...
  }
}

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