Preskočiť na obsah

Java Virtual Machine

z Wikipédie, slobodnej encyklopédie
Image
Prehľad architektúry virtuálneho stroja Javy (JVM) podľa špecifikácie The Java Virtual Machine Specification, vydanie Java SE 7.

Java Virtual Machine (JVM, virtuálny stroj Javy) je virtuálny stroj, ktorý umožňuje počítaču spúšťať programy v jazyku Java, ako aj programy napísané v iných jazykoch, tzv. jazykoch JVM, ktoré sa tiež kompilujú do bajtkódu Javy (Java bytecode). JVM je podrobne opísaný špecifikáciou, ktorá formálne stanovuje, čo sa od implementácie JVM vyžaduje. Existencia špecifikácie zaručuje interoperabilitu programov v Jave medzi rôznymi implementáciami, takže autori programov, ktorí používajú Java Development Kit (JDK), sa nemusia zaoberať zvláštnosťami hardvérovej platformy, na ktorej program beží.

Referenčnú implementáciu JVM vyvíja projekt OpenJDK ako otvorený zdrojový kód a jej súčasťou je kompilátor just-in-time (JIT) s názvom HotSpot.[1] Komerčne podporované vydania Javy od spoločnosti Oracle vychádzajú z behového prostredia OpenJDK. Ďalším JVM s otvoreným zdrojovým kódom pre OpenJDK je Eclipse OpenJ9.

Špecifikácia JVM

[upraviť | upraviť zdroj]

Virtuálny stroj Javy je abstraktný (virtuálny) počítač definovaný špecifikáciou. Použitý algoritmus zberu odpadu (garbage collection) ani žiadna vnútorná optimalizácia inštrukcií virtuálneho stroja Javy (ich preklad do strojového kódu) nie sú špecifikované. Hlavným dôvodom tohto vynechania je nezaväzovať zbytočne implementátorov. Akúkoľvek aplikáciu v Jave možno spustiť len v niektorej konkrétnej implementácii abstraktnej špecifikácie virtuálneho stroja Javy.[2]

Počnúc platformou Java Platform, Standard Edition (J2SE) 5.0 sa zmeny špecifikácie JVM pripravujú v rámci procesu Java Community Process ako JSR 924.[3] V roku 2006 sa zmeny špecifikácie, ktoré mali podporiť navrhované zmeny formátu súborov class (JSR 202),[4] pripravovali ako údržbové vydanie (maintenance release) JSR 924. Špecifikácia JVM vyšla aj knižne;[5] v jej predslove sa píše:

„ Zamýšľame, aby táto špecifikácia dokumentovala virtuálny stroj Javy dostatočne na to, aby umožnila vznik kompatibilných nezávislých implementácií (tzv. clean-room implementácií). “

[6]

Zberače odpadu

[upraviť | upraviť zdroj]

Virtuálny stroj (JVM) v OpenJDK pre Javu ponúka okrem iných tieto zberače odpadu (garbage collectors):

  • Serial
  • Parallel
  • CMS (Concurrent Mark Sweep)
  • G1 (Garbage-First)
  • ZGC (Z Garbage Collector)
  • Epsilon
  • Shenandoah
  • GenZGC (generačný ZGC)
  • GenShen (generačný Shenandoah)
  • IBM Metronome (iba v OpenJDK od IBM)
  • SAP (iba v OpenJDK od spoločnosti SAP)
  • Azul C4 (Continuously Concurrent Compacting Collector)[7] (iba v OpenJDK od spoločnosti Azul Systems)
Verzie Javy a ich zberače odpadu (stav k 15. októbru 2026)[8]
VerziaPredvolený zberačDostupné zberače
6u14Serial /
Parallel (MP)		Serial, Parallel, CMS, G1 (E)
7u4 – 8Serial, Parallel, CMS, G1
9 – 10Serial / G1
11Serial, Parallel, CMS, G1, Epsilon (E), ZGC (E)
12 – 13Serial, Parallel, CMS, G1, Epsilon (E), ZGC (E), Shenandoah (E)
14Serial, Parallel, G1, Epsilon (E), ZGC (E), Shenandoah (E)
15 – 20Serial, Parallel, G1, Epsilon (E), ZGC, Shenandoah
21 – 22Serial, Parallel, G1, Epsilon (E), ZGC, Shenandoah, GenZGC (E)
23Serial, Parallel, G1, Epsilon (E), ZGC, Shenandoah, GenZGC (predvolený ZGC)
24Serial, Parallel, G1, Epsilon (E), Shenandoah, GenZGC, GenShen (E)
25 – 26Serial, Parallel, G1, Epsilon (E), Shenandoah, GenZGC, GenShen
27G1Serial, Parallel, G1, Epsilon (E), Shenandoah, GenZGC, GenShen
(E) = experimentálny

