Annonse
Diskuterer du for øyeblikket om du vil bruke java til din neste applikasjon, eller bruke originale verktøysett og rammer? Vil du vite hvilke fordeler java gir i forhold til naturlig programmering for et program? Les videre for å finne ut av det!
Hva er en innfødt applikasjon?
Et eget program er et program skrevet spesielt for et operativsystem (OS), og muligens for den spesifikke maskinvaren som kjører det operativsystemet. Det er mest skrevet på et språk som C / C ++. C / C ++ -kildekoden blir satt sammen til en objektform ved hjelp av en kompilator, som deretter settes sammen til en kjørbar ved å koble de nødvendige bibliotekene. Et program som er bygget på denne måten, kjører på den spesifikke maskinvaren og operativsystemet det er bygget for, men fungerer kanskje ikke ordentlig på andre systemer.
Hvorfor er ikke innfødte applikasjoner bærbare?
En kompilator for et språk som C / C ++ oversetter kildekodesetninger til maskinspråk for den målrettede CPU-en. Når du prøver å kjøre denne koden på en annen CPU, kan det hende at programmet ikke fungerer riktig (eller fungerer i det hele tatt) siden maskininstruksene i den kompilerte koden kanskje ikke støttes av denne CPU.
I tillegg kan det nye operativsystemet være forskjellig fra det opprinnelige og kanskje ikke engang gjenkjenne programfilen som en kjørbar. Dette skyldes forskjellige filformater som brukes for kjørbare filer på tvers av forskjellige operativsystemer (for eksempel Windows, Linux, MacOS, etc.).
Portabilitet er et så stort problem med native applikasjoner at bare oppgradering av kompilatoren til neste versjon kan føre til ødelagte endringer. Koden din må kanskje fikses for å fungere med den nyere kompilatoren. Som sådan spruter kildekoden med det som er kjent som ifdef uttalelser for å isolere maskinvare-, OS- eller kompilator-spesifikke løsninger er vanlige.
Følgende er et lite kodebit fra BZLib komprimeringsbibliotek som illustrerer bruken av ifdefs å isolere særegenheter på plattformen:
#ifdef _WIN32. # inkluderer # ifdef small / * windows.h definere small to char * / # undef liten. # slutt om. # ifdef BZ_EXPORT. # definere BZ_API (func) WINAPI func. # definere BZ_EXTERN ekstern. # else / * import windows dll dynamisk * / # definere BZ_API (func) (WINAPI * func) # definere BZ_EXTERN. # slutt om. #ellers. # definere BZ_API (func) func. # definere BZ_EXTERN ekstern. #slutt om. Kildekodeportabilitet på tvers av operativsystemer
Denne situasjonen kan lindres til en viss grad ved å kompilere C / C ++ kildekoden på nytt til den nye CPU. Operativsystemet for den nye CPUen kan imidlertid være forskjellig. Og kildekoden kan ikke samles uten endringer, enten de er større eller mindre. Selv mindre endringer i versjoner av operativsystemet kan kreve endringer i kildekoden.
Og når du vurderer forskjellige operativsystemer som Windows og Linux / UNIX, er portabilitet et helt nytt ballspill. Med mindre du bruker et verktøysett eller et rammeverk som isolerer deg fullstendig fra operativsystemet, er kildekodeportabilitet umulig. Dette er fordi operativsystemgrensesnittet er helt forskjellig mellom disse systemene. Hvis du, i de fjerneste hjørnene av koden din, bruker noen primære operativsystemer, vil ikke koden din være bærbar på tvers av disse forskjellige operativsystemene.
Hvordan er Java annerledes?
Det er i dette scenariet som java leverer et nytt paradigme, en ny måte å bygge programvare på. Når du programmerer i java, målretter du deg 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, nettverksgrensesnitt osv. På den virtuelle maskinen.
Hvordan bygges Java-applikasjoner?
Java-språket gir en Java-kompilator som oversetter kildekoden til objektkode. Objekten utføres deretter av java virtuell maskin, som er et eget program fra kompilatoren. Operativsystemet ser på sin side den virtuelle java-maskinen som bare et annet program som kjører på det operativsystemet.
Byrden med portabilitet har nå skiftet fra applikasjonsprogrammereren til leverandøren av virtuelle java-maskiner. Applikasjonsprogrammereren skriver programvaren ved å bruke primitivene til java-språket, og javaen virtuell maskin er ansvarlig for å oversette disse primitivene til vertsoperativsystemet fasiliteter. Når en ny versjon av OS kommer ut, er det leverandørens ansvar å oppdatere den virtuelle java-maskinen slik at den fungerer riktig på det nye operativsystemet.
Hva er fordelene med Java Virtual Machine?
Som nevnt tidligere gir den virtuelle java-maskinen en virtuell oversikt over operativsystemet og maskinvaren til applikasjonsprogrammøren. Dette virtuelle synspunktet er i form av forskjellige grensesnitt og metoder, og tjener til å isolere applikasjonsprogrammøren fra forskjellene i verts OS og den underliggende maskinvaren. Dermed kan applikasjonsprogrammøren få tilgang til fasiliteter som Windowing Toolkit, Networking, 3D-grafikk, flere CPUer, etc. uten å måtte ty til samtaler på lavt nivå som ender med å gjøre programmet ikke bærbart.
Et java-program skrives og kompileres ved hjelp av java-kompilatoren. Den resulterende objektkoden (kalt byte kode) kan transporteres til et annet host-operativsystem som kjører på annen maskinvare og skal kjøres uten problemer.
JIT Compiler
Den virtuelle java-maskinen bruker a JIT-kompilator for å optimalisere byte-koden spesielt for mål-CPU. JIT står for Akkurat i tide og viser til runtime-optimaliseringene som JVM bruker for byte-koden for å få den til å kjøre bedre på den nåværende CPU.
En annen fordel med å bruke Java Virtual Machine er at den kan bruke forskjellige optimaliseringer for forskjellige brukssaker, alle med samme byte-kode. For eksempel gir Oracle JVM to alternativer for å kjøre bytekoden: en servermodus og en klientmodus. Servermodus optimaliserer for langvarige serverprogrammer, mens klientens JVM-modus optimaliserer for raske responstider siden den sannsynligvis blir brukt i interaktiv modus.
For å oppsummere, er en egen applikasjon bygget for en spesifikk maskinvare og operativsystem. En java-applikasjon følger derimot a Bygg en gang løp hvor som helst filosofi, ved å ha en JVM kjøre de kompilerte byte-kodeanvisningene. Selv om originale applikasjoner tradisjonelt har blitt sett på som mer performante enn java-applikasjoner, kan det ikke alltid være sant på grunn av bruken av en JIT-kompilator av JVM.
Har du utviklet et eget program og måtte bytte til java på grunn av portabilitet? Eller omvendt på grunn av ytelsesproblemer? Gi oss beskjed i kommentarene nedenfor.
Bildekreditt: Profit_Image via Shutterstock.com