Java/La macchina virtuale: differenze tra le versioni

Contenuto cancellato Contenuto aggiunto
taglio via del testo
Riga 2:
 
== Architettura ==
Un programma Java funziona secondo questo modello:
#il programmatore scrive il sorgente del programma;
#i file che compongono il sorgente vengono compilati;
#il programma Java (costituito dai file risultanti dalla compilazione) viene lanciato avviando un altro programma, scritto in codice nativo del sistema operativo su cui ci si trova, e chiamato [[w:it:Java Virtual Machine|Java Virtual Machine]] (indicandogli i file compilati che dovrà eseguire e un insieme di [[w:it:metadato|metadati]] che consentono la corretta esecuzione del programma).
 
Il codice eseguibile prodotto dalla compilazione (''bytecode'') non è specifico di alcuna piattaforma, se non di un unico modello astratto di macchina definito a priori. Questo modello astratto è definito da un documento, denominato ''Java Virtual Machine Specification'', il cui sviluppo viene mantenuto dalla Sun (ora assorbita dalla Oracle). A gennaio 2010, la versione più recente delle specifiche è la seconda.
 
=== Due linguaggi ===
L'architettura presentata fa sì che, di fatto, esistano due linguaggi distinti:
*il linguaggio Java, quello in cui sono scritti i sorgenti di un programma Java.
*il ''class file format'', in cui sono scritti i file risultanti dalla compilazione.
Line 43 ⟶ 37:
 
== Il linguaggio Java ==
Java è un linguaggio
*''[[w:it:case sensitive|case sensitive]]''
*''[[w:it:strongly typed|strongly typed]]''
*''[[w:it:object oriented|object oriented]]''
*dotato di ''[[w:it:garbage collection|garbage collector]]''
 
Le specifiche di linguaggio vengono mantenute dalla Sun (ora assorbita dalla Oracle) e sono definite da un documento
chiamato ''The Java Language Specification'', o, abbreviato, ''JLS''. Nel tempo, sono state realizzate tre edizioni di questo
documento (a gennaio 2010, la più recente è la terza), che hanno via via aggiunto diversi costrutti e regole al linguaggio.
 
Le specifiche vengono sviluppate avendo sempre in mente la ''retrocompatibilità'': tutto il codice Java che era corretto con le vecchie versioni delle specifiche deve risultare corretto anche con quella nuova.
 
; Modifiche separate
Uno degli aspetti più interessanti è che l'aggiunta di un nuovo costrutto al linguaggio ''non sempre'' comporta la modifica delle specifiche della macchina virtuale o la modifica delle macchine virtuali esistenti. Ad esempio, buona parte delle aggiunte che sono state introdotte con la versione 5 della piattaforma sono state progettate in modo che il compilatore possa compilare i nuovi costrutti del linguaggio usando istruzioni "vecchie" nel bytecode.<ref>Questo non è stato possibile per ''tutto'': ad esempio, restano escluse da questo meccanismo le annotazioni.</ref>
 
Un modo semplice per ottenere questo è progettare costrutti che siano "zucchero sintattico" per costrutti preesistenti e che già hanno un corrispettivo nel bytecode. In altre parole, vengono resi disponibili nuovi costrutti che rappresentano un modo più comodo e semplice di scrivere le stesse cose.
 
<!--
Lascio commentato il seguente testo, in attesa di fonti che mi confermino che è corretto. --LoStrangolatore
 
Un altro esempio: la futura introduzione delle ''closures'' in Java aveva destato in alcuni la richiesta che le funzioni diventassero membri di prima classe del linguaggio (cioè che fosse possibile definire, almeno a livello di bytecode, funzioni come entità a sé stanti, come avviene in altri linguaggi come il C). Questo avrebbe reso necessario pesanti modifiche interne alla VM e avrebbe introdotto problemi che i progettisti del linguaggio avevano intenzionalmente evitato nei primi tempi. Ora tutto questo, per fortuna, non avverrà, e le closures risultano essere "zucchero sintattico" per le già esistenti classi anonime. -->
 
I vantaggi principali di questo approccio: