Una de las primeras lecciones que aprendemos cuando empezamos con Java es que “en Java, todo son objetos”. Por eso, a la hora de comparar dos Strings, no debemos hacerlo con el operador ==, ya que estaríamos comparando sus referencias de memoria y no su contenido.

Pero otro problema relacionado con la comparación de Strings puede surgir al usar la función equals y que, aunque sea menos evidente, puede provocar errores difíciles de detectar.

La mayoría de desarrolladores tenderíamos a montar la comparación en el siguiente orden (quizás porque nos centramos en nuestra variable), lo cual, si en algún momento diaSemana es nulo, genera una NullPointerException:

1
2
3

if( diaSemana.equals("SUNDAY") ){
	hacemosAlgo();
}

Para evitarlo, basta con invertir el orden, ya que SUNDAY nunca será nulo:

1
2
3

if( "SUNDAY".equals(diaSemana) ){
	hacemosAlgo();
}

¿Por qué este detalle importa en proyectos grandes?

Imaginemos que en nuestro desarrollo original, el valor de la variable diaSemana lo obtenemos mediante algún mecanismo que nos garantice que en ningún caso sea nulo. Por ejemplo:

1
2
3

public String obtenerDiaSemana(){
	return LocalDate.now().getDayOfWeek().name();
}

Por lo que la primera implementación de la comparativa de la variable con la cadena SUNDAY funcionaría correctamente y nuestro desarrollo iría a producción pasando los test.

Pero también podría pasar, que en una aplicación grande y donde tocan varios equipos, se realiza un desarrollo nuevo que podría consistir en que un usuario puede configurar en su perfil con una zona horaria específica.

De esta forma, ese segundo equipo cambia la implementación de la función obtenerDiaSemana para hacerlo de la siguiente manera (asumiendo que el contexto es la sesión en la aplicación):

1
2
3
4
5

public String obtenerDiaSemana() {
	Usuario usuario = contexto.getUsuarioActual();
	ZonaHoraria zona = usuario.getPreferencias().getZonaHoraria();
	return LocalDate.now(zona).getDayOfWeek().name();
}

De esta forma, una implementación determinista y segura, “imposible de romper”, pasa a depender de otros factores que podrían desencadenar en que la variable diaSemana en el punto en que se compara con un valor, pueda ser nula.

Aunque el segundo equipo podría haber detectado el fallo en pruebas, el primero habría evitado el problema desde el principio escribiendo código más robusto. Un pequeño detalle en apariencia, pero de los que separan código que funciona de código que sobrevive.