Lorena ha scritto:
Ho capito qualche cosa o non ci ho capito niente?
La seconda, purtroppo.
Lorena ha scritto:
Quindi i simboli del codice ASCII e siccome i simboli sono pochi per la Java Virtual Machine è un gioco da ragazzi interpretare. Scusa mi puoi spiegare meglio vorrei capire bene cosa succede quando do un comando compilo e eseguo
Non c'entra nulla il codice ASCII.
Ripartiamo da (quasi) zero: "bytecode" innanzitutto è un termine che viene spesso usato anche in generale. Denota un linguaggio che ha un suo set di istruzioni e che non è più codice "sorgente" (quindi NON è un file di testo intelleggibile) e inoltre, attenzione, NON è nemmeno codice "macchina", cioè il codice eseguibile direttamente da un certo processore (es. gli x86 di Intel/AMD).
E' un qualcosa quindi di "intermedio". Quale è il vantaggio? Il principale vantaggio è uno: la
portabilità. Se prendi per esempio Windows, sai che il codice eseguibile sta nei .exe e .dll. Dentro questi file c'è solo (oltre a "dati" vari, naturalmente) codice macchina
nativo del processore. Quindi nei .exe/.dll ci sono istruzioni dei processori x86. E quindi un .exe per gli x86 non lo puoi certo far girare "nativamente" su un processore Arm o un PowerPC.
Java ha un suo bytecode (inventato da Sun) e una apposita virtual machine, che è in grado di interpretare/eseguire il bytecode. Anche la piattaforma .NET di Microsoft ha un equivalente. Ha un suo "bytecode" (sicuramente radicalmente diverso da quello di Java) e una "macchina virtuale" che è in grado di eseguire quel bytecode. C'è molta similitudine in questo tra la piattaforma Java e quella .NET.
Il concetto di portabilità in questo contesto è molto semplice: Avendo
N piattaforme differenti (per processore/hardware e sistema operativo), se su ciascuna di esse c'è una infrastruttura di "runtime" (la macchina virtuale più altro) apposita, allora è possibile eseguire quel bytecode, senza alcuna modifica al bytecode stesso. E questa è appunto la "portabilità".