Programmering

Java's tre typer bærbarhet

Java har skapt mye spenning i programmeringssamfunnet fordi det lover bærbar applikasjoner og appletter. Faktisk gir Java tre forskjellige typer bærbarhet: kildekodeportabilitet, CPU-arkitekturportabilitet og OS / GUI-portabilitet. Det at det er tre forskjellige typer bærbarhet er avgjørende, fordi bare en av disse typene er en trussel for Microsoft. Microsoft kan forventes å undergrave den ene typen bærbarhet mens de omfavner de andre to - hele tiden mens de hevder å støtte Java. Å forstå de tre typene bærbarhet og hvordan de fungerer sammen, er avgjørende for å forstå trusselen mot Microsoft og Microsofts mulige svar.

Før vi hopper inn i detaljer om hver av disse tre typene bærbarhet, la oss gjennomgå noen grunnleggende vilkår.

Definere noen begreper

Følgende begreper brukes i denne artikkelen:

Endianisme
Endianisme refererer til lagringsrekkefølgen for byte i en multibyte-mengde i en gitt CPU. For eksempel krever den usignerte korte 256 (desimal) to byte lagring: en 0x01 og 0x00. Disse to byte kan lagres i begge rekkefølger: 0x01, 0x00 eller 0x00, 0x01. Endianisme bestemmer rekkefølgen de to bytene lagres i. For praktiske formål betyr endianisme vanligvis bare når CPUer med forskjellig endianisme må dele data.
Java
Java er flere forskjellige teknologier pakket sammen - Java-programmeringsspråket, Java virtual machine (JVM) og klassebibliotekene som er tilknyttet språket. Denne artikkelen diskuterer alle disse aspektene.
Java virtual machine (JVM)

JVM er en imaginær CPU som de fleste Java-kompilatorer sender ut kode. Støtte for denne imaginære CPUen er det som lar Java-programmer kjøre uten å bli kompilert på forskjellige CPUer. Ingenting i Java-programmeringsspråket krever at Java-kildekode blir samlet til kode for JVM i stedet for til opprinnelig objektkode.

Faktisk har Asymetrix og Microsoft kunngjort Java-kompilatorer som avgir native Microsoft Windows-applikasjoner. (Se Ressursdelen i denne artikkelen for ytterligere informasjon.)

J-kode
J-kode er utdata fra de fleste Java-kompilatorer til klassefilene. J-kode kan betraktes som objektkode for den virtuelle Java-maskinen.
Bærbarhet
Portabilitet refererer til muligheten til å kjøre et program på forskjellige maskiner. Å kjøre et gitt program på forskjellige maskiner kan kreve forskjellige mengder arbeid (for eksempel ikke noe arbeid, kompilering eller små endringer i kildekoden). Når folk omtaler Java-applikasjoner og applets som bærbare, betyr de vanligvis at applikasjoner og applets kjøres på forskjellige typer maskiner uten endringer (for eksempel rekompilering eller justering av kildekoden).

Nå som vi har dekket noen viktige vilkår, forklarer vi hver av de tre typene Java-bærbarhet.

Java som språk: kildekodeportabilitet

Som programmeringsspråk gir Java den enkleste og mest kjente formen for bærbarhet - kildekodeportabilitet. Et gitt Java-program bør produsere identiske resultater uavhengig av underliggende CPU, operativsystem eller Java-kompilator. Denne ideen er ikke ny; språk som C og C ++ har gitt muligheten for dette nivået av bærbarhet i mange år. Imidlertid gir C og C ++ også mange muligheter til å lage ikke-bærbar kode. Med mindre programmer skrevet i C og C ++ er designet for å være bærbare fra begynnelsen, er muligheten til å flytte til forskjellige maskiner mer teoretisk enn praktisk. C og C ++ etterlater udefinerte detaljer som størrelsen og endianismen til atomdata, oppførselen til matematikk med flytende punkt, verdien av uinitialiserte variabler og oppførselen når frigjort minne er tilgjengelig.

Kort sagt, selv om syntaksen til C og C ++ er veldefinert, er ikke semantikken det. Denne semantiske løsheten tillater at en enkelt blokk med C- eller C ++ kildekode kompileres til programmer som gir forskjellige resultater når de kjøres på forskjellige CPUer, operativsystemer, kompilatorer og til og med på en enkelt kompilator / CPU / OS-kombinasjon, avhengig av forskjellige kompilatorinnstillinger. (Se sidefeltet Syntaks kontra semantikk for en diskusjon om forskjellene mellom semantikk og syntaks.)

Java er annerledes. Java gir mye strengere semantikk og overlater mindre til oppdragsgiveren. I motsetning til C og C ++ har Java definert størrelser og endianisme for atomtyper, samt definert flytende punktadferd.

