Java har skabt en masse spænding i programmeringssamfundet, fordi det lover transportabel applikationer og applets. Faktisk giver Java tre forskellige typer bærbarhed: kildekodeoverførsel, CPU-arkitekturportabilitet og OS / GUI-bærbarhed. Det faktum, at der er tre forskellige typer bærbarhed, er kritisk, fordi kun en af disse typer er en trussel mod Microsoft. Microsoft kan forventes at underminere den ene type bærbarhed, mens de omfavner de to andre - alt imens de hævder at støtte Java. At forstå de tre typer bærbarhed og hvordan de arbejder sammen er afgørende for forståelsen af truslen mod Microsoft og Microsofts mulige svar.
Før vi springer ind i detaljer om hver af disse tre typer bærbarhed, lad os dog gennemgå et par grundlæggende vilkår.
Definition af nogle udtryk
Følgende udtryk bruges i denne artikel:
- Endianisme
- Endianisme henviser til lagerordren på bytes i en multibytmængde i en given CPU. For eksempel kræver den usignerede korte 256 (decimal) to byte lager: en 0x01 og 0x00. Disse to byte kan gemmes i begge rækkefølge:
0x01, 0x00eller0x00, 0x01. Endianisme bestemmer rækkefølgen, i hvilken de to byte er gemt. Af praktiske formål betyder endianisme normalt kun, når CPU'er med forskellig endianisme skal dele data. - Java
- Java er flere forskellige teknologier pakket sammen - Java-programmeringssprog, Java virtual machine (JVM) og klassebibliotekerne, der er knyttet til sproget. Denne artikel diskuterer alle disse aspekter.
- Java virtuel maskine (JVM)
JVM er en imaginær CPU, som de fleste Java-compilere udsender kode for. Støtte til denne imaginære CPU er det, der gør det muligt for Java-programmer at køre uden at blive kompileret igen på forskellige CPU'er. Intet i Java-programmeringssproget kræver, at Java-kildekode kompileres til kode til JVM i stedet for til native objektkode.
Faktisk har Asymetrix og Microsoft annonceret Java-compilere, der udsender native Microsoft Windows-applikationer. (Se afsnittet Ressourcer i denne artikel for yderligere information.)
- J-kode
- J-kode er det output, som de fleste Java-kompilatorer udsender i klassefilerne. J-kode kan betragtes som objektkode til den virtuelle Java-maskine.
- Bærbarhed
- Portabilitet henviser til evnen til at køre et program på forskellige maskiner. At køre et givet program på forskellige maskiner kan kræve forskellige mængder arbejde (for eksempel intet arbejde overhovedet, kompilering eller foretage små ændringer i kildekoden). Når folk henviser til Java-applikationer og applets som bærbare, betyder de normalt, at applikationer og applets kører på forskellige typer maskiner uden ændringer (såsom rekompilering eller tweaks til kildekoden).
Nu hvor vi har dækket nogle vigtige udtryk, forklarer vi hver af de tre typer Java-bærbarhed.
Java som sprog: kildekodeportabilitet
Som programmeringssprog giver Java den enkleste og mest velkendte form for bærbarhed - kildekodeportabilitet. Et givet Java-program skulle gerne producere identiske resultater uanset den underliggende CPU, operativsystem eller Java-kompilator. Denne idé er ikke ny; sprog som C og C ++ har givet mulighed for dette niveau af bærbarhed i mange år. C og C ++ giver dog også adskillige muligheder for også at oprette ikke-bærbar kode. Medmindre programmer skrevet i C og C ++ er designet til at være bærbare fra starten, er evnen til at flytte til forskellige maskiner mere teoretisk end praktisk. C og C ++ efterlader udefinerede detaljer, såsom størrelsen og endianismen af atomiske datatyper, opførelsen af flydende matematik, værdien af uinitialiserede variabler og adfærden, når der er adgang til fri hukommelse.
Kort sagt, selvom syntaksen for C og C ++ er veldefineret, er semantikken ikke. Denne semantiske løshed tillader en enkelt blok af C- eller C ++ -kildekode at kompilere til programmer, der giver forskellige resultater, når de køres på forskellige CPU'er, operativsystemer, compilere og endda på en enkelt compiler / CPU / OS-kombination afhængigt af forskellige compilerindstillinger. (Se sidepanelet Syntaks versus semantik til en diskussion af forskellene mellem semantik og syntaks.)
Java er anderledes. Java leverer meget strengere semantik og overlader mindre til implementereren. I modsætning til C og C ++ har Java defineret størrelser og endianisme for atomtyperne samt defineret flydende punktadfærd.
Derudover definerer Java mere adfærd end C og C ++. I Java frigøres hukommelse ikke, før den ikke længere kan tilgås, og sproget har ikke uinitialiserede variabler. Alle disse funktioner hjælper med at indsnævre variationen i et Java-programs opførsel fra platform til platform og implementering til implementering. Selv uden JVM kan programmer, der er skrevet på Java-sproget, forventes at portes (efter rekompilering) til forskellige CPU'er og operativsystemer meget bedre end tilsvarende C- eller C ++ -programmer.
Desværre har de funktioner, der gør Java så bærbare, en ulempe. Java antager en 32-bit maskine med 8-bit byte og IEEE754 flydende matematik. Maskiner, der ikke passer til denne model, inklusive 8-bit mikrocontrollere og Cray supercomputere, kan ikke køre Java effektivt. Af denne grund bør vi forvente, at C og C ++ bruges på flere platforme end Java-sproget. Vi bør også forvente, at Java-programmer portes lettere end C eller C ++ mellem de platforme, der understøtter begge dele.
Java som en virtuel maskine: CPU-bærbarhed
De fleste compilere producerer objektkode, der kører på en CPU-familie (for eksempel Intel x86-familien). Selv kompilatorer, der producerer objektkode til flere forskellige CPU-familier (f.eks. X86, MIPS og SPARC), producerer kun objektkode for en CPU-type ad gangen; hvis du har brug for objektkode til tre forskellige CPU-familier, skal du kompilere din kildekode tre gange.
De nuværende Java-kompilatorer er forskellige. I stedet for at producere output for hver anden CPU-familie, som Java-programmet er beregnet til at køre på, producerer de nuværende Java-kompilatorer objektkode (kaldet J-kode) til en CPU, der endnu ikke findes.
(Sol har annoncerede en CPU, der vil udføre J-kode direkte, men indikerer, at de første prøver af Java-chips først vises i anden halvdel af dette år; fuld produktion af sådanne chips begynder næste år. Sun Microelectronics 'picoJavaI-kerneteknologi vil være kernen i Suns egen microJava-processorlinje, der er målrettet mod netværkscomputere. Licenshavere som LG Semicon, Toshiba Corp. og Rockwell Collins Inc. planlægger også at producere Java-chips baseret på picoJavaI-kernen.)
For hver rigtig CPU, som Java-programmer er beregnet til at køre, "udfører" en Java-tolk eller virtuel maskine J-koden. Denne ikke-eksisterende CPU tillader, at den samme objektkode kører på enhver CPU, som der findes en Java-tolk.
At producere output til en imaginær CPU er ikke nyt med Java: UPSD (University of California i San Diego) Pascal-kompilatorer producerede P-kode for mange år siden; Limbo, et nyt programmeringssprog under udvikling hos Lucent Technologies, producerer objektkode til en imaginær CPU; og Perl opretter en mellemliggende programrepræsentation og udfører denne mellemrepræsentation i stedet for at oprette native eksekverbar kode. Den internetkyndige JVM adskiller sig fra disse andre virtuelle CPU-implementeringer ved bevidst at være designet til at tillade generering af beviseligt sikker, virusfri kode. Forud for Internettet var der ikke behov for virtuelle maskiner til at bevise programmer sikre og virusfrie. Denne sikkerhedsfunktion kombineret med en meget bedre forståelse af, hvordan man hurtigt udfører programmer til imaginære CPU'er, har ført til hurtig, udbredt accept af JVM. I dag har de fleste større operativsystemer, herunder OS / 2, MacOS, Windows 95 / NT og Novell Netware, enten eller forventes at have indbygget support til J-kodeprogrammer.
JVM, der i det væsentlige er en imaginær CPU, er uafhængig af kildekodesproget. Java-sproget kan producere J-kode. Men det kan Ada95 også. Faktisk er J-code-hostede tolke blevet skrevet til flere sprog, herunder BASIC, Forth, Lisp og Scheme, og det er næsten sikkert, at implementeringer af andre sprog vil udsende J-kode i fremtiden. Når kildekoden er konverteret til J-kode, kan Java-tolk ikke fortælle, hvilket programmeringssprog der oprettede den J-kode, den udførte. Resultatet: bærbarhed mellem forskellige CPU'er.
Fordelen ved at kompilere programmer (på ethvert sprog) til J-kode er, at den samme kode kører på forskellige familier af CPU'er. Ulempen er, at J-kode ikke kører så hurtigt som native-kode. For de fleste applikationer betyder det ikke noget, men for de højeste af avancerede programmer - dem, der har brug for hver sidste procent af CPU'en - vil præstationsomkostningerne for J-kode ikke være acceptabel.
Java som et virtuelt operativsystem og GUI: OS-bærbarhed
De fleste Microsoft Windows-programmer, der er skrevet i C eller C ++, kan ikke nemt porteres til Macintosh- eller Unix-miljøet, selv efter genkompilering. Selvom programmørerne er ekstra forsigtige med at håndtere de semantiske svagheder i C eller C ++, er porten vanskelig. Denne vanskelighed opstår, selv når porten til ikke-Windows-operativsystemet finder sted uden at ændre CPU'er. Hvorfor vanskeligheden?
Efter at have fjernet de semantiske problemer i C og C ++ og CPU-porting-problemer, skal programmører stadig beskæftige sig med det forskellige operativsystem og forskellige GUI API-opkald.
Windows-programmer foretager meget forskellige opkald til operativsystemet end Macintosh- og Unix-programmer. Disse opkald er kritiske for at skrive ikke-trivielle programmer, så indtil dette problem med bærbarhed er løst, er det stadig vanskeligt at portere.
Java løser dette problem ved at levere et sæt biblioteksfunktioner (indeholdt i Java-leverede biblioteker som f.eks awt, utilog lang) der taler til et imaginært operativsystem og imaginært GUI. Ligesom JVM præsenterer en virtuel CPU, præsenterer Java-bibliotekerne et virtuelt OS / GUI. Hver Java-implementering giver biblioteker, der implementerer dette virtuelle OS / GUI. Java-programmer, der bruger disse biblioteker til at levere den nødvendige OS- og GUI-funktionalitetsport relativt let.
Brug af et portabilitetsbibliotek i stedet for native OS / GUI-opkald er ikke en ny idé. Produkter som Visix Softwares Galaxy og Protools Softwares Zink giver denne mulighed for C og C ++. En anden tilgang, ikke fulgt af Java, er at vælge et enkelt OS / GUI som master og levere wrapper-biblioteker, der understøtter dette master OS / GUI på alle maskiner, som du vil portere til. Problemet med master OS / GUI-tilgangen er, at de porterede applikationer ofte ser fremmede ud på de andre maskiner. Macintosh-brugere klagede for eksempel over en nyere version af Microsoft Word til Macintosh, fordi den så ud og opførte sig som et Windows-program, ikke som et Macintosh-program. Desværre har den tilgang, som Java har taget, også problemer.
Java har leveret en mindst-fællesnævnerfunktionalitet i sine OS / GUI-biblioteker. Funktioner, der kun er tilgængelige på en OS / GUI, såsom dialogbokse med faner, blev udeladt. Fordelen ved denne tilgang er, at kortlægning af den fælles funktionalitet til det oprindelige OS / GUI er ret let og med omhu kan levere applikationer, der fungerer som forventet på de fleste OS'er / GUI'er. Ulempen er, at der vil være funktionalitet tilgængelig for native-mode applikationer, der ikke er tilgængelig for Java-applikationer. Nogle gange vil udviklere være i stand til at omgå dette ved at udvide AWT; andre gange vil de ikke. I de tilfælde, hvor ønsket funktionalitet ikke kan opnås med løsninger, vil udviklere sandsynligvis vælge at skrive ikke-bærbar kode.
Hvem bekymrer sig om bærbarhed?
Tre hovedkredse er opmærksomme på bærbarhed: udviklere, slutbrugere og MIS-afdelinger.
Udviklere: Muligheder og trusler væver store
Udviklere har en interesse i at skabe bærbar software. På den positive side giver bærbar software dem mulighed for at understøtte flere platforme, hvilket fører til en større base af potentielle kunder. Den samme bærbarhed, der giver udviklere mulighed for at målrette mod nye markeder, giver dog også konkurrenter mulighed for at målrette mod deres marked.
I en nøddeskal skubber Java-portabilitet applikationssoftwaremarkedet væk fra adskilte markeder baseret på de forskellige OS'er og GUI'er og mod et stort marked. På det nuværende softwaremarked er Microsoft for eksempel en kraft, der skal tages i betragtning på Windows- og Macintosh-applikationssoftwaremarkederne, men har næsten ingen tilstedeværelse på OS / 2- og Unix-markederne. Denne partitionering gør det muligt for virksomheder i OS / 2 og Unix-markederne at se bort fra Microsoft som en konkurrent. Java gør det lettere for disse virksomheder at konkurrere på Windows-markedet, men giver også Microsoft lettere adgang til OS / 2 og Unix-markederne.
Brugere: De indirekte modtagere af bærbarhed
Brugere er i sig selv ligeglade med bærbarhed. Hvis bærbarhed gør deres liv lettere og mere behageligt, så er de alt for det; hvis ikke, er de ikke. Bærbarhed har nogle positive virkninger for brugerne, men disse er noget indirekte. De positive effekter:
