Java es, desde hace casi tres décadas, uno de los lenguajes más utilizados del mundo para construir software que tiene que funcionar durante años, en máquinas distintas y bajo carga real. Antes de escribir una sola línea de código conviene entender qué problema vino a resolver Java, cómo consigue ejecutarse en cualquier sistema operativo sin recompilar, y qué significan exactamente las siglas JDK, JRE y JVM que aparecerán en cada tutorial, cada error y cada oferta de trabajo. Esta lección te da ese mapa mental. También te presenta BiblioTech, el proyecto que construirás de principio a fin a lo largo del curso y que convertirá cada concepto abstracto en algo que funciona.

1. Qué es Java y qué problemas resuelve
2. El principio WORA: escribe una vez, ejecuta en cualquier sitio
3. JDK, JRE y JVM: tres piezas que se confunden constantemente
4. Las características del lenguaje, explicadas
5. Breve historia y el calendario de versiones LTS
6. Dónde se usa Java hoy
7. El proyecto del curso: BiblioTech
8. Errores Comunes y Consejos
9. Ejercicios

Java es un lenguaje de programación de propósito general, orientado a objetos y de tipado estático, junto con una plataforma de ejecución (la máquina virtual y su biblioteca estándar). Esta doble naturaleza es importante: cuando alguien dice "trabajo con Java" no se refiere solo a una sintaxis, sino a todo un ecosistema de herramientas, librerías y servidores que se apoyan en la misma máquina virtual.

Java nació en Sun Microsystems a principios de los noventa, en un contexto en el que programar aplicaciones portables era doloroso. Los problemas concretos que atacó fueron:

• La dependencia del sistema operativo y del procesador. Un programa escrito en C se compilaba a instrucciones nativas de una arquitectura concreta. Llevarlo de Windows a Solaris significaba recompilar y, casi siempre, reescribir partes. Java introdujo un formato intermedio (bytecode) que se ejecuta igual en cualquier máquina que tenga una JVM.
• La gestión manual de memoria. En C y C++ el programador reserva y libera memoria a mano. Olvidarse de liberar produce fugas; liberar dos veces o usar un puntero ya liberado produce corrupciones difíciles de depurar. Java delegó eso en un recolector de basura automático.
• La aritmética de punteros y los desbordamientos. Java eliminó los punteros manipulables por el programador y añadió comprobación de límites en los accesos a memoria indexada. Muchos fallos de seguridad clásicos simplemente no pueden ocurrir.
• La falta de una biblioteca estándar rica. Java se distribuyó desde el principio con clases para texto, fechas, colecciones, red, hilos y entrada/salida. No había que buscar una librería distinta por cada sistema operativo.

El resultado es un lenguaje pensado para software de larga vida: aplicaciones empresariales que se mantienen diez o quince años, con equipos que rotan y donde la legibilidad y la estabilidad valen más que la brillantez sintáctica.

El eslogan histórico de Java es WORA (Write Once, Run Anywhere): escribes el código una sola vez y se ejecuta en cualquier plataforma sin cambios. Esto no es magia, es una consecuencia directa de cómo se compila y ejecuta un programa Java.

1. Escribes un fichero de código fuente con extensión .java. Es texto plano legible por humanos.
2. El compilador javac lo traduce a bytecode, un juego de instrucciones intermedio, y lo guarda en un fichero .class. Ese bytecode no es específico de Windows, Linux ni macOS: es específico de la máquina virtual de Java.
3. La JVM (Java Virtual Machine) instalada en cada sistema lee ese .class y lo ejecuta. Internamente, un compilador JIT (Just-In-Time) traduce las partes más usadas del bytecode a instrucciones nativas del procesador real, para que el rendimiento sea alto.

La clave está en la bifurcación final: lo que se distribuye es el bytecode, y lo que cambia entre sistemas es la JVM, no tu programa. Cuando compilas el fichero BiblioTechApp.java en tu portátil y envías el .class resultante a un servidor Linux, ese servidor lo ejecuta sin recompilar nada.

WORA es real, pero conviene conocer sus límites desde el principio:

• Un programa compilado con un JDK 21 no se ejecuta en una JVM 17. La compatibilidad es hacia adelante (una JVM nueva ejecuta bytecode antiguo), no hacia atrás. Por eso la versión importa tanto.
• Si tu código usa rutas como C:\datos\libros.txt o llama a comandos del sistema, has introducido una dependencia de plataforma tú mismo. Java te da las herramientas para evitarlo, no te obliga a usarlas.
• Detalles como la codificación de caracteres por defecto o el separador de línea han variado históricamente entre sistemas. Java moderno (17+) ha unificado buena parte de esto, por ejemplo fijando UTF-8 como codificación por defecto a partir de Java 18.

Esta es probablemente la confusión número uno de quien empieza. Las tres siglas describen capas concéntricas: el JDK contiene al JRE, y el JRE contiene a la JVM.

La regla práctica es simple: como desarrollador instalas el JDK y te olvidas del resto. El JRE por separado dejó de distribuirse a partir de Java 11; hoy se asume que quien ejecuta Java tiene un JDK completo o una imagen reducida creada con jlink.

Una analogía que suele funcionar: la JVM es el motor de un coche, el JRE es el coche completo listo para conducir, y el JDK es el coche más el taller con todas las herramientas para fabricar coches nuevos.

Las listas de "características de Java" suelen ser inútiles porque enumeran adjetivos sin explicarlos. Veamos qué significa cada uno en la práctica.

En Java, el código se organiza en clases: plantillas que agrupan datos y las operaciones sobre esos datos. En lugar de tener por un lado unas variables sueltas con el título, el autor y el ISBN de un libro, y por otro unas funciones que operan sobre ellas, defines una clase Libro que contiene ambas cosas. Eso hace que el código crezca de forma ordenada: cuando el sistema tiene doscientas entidades distintas, cada una sabe cuidar de sus propios datos.

En este primer módulo trabajarás solo con variables sueltas dentro de un main, precisamente para que sientas la incomodidad de hacerlo así. En el módulo 3 convertirás esas variables en clases y verás la diferencia con tus propios ojos.

Cada variable declara de qué tipo es, y el compilador comprueba antes de ejecutar que no haces operaciones imposibles. Si declaras que anioPublicacion es un número entero e intentas guardarle el texto "desconocido", el programa no llega a compilar. Esto tiene un coste (hay que escribir más) y una gran ventaja: una familia entera de errores se detecta en tu máquina, en segundos, y no en producción a las tres de la madrugada.

Cuando creas objetos, Java reserva memoria por ti en una zona llamada heap. Cuando dejan de ser accesibles, un proceso en segundo plano llamado recolector de basura (garbage collector) libera esa memoria. No escribes free() ni delete. Esto elimina las fugas más comunes y los accesos a memoria liberada, aunque no te exime de pensar: guardar referencias a millones de objetos en una lista que nunca vacías sigue siendo una fuga, solo que de otro tipo.

Ya la hemos visto: es la consecuencia del bytecode y la JVM. Su valor práctico es que puedes desarrollar en un portátil con Windows o macOS y desplegar en un servidor Linux con la certeza razonable de que el comportamiento será el mismo.

Java hace muchas comprobaciones en tiempo de ejecución que otros lenguajes omiten: los accesos fuera de rango se detectan, las conversiones inválidas de tipo se detectan, y los errores se comunican mediante excepciones, un mecanismo estructurado para propagar y tratar fallos (lo verás a fondo en el módulo 6). El efecto es que un programa Java que falla suele hacerlo de forma ruidosa y localizable, con una traza que dice exactamente en qué línea ocurrió.

