Vad är Java Virtual Machine och hur fungerar det?

Java Virtual Machine (JVM) är ett riktigt namn dropper när du programmerar i Java. I motsats till vad namnet indikerar kan Java Virtual Machine störas i förhållande till andra programmeringsspråk.

I allmänhet är det inte nödvändigt att veta vad Java Virtual Machine är, eller till och med vad det gör, för att kunna programmera i Java. Å andra sidan, att bekanta sig med maskinens inre arbeten hjälper dig att öka din förståelse och övergripande insikt.

Denna artikel borstar över idén om Java Virtual Machine, vad den gör för dig, och några av de viktigaste fördelarna och nackdelarna. Även om jag har försökt att hålla det enkelt, och det finns definitivt mer avancerad litteratur om ämnet, förväntas en rudimentär förståelse för Java och programmering.

Hög nivå språk

Semantiken i ett programmeringsspråk är utformat för att vara nära vårt naturliga språk, samtidigt som det är koncist och lätt att tolka för en maskin. Som du säkert vet är programmeringsspråket helt annorlunda än maskinkod, uppsättningen instruktioner som en dator använder för att konstruera och köra ett program. Detta kallar vi språk på hög nivå; en eller flera abstraktionsnivåer från maskinkoden.

Innan den kan köra, måste högkodskoden först tolkas. Många programmeringsgränssnitt sammanställer i förväg (AOT kompilering) för en specifik plattform. Detta gör programmet mer effektivt vid körning men långt mindre kompatibelt med olika plattformar. Java arbetar däremot med ett mellanliggande språk som heter Java bytecode och den Java Virtual Machine.

JVM & Java Bytecode

När ditt Java-projekt bygger, översätter det källkoden (finns i *.java källfiler) till Java bytecode (oftast i * .class-filer). Detta tar din högnivå kod ett steg närmare maskinkoden, men inte riktigt där än. Denna bytecode är en samling kompakta instruktioner; lättare för en maskin att tolka men mindre läsbar.

När du kör en Java-applikation på din dator, mobiltelefon eller någon annan Java-aktiverad plattform, skickar du i princip Java bytecode till Java Virtual Machine. Tolkaren i Java Virtual Machine börjar vanligen att kompilera hela bytekoden vid körning, enligt principerna för så kallad just-in-time kompilering. Detta medför en typisk, men ofta liten fördröjning när du öppnar en Java-applikation, men förbättrar i allmänhet programets prestanda jämfört med tolkad sammanställning.

Den största fördelen med detta system är den ökade kompatibiliteten. Eftersom dina program körs i en virtuell maskin istället för direkt på din hårdvara, kan utvecklaren programmera och bygga sin applikation en gång, som sedan kan utföras på varje enhet med en implementering av Java Virtual Machine. Denna princip har fött Java-slogan: “Skriv en gång, spring överallt.”

Pro: Kompatibilitet och ökad säkerhet

Bortsett från kodkompatibilitet, kommer Java Virtual Machine med andra fördelar. En av de viktigaste av dessa är den relativa säkerheten för Java-program som ett resultat av Java Virtual Machine. Säkerhet, vilket betyder att ett program som körs i en virtuell maskin är mycket mindre sannolikt att störa användarens operativsystem eller korrupta datafiler om fel uppstår.

Con: Olika JVM-implementeringar och debugging

En av de viktigaste kritikerna mot kodkompatibiliteten och Java Virtual Machine beror på de många olika implementationerna av den senare. Du förstår, Java Virtual Machine är inte ett program. Oracle, Java-ägare, har sin implementering av Java Virtual Machine, men andra kan göra deras om det uppfyller olika praktiska och avtalsenliga krav.

Dessa olika implementeringar innebär att din kod kan fungera smidigt på en Java Virtual Machine, men krasch och bränna på en annan. Även om du i praktiken kan skriva din kod en gång och köra den överallt, måste mer komplext kod ibland debuggeras i olika Java Virtual Machine-implementeringar för att säkerställa korrekt drift.

Har du någon erfarenhet av att arbeta med Java Virtual Machine? Om så är fallet finns det något jag saknade här, som bör nämnas?

Bildkredit: Michaelaw, Dcoetzee

Utforska mer om: Java, Programmering.