Java és, des de fa gairebé tres dècades, un dels llenguatges més utilitzats del món per construir programari que ha de funcionar durant anys, en màquines diferents i sota càrrega real. Abans d'escriure ni una sola línia de codi val la pena entendre quin problema va venir a resoldre Java, com aconsegueix executar-se en qualsevol sistema operatiu sense recompilar, i què signifiquen exactament les sigles JDK, JRE i JVM que apareixeran a cada tutorial, a cada error i a cada oferta de feina. Aquesta lliçó et dona aquest mapa mental. També et presenta BiblioTech, el projecte que construiràs de dalt a baix al llarg del curs i que convertirà cada concepte abstracte en alguna cosa que funciona.

1. Què és Java i quins problemes resol
2. El principi WORA: escriu una vegada, executa a qualsevol lloc
3. JDK, JRE i JVM: tres peces que es confonen constantment
4. Les característiques del llenguatge, explicades
5. Breu història i el calendari de versions LTS
6. On s'utilitza Java avui
7. El projecte del curs: BiblioTech
8. Errors Habituals i Consells
9. Exercicis

Java és un llenguatge de programació de propòsit general, orientat a objectes i de tipatge estàtic, juntament amb una plataforma d'execució (la màquina virtual i la seva biblioteca estàndard). Aquesta doble naturalesa és important: quan algú diu "treballo amb Java" no es refereix només a una sintaxi, sinó a tot un ecosistema d'eines, llibreries i servidors que s'aguanten sobre la mateixa màquina virtual.

Java va néixer a Sun Microsystems a principis dels noranta, en un context en què programar aplicacions portables era dolorós. Els problemes concrets que va atacar van ser aquests:

• La dependència del sistema operatiu i del processador. Un programa escrit en C es compilava a instruccions natives d'una arquitectura concreta. Portar-lo de Windows a Solaris volia dir recompilar i, gairebé sempre, reescriure'n parts. Java va introduir un format intermedi (bytecode) que s'executa igual en qualsevol màquina que tingui una JVM.
• La gestió manual de memòria. En C i C++ el programador reserva i allibera memòria a mà. Oblidar-se d'alliberar provoca fuites; alliberar dues vegades o fer servir un punter ja alliberat provoca corrupcions difícils de depurar. Java va delegar això en un recol·lector de brossa automàtic.
• L'aritmètica de punters i els desbordaments. Java va eliminar els punters manipulables pel programador i va afegir comprovació de límits en els accessos a memòria indexada. Molts errors de seguretat clàssics senzillament no poden passar.
• La manca d'una biblioteca estàndard rica. Java es va distribuir des del principi amb classes per a text, dates, col·leccions, xarxa, fils i entrada/sortida. No calia buscar una llibreria diferent per a cada sistema operatiu.

El resultat és un llenguatge pensat per a programari de llarga vida: aplicacions empresarials que es mantenen deu o quinze anys, amb equips que van rotant i on la llegibilitat i l'estabilitat valen més que la brillantor sintàctica.

L'eslògan històric de Java és WORA (Write Once, Run Anywhere): escrius el codi una sola vegada i s'executa en qualsevol plataforma sense canvis. Això no és màgia, és una conseqüència directa de com es compila i s'executa un programa Java.

1. Escrius un fitxer de codi font amb extensió .java. És text pla llegible per humans.
2. El compilador javac el tradueix a bytecode, un joc d'instruccions intermedi, i el desa en un fitxer .class. Aquest bytecode no és específic de Windows, Linux ni macOS: és específic de la màquina virtual de Java.
3. La JVM (Java Virtual Machine) instal·lada a cada sistema llegeix aquest .class i l'executa. Internament, un compilador JIT (Just-In-Time) tradueix les parts més utilitzades del bytecode a instruccions natives del processador real, perquè el rendiment sigui alt.

