Hvorfor Java Virtual Machine hjelper koden din til å kjøre bedre

Diskuterer du for øyeblikket om du vil bruke Java for ditt neste program, eller bruk innfødte verktøy og rammer? Vil du vite hvilke fordeler Java gir over innfødt programmering for et program? Les videre for å finne ut!

Hva er en innfødt søknad?

En innfødt applikasjon er et program som er skrevet spesielt for et operativsystem (OS), og muligens for den spesifikke maskinvaren som kjører det operativsystemet. Det er for det meste skrevet på et språk som C / C ++. C / C + + kildekoden er kompilert til en objektform ved hjelp av en kompilator, som deretter settes sammen i en kjørbar ved å koble de nødvendige biblioteker. Et program bygget på denne måten vil kjøre på den spesifikke maskinvaren og operativsystemet den er bygget for, men fungerer kanskje ikke riktig på andre systemer.

Hvorfor er ikke native applikasjoner bærbare?

En kompilator for et språk som C / C ++ oversetter kildekodenes setninger til maskinspråk for den målrettede CPU. Når du forsøker å kjøre denne koden på en annen CPU, kan det hende at programmet ikke fungerer riktig (eller jobber i det hele tatt), siden maskinens språkinstruksjoner i den kompilerte koden kanskje ikke støttes av denne CPU.

I tillegg kan det nye operativsystemet være forskjellig fra den opprinnelige og kanskje ikke engang gjenkjenne programfilen som en kjørbar. Dette skyldes forskjellige filformater som brukes for kjørbare på forskjellige operativsystemer (for eksempel Windows, Linux, MacOS, etc.).

Bærbarhet er et så stort problem med innfødte applikasjoner som bare kan oppgradere kompilatoren til neste versjon, kan innføre bruddendringer. Koden din må kanskje løses for å fungere med den nyere kompilatoren. Som sådan spatter kildekoden med det som er kjent som ifdef uttalelser for å isolere maskinvare-, OS- eller kompilatorspecifikke løsninger er vanlige.

Følgende er en liten kodebit fra BZLib-komprimeringsbiblioteket som illustrerer bruken av ifdefs å isolere plattformens særegenheter:

#ifdef _WIN32 # inkluderer  # ifdef small / * windows.h definere liten til char * / # undef liten # endif # ifdef BZ_EXPORT # definere BZ_API (func) WINAPI func # definere BZ_EXTERN ekstern # else / * importere windows dll dynamisk * / # definere BZ_API (func) (WINAPI * func) # definere BZ_EXTERN # endif #else # definere BZ_API (func) func # definere BZ_EXTERN ekstern #endif 

Kildekodeportabilitet over operativsystemer

Denne situasjonen kan til en viss grad lindres ved å kompilere C / C + + kildekoden til den nye CPU. Operativsystemet for den nye CPUen kan imidlertid være forskjellig. Og kildekoden kan ikke kompilere uten endringer, enten større eller mindre. Selv små endringer i operativsystemversjoner kan kreve noen endringer i kildekoden.

Og når du ser på forskjellige operativsystemer som Windows og Linux / UNIX, er portabilitet helt nytt ballspill. Med mindre du bruker et verktøykasse eller et rammeverk som helt isolerer deg fra operativsystemet, er det ikke mulig å overføre kildekoden. Dette skyldes at operativsystemgrensesnittet er helt forskjellig mellom disse systemene. Hvis du i de fjerneste hjørner av koden din bruker primitive operativsystemer direkte, vil koden din ikke være bærbar på tvers av disse ulike operativsystemene.

Hvordan er Java annerledes?

Det er i dette scenariet at java leverer et nytt paradigme, en ny måte å bygge programvare på. Når du programmerer i Java, målretter du mot a virtuell maskin. En slik maskin eksisterer som et konsept, og java-språket gir grensesnitt for programmering mot denne maskinen. For eksempel kan du spørre om hvor mye minne som er tilgjengelig, antall CPUer, nettverksgrensesnittene, etc. av den virtuelle maskinen.

Hvordan er Java-programmer bygget?

Java-språket gir en java-kompilator som oversetter kildekoden til objektkode. Objektkoden blir deretter utført av java virtuell maskin, som er et eget program fra kompilatoren. Operativsystemet, i sin tur, ser java virtuell maskin som bare et annet program som kjører på det operativsystemet.

Bærbarhetsbelastningen har nå blitt skiftet fra applikasjonsprogrammereren til java virtuelle maskinleverandøren. Applikasjonsprogrammereren skriver programvaren ved hjelp av primitiver av java-språket, og java-virtuell maskin er ansvarlig for å oversette disse primitiver til vertsoperativsystemet. Når en ny versjon av operativsystemet kommer ut, er det leverandørens ansvar å oppdatere java virtuell maskin slik at den fungerer riktig på det nye operativsystemet.

Hva er fordelene med Java Virtual Machine?

Som nevnt tidligere gir java virtuell maskin en virtuell visning av operativsystemet og maskinvaren til applikasjonsprogrammereren. Denne virtuelle visningen er i form av forskjellige grensesnitt og metoder, og tjener til å isolere applikasjonsprogrammereren fra forskjellene i verts-operativsystemet og den underliggende maskinvaren. Dermed kan applikasjonsprogrammereren få tilgang til fasiliteter som en vindsøkeverktøy, nettverk, 3D-grafikk, flere CPUer, etc. uten å måtte ty til lavnivåsamtaler som ender opp med å gjøre programmet ikke-bærbart.

Et java-program er skrevet og kompilert ved hjelp av java kompilatoren. Den resulterende objektkoden (kalles byte kode) kan transporteres til et annet vertsoperativsystem som kjører på annen maskinvare og burde løpe uten problemer.

JIT Compiler

Java virtuell maskin bruker en JIT kompilator å optimalisere byte-koden spesifikt for mål-CPU. JIT står for Akkurat i tide og refererer til runtimeoptimaliseringene som JVM gjelder for byte-koden for å få det til å løpe bedre på den nåværende CPU.

En annen fordel ved å bruke Java Virtual Machine er at den kan bruke forskjellige optimaliseringer for ulike brukstilfeller, alle med samme bytekode. For eksempel gir Oracle JVM to alternativer for kjøring av bytekode: en servermodus og en klientmodus. Servermodusen optimaliseres for lange løpende serverprogrammer, mens klientens JVM-modus optimaliserer for hurtige svartider siden det sannsynligvis blir brukt i interaktiv modus.

For å oppsummere, er en innfødt applikasjon bygget for et bestemt maskinvare og operativsystem. En Java-applikasjon, derimot, følger a Bygg en gang kjør hvor som helst filosofi, ved å ha en JVM kjører kompilert byte kode instruksjoner. Selv om innfødte applikasjoner tradisjonelt har blitt sett på som mer ytelsesrike enn Java-applikasjoner, kan det ikke alltid være sant på grunn av bruk av en JIT-kompilator av JVM.

Har du utviklet en opprinnelig applikasjon og måtte bytte til Java på grunn av bærbarhet? Eller omvendt på grunn av ytelsesproblemer? Gi oss beskjed i kommentarene nedenfor.

Image Credit: Profit_Image via Shutterstock.com

Utforsk mer om: Java.