Java incorporó hilos de ejecución en el propio lenguaje desde la versión 1.0, algo poco habitual en su época. Un programa Java puede atender a miles de peticiones simultáneas, y la biblioteca estándar trae colas, pools de hilos y estructuras seguras para ello. Es una de las razones de su dominio en servidores. Lo trabajarás en el módulo 8, cuando BiblioTech tenga que enviar recordatorios en segundo plano sin bloquear al usuario.

Java se publicó en 1995 bajo el paraguas de Sun Microsystems. Oracle adquirió Sun en 2010 y desde entonces mantiene el lenguaje junto con una comunidad amplia (el proyecto OpenJDK, que es la implementación de referencia y de código abierto).

Los hitos que más te afectan como desarrollador:

Desde 2018 Java publica una versión nueva cada seis meses (marzo y septiembre). La mayoría son versiones de feature release, con soporte solo hasta que sale la siguiente. Cada dos o tres años una de ellas se designa LTS (Long-Term Support): recibe actualizaciones de seguridad y correcciones durante años.

Las LTS actuales son 8, 11, 17 y 21 (y 25, publicada en 2025). Las implicaciones prácticas:

• En producción se usan casi siempre versiones LTS. Ninguna empresa quiere actualizar la base de su plataforma cada seis meses.
• Java 17 es hoy el mínimo razonable para un proyecto nuevo, y Java 21 es la elección más habitual si no hay restricciones. Este curso usa Java 17 como referencia y señala explícitamente lo que requiere una versión superior.
• Java 8 sigue vivo en muchísimo código empresarial heredado. Si entras en una empresa con una base de código antigua, es muy posible que te encuentres con él. Todo lo que aprendas aquí sigue siendo válido; simplemente algunas comodidades modernas no estarán disponibles.

Conviene saber qué puertas abre lo que estás aprendiendo:

• Backend empresarial. Es su terreno dominante. Bancos, aseguradoras, telecomunicaciones, administraciones públicas y comercio electrónico ejecutan sus servicios centrales sobre Java, normalmente con Spring Boot (módulo 11). Los sistemas que mueven dinero y que no pueden caerse suelen estar escritos en Java.
• Android. Durante años, el desarrollo Android fue Java puro. Hoy Kotlin es el lenguaje recomendado, pero Kotlin se ejecuta sobre la misma máquina virtual, interopera con Java y comparte librerías. Saber Java sigue siendo una base directa para el desarrollo móvil.
• Big data y procesamiento distribuido. Hadoop, Spark, Kafka, Elasticsearch, Flink: la infraestructura de datos moderna está escrita mayoritariamente en Java o Scala sobre la JVM.
• Herramientas y sistemas. IDEs como IntelliJ IDEA y Eclipse, servidores de integración como Jenkins, bases de datos como Cassandra y Neo4j.
• Sistemas embebidos y tarjetas inteligentes, un nicho menos visible pero real.

Aprender a programar leyendo ejemplos desconectados entre sí no funciona. Por eso este curso construye un único sistema real, de forma incremental, desde la primera lección hasta la última.

Nexus Software es una empresa de desarrollo con unas doscientas personas. Tiene una biblioteca técnica interna: varios cientos de libros de programación, arquitectura y gestión que los empleados toman prestados. Hasta ahora se gestionaba con una hoja de cálculo compartida, con los problemas previsibles: nadie sabe quién tiene qué, los libros desaparecen y no hay forma de saber cuánto tiempo lleva prestado cada ejemplar.

Tu encargo es construir BiblioTech, el sistema que sustituya esa hoja de cálculo.

Los datos con los que trabajarás durante todo el curso serán siempre los mismos, para que puedas centrarte en el concepto nuevo y no en entender el ejemplo:

Al terminar el curso habrás construido, paso a paso y entendiendo cada decisión, una aplicación con catálogo de libros, gestión de préstamos y reservas, cálculo de multas, importación y exportación de datos, tareas en segundo plano, acceso remoto, pruebas automatizadas y una interfaz web desplegada. No será un juguete: será un proyecto que puedes enseñar.

