Los operadores son los verbos del lenguaje: lo que convierte datos inertes en cálculos. Ya has usado + y - de forma intuitiva, pero Java tiene un catálogo amplio y varias trampas que atrapan a todo el mundo al menos una vez: la división entre enteros que descarta los decimales, la diferencia entre i++ e ++i, la comparación de cadenas con == que a veces funciona y a veces no, y la precisión traicionera de double cuando hay dinero de por medio. Esta lección los recorre todos con calma, siempre sobre el mismo caso de BiblioTech: calcular la multa por retraso de un préstamo de la biblioteca de Nexus Software.

1. Operadores aritméticos y la trampa de la división entera
2. El operador módulo
3. Operadores de asignación compuesta
4. Incremento y decremento: pre y post
5. Operadores relacionales
6. Operadores lógicos y evaluación de cortocircuito
7. El operador ternario
8. Operadores a nivel de bit y desplazamiento
9. El operador instanceof
10. Precedencia y asociatividad
11. Comparar cadenas: == frente a equals
12. La precisión de double y por qué existe BigDecimal
13. Errores Comunes y Consejos
14. Ejercicios

Los cinco operadores aritméticos básicos:

Es el error número uno de quien empieza en Java:

La regla es la siguiente: si ambos operandos son enteros, la división es entera y el resultado se trunca hacia cero, descartando los decimales. Java no redondea, corta.

Y esto no se arregla guardando el resultado en un double:

¿Por qué? Porque la operación total / partes se evalúa primero, entre enteros, dando 2; solo después ese 2 se convierte a double. La conversión llega demasiado tarde.

Las tres soluciones correctas:

Ojo con el orden en el cast: (double)(total / partes) no funciona. Los paréntesis hacen que se divida primero entre enteros y se convierta después: da 2.0. El cast tiene que aplicarse a uno de los operandos.

Depende del tipo, y la diferencia es importante:

La división entera por cero lanza un error de ejecución. La división decimal produce valores especiales (Infinity, NaN) que se propagan silenciosamente por todos los cálculos posteriores, lo que puede ser peor: acabas mostrando NaN EUR en un recibo sin haber visto ningún error.

Aquí diasRetraso es int y TARIFA_DIARIA es double: Java promociona el entero a decimal antes de multiplicar y el resultado es correcto. La promoción automática nos salva; la división es la única que hay que vigilar.

% devuelve el resto de una división entera. Es mucho más útil de lo que parece a primera vista.

Usos habituales:

Aplicado a BiblioTech, para expresar el retraso en semanas y días sueltos:

Fíjate en cómo / y % trabajan en pareja: uno da el cociente, el otro lo que sobra. Es un patrón que reaparecerá muchas veces.

Son atajos para operar sobre una variable y guardar el resultado en ella misma:

Hay un detalle poco conocido: la asignación compuesta incluye un cast implícito. Esto compila:

mientras que la forma "larga" equivalente no compila:

Es una asimetría del lenguaje que puede ocultar pérdidas de precisión sin ningún aviso. Merece la pena conocerla.

++ suma 1 y -- resta 1. Lo interesante es que se pueden escribir antes o después de la variable, y eso cambia el valor de la expresión:

• Post-incremento x++: usa el valor actual, y después incrementa.
• Pre-incremento ++x: incrementa primero, y después usa el valor nuevo.

La tabla resume la diferencia partiendo siempre de x = 5:

Cuándo importa de verdad: si el ++ está solo en su propia línea (contador++;), pre y post son idénticos y da igual cuál uses. La diferencia solo se manifiesta cuando el valor de la expresión se usa para algo, como en una asignación, un índice o un argumento.

Consejo práctico: no escribas expresiones que dependan de esa sutileza. Código como int x = i++ + ++i; es un acertijo, no un programa. Cuando importe, sepáralo en dos líneas claras.

Comparan dos valores y siempre producen un boolean:

Repite la idea de la lección anterior: una comparación es una expresión que vale true o false por sí misma. No necesitas un if para obtenerla; el if (módulo 2) sirve para decidir qué hacer con ella.

Dos advertencias:

• == compara valores en primitivos, pero referencias en objetos. Es el tema del apartado 11.
• El error tipográfico más caro de la programación es escribir = (asignación) donde querías == (comparación). En Java, afortunadamente, if (x = 5) no compila salvo que x sea boolean, porque una asignación de int no produce un boolean. El compilador te protege.