La clau és a la bifurcació final: el que es distribueix és el bytecode, i el que canvia entre sistemes és la JVM, no pas el teu programa. Quan compiles el fitxer BiblioTechApp.java al teu portàtil i envies el .class resultant a un servidor Linux, aquell servidor l'executa sense recompilar res.

WORA és real, però convé conèixer-ne els límits des del principi:

• Un programa compilat amb un JDK 21 no s'executa en una JVM 17. La compatibilitat és cap endavant (una JVM nova executa bytecode antic), no cap enrere. Per això la versió importa tant.
• Si el teu codi utilitza camins com ara C:\dades\llibres.txt o crida ordres del sistema, has introduït tu mateix una dependència de plataforma. Java et dona les eines per evitar-ho, no t'obliga a fer-les servir.
• Detalls com la codificació de caràcters per defecte o el separador de línia han variat històricament entre sistemes. El Java modern (17+) ha unificat bona part d'això; per exemple, fixant UTF-8 com a codificació per defecte a partir de Java 18.

Aquesta és probablement la confusió número u de qui comença. Les tres sigles descriuen capes concèntriques: el JDK conté el JRE, i el JRE conté la JVM.

La regla pràctica és senzilla: com a desenvolupador instal·les el JDK i t'oblides de la resta. El JRE per separat va deixar de distribuir-se a partir de Java 11; avui s'assumeix que qui executa Java té un JDK complet o una imatge reduïda creada amb jlink.

Una analogia que sol funcionar: la JVM és el motor d'un cotxe, el JRE és el cotxe sencer a punt per conduir, i el JDK és el cotxe més el taller amb totes les eines per fabricar cotxes nous.

Les llistes de "característiques de Java" solen ser inútils perquè enumeren adjectius sense explicar-los. Vegem què vol dir cadascun a la pràctica.

En Java, el codi s'organitza en classes: plantilles que agrupen dades i les operacions sobre aquestes dades. En comptes de tenir per una banda unes quantes variables soltes amb el títol, l'autor i l'ISBN d'un llibre, i per l'altra unes funcions que hi operen, defineixes una classe Llibre que conté totes dues coses. Això fa que el codi creixi de manera ordenada: quan el sistema té dues-centes entitats diferents, cadascuna sap tenir cura de les seves pròpies dades.

En aquest primer mòdul treballaràs només amb variables soltes dins d'un main, precisament perquè sentis la incomoditat de fer-ho així. Al mòdul 3 convertiràs aquestes variables en classes i veuràs la diferència amb els teus propis ulls.

Cada variable declara de quin tipus és, i el compilador comprova abans d'executar que no facis operacions impossibles. Si declares que anyPublicacio és un nombre enter i hi intentes desar el text "desconegut", el programa no arriba a compilar. Això té un cost (cal escriure més) i un gran avantatge: una família sencera d'errors es detecta a la teva màquina, en segons, i no en producció a les tres de la matinada.

Quan crees objectes, Java reserva memòria per tu en una zona anomenada heap. Quan deixen de ser accessibles, un procés en segon pla anomenat recol·lector de brossa (garbage collector) allibera aquesta memòria. No escrius free() ni delete. Això elimina les fuites més habituals i els accessos a memòria alliberada, tot i que no t'estalvia de pensar: desar referències a milions d'objectes en una llista que no buides mai continua sent una fuita, només que d'una altra mena.

Ja l'hem vista: és la conseqüència del bytecode i la JVM. El seu valor pràctic és que pots desenvolupar en un portàtil amb Windows o macOS i desplegar en un servidor Linux amb la certesa raonable que el comportament serà el mateix.

Java fa moltes comprovacions en temps d'execució que altres llenguatges ometen: els accessos fora de rang es detecten, les conversions de tipus invàlides es detecten, i els errors es comuniquen mitjançant excepcions, un mecanisme estructurat per propagar i tractar fallades (ho veuràs a fons al mòdul 6). L'efecte és que un programa Java que falla ho sol fer de manera sorollosa i localitzable, amb una traça que diu exactament a quina línia va passar.