En este módulo 1 escribirás la primera versión de BiblioTechApp: un programa lineal, sin repeticiones ni decisiones complejas, que pide por consola los datos de un préstamo y emite un recibo con la multa calculada. Todo con un único método main, variables, operadores y entrada/salida por consola. Es deliberadamente limitado, y en la lección 01-07 analizaremos exactamente qué le falta y qué módulo lo resolverá.

• Confundir el lenguaje Java con JavaScript. No tienen relación técnica alguna más allá del nombre, que fue una decisión de marketing de los años noventa. Sintaxis, ejecución y ecosistema son distintos.
• Instalar un JRE en lugar de un JDK. Es el clásico "¿por qué no funciona javac?". Sin JDK no tienes compilador. Lo resolveremos en la lección siguiente.
• Creer que WORA significa "funciona en cualquier versión". El bytecode es portable entre sistemas operativos, no entre versiones de JVM hacia atrás. Compilar con JDK 21 y ejecutar en JVM 17 produce el error UnsupportedClassVersionError.
• Elegir la última versión sin más. Para aprender, cualquier LTS reciente vale. Para un proyecto real, comprueba primero qué versión soportan tu framework, tu servidor y tu proveedor de nube.
• Consejo de método: teclea todos los ejemplos del curso a mano, sin copiar y pegar. Los errores de compilación que cometerás al hacerlo son parte esencial del aprendizaje, y aprender a leerlos (lección 01-03) te ahorrará cientos de horas.
• Consejo de recursos: acostúmbrate desde el primer día a consultar la documentación oficial de la API de Java. Es densa al principio, pero es la fuente de verdad y todo desarrollador Java la usa a diario.

Explica con tus palabras, y sin mirar el texto, qué ocurre desde que guardas un fichero BiblioTechApp.java hasta que ves el resultado en pantalla. Menciona los nombres de los ficheros intermedios y las herramientas implicadas. Después, responde: si envías únicamente el fichero .class a un compañero que usa Linux mientras tú usas Windows, ¿podrá ejecutarlo? ¿Y si tú compilaste con JDK 21 y él tiene instalada una JVM 17?

Nexus Software va a arrancar BiblioTech como proyecto nuevo. El equipo de sistemas mantiene otra aplicación que corre sobre Java 8 y pregunta si BiblioTech debería usar la misma versión "para simplificar". Elabora una recomendación razonada de tres o cuatro puntos: qué versión elegirías, qué argumentos darías, y qué riesgo real hay en cada opción.

Busca tres aplicaciones o plataformas que uses (o de las que hayas oído hablar) y averigua si están construidas total o parcialmente sobre la JVM. Para cada una, anota qué parte del sistema usa Java y por qué crees que se eligió ese lenguaje en lugar de otro.

Solución 1

El recorrido tiene tres etapas:

1. Edición. BiblioTechApp.java es texto plano. No es ejecutable; ninguna máquina lo entiende directamente.
2. Compilación. La herramienta javac, incluida en el JDK, lee el .java, comprueba que la sintaxis y los tipos son correctos y genera BiblioTechApp.class con bytecode. Si hay un error de tipos o de sintaxis, este paso falla y no se genera nada.
3. Ejecución. El comando java arranca una JVM, que carga el .class, verifica el bytecode e inicia su ejecución. El compilador JIT traduce a instrucciones nativas las partes que más se ejecutan, y el recolector de basura gestiona la memoria en paralelo.

Sobre las dos preguntas:

• Windows → Linux: sí funciona. Es exactamente el propósito de WORA. El .class no contiene instrucciones de x86 ni de ARM, sino bytecode; la JVM de Linux lo traduce a lo que necesite esa máquina.
• JDK 21 → JVM 17: no funciona. El fichero .class lleva grabado un número de versión de formato. Una JVM 17 se niega a cargar un .class generado para 21 y lanza UnsupportedClassVersionError. La compatibilidad de Java es hacia adelante (una JVM nueva ejecuta clases antiguas), no hacia atrás. Si necesitas compilar con un JDK moderno pero ejecutar en una JVM antigua, existe la opción javac --release 17, que genera bytecode compatible con esa versión.