Combinan valores booleanos:

Tablas de verdad:

Aplicado a BiblioTech:

Esta es la parte importante. && y || son perezosos: dejan de evaluar en cuanto el resultado ya está decidido.

• En a && b, si a es false, el resultado es false pase lo que pase con b. b no se evalúa.
• En a || b, si a es true, el resultado es true pase lo que pase con b. b no se evalúa.

¿Por qué importa? Porque permite proteger operaciones peligrosas colocando la comprobación de seguridad primero:

El orden de las condiciones no es estético: es funcional. Recuérdalo, porque es un patrón que usarás constantemente a partir del módulo 6.

Existen & y | aplicados a booleanos, que siempre evalúan ambos lados:

En la práctica se usan && y || casi siempre. Recuerda que & y | tienen además otro significado completamente distinto sobre números, que es el siguiente apartado.

Es el único operador de Java con tres operandos. Su forma es:

Se lee: "si la condición es verdadera, el resultado es lo primero; si no, lo segundo".

Esta línea hace algo muy valioso para nosotros: evita que el retraso sea negativo. Si el libro se devuelve a los 10 días, 10 - 15 daría -5, y una multa negativa sería un absurdo (¡la biblioteca pagando al empleado!). El ternario nos permite corregirlo sin usar if, que todavía no hemos visto.

El uso más habitual es adaptar un texto:

Se pueden anidar, pero la legibilidad se degrada muy rápido:

Regla práctica: el ternario es excelente para elegir un valor; en cuanto quieras ejecutar varias acciones distintas, necesitas un if, que llega en la lección 02-01.

Estos operadores trabajan sobre la representación binaria de los números enteros. Al principio parecen esotéricos, pero aparecen en permisos, banderas, criptografía, procesamiento de imágenes y protocolos de red, y en las entrevistas técnicas.

Recordatorio: un int son 32 bits. El número 12 es 00000000 00000000 00000000 00001100, y el 10 es ...00001010.

El resultado de ~12 = -13 sorprende. La razón es que Java representa los enteros negativos en complemento a dos, donde ~x equivale siempre a -x - 1.

La relación con la aritmética es directa y muy fácil de recordar:

• x << n equivale a multiplicar por 2ⁿ
• x >> n equivale a dividir entre 2ⁿ (división entera)

El caso donde estos operadores brillan de verdad es empaquetar varias opciones booleanas en un solo entero. En BiblioTech podríamos codificar los permisos de un empleado sobre el catálogo:

Cuatro booleanos en un solo int, con comprobaciones instantáneas. Es el mecanismo que usan por debajo los permisos de ficheros de Unix y muchísimas APIs.

instanceof comprueba si un objeto es de un tipo determinado y devuelve un boolean:

Solo se menciona aquí para completar el catálogo de operadores. Su verdadera utilidad aparece cuando existen jerarquías de tipos y polimorfismo, es decir, a partir del módulo 3. Desde Java 16 admite además la coincidencia de patrones (if (obj instanceof String s)), que se estudia en el módulo 10.

Cuando una expresión combina varios operadores, Java aplica un orden fijo. De mayor a menor prioridad:

La asociatividad decide qué pasa cuando hay operadores del mismo nivel: 10 - 4 - 3 se agrupa como (10 - 4) - 3 = 3, no como 10 - (4 - 3) = 9.

Ejemplos donde la precedencia cambia el resultado:

Y un caso real de BiblioTech donde faltan paréntesis:

El consejo definitivo: no memorices la tabla. Usa paréntesis. Nadie ha perdido nunca una revisión de código por poner paréntesis de más, y sí muchas horas por confiar en la precedencia. Los paréntesis documentan tu intención.

Es el error clásico por excelencia de Java, y lo peor es que a veces funciona, lo que retrasa el diagnóstico durante semanas.

Recuerda de la lección anterior que una variable String no contiene el texto, sino una referencia a un objeto en el montículo. Y == sobre referencias compara si apuntan al mismo objeto, no si el contenido es igual.

La JVM mantiene un pool de cadenas (string pool): una zona especial donde guarda los literales. Cuando compila String a = "Java Efectivo"; y luego String b = "Java Efectivo";, ve que el literal es idéntico y hace que ambas variables apunten al mismo objeto del pool. Por eso a == b da true. Es una optimización de memoria, no una promesa del lenguaje.