Java predpokladá automatickú správu pamäte: program pamäť na halde len prideľuje, ale neuvoľňuje; o jej uvoľnení rozhoduje virtuálny stroj, zvyčajne pomocou zberača odpadu.[2] Na rozdiel od C++ preto Java nemá kľúčové slovo delete. Pamäť mimo haldy Javy možno alokovať a uvoľňovať pomocou rozhrania java.lang.foreign (Foreign Function & Memory API), ktoré nahrádza metódy na prístup k pamäti v nepodporovanej triede sun.misc.Unsafe.[9][10] Keďže Java prideľuje pamäť prevažne na halde, objekty sa uchovávajú ako referencie a ich zmazanie by viedlo k visiacim smerníkom (dangling pointers).

Foo a = new Foo();
Foo b = a;

delete a;
System.out.println(b);

Architektúra virtuálneho stroja

[upraviť | upraviť zdroj]

JVM pracuje s určitými typmi údajov, ktoré stanovuje špecifikácia virtuálneho stroja Javy. Dátové typy možno rozdeliť[11] na primitívne typy (celočíselné hodnoty a hodnoty s pohyblivou rádovou čiarkou) a referenčné typy. Typy long a double, ktoré sú 64-bitové, sú podporované natívne, ale v lokálnych premenných rámca alebo v zásobníku operandov zaberajú dve jednotky úložného priestoru, pretože každá jednotka má 32 bitov. Typy boolean, byte, short a char sa pri výpočtoch rozširujú na 32 bitov so zachovaním znamienka (okrem typu char, ktorý sa dopĺňa nulami) a pracuje sa s nimi ako s celými číslami typu int. Menšie typy majú len niekoľko inštrukcií špecifických pre daný typ, a to na načítanie, uloženie a konverziu typu. S typom boolean sa pracuje ako s 8-bitovými hodnotami typu byte, pričom 0 predstavuje false a 1 predstavuje true. (Hoci sa boolean považuje za typ od čias, keď to objasnilo druhé vydanie špecifikácie The Java Virtual Machine Specification, v skompilovanom a vykonávanom kóde je medzi typmi boolean a byte len malý rozdiel – okrem toho, ako sa typy zapisujú v signatúrach metód, a typu booleovských polí. Hodnoty boolean sa v signatúrach metód kódujú ako Z, kým hodnoty byte ako B. Booleovské polia majú typ boolean[], ale na každý prvok používajú 8 bitov a JVM nemá zabudovanú schopnosť zhustiť booleovské hodnoty do bitového poľa, takže okrem typu sa správajú rovnako ako polia typu byte. Vo všetkých ostatných prípadoch je typ boolean pre JVM v podstate neznámy, pretože všetky inštrukcie pracujúce s booleovskými hodnotami sa používajú aj na prácu s hodnotami byte.)

JVM má haldu so zberom odpadu na uchovávanie objektov a polí. Kód, konštanty a ďalšie údaje tried sa ukladajú v „oblasti metód“ (method area). Oblasť metód je logicky súčasťou haldy, ale implementácie môžu s oblasťou metód zaobchádzať oddelene od haldy a napríklad v nej nemusia zbierať odpad. Každé vlákno JVM má aj vlastný zásobník volaní (call stack; kvôli jasnosti sa nazýva „zásobník virtuálneho stroja Javy“), v ktorom sa uchovávajú rámce (frames). Nový rámec sa vytvorí pri každom volaní metódy a zruší sa, keď metóda skončí.

Každý rámec poskytuje „zásobník operandov“ (operand stack) a pole „lokálnych premenných“ (local variables). Zásobník operandov slúži na operandy pri výpočtoch a na prevzatie návratovej hodnoty volanej metódy, kým lokálne premenné majú rovnaký účel ako registre a používajú sa aj na odovzdávanie argumentov metód. JVM je teda zásobníkový aj registrový stroj. V praxi HotSpot odstraňuje všetky zásobníky okrem natívneho zásobníka vlákna/volaní aj v interpretovanom režime, pretože jeho interpreter založený na šablónach (template interpreter) technicky funguje ako kompilátor.