Solución 2

Una recomendación defendible sería:

1. Elegiría Java 21 (o, en su defecto, Java 17). Ambas son LTS, con soporte y actualizaciones de seguridad garantizadas durante años, y son las versiones que esperan hoy los frameworks del ecosistema.
2. Argumento de productividad. Java 17 y 21 aportan características que reducen código repetitivo y errores: registros para modelar datos, switch como expresión, coincidencia de patrones, text blocks. En un proyecto como BiblioTech, que va a modelar libros, empleados y préstamos, esto se nota desde el primer día.
3. Argumento de compatibilidad con el ecosistema. Las versiones actuales de Spring Boot exigen Java 17 como mínimo. Empezar en Java 8 cerraría la puerta a las versiones soportadas del framework que usaremos en el módulo 11.
4. El riesgo real de cada opción. Elegir Java 21 no obliga a tocar la aplicación existente: dos aplicaciones pueden convivir en el mismo servidor con JVMs distintas, y hoy es habitual que cada servicio empaquete la suya (por ejemplo, en un contenedor). El riesgo verdadero está en la opción contraria: arrancar un proyecto nuevo en 2026 sobre Java 8 significa nacer con deuda técnica, sobre una versión cuyo soporte es de pago o limitado y que muchas librerías modernas ya no admiten.

Conclusión de la recomendación: la simplificación que propone el equipo de sistemas es aparente; el coste de mantener una versión obsoleta en un proyecto nuevo supera con mucho el de gestionar dos versiones.

Solución 3

No hay una única respuesta correcta, pero un buen desarrollo del ejercicio debería identificar patrones como estos:

• Una aplicación bancaria móvil. El backend (cuentas, transferencias, antifraude) suele ser Java con Spring. Motivos: madurez, transaccionalidad, disponibilidad de perfiles profesionales y décadas de código probado en el sector financiero.
• Una aplicación Android. La aplicación se ejecuta sobre ART, una máquina virtual que ejecuta bytecode derivado del de Java. Aunque hoy se escriba en Kotlin, todo el modelo de ejecución y buena parte de la API son herencia directa de Java.
• Un buscador interno o una plataforma de análisis. Elasticsearch está escrito en Java; Kafka y Spark también. Motivo: la JVM ofrece un rendimiento muy alto con gestión automática de memoria, excelente soporte de concurrencia y portabilidad entre los miles de servidores de un clúster.

Lo relevante del ejercicio no es acertar el dato, sino observar el patrón: Java domina donde importan la fiabilidad a largo plazo, la concurrencia y el mantenimiento por equipos grandes, más que donde importa escribir el prototipo en dos tardes.

Ya tienes el mapa. Java es a la vez un lenguaje y una plataforma; su portabilidad viene de compilar a bytecode y ejecutarlo sobre una JVM específica de cada sistema; el JDK es lo que instalarás porque contiene el compilador, el JRE y la JVM; y las versiones LTS (8, 11, 17, 21) marcan el ritmo real de la industria, con Java 17 como referencia de este curso. Sabes también que Java vive sobre todo en el backend empresarial, en Android y en la infraestructura de datos, y conoces el proyecto BiblioTech que darás forma módulo a módulo para Nexus Software.

Con la teoría situada, toca preparar el terreno. En la siguiente lección, Configuración del Entorno de Desarrollo, instalarás un JDK en tu sistema, comprobarás que java y javac responden, entenderás para qué sirven JAVA_HOME y PATH, compilarás y ejecutarás tu primer fichero desde la terminal, conocerás JShell y elegirás el IDE con el que trabajarás el resto del curso.