Pero new String("Java Efectivo") fuerza la creación de un objeto nuevo, fuera del pool. Ahora hay dos objetos con el mismo texto en direcciones distintas, y == da false.

a == b compara #p1 == #p1 → true. a == c compara #p1 == #h9 → false. En ambos casos el texto es el mismo.

Para comparar el contenido de dos String, usa siempre equals(). Nunca ==.

Por qué el peligro es real: las cadenas que llegan de un Scanner, de un fichero o de la red no están en el pool. Así que tu comparación con == funcionará perfectamente en las pruebas con literales y fallará con datos reales.

Una técnica defensiva habitual es poner el literal a la izquierda, porque un literal nunca es null:

Resumen en tabla:

Un último aviso, particularmente relevante porque BiblioTech maneja dinero:

Esto no es un fallo de Java: ocurre en Python, JavaScript, C y prácticamente en todos los lenguajes. La causa es que float y double siguen el estándar IEEE 754, que representa los números en binario. Del mismo modo que en decimal no puedes escribir 1/3 exactamente (0,3333…), en binario no puedes escribir 0,1 exactamente. El valor almacenado es una aproximación buenísima, pero aproximación.

Consecuencias prácticas:

• Nunca compares dos double con ==. Compara si su diferencia es menor que una tolerancia: Math.abs(a - b) < 0.0001.
• Nunca uses double para dinero en un sistema real. Los errores se acumulan a lo largo de miles de operaciones y acaban descuadrando la contabilidad.

La solución de Java es la clase BigDecimal, que representa decimales con precisión exacta y permite controlar el redondeo:

Tiene su coste: es más verboso (no se puede usar +, hay que llamar a add()) y más lento. Se estudia en el módulo 10; en este curso seguiremos usando double para las multas de BiblioTech porque el foco está en aprender el lenguaje, pero quedas advertido: en un sistema de facturación real, BigDecimal.

• 5 / 2 da 2. División entera. Aplica un cast a uno de los operandos: (double) 5 / 2.
• (double)(5 / 2) sigue dando 2.0. El cast llega después de la división. Debe aplicarse a un operando, no al resultado.
• Comparar String con ==. Funciona con literales y falla con datos de entrada. Usa equals() siempre.
• Comparar double con ==. Usa una tolerancia.
• Olvidar paréntesis en (a - b) * c. La multiplicación tiene más prioridad que la resta.
• Confundir & con &&. Sobre booleanos, && evita evaluar el segundo operando; & no. Sobre enteros, & es una operación bit a bit completamente distinta.
• Ordenar mal las condiciones protegidas. x != null && x.length() > 0, nunca al revés.
• Escribir expresiones acrobáticas con ++. Si tienes que pararte a pensar, refactorízalo en dos líneas.
• Consejo: usa paréntesis siempre que la expresión tenga más de dos operadores. No hay penalización de rendimiento y la ganancia en claridad es enorme.
• Consejo: Integer.toBinaryString(n) es la mejor herramienta para entender los operadores de bits. Pruébalo en JShell.
• Consejo: el ternario es perfecto para saturar valores a cero (x > 0 ? x : 0), un patrón que usarás mucho en BiblioTech para que los días de retraso nunca sean negativos.

Sin ejecutar el código, escribe la salida de cada línea y justifica el porqué.

Escribe la clase CalculadoraMulta que, a partir de las siguientes constantes y datos, calcule y muestre la liquidación de un préstamo:

• Constantes: DIAS_PRESTAMO = 15, TARIFA_DIARIA = 0.25, MULTA_MAXIMA = 20.0, RECARGO_GRAVE = 1.5 (multiplicador que se aplica si el retraso supera los 30 días).
• Datos del préstamo: empleado "Diego Alonso", libro "Refactorizacion", diasTranscurridos = 52.

Debe calcular y mostrar:

1. Los días de retraso, que nunca pueden ser negativos (usa el operador ternario).
2. El retraso expresado en semanas completas y días sueltos (usa / y %).
3. La multa base (diasRetraso * TARIFA_DIARIA).
4. La multa con recargo si el retraso supera 30 días (usa el ternario).
5. La multa final, sin superar nunca MULTA_MAXIMA (usa el ternario).
6. Una etiqueta de gravedad: "EN PLAZO", "LEVE" (1-7 días) o "GRAVE" (más de 7), con ternarios anidados.