JVM adresuje údaje pomocou referencií a indexov do zásobníka či poľa; nepoužíva adresovanie po bajtoch ako väčšina fyzických strojov, a preto nezapadá úhľadne do obvyklého delenia na 32-bitové alebo 64-bitové stroje. Implementácia JVM môže byť navrhnutá tak, aby bežala na procesore s ľubovoľnou natívnou šírkou slova, pokiaľ správne implementuje celočíselnú (8-, 16-, 32- a 64-bitovú) aritmetiku a aritmetiku s pohyblivou rádovou čiarkou (32- a 64-bitovú), ktorú JVM vyžaduje. V závislosti od spôsobu implementácie referencií (natívne smerníky, komprimované smerníky alebo tabuľka nepriamych odkazov) to môže obmedziť počet objektov pod teoretické maximum. Implementácia JVM na 64-bitovej platforme má prístup k oveľa väčšiemu adresnému priestoru ako implementácia na 32-bitovej platforme, čo umožňuje oveľa väčšiu haldu a vyšší maximálny počet vlákien, ktoré potrebujú niektoré druhy rozsiahlych aplikácií; 64-bitová implementácia však môže byť v porovnaní s 32-bitovou pomalšia.[pozn. 1]

Jazyky JVM

[upraviť | upraviť zdroj]

Jazyk JVM je akýkoľvek jazyk, ktorého funkcie možno vyjadriť v platnom súbore class, ktorý dokáže hostiť JVM. Súbor class obsahuje inštrukcie JVM (bajtkód JVM), tabuľku symbolov a ďalšie pomocné informácie. Formát súborov class je binárny formát nezávislý od hardvéru aj operačného systému, ktorý sa používa na reprezentáciu skompilovaných tried a rozhraní.[6]

Jazykov JVM je viacero – staršie zavedené jazyky portované na JVM aj oveľa novšie jazyky vytvorené od základov. Najznámejšími portmi starších jazykov sú zrejme JRuby a Jython, teda porty jazykov Ruby a Python. Z nových jazykov vytvorených od základov na kompiláciu do bajtkódu Javy sú zrejme najpopulárnejšie Clojure, Groovy, Scala a Kotlin. Významnou vlastnosťou jazykov JVM je ich vzájomná interoperabilita – sú navzájom kompatibilné, takže napríklad knižnice jazyka Scala možno používať v programoch v Jave a naopak.[14]

JVM v Jave 7 implementuje JSR 292: Supporting Dynamically Typed Languages[15] na platforme Java – novú vlastnosť, ktorá v JVM podporuje dynamicky typované jazyky. Táto vlastnosť vznikla v rámci projektu Da Vinci Machine, ktorého poslaním je rozšíriť JVM tak, aby podporoval aj iné jazyky ako Java.[16][17]

Zavádzač tried

[upraviť | upraviť zdroj]

Jednou z organizačných jednotiek bajtkódu JVM je trieda. Implementácia zavádzača tried (class loader) musí dokázať rozpoznať a načítať čokoľvek, čo zodpovedá formátu súboru class Javy. Každá implementácia smie okrem súborov class rozpoznávať aj iné binárne formy, ale súbory class rozpoznávať musí.

Zavádzač tried vykonáva tri základné činnosti v tomto prísnom poradí:

  1. Načítanie (loading): nájde a importuje binárne údaje typu
  2. Linkovanie (linking): vykoná overenie, prípravu a (voliteľne) rozlíšenie
    • Overenie (verification): zabezpečí správnosť importovaného typu
    • Príprava (preparation): pridelí pamäť pre premenné triedy a inicializuje ju na predvolené hodnoty
    • Rozlíšenie (resolution): transformuje symbolické odkazy z typu na priame odkazy
  3. Inicializácia (initialization): vyvolá kód v Jave, ktorý inicializuje premenné triedy na ich správne počiatočné hodnoty.

Vo všeobecnosti existujú tri druhy zavádzačov tried: zavádzač bootstrap (bootstrap class loader), zavádzač rozšírení (extension class loader; od Javy 9 zavádzač platformy, platform class loader) a systémový či aplikačný zavádzač (System / Application class loader).[18]

Každá implementácia virtuálneho stroja Javy musí mať zavádzač bootstrap, ktorý dokáže načítať dôveryhodné triedy, a tiež zavádzač rozšírení alebo aplikačný zavádzač. Špecifikácia virtuálneho stroja Javy neurčuje, ako má zavádzač tried triedy vyhľadávať.[2]

Inštrukcie bajtkódu

[upraviť | upraviť zdroj]

JVM má inštrukcie pre tieto skupiny úloh:

  • načítanie a uloženie (load and store)
  • aritmetika
  • konverzia typov
  • vytváranie objektov a práca s nimi
  • správa zásobníka operandov (push / pop)
  • odovzdanie riadenia (vetvenie)
  • volanie metód a návrat z nich
  • vyvolávanie výnimiek
  • súbežnosť založená na monitoroch

Cieľom je binárna kompatibilita. Každý konkrétny hostiteľský operačný systém potrebuje vlastnú implementáciu JVM a behového prostredia. Tieto JVM interpretujú bajtkód sémanticky rovnako, ale skutočná implementácia môže byť rozdielna. Zložitejšie ako samotná emulácia bajtkódu je kompatibilne a efektívne implementovať základné API Javy (Java core API), ktoré treba namapovať na každý hostiteľský operačný systém.

Tieto inštrukcie pracujú so spoločnou sadou abstrahovaných dátových typov, a nie s natívnymi dátovými typmi niektorej konkrétnej architektúry inštrukčnej sady.

Overovač bajtkódu

[upraviť | upraviť zdroj]

Základnou filozofiou Javy je, že je vo svojej podstate bezpečná v tom zmysle, že žiadny používateľský program nemôže zrútiť hostiteľský počítač ani inak nevhodne zasahovať do iných operácií na hostiteľskom počítači, a že je možné chrániť určité metódy a dátové štruktúry patriace dôveryhodnému kódu pred prístupom alebo poškodením zo strany nedôveryhodného kódu, ktorý sa vykonáva v tom istom JVM. Okrem toho sa nesmú vyskytnúť bežné programátorské chyby, ktoré často viedli k poškodeniu údajov alebo nepredvídateľnému správaniu, napríklad prístup za koniec poľa alebo použitie neinicializovaného smerníka. Túto bezpečnosť zabezpečuje kombinácia viacerých vlastností Javy vrátane modelu tried, haldy so zberom odpadu a overovača (verifier).

JVM overí všetok bajtkód skôr, ako sa vykoná. Toto overenie pozostáva predovšetkým z troch druhov kontrol:

  • vetvenia vždy smerujú na platné miesta,
  • údaje sú vždy inicializované a referencie sú vždy typovo bezpečné,
  • prístup k súkromným údajom a metódam alebo k údajom a metódam s prístupom v rámci balíka je prísne kontrolovaný.

Prvé dve z týchto kontrol prebiehajú predovšetkým počas kroku overenia, ktorý sa uskutoční pri načítaní triedy a jej sprístupnení na použitie. Tretia sa vykonáva prevažne dynamicky, keď iná trieda prvýkrát pristúpi k údajovým položkám alebo metódam triedy.

Overovač pripúšťa v platných programoch len niektoré postupnosti bajtkódu, napr. inštrukcia skoku (vetvenia) môže smerovať len na inštrukciu v rámci tej istej metódy. Overovač ďalej zabezpečuje, že každá daná inštrukcia pracuje s pevným miestom v zásobníku,[19] čo kompilátoru JIT umožňuje transformovať prístupy do zásobníka na prístupy do pevných registrov. Vďaka tomu z toho, že JVM má zásobníkovú architektúru, nevyplýva pri použití kompilátora JIT spomalenie emulácie na architektúrach založených na registroch. Pri architektúre JVM s overeným kódom je pre kompilátor JIT jedno, či dostane pomenované pomyselné registre, alebo pomyselné pozície v zásobníku, ktoré treba prideliť registrom cieľovej architektúry. Overovanie kódu v skutočnosti odlišuje JVM od klasickej zásobníkovej architektúry, ktorej efektívna emulácia kompilátorom JIT je zložitejšia a zvyčajne ju vykonáva pomalší interpreter. Interpreter, ktorý používa predvolený JVM, je navyše osobitným typom, interpreterom založeným na šablónach (template interpreter), ktorý prekladá bajtkód priamo do natívneho strojového jazyka založeného na registroch, namiesto toho, aby emuloval zásobník ako typický interpreter.[20] V mnohých ohľadoch možno interpreter HotSpot považovať skôr za kompilátor JIT než za skutočný interpreter, čo znamená, že zásobníková architektúra, na ktorú bajtkód cieli, sa v implementácii v skutočnosti nepoužíva, ale je len špecifikáciou medzikódu, ktorý možno dobre implementovať na architektúre založenej na registroch. Ďalším prípadom, keď je zásobníková architektúra len špecifikáciou a implementuje sa vo virtuálnom stroji založenom na registroch, je Common Language Runtime.[21]

Pôvodná špecifikácia overovača bajtkódu používala prirodzený jazyk, ktorý bol v niektorých ohľadoch neúplný alebo nesprávny. Uskutočnilo sa viacero pokusov špecifikovať JVM ako formálny systém. Takto možno dôkladnejšie analyzovať bezpečnosť súčasných implementácií JVM a predchádzať možným bezpečnostným zneužitiam (exploitom). Bude tiež možné optimalizovať JVM vynechaním zbytočných bezpečnostných kontrol, ak sa preukáže, že spúšťaná aplikácia je bezpečná.[22]

Bezpečné vykonávanie vzdialeného kódu

[upraviť | upraviť zdroj]

Architektúra virtuálneho stroja umožňuje veľmi jemnú kontrolu nad tým, aké činnosti smie kód vo vnútri stroja vykonávať. Predpokladá sa, že kód je „sémanticky“ správny, teda že úspešne prešiel (formálnym) procesom overovača bajtkódu, ktorý zabezpečuje nástroj, prípadne aj mimo virtuálneho stroja. Cieľom je umožniť bezpečné vykonávanie nedôveryhodného kódu zo vzdialených zdrojov, čo je model, ktorý využívajú aplety Javy a iné bezpečné sťahovanie kódu. Po overení bajtkódu beží stiahnutý kód v obmedzenom „pieskovisku“ (sandbox), ktoré má chrániť používateľa pred chybne sa správajúcim alebo škodlivým kódom. Okrem overenia bajtkódu si môžu vydavatelia kúpiť certifikát, ktorým aplety digitálne podpíšu ako bezpečné, čím im dajú oprávnenie požiadať používateľa o opustenie pieskoviska a o prístup k miestnemu súborovému systému, schránke, spúšťaniu externého softvéru alebo k sieti.

Formálne dôkazy overovačov bajtkódu vypracovalo odvetvie Java Card (Formal Development of an Embedded Verifier for Java Card Byte Code[23]).

Interpreter bajtkódu a kompilátor just-in-time

[upraviť | upraviť zdroj]

Pre každú hardvérovú architektúru je potrebný iný interpreter bajtkódu Javy. Ak má počítač interpreter bajtkódu Javy, dokáže spustiť akýkoľvek program v bajtkóde Javy a ten istý program možno spustiť na akomkoľvek počítači, ktorý takýto interpreter má.

Keď bajtkód Javy vykonáva interpreter, vykonávanie bude vždy pomalšie ako vykonávanie toho istého programu skompilovaného do natívneho strojového jazyka. Tento problém zmierňujú kompilátory just-in-time (JIT) na vykonávanie bajtkódu Javy. Kompilátor JIT môže počas vykonávania programu prekladať bajtkód Javy do natívneho strojového jazyka. Preložené časti programu sa potom môžu vykonávať oveľa rýchlejšie, ako keby sa interpretovali. Táto technika sa uplatňuje na tie časti programu, ktoré sa vykonávajú často. Kompilátor JIT tak môže výrazne skrátiť celkový čas vykonávania.

Medzi programovacím jazykom Java a bajtkódom Javy nie je nevyhnutná súvislosť. Program napísaný v Jave možno skompilovať priamo do strojového jazyka skutočného počítača a programy napísané v iných jazykoch ako Java možno skompilovať do bajtkódu Javy.

Bajtkód Javy má byť nezávislý od platformy a bezpečný.[24] Niektoré implementácie JVM neobsahujú interpreter, ale pozostávajú len z kompilátora just-in-time.[25]

Java Native Interface

[upraviť | upraviť zdroj]

Java Native Interface (alebo Native Method Interface) je rozhranie na volanie funkcií v iných jazykoch (foreign function interface), ktoré umožňuje kódu v Jave bežiacemu vo virtuálnom stroji Javy (JVM) volať natívne aplikácie (programy špecifické pre určitú hardvérovú platformu a platformu operačného systému) a knižnice napísané v iných jazykoch, ako sú C, C++ a jazyk symbolických inštrukcií, a byť nimi volaný.