I tillegg definerer Java mer atferd enn C og C ++. I Java blir ikke minnet frigjort før det ikke lenger er tilgjengelig, og språket har ingen uinitialiserte variabler. Alle disse funksjonene bidrar til å begrense variasjonen i oppførselen til et Java-program fra plattform til plattform og implementering til implementering. Selv uten JVM kan programmer som er skrevet på Java-språket forventes å portere (etter rekompilering) til forskjellige CPUer og operativsystemer mye bedre enn tilsvarende C- eller C ++ -programmer.

Dessverre har funksjonene som gjør Java så bærbare en ulempe. Java antar en 32-biters maskin med 8-biters byte og IEEE754 matematikk med flytende punkt. Maskiner som ikke passer til denne modellen, inkludert 8-biters mikrokontrollere og Cray superdatamaskiner, kan ikke kjøre Java effektivt. Av denne grunn bør vi forvente at C og C ++ skal brukes på flere plattformer enn Java-språket. Vi bør også forvente at Java-programmer skal porteres enklere enn C eller C ++ mellom de plattformene som støtter begge deler.

Java som en virtuell maskin: CPU-portabilitet

De fleste kompilatorer produserer objektkode som kjører på en CPU-familie (for eksempel Intel x86-familien). Selv kompilatorer som produserer objektkode for flere forskjellige CPU-familier (for eksempel x86, MIPS og SPARC), produserer bare objektkode for en CPU-type om gangen; Hvis du trenger objektkode for tre forskjellige familier av CPU, må du kompilere kildekoden tre ganger.

De nåværende Java-kompilatorene er forskjellige. I stedet for å produsere utdata for hver forskjellige CPU-familie som Java-programmet er ment å kjøre på, produserer de nåværende Java-kompilatorene objektkode (kalt J-kode) for en CPU som ennå ikke eksisterer.