Todo sin usar if.

Usando los operadores a nivel de bit, escribe la clase PermisosBiblioTech que:

1. Defina cuatro constantes de permiso con valores 1, 2, 4 y 8: consultar, prestar, reservar y administrar.
2. Componga los permisos de tres empleados de Nexus Software: Marta Ruiz (consultar + prestar), Diego Alonso (consultar + prestar + reservar) y Nuria Vidal (los cuatro).
3. Muestre para cada uno el valor entero de sus permisos, su representación binaria y si puede administrar.
4. Añada el permiso de reservar a Marta Ruiz usando |= y muestre el resultado.

Solución 1

Justificaciones:

• 7 / 2 → 3. Ambos operandos son int: división entera truncada.
• 7 % 2 → 1. El resto de dividir 7 entre 2.
• 7.0 / 2 → 3.5. Al ser 7.0 un double, el 2 se promociona y la división es decimal.
• (double)(7 / 2) → 3.0. Los paréntesis fuerzan la división entera primero (3) y el cast llega después.
• x++ → 5, y a continuación x vale 6. El post-incremento devuelve el valor anterior.
• x → 6. Confirma el incremento previo.
• ++x → 7. El pre-incremento incrementa primero (7) y devuelve el valor nuevo.
• 2 + 3 * 4 → 14. * tiene más precedencia que +: se calcula 3*4=12 y luego 2+12.
• 10 - 4 - 3 → 3. Asociatividad por la izquierda: (10-4)-3.
• a == b → true. Ambos son literales idénticos, así que la JVM los comparte en el pool de cadenas y las dos referencias apuntan al mismo objeto.
• a == c → false. new String(...) crea un objeto distinto fuera del pool; las referencias difieren aunque el texto sea igual.
• a.equals(c) → true. equals compara el contenido, que sí es idéntico.
• 0.1 + 0.2 == 0.3 → false. La representación IEEE 754 de 0.1 y 0.2 es aproximada; la suma da 0.30000000000000004.
• 12 & 10 → 8. En binario, 1100 & 1010 = 1000, que es 8.
• 12 << 2 → 48. Desplazar 2 bits a la izquierda equivale a multiplicar por 2² = 4.

Solución 2

Salida:

Observa el 13.875: tres decimales para un importe en euros. Es exactamente el tipo de resultado que en un sistema real exigiría BigDecimal o, como mínimo, un formateo a dos decimales. Eso último lo resolveremos en la lección siguiente con printf.

Solución 3

Salida:

Dos detalles que merecen atención:

• Los paréntesis en (permisosMarta & ADMINISTRAR) != 0 son obligatorios, no opcionales. & tiene menos precedencia que !=, así que sin ellos Java intentaría evaluar permisosMarta & (ADMINISTRAR != 0), lo que ni siquiera compila por mezclar int y boolean.
• Integer.toBinaryString no muestra los ceros a la izquierda: el 3 aparece como 11, no como 0011. Es normal; representa el mismo valor.

Ya dominas el catálogo completo de operadores de Java: la aritmética con su trampa de la división entera, el módulo y su pareja natural con /, la asignación compuesta con su cast implícito oculto, el incremento pre y post y cuándo la diferencia importa, las comparaciones que producen booleanos, los operadores lógicos con la evaluación de cortocircuito que te permite proteger expresiones peligrosas, el ternario para elegir valores sin if, las operaciones a nivel de bit aplicadas a banderas de permisos, la precedencia y el consejo de usar paréntesis, la diferencia crítica entre == y equals explicada por el pool de cadenas, y las limitaciones de precisión de double que un día te llevarán a BigDecimal. Con eso, BiblioTech ya sabe calcular una multa completa: días de retraso saturados a cero, recargo por gravedad y tope máximo.

En la siguiente lección, Entrada y Salida por Consola, resolveremos lo que ha quedado feo en estos ejemplos: dejaremos de escribir importes como 13.875 y aprenderemos a formatear la salida con printf (%.2f, anchos, alineación), y sobre todo dejaremos de tener los datos escritos a fuego en el código para pedírselos al usuario con Scanner. Es el último ingrediente antes de construir la primera versión completa de BiblioTechApp.