Java va incorporar fils d'execució en el mateix llenguatge des de la versió 1.0, una cosa poc habitual a la seva època. Un programa Java pot atendre milers de peticions simultànies, i la biblioteca estàndard porta cues, agrupacions de fils i estructures segures per fer-ho. És una de les raons del seu domini en servidors. Ho treballaràs al mòdul 8, quan BiblioTech hagi d'enviar recordatoris en segon pla sense bloquejar l'usuari.

Java es va publicar el 1995 sota el paraigua de Sun Microsystems. Oracle va adquirir Sun el 2010 i des d'aleshores manté el llenguatge juntament amb una comunitat àmplia (el projecte OpenJDK, que és la implementació de referència i de codi obert).

Les fites que més t'afecten com a desenvolupador:

Des del 2018 Java publica una versió nova cada sis mesos (març i setembre). La majoria són versions de feature release, amb suport només fins que surt la següent. Cada dos o tres anys una d'elles es designa LTS (Long-Term Support): rep actualitzacions de seguretat i correccions durant anys.

Les LTS actuals són la 8, l'11, la 17 i la 21 (i la 25, publicada el 2025). Les implicacions pràctiques:

• En producció s'utilitzen gairebé sempre versions LTS. Cap empresa no vol actualitzar la base de la seva plataforma cada sis mesos.
• Java 17 és avui el mínim raonable per a un projecte nou, i Java 21 és l'elecció més habitual si no hi ha restriccions. Aquest curs fa servir Java 17 com a referència i assenyala explícitament allò que requereix una versió superior.
• Java 8 continua viu en moltíssim codi empresarial heretat. Si entres en una empresa amb una base de codi antiga, és molt possible que te'l trobis. Tot el que aprenguis aquí continua sent vàlid; senzillament algunes comoditats modernes no hi seran disponibles.

Val la pena saber quines portes obre allò que estàs aprenent:

• Backend empresarial. És el seu terreny dominant. Bancs, asseguradores, telecomunicacions, administracions públiques i comerç electrònic executen els seus serveis centrals sobre Java, normalment amb Spring Boot (mòdul 11). Els sistemes que mouen diners i que no poden caure solen estar escrits en Java.
• Android. Durant anys, el desenvolupament d'Android va ser Java pur. Avui Kotlin és el llenguatge recomanat, però Kotlin s'executa sobre la mateixa màquina virtual, interopera amb Java i en comparteix llibreries. Saber Java continua sent una base directa per al desenvolupament mòbil.
• Big data i processament distribuït. Hadoop, Spark, Kafka, Elasticsearch, Flink: la infraestructura de dades moderna està escrita majoritàriament en Java o Scala sobre la JVM.
• Eines i sistemes. IDEs com IntelliJ IDEA i Eclipse, servidors d'integració com Jenkins, bases de dades com Cassandra i Neo4j.
• Sistemes encastats i targetes intel·ligents, un nínxol menys visible però real.

Aprendre a programar llegint exemples desconnectats entre ells no funciona. Per això aquest curs construeix un únic sistema real, de manera incremental, des de la primera lliçó fins a l'última.

Nexus Software és una empresa de desenvolupament amb unes dues-centes persones. Té una biblioteca tècnica interna: uns quants centenars de llibres de programació, arquitectura i gestió que els empleats prenen en préstec. Fins ara es gestionava amb un full de càlcul compartit, amb els problemes previsibles: ningú no sap qui té què, els llibres desapareixen i no hi ha manera de saber quant de temps fa que està prestat cada exemplar.

El teu encàrrec és construir BiblioTech, el sistema que substitueixi aquell full de càlcul.

Les dades amb què treballaràs durant tot el curs seran sempre les mateixes, perquè puguis centrar-te en el concepte nou i no a entendre l'exemple:

Quan acabis el curs hauràs construït, pas a pas i entenent cada decisió, una aplicació amb catàleg de llibres, gestió de préstecs i reserves, càlcul de multes, importació i exportació de dades, tasques en segon pla, accés remot, proves automatitzades i una interfície web desplegada. No serà una joguina: serà un projecte que pots ensenyar.

En aquest mòdul 1 escriuràs la primera versió de BiblioTechApp: un programa lineal, sense repeticions ni decisions complexes, que demana per consola les dades d'un préstec i emet un rebut amb la multa calculada. Tot amb un únic mètode main, variables, operadors i entrada/sortida per consola. És deliberadament limitat, i a la lliçó 01-07 analitzarem exactament què li falta i quin mòdul ho resoldrà.

• Confondre el llenguatge Java amb JavaScript. No tenen cap relació tècnica més enllà del nom, que va ser una decisió de màrqueting dels anys noranta. Sintaxi, execució i ecosistema són diferents.
• Instal·lar un JRE en comptes d'un JDK. És el clàssic "per què no funciona javac?". Sense JDK no tens compilador. Ho resoldrem a la lliçó següent.
• Creure que WORA vol dir "funciona en qualsevol versió". El bytecode és portable entre sistemes operatius, no entre versions de JVM cap enrere. Compilar amb JDK 21 i executar en JVM 17 produeix l'error UnsupportedClassVersionError.
• Triar l'última versió sense pensar-hi. Per aprendre, qualsevol LTS recent serveix. Per a un projecte real, comprova primer quina versió admeten el teu framework, el teu servidor i el teu proveïdor de núvol.
• Consell de mètode: tecleja tots els exemples del curs a mà, sense copiar i enganxar. Els errors de compilació que cometràs en fer-ho són part essencial de l'aprenentatge, i aprendre a llegir-los (lliçó 01-03) t'estalviarà centenars d'hores.
• Consell de recursos: acostuma't des del primer dia a consultar la documentació oficial de l'API de Java. És densa al principi, però és la font de veritat i tot desenvolupador Java la fa servir cada dia.

Explica amb les teves paraules, i sense mirar el text, què passa des que deses un fitxer BiblioTechApp.java fins que veus el resultat a la pantalla. Esmenta els noms dels fitxers intermedis i les eines implicades. Després, respon: si envies només el fitxer .class a un company que fa servir Linux mentre tu fas servir Windows, el podrà executar? I si tu vas compilar amb JDK 21 i ell té instal·lada una JVM 17?

Nexus Software arrencarà BiblioTech com a projecte nou. L'equip de sistemes manté una altra aplicació que corre sobre Java 8 i pregunta si BiblioTech hauria de fer servir la mateixa versió "per simplificar". Elabora una recomanació raonada de tres o quatre punts: quina versió triaries, quins arguments donaries, i quin risc real hi ha en cada opció.

Busca tres aplicacions o plataformes que facis servir (o de les quals hagis sentit a parlar) i esbrina si estan construïdes totalment o parcialment sobre la JVM. Per a cadascuna, anota quina part del sistema fa servir Java i per què creus que es va triar aquest llenguatge en comptes d'un altre.

Solució 1

El recorregut té tres etapes:

1. Edició. BiblioTechApp.java és text pla. No és executable; cap màquina no l'entén directament.
2. Compilació. L'eina javac, inclosa en el JDK, llegeix el .java, comprova que la sintaxi i els tipus siguin correctes i genera BiblioTechApp.class amb bytecode. Si hi ha un error de tipus o de sintaxi, aquest pas falla i no es genera res.
3. Execució. L'ordre java arrenca una JVM, que carrega el .class, verifica el bytecode i n'inicia l'execució. El compilador JIT tradueix a instruccions natives les parts que més s'executen, i el recol·lector de brossa gestiona la memòria en paral·lel.

Sobre les dues preguntes:

• Windows → Linux: sí que funciona. És exactament el propòsit de WORA. El .class no conté instruccions d'x86 ni d'ARM, sinó bytecode; la JVM de Linux el tradueix al que necessiti aquella màquina.
• JDK 21 → JVM 17: no funciona. El fitxer .class porta gravat un número de versió de format. Una JVM 17 es nega a carregar un .class generat per a la 21 i llança UnsupportedClassVersionError. La compatibilitat de Java és cap endavant (una JVM nova executa classes antigues), no cap enrere. Si necessites compilar amb un JDK modern però executar en una JVM antiga, existeix l'opció javac --release 17, que genera bytecode compatible amb aquella versió.

Solució 2

Una recomanació defensable seria aquesta:

1. Triaria Java 21 (o, si no pot ser, Java 17). Totes dues són LTS, amb suport i actualitzacions de seguretat garantides durant anys, i són les versions que esperen avui els frameworks de l'ecosistema.
2. Argument de productivitat. Java 17 i 21 aporten característiques que redueixen codi repetitiu i errors: registres per modelar dades, switch com a expressió, coincidència de patrons, text blocks. En un projecte com BiblioTech, que modelarà llibres, empleats i préstecs, això es nota des del primer dia.
3. Argument de compatibilitat amb l'ecosistema. Les versions actuals de Spring Boot exigeixen Java 17 com a mínim. Començar amb Java 8 tancaria la porta a les versions amb suport del framework que farem servir al mòdul 11.
4. El risc real de cada opció. Triar Java 21 no obliga a tocar l'aplicació existent: dues aplicacions poden conviure al mateix servidor amb JVM diferents, i avui és habitual que cada servei empaqueti la seva (per exemple, dins d'un contenidor). El risc veritable és a l'opció contrària: arrencar un projecte nou el 2026 sobre Java 8 vol dir néixer amb deute tècnic, sobre una versió el suport de la qual és de pagament o limitat i que moltes llibreries modernes ja no admeten.

Conclusió de la recomanació: la simplificació que proposa l'equip de sistemes és aparent; el cost de mantenir una versió obsoleta en un projecte nou supera de llarg el de gestionar dues versions.

Solució 3

No hi ha una única resposta correcta, però un bon desenvolupament de l'exercici hauria d'identificar patrons com aquests:

• Una aplicació bancària mòbil. El backend (comptes, transferències, antifrau) sol ser Java amb Spring. Motius: maduresa, transaccionalitat, disponibilitat de perfils professionals i dècades de codi provat al sector financer.
• Una aplicació Android. L'aplicació s'executa sobre ART, una màquina virtual que executa bytecode derivat del de Java. Encara que avui s'escrigui en Kotlin, tot el model d'execució i bona part de l'API són herència directa de Java.
• Un cercador intern o una plataforma d'anàlisi. Elasticsearch està escrit en Java; Kafka i Spark també. Motiu: la JVM ofereix un rendiment molt alt amb gestió automàtica de memòria, un suport de concurrència excel·lent i portabilitat entre els milers de servidors d'un clúster.

El que és rellevant de l'exercici no és encertar la dada, sinó observar el patró: Java domina allà on importen la fiabilitat a llarg termini, la concurrència i el manteniment per part d'equips grans, més que no pas allà on importa escriure el prototip en dues tardes.

Ja tens el mapa. Java és alhora un llenguatge i una plataforma; la seva portabilitat ve de compilar a bytecode i executar-lo sobre una JVM específica de cada sistema; el JDK és el que instal·laràs perquè conté el compilador, el JRE i la JVM; i les versions LTS (8, 11, 17, 21) marquen el ritme real de la indústria, amb Java 17 com a referència d'aquest curs. Saps també que Java viu sobretot al backend empresarial, a Android i a la infraestructura de dades, i coneixes el projecte BiblioTech que aniràs donant forma mòdul a mòdul per a Nexus Software.

Amb la teoria situada, toca preparar el terreny. A la lliçó següent, Configuració de l'entorn de desenvolupament, instal·laràs un JDK al teu sistema, comprovaràs que java i javac responen, entendràs per a què serveixen JAVA_HOME i PATH, compilaràs i executaràs el teu primer fitxer des del terminal, coneixeràs JShell i triaràs l'IDE amb què treballaràs la resta del curs.