&& (AND) y || (O) en declaraciones IF

Tengo el siguiente código:

if(!partialHits.get(req_nr).containsKey(z) || partialHits.get(req_nr).get(z) < tmpmap.get(z)){  
    partialHits.get(z).put(z, tmpmap.get(z));  
}

donde partialHitses un HashMap
¿Qué pasará si la primera afirmación es verdadera? ¿Java aún verificará la segunda declaración? Porque para que la primera declaración sea verdadera, el HashMap no debe contener la clave dada, por lo que si la segunda declaración está marcada, obtendré NullPointerException.
En palabras simples, si tenemos el siguiente código

if(a && b)  
if(a || b)

¿Java comprobaría bsi aes falso en el primer caso y si aes verdadero en el segundo caso?

No, no será evaluado. Y esto es muy útil. Por ejemplo, si necesita probar si una Cadena no es nula o está vacía, puede escribir:

if (str != null && !str.isEmpty()) {
  doSomethingWith(str.charAt(0));
}

O al revés

if (str == null || str.isEmpty()) {
  complainAboutUnusableString();
} else {
  doSomethingWith(str.charAt(0));
}

Si no tuviéramos 'cortocircuitos' en Java, recibiríamos muchas NullPointerExceptions en las líneas de código anteriores.

Java tiene 5 operadores booleanos de comparación diferentes: &, &&, |, ||, ^

& y && son operadores "y", | y || "u" operadores, ^ es "xor"

Los únicos verificarán cada parámetro, independientemente de los valores, antes de verificar los valores de los parámetros. Los dobles primero verifican el parámetro izquierdo y su valor y si true( ||) o false( &&) dejan el segundo sin tocar. ¿Sonido compilado? Un ejemplo sencillo debería aclararlo:

Dado para todos los ejemplos:

 String aString = null;

Y:

 if (aString != null & aString.equals("lala"))

Ambos parámetros se verifican antes de que se realice la evaluación y se lanzará una NullPointerException para el segundo parámetro.

 if (aString != null && aString.equals("lala"))

El primer parámetro se verifica y regresa false, por lo que el segundo parámetro no se verificará porque el resultado es de falsetodos modos.

Lo mismo para OR:

 if (aString == null | !aString.equals("lala"))

También generará NullPointerException.

 if (aString == null || !aString.equals("lala"))

El primer parámetro se verifica y regresa true, por lo que el segundo parámetro no se verificará porque el resultado es de truetodos modos.

XOR no se puede optimizar, porque depende de ambos parámetros.

No, no se comprobará. Este comportamiento se denomina evaluación de cortocircuito y es una característica en muchos idiomas, incluido Java.

Todas las respuestas aquí son geniales, pero, solo para ilustrar de dónde viene esto, para preguntas como esta es bueno ir a la fuente: la Especificación del lenguaje Java.

La Sección 15:23, Operador condicional y (&&) , dice:

El operador && es como & (§15.22.2), pero evalúa su operando de la derecha solo si el valor de su operando de la izquierda es verdadero. [...] En tiempo de ejecución, la expresión del operando de la izquierda se evalúa primero [...] si el valor resultante es falso, el valor de la expresión condicional y es falso y la expresión del operando de la derecha no se evalúa . Si el valor del operando de la izquierda es verdadero, entonces la expresión de la derecha se evalúa [...] y el valor resultante se convierte en el valor de la expresión condicional y. Por lo tanto, && calcula el mismo resultado que & en operandos booleanos. Solo difiere en que la expresión del operando de la derecha se evalúa condicionalmente en lugar de siempre.

Y de manera similar, la Sección 15:24, Operador Condicional-O (||) , dice:

El || operador es como | (§15.22.2), pero evalúa su operando de la derecha solo si el valor de su operando de la izquierda es falso. [...] En tiempo de ejecución, la expresión del operando de la izquierda se evalúa primero; [...] si el valor resultante es verdadero, el valor de la condicional-o expresión es verdadero y la expresión del operando de la derecha no se evalúa. Si el valor del operando de la izquierda es falso, entonces se evalúa la expresión de la derecha; [...] el valor resultante se convierte en el valor de la condicional-o expresión. Por lo tanto, || calcula el mismo resultado que | en operandos booleanos o booleanos. Solo difiere en que la expresión del operando de la derecha se evalúa condicionalmente en lugar de siempre.

Un poco repetitivo, tal vez, pero la mejor confirmación de cómo funcionan exactamente. De manera similar, el operador condicional (? :) solo evalúa la 'mitad' apropiada (mitad izquierda si el valor es verdadero, mitad derecha si es falso), permitiendo el uso de expresiones como:

int x = (y == null) ? 0 : y.getFoo();

sin una excepción NullPointerException.

No, si a es verdadero (en una orprueba), b no se probará, ya que el resultado de la prueba siempre será verdadero, sea cual sea el valor de la expresión b.

Haz una prueba simple:

if (true || ((String) null).equals("foobar")) {
    ...
}

será no lanzar una NullPointerException!

Cortocircuito aquí significa que la segunda condición no será evaluada.

Si (A y B) dará como resultado un cortocircuito si A es falso.

Si (A y B) no generará un cortocircuito si A es verdadero.

Si (A || B) provocará un cortocircuito si A es verdadero.

Si (A || B) no provocará un cortocircuito si A es falso.

No, no lo hará, Java hará un cortocircuito y dejará de evaluar una vez que sepa el resultado.

Sí, la evaluación de cortocircuito para expresiones booleanas es el comportamiento predeterminado en toda la familia tipo C.

Un hecho interesante es que Java también usa los &y |como operandos lógicos (están sobrecargados, con inttipos son las operaciones bit a bit esperadas) para evaluar todos los términos en la expresión, lo que también es útil cuando necesita los efectos secundarios.

Esto se remonta a la diferencia básica entre & y &&, | y ||

Por cierto, realiza las mismas tareas muchas veces. No estoy seguro si la eficiencia es un problema. Puede eliminar parte de la duplicación.

Z z2 = partialHits.get(req_nr).get(z); // assuming a value cannout be null.
Z z3 = tmpmap.get(z); // assuming z3 cannot be null.
if(z2 == null || z2 < z3){   
    partialHits.get(z).put(z, z3);   
}