Innen datavitenskap er den virtuelle Java-maskinen (også kalt Java Virtual Machine eller JVM ) programvarekomponenten i Java - plattformen som kjører programmer oversatt til bytekode etter den første kompileringsfasen i bytekode (blant programmeringsspråkene som kan oversettes til bytekode). bytecode finner vi Java , Groovy , Clojure , Scala og Eta ).
Trinnene som må tas for å kjøre et program skrevet i Java er følgende:
Bytekode produseres vanligvis ved å kompilere kildekoder (eller kildefiler ) skrevet i Java , selv om det er mulig å produsere bytekode fra andre språk som Scala , Kotlin , Clojure eller Groovy [1] .
JVM er definert av en spesifikasjon som vedlikeholdes av Oracle . Ethvert system som oppfører seg på en måte i samsvar med denne spesifikasjonen anses å være en spesiell implementering av JVM. Det finnes programvareimplementeringer for praktisk talt alle moderne operativsystemer , både gratis og kommersielle. I tillegg er det spesielle implementeringer for spesielle maskinvare- / programvaremiljøer , for eksempel mobiltelefoner og PDA - er), og til og med maskinvareimplementeringer som Jazelle .
Tilgjengeligheten av Java virtuelle maskinimplementeringer for forskjellige driftsmiljøer er nøkkelen til Javas portabilitet , proklamert i slagordet skriv én gang, kjøre overalt . Den virtuelle maskinen skaper faktisk et homogent utførelsesmiljø, som skjuler enhver spesifisitet til det underliggende operativsystemet fra Java-programvaren (og derfor fra programmereren):
| Java-programvare |
|---|
| Java Virtual Machine |
| Operativsystem |
I tillegg til å håndtere Java Virtual Machine-spesifikasjonene, tilbyr Oracle en implementering kalt HotSpot som er gratis og delvis åpen kildekode. Den ikke-distribuerbare delen gjelder fonter, lyd, sikkerhet og kryptering [2] [3] ; Oracle-implementeringer blir vanligvis sett på som referanseimplementeringer , men er også mye brukt av sluttbrukere, bedrifter og institusjoner.
For å erstatte delene av HotSpot som var under en ikke-åpen lisens, ble IcedTea-prosjektet født. [4] Den virtuelle maskinen utviklet i dette prosjektet kalles HotSpot Zero Assembly, også ganske enkelt kalt Zero. [5] Prosjektet har også som mål å støtte flere prosessorfamilier enn Oracles virtuelle maskin. For å gjøre dette, har all monteringskoden som finnes i HotSpot blitt skrevet om i C ++, slik at den kan kompileres på flere arkitekturer. [6]
Tallrike andre parter tilbyr jevnlig Java-implementeringer for virtuelle maskiner, typisk med den hensikt å konkurrere med Oracle-implementeringen i ytelse; i noen tilfeller er dette kommersielle implementeringer. Andre åpen kildekode -implementeringer er også tilgjengelige ; blant de mest kjente kan vi nevne Waba [7] . JVM-spesifikasjonene er diktert og oppdatert av Oracle som initiativtaker og vedlikeholder av prosjektet, men blir ofte ignorert av mange av ikke-Oracle JVM-implementeringene som er der ute, spesielt når det gjelder rammeverket som hver JVM inkluderer. Følgelig er de forskjellige JVM-ene ikke helt kompatible med hverandre, og man må være forsiktig med å skrive programmene hvis du vil at de skal fungere på hver JVM. Den beste tingen å gjøre for dette ville være å ikke bruke de nyeste språkfunksjonene introdusert av Oracle i de nyeste JVM-ene og å bruke "stabile" APIer , det vil si som har vært til stede i Oracle JVM fra forskjellige versjoner.
De første implementeringene av den virtuelle Java-maskinen var tolker . Denne løsningen viste seg imidlertid å være ineffektiv, da de tolkede programmene fortsatt var veldig trege. Av denne grunn har alle nyere implementeringer av virtuelle Java-maskiner inkorporert en just-in-time kompilator ( JIT-kompilator ), dvs. en intern kompilator, som ved lansering oversetter Java-bytekodeprogrammet til et normalt maskinspråkprogram på farten. vertsdatamaskin [8] . I tillegg er denne rekompileringen dynamisk, det vil si at den virtuelle maskinen konstant analyserer utførelsesmodellen til koden ( profylaktisk ), og optimaliserer de delene som oftest utføres, mens programmet kjører.
Disse tiltakene, til prisen av en liten ventetid under lanseringsfasen av programmet, lar deg ha mye raskere og lettere Java-applikasjoner. Men selv på denne måten forblir Java et mindre effektivt språk enn riktig kompilerte språk som C++ , med tanke på det faktum å ha ekstra lag med abstraksjon, og å implementere en serie automatismer, for eksempel søppelsamleren , som på den ene siden sparer penger, tid og feil i utviklingsfasen av programmene, på den andre siden bruker de minne og CPU -tid i utførelsesfasen av det ferdige programmet.