Java 22 prináša rozhranie Foreign Function and Memory API, ktoré možno považovať za nástupcu rozhrania Java Native Interface.[9]

Natívne metódy umožňuje JNI na zvládnutie situácií, keď aplikáciu nemožno napísať celú v programovacom jazyku Java, napr. keď štandardná knižnica tried Javy nepodporuje vlastnosti alebo programovú knižnicu špecifickú pre platformu.

Rámec JNI umožňuje natívnej metóde používať objekty Javy rovnakým spôsobom, akým ich používa kód v Jave. Natívna metóda môže vytvárať objekty Javy a potom ich skúmať a používať na vykonanie svojich úloh. Natívna metóda môže skúmať a používať aj objekty vytvorené kódom aplikácie v Jave.

JNI umožňuje aj priamy prístup ku kódu v jazyku symbolických inštrukcií, dokonca bez sprostredkovania cez jazyk C. Rovnakým spôsobom je možné pristupovať k aplikáciám v Jave z jazyka symbolických inštrukcií.

JVM vo webovom prehliadači

[upraviť | upraviť zdroj]

Na začiatku existencie platformy Java sa JVM propagoval ako webová technológia na tvorbu bohatých webových aplikácií (Rich Web Applications). Zásuvný modul Javy pre prehliadače bol v JDK 9 označený za zastaraný (deprecated).[26] Rozhranie Applet API bolo z JDK odstránené vo verzii JDK 26, pretože aplety už nepodporujú ani súčasné webové prehliadače.[27]

Zásuvný modul Javy pre prehliadače, založený na rozhraní NPAPI, mal umožniť JVM vykonávať tzv. aplety Javy vložené do stránok HTML. V prehliadačoch s nainštalovaným zásuvným modulom smie aplet kresliť do obdĺžnikovej oblasti na stránke, ktorá mu bola pridelená. Keďže zásuvný modul obsahuje JVM, aplety Javy nie sú obmedzené na programovací jazyk Java; v zásuvnom module môže bežať akýkoľvek jazyk, ktorý sa kompiluje pre JVM. Obmedzená sada rozhraní API umožňuje apletom prístup k mikrofónu používateľa alebo k 3D akcelerácii, hoci aplety nedokážu meniť stránku mimo svojej obdĺžnikovej oblasti. Adobe Flash Player, hlavná konkurenčná technológia, funguje v tomto ohľade rovnako.

Podľa služby W3Techs používalo k 1. januáru 2015 aplety Javy aj technológiu Silverlight po 0,1 % webových stránok a technológiu Flash 12,1 %.[28]

JVM a interpretery v JavaScripte

[upraviť | upraviť zdroj]

Od mája 2016 umožňuje knižnica JavaPoly používateľom importovať nezmenené knižnice Javy a volať ich priamo z JavaScriptu. JavaPoly umožňuje webovým stránkam používať nezmenené knižnice Javy, aj keď používateľ nemá na svojom počítači nainštalovanú Javu.[29]

Transpilácia do JavaScriptu

[upraviť | upraviť zdroj]

S neustálym zrýchľovaním vykonávania JavaScriptu a s rastúcim používaním mobilných zariadení, ktorých webové prehliadače nepodporujú zásuvné moduly, sa objavujú snahy osloviť týchto používateľov transpiláciou (transpilation, preklad zdrojového kódu do iného programovacieho jazyka) do JavaScriptu. Do JavaScriptu možno transpilovať buď zdrojový kód, alebo bajtkód JVM.

Kompilácia bajtkódu JVM, ktorý je spoločný pre všetky jazyky JVM, umožňuje stavať na existujúcom kompilátore jazyka do bajtkódu. Hlavnými transpilátormi z bajtkódu JVM do JavaScriptu sú TeaVM,[30] kompilátor obsiahnutý v súprave Dragome Web SDK,[31] Bck2Brwsr[32] a j2js-compiler.[33]

Medzi popredné transpilátory z jazykov JVM do JavaScriptu patria transpilátor z Javy do JavaScriptu obsiahnutý v nástroji Google Web Toolkit, J2CL,[34] ClojureScript (Clojure), GrooScript (Apache Groovy), Scala.js (Scala) a ďalšie.[35]

Poznámky

[upraviť | upraviť zdroj]
  1. ↑ Podpora 32-bitovej architektúry x86 bola odstránená od JDK 24 (Windows)[12] a od JDK 25 (ostatné platformy).[13]

Referencie

[upraviť | upraviť zdroj]
  1. ↑ HotSpot Group [online]. OpenJDK, [cit. 2026-10-15]. Dostupné online. (po anglicky)
  2. 1 2 3 VENNERS, Bill. Inside the Java Virtual Machine. [s.l.] : [s.n.]. Dostupné online. Kapitola Chapter 5: The Java Virtual Machine. Archivované 2021-01-25 z originálu. (po anglicky)
  3. ↑ The Java Community Process(SM) Program – JSRs: Java Specification Requests – detail JSR# 924 [online]. Jcp.org, [cit. 2015-06-26]. Dostupné online. Archivované 2020-12-24 z originálu. (po anglicky)
  4. ↑ The Java Community Process(SM) Program – JSRs: Java Specification Requests – detail JSR# 202 [online]. Jcp.org, [cit. 2015-06-26]. Dostupné online. Archivované 2012-02-26 z originálu. (po anglicky)
  5. ↑ The Java Virtual Machine Specification [online]. Sun Microsystems. Dostupné online. Archivované 2008-07-09 z originálu. (po anglicky) (online sú dostupné aj prvé a druhé vydanie).
  6. 1 2 The Java Virtual Machine Specification: Java SE 7 Edition [online]. Docs.oracle.com, [cit. 2015-06-26]. Dostupné online. Archivované 2021-02-04 z originálu. (po anglicky)
  7. ↑ TENE, Gil; IYENGAR, Balaji; WOLF, Michael. ISMM '11: Proceedings of the international symposium on Memory management. [s.l.] : [s.n.], 2011. Dostupné online. ISBN 978-1-45030263-0. DOI:10.1145/1993478 Kapitola C4: the continuously concurrent compacting collector. Archivované 2017-08-09 z originálu. (po anglicky)
  8. ↑ JEP 0: JEP Index [online]. OpenJDK, [cit. 2026-10-15]. Dostupné online. (po anglicky) – JEP 189, 248, 318, 333, 363, 377, 379, 404, 439, 474, 490, 521 a 523.
  9. 1 2 JEP 454: Foreign Function & Memory API [online]. OpenJDK, 2025-04-07. Dostupné online. (po anglicky)
  10. ↑ JEP 471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal [online]. OpenJDK, [cit. 2026-10-15]. Dostupné online. (po anglicky)
  11. ↑ Chapter 2. The Structure of the Java Virtual Machine [online]. Oracle, [cit. 2021-09-15]. Dostupné online. Archivované 2021-09-15 z originálu. (po anglicky)
  12. ↑ JEP 479: Remove the Windows 32-bit x86 Port [online]. OpenJDK, [cit. 2026-10-03]. Dostupné online. (po anglicky)
  13. ↑ JEP 503: Remove the 32-bit x86 Port [online]. OpenJDK, [cit. 2026-10-03]. Dostupné online. (po anglicky)
  14. ↑ Frequently Asked Questions – Java Interoperability [online]. scala-lang.org, [cit. 2015-11-18]. Dostupné online. Archivované 2020-08-09 z originálu. (po anglicky)
  15. ↑ The Java Community Process(SM) Program – JSRs: Java Specification Requests – detail JSR# 292 [online]. Jcp.org, [cit. 2015-06-26]. Dostupné online. Archivované 2020-12-20 z originálu. (po anglicky)
  16. ↑ Da Vinci Machine project [online]. Openjdk.java.net, [cit. 2015-06-26]. Dostupné online. Archivované 2020-11-11 z originálu. (po anglicky)
  17. ↑ New JDK 7 Feature: Support for Dynamically Typed Languages in the Java Virtual Machine [online]. Oracle.com, [cit. 2015-06-26]. Dostupné online. Archivované 2018-09-13 z originálu. (po anglicky)
  18. ↑ ClassLoader (Java SE 25 & JDK 25) [online]. Oracle, [cit. 2026-10-15]. Dostupné online. (po anglicky)
  19. ↑ The Verification process [online]. Sun Microsystems (The Java Virtual Machine Specification), 1999, [cit. 2009-05-31]. Dostupné online. Archivované 2011-03-21 z originálu. (po anglicky)
  20. ↑ HotSpot Runtime Overview – Interpreter [online]. OpenJDK, [cit. 2021-05-24]. Dostupné online. Archivované 2022-05-21 z originálu. (po anglicky)
  21. ↑ Why not make CLR register-based? · Issue #4775 · dotnet/runtime [online]. GitHub, [cit. 2021-05-24]. Dostupné online. Archivované 2023-04-20 z originálu. (po anglicky)
  22. ↑ FREUND, Stephen N.; MITCHELL, John C.. Proceedings of the 14th ACM SIGPLAN conference on Object-oriented programming, systems, languages, and applications – OOPSLA '99. [s.l.] : [s.n.], 1999. ISBN 978-1581132380. DOI:10.1145/320384.320397 Kapitola A formal framework for the Java bytecode language and verifier, s. 147–166. (po anglicky)
  23. ↑ CASSET, Ludovic; BURDY, Lilian; REQUET, Antoine. Formal Development of an Embedded Verifier for Java Card Byte Code [online]. Inria (Université Côte d'Azur), 2002-04-10. Dostupné online. Archivované 2022-10-03 z originálu. (po anglicky)
  24. ↑ ECK, David J.. Introduction to Programming Using Java. 7. vyd. [s.l.] : [s.n.], 2014. Dostupné online. Kapitola 1.3 The Java Virtual Machine. Archivované 2014-10-11 z originálu. (po anglicky)
  25. ↑ Oracle JRockit Introduction, Release R28: 2. Understanding Just-In-Time Compilation and Optimization [online]. Oracle. Dostupné online. Archivované 2015-09-06 z originálu. (po anglicky)
  26. ↑ Oracle deprecates the Java browser plugin, prepares for its demise [online]. Ars Technica, 2016-01-28, [cit. 2016-04-15]. Dostupné online. Archivované 2016-04-08 z originálu. (po anglicky)
  27. ↑ JEP 504: Remove the Applet API [online]. OpenJDK, [cit. 2026-10-15]. Dostupné online. (po anglicky)
  28. ↑ Historical yearly trends in the usage statistics of client-side programming languages for websites [online]. W3Techs, [cit. 2026-10-15]. Dostupné online. (po anglicky)
  29. ↑ KRILL, Paul. JavaPoly.js imports existing Java code and invokes it directly from JavaScript. InfoWorld, 2016-05-13. Dostupné online [cit. 2016-07-18]. Archivované 2016-07-25 z originálu. (po anglicky)
  30. ↑ TeaVM project home page [online]. Teavm.org, [cit. 2015-06-26]. Dostupné online. Archivované 2015-06-27 z originálu. (po anglicky)
  31. ↑ dragome-sdk [online]. GitHub (dragome), [cit. 2026-10-15]. Dostupné online. (po anglicky)
  32. ↑ Bck2Brwsr – APIDesign [online]. Wiki.apidesign.org, [cit. 2015-06-26]. Dostupné online. Archivované 2015-06-27 z originálu. (po anglicky)
  33. ↑ KUEHN, Wolfgang. j2js-compiler [online]. GitHub (decatur). Dostupné online. Archivované 2013-09-29 z originálu. (po anglicky)
  34. ↑ J2cl: Transpile Java to JavaScript for Closure Compiler – Hacker News [online]. news.ycombinator.com, [cit. 2025-10-31]. Dostupné online. Archivované 2021-01-02 z originálu. (po anglicky)
  35. ↑ List of languages that compile to JS · jashkenas/coffeescript Wiki · GitHub [online]. Github.com, 2015-06-19, [cit. 2015-06-26]. Dostupné online. Archivované 2020-01-31 z originálu. (po anglicky)

Ďalšia literatúra

[upraviť | upraviť zdroj]
  • Clarifications and Amendments to the Java Virtual Machine Specification, Second Edition [online]. Sun Microsystems. Dostupné online. Archivované 2006-01-10 z originálu. (po anglicky) – obsahuje zoznam zmien potrebných na podporu J2SE 5.0 a JSR 45
  • JSR 45 [online]. Jcp.org. Dostupné online. Archivované 2006-02-05 z originálu. (po anglicky) – špecifikuje zmeny formátu súborov class na podporu ladenia na úrovni zdrojového kódu v jazykoch, ktoré sa prekladajú do Javy, ako sú JavaServer Pages (JSP) a SQLJ

Iné projekty

[upraviť | upraviť zdroj]

Externé odkazy

[upraviť | upraviť zdroj]

Zdroj

[upraviť | upraviť zdroj]

Tento článok je čiastočný alebo úplný preklad článku Java virtual machine na anglickej Wikipédii.

Zdroj: „https://sk.wikipedia.org/w/index.php?title=Java_Virtual_Machine&oldid=8395775“