Trīs Java pārnesamības veidi

Java ir radījusi daudz satraukuma programmētāju vidē, jo tā sola pārnēsājams lietojumprogrammas un sīklietotnes. Faktiski Java nodrošina trīs atšķirīgus pārnesamības veidus: pirmkodu pārnesamību, CPU arhitektūras pārnesamību un OS / GUI pārnesamību. Fakts, ka pastāv trīs atšķirīgi pārnesamības veidi, ir kritisks, jo tikai viens no šiem veidiem ir Microsoft drauds. Var sagaidīt, ka Microsoft grauj šo viena veida pārnesamību, vienlaikus aptverot pārējos divus - vienlaikus apgalvojot, ka atbalsta Java. Izpratne par trim pārnesamības veidiem un to kopdarbību ir kritiska, lai izprastu Microsoft apdraudējumu un Microsoft iespējamās atbildes.

Pirms sīkāk aplūkot katru no šiem trim pārnesamības veidiem, pārskatīsim dažus pamatnosacījumus.

Dažu terminu definēšana

Šajā rakstā tiek izmantoti šādi termini:

Endianisms

Endianisms attiecas uz baitu glabāšanas secību daudzbaitu daudzumā noteiktā CPU. Piemēram, neparakstītais īss 256 (decimālskaitlis) prasa divus baitus krātuves: 0x01 un 0x00. Šos divus baitus var saglabāt jebkurā secībā: 0x01, 0x00 vai 0x00, 0x01. Endianisms nosaka secību, kādā tiek glabāti divi baiti. Praktiskos nolūkos endiānismam parasti ir nozīme tikai tad, ja dažādu endiānismu procesoriem ir jādala dati.

Java

Java ir vairākas dažādas kopā iepakotas tehnoloģijas - Java programmēšanas valoda, Java virtuālā mašīna (JVM) un ar valodu saistītās klases bibliotēkas. Šajā rakstā ir aplūkoti visi šie aspekti.

Java virtuālā mašīna (JVM)

JVM ir iedomāts centrālais procesors, kuram lielākā daļa Java kompilatoru emitē kodu. Atbalsts šim iedomātajam centrālajam procesoram ļauj Java programmām darboties bez kompilācijas dažādos procesoros. Nekas Java programmēšanas valodā neprasa, lai Java avota kods tiktu apkopots JVM kodā, nevis vietējā objekta kodā.

Faktiski Asymetrix un Microsoft ir paziņojuši par Java kompilatoriem, kas izstaro vietējās Microsoft Windows lietojumprogrammas. (Papildinformāciju skatiet šī raksta sadaļā Resursi.)

J kods

J kods ir izvads, ko lielākā daļa Java kompilatoru izstaro klases failos. J kodu var uzskatīt par Java virtuālās mašīnas objekta kodu.

Pārnesamība

Pārnesamība attiecas uz iespēju palaist programmu dažādās mašīnās. Konkrētas programmas palaišana dažādās mašīnās var prasīt atšķirīgu darba apjomu (piemēram, nekādu darbu, pārkompilēšanu vai nelielu izmaiņu veikšanu avota kodā). Kad cilvēki atsaucas uz Java lietojumprogrammām un sīklietotnēm kā pārnēsājamām, tās parasti nozīmē, ka lietojumprogrammas un sīklietotnes darbojas dažāda veida mašīnās bez izmaiņām (piemēram, atkārtota kompilācija vai avota koda pielāgošana).

Tagad, kad esam apskatījuši dažus būtiskus terminus, mēs izskaidrosim visus trīs Java pārnesamības veidus.

Java kā valoda: pirmkodu pārnesamība

