Annons
Debatterar du för närvarande om du vill använda java för din nästa applikation eller använda inbyggda verktygssatser och ramverk? Vill du veta vilka fördelar java ger jämfört med programmering för en applikation? Läs vidare för att ta reda på det!
Vad är en inföding?
En naturlig applikation är ett program som är skrivet specifikt för ett operativsystem (OS) och eventuellt för den specifika hårdvaran som kör det operativsystemet. Det är mest skrivet på ett språk som C / C ++. C / C ++ -källkoden sammanställs till en objektform med hjälp av en kompilator, som sedan monteras i en körbar genom att länka de nödvändiga biblioteken. Ett program som är byggt på detta sätt kommer att köras på den specifika hårdvaran och operativsystemet det är byggt för, men kanske inte fungerar korrekt på andra system.
Varför är inte infödda applikationer bärbara?
En kompilator för ett språk som C / C ++ översätter källkodsatser till maskinspråk för den riktade CPU: n. När du försöker köra den här koden på en annan CPU kanske programmet kanske inte fungerar korrekt (eller fungerar alls) eftersom maskinens språkinstruktioner i den sammanställda koden kanske inte stöds av denna CPU.
Dessutom kan det nya operativsystemet skilja sig från det ursprungliga och kanske inte ens känner igen programfilen som en körbar. Detta beror på olika filformat som används för körbara filer över olika operativsystem (som Windows, Linux, MacOS, etc.).
Portabilitet är en så stor fråga med ursprungliga applikationer att bara en uppgradering av kompilatorn till nästa version kan innebära brottförändringar. Din kod kan behöva fixas för att fungera med den nyare kompilatorn. Som sådan sprutar källkoden med vad som kallas ifdef uttalanden för att isolera hårdvara-, OS- eller kompileringsspecifika lösningar är vanliga.
Följande är ett litet kodavsnitt från BZLib-komprimeringsbibliotek vilket illustrerar användningen av ifdefs för att isolera plattformsegenskaper:
#ifdef _WIN32. # inkludera # ifdef small / * windows.h definiera small to char * / # undef litet. # endif. # ifdef BZ_EXPORT. # definiera BZ_API (func) WINAPI func. # definiera BZ_EXTERN extern. # else / * importera windows dll dynamiskt * / # definiera BZ_API (func) (WINAPI * func) # definiera BZ_EXTERN. # endif. #annan. # definiera BZ_API (func) func. # definiera BZ_EXTERN extern. #endif. Källkodportabilitet över operativsystem
Denna situation kan till viss del lindras genom att kompilera C / C ++ -källkoden till den nya CPU: n. Operativsystemet för den nya CPU kan dock vara annorlunda. Och källkoden kanske inte sammanställs utan ändringar, vare sig större eller mindre. Även mindre ändringar i operativsystemversioner kan kräva vissa källkodförändringar.
Och när du överväger olika operativsystem som Windows och Linux / UNIX, är portabilitet helt nytt bollspel. Om du inte använder en verktygssats eller ett ramverk som helt isolerar dig från operativsystemet är källkodportabilitet omöjligt. Detta beror på att operativsystemgränssnittet är helt annorlunda mellan dessa system. Om du, i de avlägsta hörnen av din kod, använder några primära operativsystem, kommer din kod inte att vara portabel över dessa olika operativsystem.
Hur är Java annorlunda?
Det är i detta scenario som java levererar ett nytt paradigm, ett nytt sätt att bygga programvara. När du programmerar i java riktar du dig till a virtuell maskin. En sådan maskin finns som ett koncept, och java-språket ger gränssnitt för programmering mot denna maskin. Till exempel kan du fråga hur mycket minne som finns tillgängligt, antalet CPU: er, nätverksgränssnitten osv på den virtuella maskinen.
Hur byggs Java-applikationer?
Java-språket tillhandahåller en java-kompilator som översätter källkoden till objektkod. Objekten körs sedan av java virtuell maskin, som är ett separat program från kompilatorn. Operativsystemet visar i sin tur den virtuella java-maskinen som bara ett annat program som körs på det operativsystemet.
Bärbarheten för portabilitet har nu flyttats från applikationsprogrammeraren till leverantören av virtuell java-maskin. Applikationsprogrammeraren skriver programvaran med hjälp av primitiven för java-språket och java virtuell maskin ansvarar för att översätta dessa primitiva till värdoperativsystemet anläggningar. När en ny version av operativsystemet kommer ut är det leverantörens ansvar att uppdatera den virtuella java-maskinen så att den fungerar korrekt på det nya operativsystemet.
Vilka är fördelarna med Java Virtual Machine?
Som nämnts tidigare ger den virtuella java-maskinen en virtuell bild av operativsystemet och hårdvaran till applikationsprogrammeraren. Denna virtuella vy är i form av olika gränssnitt och metoder och tjänar till att isolera applikationsprogrammeraren från skillnaderna i värdens OS och den underliggande hårdvaran. Således kan applikationsprogrammeraren få tillgång till faciliteter som en Windowing Toolkit, nätverk, 3D-grafik, flera processorer etc. utan att behöva tillgripa samtal på låg nivå som i slutändan gör programmet inte portabelt.
Ett java-program skrivs och sammanställs med java-kompilatorn. Den resulterande objektkoden (kallas byte-kod) kan transporteras till ett annat värdoperativsystem som körs på annan hårdvara och bör köras utan problem.
JIT Compiler
Den java virtuella maskinen använder en JIT-kompilator för att optimera bytekoden specifikt för mål-CPU: n. JIT står för Precis i tid och hänvisar till runtime-optimeringarna som JVM tillämpar för byte-koden för att få den att köra bättre på den aktuella CPU: n.
En annan fördel med att använda Java Virtual Machine är att den kan tillämpa olika optimeringar för olika användningsfall, alla med samma byte-kod. Till exempel ger Oracle JVM två alternativ för att köra byte-koden: ett serverläge och ett klientläge. Serverläget optimerar för långvariga serverprogram medan klientens JVM-läge optimerar för snabba svarstider eftersom det troligtvis används i interaktivt läge.
Sammanfattningsvis är en inbyggd applikation byggd för en specifik hårdvara och operativsystem. En java-applikation följer å andra sidan a Bygg en gång kör någonstans filosofi, genom att ha en JVM som kör de sammanställda byte-kodinstruktionerna. Även om inhemska applikationer traditionellt har betraktats som mer utförande än java-applikationer, kanske det inte alltid är sant på grund av användningen av en JIT-kompilator av JVM.
Har du utvecklat en egen applikation och var tvungen att byta till java på grund av portabilitet? Eller vice versa på grund av prestandafrågor? Låt oss veta i kommentarerna nedan.
Bildkredit: Profit_Image via Shutterstock.com