(Sol har kunngjorde en CPU som vil utføre J-kode direkte, men indikerer at de første prøvene av Java-sjetonger ikke vises før i andre halvdel av året; full produksjon av slike chips begynner neste år. Sun Microelectronics 'picoJavaI-kjerneteknologi vil være hjertet i Suns egen microJava-prosessorlinje, som vil målrette nettverksdatamaskiner. Lisensinnehavere som LG Semicon, Toshiba Corp. og Rockwell Collins Inc. planlegger også å produsere Java-sjetonger basert på picoJavaI-kjernen.)

For hver ekte CPU der Java-programmer er ment å kjøre, "kjører" en Java-tolk eller virtuell maskin J-koden. Denne ikke-eksisterende CPU-en lar den samme objektkoden kjøre på hvilken som helst CPU som det finnes en Java-tolk for.

Å produsere utdata for en tenkt CPU er ikke nytt med Java: UCSD (University of California i San Diego) Pascal-kompilatorer produserte P-kode for mange år siden; Limbo, et nytt programmeringsspråk under utvikling hos Lucent Technologies, produserer objektkode for en tenkt CPU; og Perl oppretter en mellomliggende programrepresentasjon og utfører denne mellomrepresentasjonen i stedet for å opprette innfødt kjørbar kode. Den internettkyndige JVM skiller seg ut fra disse andre virtuelle CPU-implementeringene ved å med vilje være designet for å tillate generering av beviselig sikker, virusfri kode. Før Internett var det ikke behov for virtuelle maskiner for å bevise at programmene er sikre og virusfrie. Denne sikkerhetsfunksjonen, kombinert med en mye bedre forståelse av hvordan du raskt kjører programmer for imaginære CPUer, har ført til rask, utbredt aksept av JVM. I dag har de fleste store operativsystemene, inkludert OS / 2, MacOS, Windows 95 / NT og Novell Netware, enten eller forventes å ha innebygd støtte for J-kodeprogrammer.

JVM, som egentlig er en imaginær CPU, er uavhengig av kildekodespråket. Java-språket kan produsere J-kode. Men det kan Ada95 også. Faktisk er tolker som er hostet av J-kode skrevet for flere språk, inkludert BASIC, Forth, Lisp og Scheme, og det er nesten sikkert at implementeringer av andre språk vil avgi J-kode i fremtiden. Når kildekoden er konvertert til J-kode, kan ikke Java-tolk fortelle hvilket programmeringsspråk som ble opprettet J-koden den utførte. Resultatet: bærbarhet mellom forskjellige CPUer.

Fordelen med å kompilere programmer (på hvilket som helst språk) til J-kode er at den samme koden kjører på forskjellige familier av CPUer. Ulempen er at J-kode ikke kjører så fort som innfødt kode. For de fleste applikasjoner vil dette ikke ha noe å si, men for de høyeste av avanserte programmer - de som trenger hver siste prosent av CPU - vil ytelseskostnadene for J-kode ikke være akseptable.

Java som et virtuelt operativsystem og GUI: OS-portabilitet

De fleste Microsoft Windows-programmer skrevet i C eller C ++, porteres ikke lett til Macintosh- eller Unix-miljøene, selv ikke etter kompilering. Selv om programmererne er ekstra forsiktige med å takle de semantiske svakhetene i C eller C ++, er porten vanskelig. Denne vanskeligheten oppstår selv når porten til operativsystemet som ikke er Windows, finner sted uten å endre CPU. Hvorfor vanskeligheten?

Etter å ha eliminert de semantiske problemene i C og C ++ og CPU-porteringsproblemene, må programmerere fortsatt håndtere det forskjellige operativsystemet og forskjellige GUI API-anrop.

Windows-programmer ringer til operativsystemet veldig forskjellige enn Macintosh- og Unix-programmer. Disse samtalene er avgjørende for å skrive ikke-trivielle programmer, så til dette portabilitetsproblemet er løst, vil det være vanskelig å portere.

Java løser dette problemet ved å tilby et sett med biblioteksfunksjoner (som finnes i Java-leverte biblioteker som f.eks awt, util, og lang) som snakker med et tenkt operativsystem og tenkt GUI. Akkurat som JVM presenterer en virtuell CPU, presenterer Java-bibliotekene et virtuelt OS / GUI. Hver Java-implementering gir biblioteker som implementerer dette virtuelle OS / GUI. Java-programmer som bruker disse bibliotekene for å gi nødvendig OS- og GUI-funksjonalitetsport ganske enkelt.

Å bruke et portabilitetsbibliotek i stedet for innfødte OS / GUI-anrop er ikke en ny ide. Produkter som Visix Software's Galaxy og Protools Software's sink gir denne muligheten for C og C ++. En annen tilnærming, ikke fulgt av Java, er å velge en enkelt OS / GUI som master og tilby wrapper-biblioteker som støtter dette master OS / GUI på alle maskiner du vil portere til. Problemet med master OS / GUI-tilnærmingen er at de portede applikasjonene ofte ser fremmed ut på de andre maskinene. Macintosh-brukere klaget for eksempel på en nylig versjon av Microsoft Word for Macintosh fordi den så ut og oppførte seg som et Windows-program, ikke som et Macintosh-program. Dessverre har tilnærmingen Java har tatt også problemer.

Java har levert en funksjon som har minst fellesnevner i OS / GUI-bibliotekene. Funksjoner som er tilgjengelige på bare ett OS / GUI, for eksempel fanedialogbokser, ble utelatt. Fordelen med denne tilnærmingen er at kartlegging av den vanlige funksjonaliteten til det opprinnelige operativsystemet / GUI er ganske enkelt og med forsiktighet kan tilby applikasjoner som fungerer som forventet på de fleste operativsystemer / GUIer. Ulempen er at det vil være funksjonalitet tilgjengelig for native-modus-applikasjoner som ikke er tilgjengelig for Java-applikasjoner. Noen ganger vil utviklere kunne omgå dette ved å utvide AWT; andre ganger vil de ikke. I de tilfeller der ønsket funksjonalitet er uoppnåelig med løsninger, vil utviklere sannsynligvis velge å skrive ikke-bærbar kode.

Hvem bryr seg om bærbarhet?

Tre hovedkretser bryr seg om bærbarhet: utviklere, sluttbrukere og MIS-avdelinger.

Utviklere: Muligheter og trusler er store

Utviklere har en interesse i å lage bærbar programvare. På forsiden lar bærbar programvare dem støtte flere plattformer, noe som fører til en større base av potensielle kunder. Den samme bærbarheten som gjør at utviklere kan målrette seg mot nye markeder, gir imidlertid også konkurrenter muligheten til å målrette markedet.

I et nøtteskall presser Java-portabilitet applikasjonsprogramvaremarkedet bort fra segregerte markeder basert på de forskjellige operativsystemene og GUI-ene og mot ett stort marked. I det nåværende programvaremarkedet er Microsoft for eksempel en kraft å regne med i programvaremarkedene for Windows og Macintosh, men har nesten ingen tilstedeværelse i OS / 2 og Unix-markedene. Denne partisjonen gjør det mulig for selskaper i OS / 2 og Unix-markedene å se bort fra Microsoft som en konkurrent. Java gjør det lettere for disse selskapene å konkurrere i Windows-markedet, men gir også Microsoft lettere tilgang til OS / 2 og Unix-markedet.

Brukere: De indirekte mottakerne av bærbarhet

Brukere bryr seg ikke om portabilitet. Hvis bærbarhet gjør livet enklere og hyggeligere, er de alt for det; hvis ikke, er de ikke det. Bærbarhet har noen positive effekter for brukerne, men disse er noe indirekte. De positive effektene:

$config[zx-auto] not found$config[zx-overlay] not found