Kā programmēšanas valoda Java nodrošina vienkāršāko un pazīstamāko pārnesamības veidu - pirmkodu pārnesamību. Dota Java programma vajadzētu radīt identiskus rezultātus neatkarīgi no pamata CPU, operētājsistēmas vai Java kompilatora. Šī ideja nav jauna; tādas valodas kā C un C ++ daudzus gadus ir nodrošinājušas iespēju šādam pārnesamības līmenim. Tomēr C un C ++ sniedz arī daudzas iespējas izveidot nepārnēsājamu kodu. Ja vien programmas, kas rakstītas C un C ++, nav paredzētas pārnēsājamībai no paša sākuma, spēja pāriet uz dažādām mašīnām ir vairāk teorētiska nekā praktiska. C un C ++ atstāj nedefinētas detaļas, piemēram, atomu datu tipu lielumu un endiānismu, peldošā komata matemātikas uzvedību, neinicializēto mainīgo lielumu vērtību un uzvedību, kad piekļūstat atbrīvotajai atmiņai.

Īsāk sakot, lai arī C un C ++ sintakse ir precīzi definēta, semantika tā nav. Šis semantiskais vaļīgums ļauj vienā C vai C ++ avota koda blokā apkopot programmas, kas, darbojoties dažādos procesoros, operētājsistēmās, kompilatoros un pat vienā kompilatora / CPU / OS kombinācijā, dod atšķirīgus rezultātus, atkarībā no dažādiem kompilatora iestatījumiem. (Skatiet sānjoslu Sintakse pret semantiku semantikas un sintakses atšķirību apspriešanai.)

Java ir atšķirīga. Java nodrošina daudz stingrāku semantiku un atstāj mazāk īstenotāja ziņā. Atšķirībā no C un C ++, Java atomu tipiem ir definējis izmērus un endiānismu, kā arī definējis peldošā komata uzvedību.

Turklāt Java nosaka vairāk uzvedības nekā C un C ++. Java atmiņa netiek atbrīvota, kamēr tai vairs nevar piekļūt, un valodā nav neinicializētu mainīgo. Visas šīs funkcijas palīdz sašaurināt Java programmas uzvedības variācijas no platformas uz platformu un ieviešanu līdz ieviešanai. Pat bez JVM var sagaidīt, ka Java valodā rakstītās programmas (pēc pārkompilēšanas) daudz labāk pārnēsās uz dažādiem procesoriem un operētājsistēmām nekā līdzvērtīgas C vai C ++ programmas.

Diemžēl funkcijām, kas padara Java tik pārnēsājamu, ir negatīvie aspekti. Java pieņem 32 bitu mašīnu ar 8 bitu baitiem un IEEE754 peldošā komata matemātiku. Mašīnas, kas neatbilst šim modelim, ieskaitot 8 bitu mikrokontrollerus un Cray superdatorus, nevar efektīvi darbināt Java. Šī iemesla dēļ mums vajadzētu sagaidīt, ka C un C ++ tiks izmantoti vairāk platformās nekā Java valoda. Mums vajadzētu arī sagaidīt, ka Java programmas starp tām platformām, kas atbalsta abas, pārnēsā vieglāk nekā C vai C ++.

Java kā virtuālā mašīna: CPU pārnesamība

Lielākā daļa kompilatoru ražo objekta kodu, kas darbojas vienā CPU ģimenē (piemēram, Intel x86 saime). Pat kompilatori, kas ražo objekta kodu vairākām dažādām procesoru grupām (piemēram, x86, MIPS un SPARC), vienlaikus rada objekta kodu tikai vienam procesora tipam; ja jums ir nepieciešams objekta kods trim dažādām CPU ģimenēm, avota kods jāapkopo trīs reizes.

Pašreizējie Java kompilatori ir atšķirīgi. Tā vietā, lai ražotu izvadi katrai atšķirīgai CPU saimei, kurā paredzēts darboties Java programmai, pašreizējie Java kompilatori ražo objekta kodu (sauktu par J kodu) procesoram, kura vēl nepastāv.

(Saule ir paziņoja par CPU, kas tieši izpildīs J kodu, taču norāda, ka pirmie Java mikroshēmu paraugi neparādīsies tikai šī gada otrajā pusē; pilnīga šādu mikroshēmu ražošana tiks sākta nākamajā gadā. Sun Microelectronics picoJavaI pamattehnoloģija būs pašas Sun paša microJava procesoru līnijas centrā, kas būs paredzēta tīkla datoriem. Licenciāti, piemēram, LG Semicon, Toshiba Corp. un Rockwell Collins Inc., arī plāno ražot Java mikroshēmas, pamatojoties uz picoJavaI kodolu.)

Katram reālam centrālajam procesoram, kurā paredzēts darboties Java programmām, Java tulks vai virtuālā mašīna "izpilda" J kodu. Šis neeksistējošais procesors ļauj vienam un tam pašam objekta kodam darboties jebkurā CPU, kuram pastāv Java tulks.

Izejas ražošana iedomātam centrālajam procesoram nav jauna Java: UCSD (Kalifornijas Universitāte, San Diego) Pascal kompilatori pirms gadiem ražoja P kodu; Limbo, jauna programmēšanas valoda, kuru izstrādā Lucent Technologies, ražo objekta kodu iedomātam CPU; un Perls izveido starpposma programmas attēlojumu un izpilda šo starpposma attēlojumu, nevis izveido vietējo izpildāmo kodu. Interneta lietpratējs JVM atšķiras no šiem citiem virtuālajiem procesoriem, ar nolūku veidojot tā, lai ļautu ģenerēt pierādāmi drošu, bez vīrusiem kodu. Pirms interneta izmantošanas virtuālajām mašīnām nebija vajadzība pierādīt programmu drošu un bez vīrusiem. Šī drošības funkcija apvienojumā ar daudz labāku izpratni par to, kā ātri izpildīt programmas iedomātiem procesoriem, ir izraisījusi ātru, plašu JVM akceptēšanu. Mūsdienās lielākajai daļai lielāko operētājsistēmu, tostarp OS / 2, MacOS, Windows 95 / NT un Novell Netware, ir vai ir paredzēts iebūvēts atbalsts J-kodu programmām.

JVM, kas būtībā ir iedomāts centrālais procesors, nav atkarīgs no pirmkodu valodas. Java valoda var radīt J kodu. Bet tā var arī Ada95. Faktiski J koda mitinātie tulki ir rakstīti vairākām valodām, tostarp BASIC, Forth, Lisp un Scheme, un ir gandrīz skaidrs, ka citu valodu ieviešana nākotnē izstaros J kodu. Kad avota kods ir pārveidots par J kodu, Java tulks nevar pateikt, kāda programmēšanas valoda izveidoja J kodu, kuru tas izpilda. Rezultāts: pārnesamība starp dažādiem procesoriem.

Programmu (jebkurā valodā) sastādīšana ar J kodu ir tā, ka viens un tas pats kods darbojas dažādās CPU grupās. Negatīvie ir tas, ka J kods nedarbojas tikpat ātri kā vietējais kods. Lielākajai daļai lietojumprogrammu tas nebūs svarīgi, taču visaugstākās klases augstas klases programmām - tām, kurām nepieciešami pēdējie procenti no procesora - J-koda veiktspējas izmaksas nebūs pieņemamas.

Java kā virtuāla OS un GUI: OS pārnesamība

Lielākā daļa C vai C ++ rakstīto Microsoft Windows programmu pat pēc atkārtotas kompilēšanas netiek viegli pārnestas uz Macintosh vai Unix vidi. Pat ja programmētāji īpaši rūpējas, lai tiktu galā ar semantiskajiem trūkumiem C vai C ++, ports ir grūti. Šīs grūtības rodas pat tad, ja ports operētājsistēmai, kas nav Windows, notiek, nemainot procesorus. Kāpēc grūtības?

Pēc semantisko problēmu novēršanas C un C ++ un centrālā procesora pārnešanas problēmas, programmētājiem joprojām ir jātiek galā ar dažādām operētājsistēmām un dažādiem GUI API izsaukumiem.

Windows programmas veic ļoti atšķirīgus zvanus uz operētājsistēmu nekā Macintosh un Unix programmas. Šie zvani ir kritiski svarīgi, lai rakstītu nebūtiskas programmas, tāpēc, kamēr šī pārnesamības problēma netiks novērsta, pārnešana joprojām būs sarežģīta.

Java atrisina šo problēmu, nodrošinot bibliotēkas funkciju kopu (kas atrodas Java piegādātās bibliotēkās, piemēram, awt, util, un lang), kas runā ar iedomātu OS un iedomātu GUI. Tāpat kā JVM prezentē virtuālo procesoru, Java bibliotēkas piedāvā virtuālo OS / GUI. Katra Java ieviešana nodrošina bibliotēkas, kas ievieš šo virtuālo OS / GUI. Java programmas, kas izmanto šīs bibliotēkas, lai diezgan viegli nodrošinātu nepieciešamo OS un GUI funkcionalitāti.

Pārnēsājamās bibliotēkas izmantošana vietējo OS / GUI zvanu vietā nav jauna ideja. Tādi produkti kā Visix programmatūras Galaxy un Protools programmatūras cinks nodrošina šo iespēju C un C ++. Vēl viena pieeja, kurai Java neseko, ir izvēlēties vienu OS / GUI kā galveno un nodrošināt iesaiņošanas bibliotēkas, kas atbalsta šo galveno OS / GUI visās mašīnās, uz kurām vēlaties pārnest. Galvenās OS / GUI pieejas problēma ir tā, ka pārnestās lietojumprogrammas citās mašīnās bieži izskatās svešas. Piemēram, Macintosh lietotāji sūdzējās par jaunāko Microsoft Word for Macintosh versiju, jo tas izskatījās un izturējās kā Windows programma, nevis kā Macintosh programma. Diemžēl arī Java pieejai ir problēmas.

Java ir nodrošinājusi vismazāk kopsaucēja funkcionalitāti savās OS / GUI bibliotēkās. Tika izlaistas funkcijas, kas pieejamas tikai vienā OS / GUI, piemēram, dialoglodziņi ar cilnēm. Šīs pieejas priekšrocība ir tā, ka kopējās funkcionalitātes kartēšana ar vietējo OS / GUI ir diezgan vienkārša un ar rūpību var nodrošināt lietojumprogrammas, kas darbojas kā paredzēts, lielākajā daļā OS / GUI. Trūkums ir tāds, ka vietējā režīma lietojumprogrammām būs pieejama funkcionalitāte, kas nav pieejama Java lietojumprogrammām. Dažreiz izstrādātāji to varēs novērst, paplašinot AWT; citreiz viņi to nedarīs. Tajos gadījumos, kad vēlamā funkcionalitāte nav sasniedzama, izmantojot risinājumus, izstrādātāji, visticamāk, izvēlēsies rakstīt nepārnēsājamu kodu.

Kas rūpējas par pārnesamību?

Par pārnesamību rūpējas trīs galvenie vēlēšanu apgabali: izstrādātāji, galalietotāji un MIS nodaļas.

Izstrādātāji: iespējas un draudi ir ļoti lieli

Izstrādātājiem ir īpaša interese radīt pārnēsājamu programmatūru. Pozitīvi ir tas, ka pārnēsājamā programmatūra ļauj viņiem atbalstīt vairāk platformu, kas noved pie lielāka potenciālo klientu bāzes. Tomēr tā pati pārnesamība, kas ļauj izstrādātājiem orientēties uz jauniem tirgiem, ļauj konkurentiem orientēties arī uz savu tirgu.

Īsāk sakot, Java pārnesamība izstumj lietojumprogrammatūras tirgu no segregētiem tirgiem, kuru pamatā ir dažādas OS un GUI, un uz vienu lielu tirgu. Piemēram, pašreizējā programmatūras tirgū Microsoft ir spēks, ar kuru jārēķinās Windows un Macintosh lietojumprogrammatūras tirgū, taču OS / 2 un Unix tirgū to gandrīz nav. Šis sadalījums ļauj uzņēmumiem OS / 2 un Unix tirgos neņemt vērā Microsoft kā konkurentu. Java atvieglo šo uzņēmumu konkurenci Windows tirgū, bet ļauj arī Microsoft vieglāk iekļūt OS / 2 un Unix tirgos.

Lietotāji: netiešie ieguvēji no pārnesamības

Lietotājiem vienalga nav pārnesamības. Ja pārnesamība padara viņu dzīvi vieglāku un patīkamāku, tad viņi visi ir par to; ja nē, viņi nav. Pārnesamībai ir pozitīva ietekme uz lietotājiem, taču tā ir nedaudz netieša. Pozitīvā ietekme: