Ohjelmointi

Java on kolmen tyyppinen siirrettävyys

Java on herättänyt paljon jännitystä ohjelmointiyhteisössä, koska se lupaa kannettava sovellukset ja sovelmat. Itse asiassa Java tarjoaa kolme erillistä siirrettävyystyyppiä: lähdekoodin siirrettävyys, CPU-arkkitehtuurin siirrettävyys ja OS / GUI-siirrettävyys. Se, että siirrettävyyttä on kolme erillistä tyyppiä, on kriittinen, koska vain yksi näistä tyypeistä on uhka Microsoftille. Microsoftin voidaan odottaa heikentävän tämäntyyppistä siirrettävyyttä samalla kun se käsittää kaksi muuta - väittäen samalla tukevansa Java-ohjelmaa. Kolmen tyyppisen siirrettävyyden ja niiden yhteistyön ymmärtäminen on kriittistä ymmärrettäessä Microsoftin uhkaa ja Microsoftin mahdollisia vastauksia.

Ennen kuin ryhdymme yksityiskohtiin näistä kolmesta siirrettävyystyypistä, katsotaanpa muutama peruskäsite.

Määritellään joitain termejä

Tässä artikkelissa käytetään seuraavia termejä:

Endianismi
Endianismi viittaa tavujen tallennusjärjestykseen monitavuisena määränä tietyssä prosessorissa. Esimerkiksi allekirjoittamaton lyhyt 256 (desimaali) vaatii kaksi tavua tallennustilaa: 0x01 ja 0x00. Nämä kaksi tavua voidaan tallentaa jommassakummassa järjestyksessä: 0x01, 0x00 tai 0x00, 0x01. Endianismi määrittää järjestyksen, johon nämä kaksi tavua tallennetaan. Käytännöllisistä syistä endianismilla on merkitystä yleensä vain silloin, kun erilaisten endianismien suorittimien on jaettava tietoja.
Java
Java on useita eri tekniikoita, jotka on pakattu yhteen - Java-ohjelmointikieli, Java-virtuaalikone (JVM) ja kieleen liittyvät luokkakirjastot. Tässä artikkelissa käsitellään kaikkia näitä näkökohtia.
Java-virtuaalikone (JVM)

JVM on kuvitteellinen suoritin, jolle useimmat Java-kääntäjät lähettävät koodia. Tämän kuvitteellisen suorittimen tuki antaa Java-ohjelmien toimia ilman, että niitä käännetään uudelleen eri suorittimille. Mikään Java-ohjelmointikielessä ei vaadi Java-lähdekoodin kääntämistä JVM: n koodiksi alkuperäisen objektikoodin sijaan.

Itse asiassa Asymetrix ja Microsoft ovat ilmoittaneet Java-kääntäjistä, jotka lähettävät alkuperäisiä Microsoft Windows -sovelluksia. (Katso lisätietoja tämän artikkelin Resurssit-osiosta.)

J-koodi
J-koodi on lähtö, jonka useimmat Java-kääntäjät lähettävät luokkatiedostoihin. J-koodi voidaan ajatella Java-virtuaalikoneen objektikoodina.
Siirrettävyys
Siirrettävyys tarkoittaa kykyä suorittaa ohjelma eri koneilla. Tietyn ohjelman ajaminen eri koneilla voi vaatia erilaisia ​​töitä (esimerkiksi ei mitään työtä, uudelleenkääntämistä tai pieniä muutoksia lähdekoodiin). Kun ihmiset viittaavat Java-sovelluksiin ja -sovelluksiin kannettavina, ne tarkoittavat yleensä sovelluksia ja sovelmia, jotka suoritetaan erityyppisillä koneilla ilman muutoksia (kuten uudelleen kääntäminen tai lähdekoodin muokkaaminen).

Nyt kun olemme käsitelleet joitain olennaisia ​​termejä, selitämme kaikki kolme Java-siirrettävyyden tyyppiä.

Java kielenä: lähdekoodin siirrettävyys

Ohjelmointikielenä Java tarjoaa yksinkertaisen ja tutun siirrettävyyden muodon - lähdekoodin siirrettävyyden. Annettu Java-ohjelma pitäisi tuottaa samanlaisia ​​tuloksia riippumatta taustalla olevasta suorittimesta, käyttöjärjestelmästä tai Java-kääntäjästä. Tämä ajatus ei ole uusi; kielet, kuten C ja C ++, ovat tarjonneet mahdollisuuden tämän tason siirrettävyyteen monien vuosien ajan. C ja C ++ tarjoavat kuitenkin myös lukuisia mahdollisuuksia luoda kannettavia koodeja. Ellei C: llä ja C ++: lla kirjoitettuja ohjelmia ole suunniteltu kannettaviksi alusta alkaen, kyky siirtyä eri koneisiin on enemmän teoreettista kuin käytännöllistä. C ja C ++ jättävät määrittelemättömät yksityiskohdat, kuten atomitietotyyppien koon ja endianismin, liukulukuisen matematiikan käyttäytymisen, alustamattomien muuttujien arvon ja käyttäytymisen vapautettua muistia käytettäessä.

Lyhyesti sanottuna, vaikka C: n ja C ++: n syntaksit on määritelty hyvin, semantiikka ei ole. Tämän semanttisen löysyyden ansiosta yksi C- tai C ++ -lähdekoodilohko voi koota ohjelmiin, jotka antavat erilaisia ​​tuloksia suoritettaessa eri suorittimilla, käyttöjärjestelmillä, kääntäjillä ja jopa yhdellä kääntäjä / CPU / OS-yhdistelmällä kääntäjän eri asetuksista riippuen. (Katso sivupalkki Syntaksi vs. semantiikka keskustelua semantiikan ja syntaksin eroista.)

Java on erilainen. Java tarjoaa paljon tiukemman semantiikan ja jättää vähemmän toteuttajan tehtäväksi. Toisin kuin C ja C ++, Java on määritellyt koot ja endianismin atomityypeille sekä määritellyt liukulukukäyttäytymisen.

Lisäksi Java määrittelee enemmän käyttäytymistä kuin C ja C ++. Java-tilassa muisti vapautuu vasta, kun sitä ei enää voida käyttää, eikä kielellä ole alustamattomia muuttujia. Kaikki nämä ominaisuudet auttavat kaventamaan Java-ohjelman käyttäytymisen vaihtelua alustasta alustaan ​​ja toteutuksesta toteutukseen. Jopa ilman JVM: ää Java-kielellä kirjoitettujen ohjelmien voidaan odottaa siirtyvän (uudelleen kääntämisen jälkeen) eri suorittimiin ja käyttöjärjestelmiin paljon paremmin kuin vastaavat C- tai C ++ -ohjelmat.

Valitettavasti ominaisuuksilla, jotka tekevät Javasta niin kannettavan, on haittapuoli. Java olettaa 32-bittisen koneen, jossa on 8-bittiset tavut ja IEEE754-liukuluku. Koneet, jotka eivät sovi tähän malliin, mukaan lukien 8-bittiset mikro-ohjaimet ja Cray-supertietokoneet, eivät voi käyttää Java-ohjelmaa tehokkaasti. Tästä syystä meidän pitäisi odottaa C: n ja C ++: n käyttöä useammalla alustalla kuin Java-kieltä. Meidän pitäisi myös odottaa Java-ohjelmien siirtyvän helpommin kuin C tai C ++ niiden alustojen välillä, jotka tukevat molempia.

Java virtuaalikoneena: CPU-siirrettävyys

Suurin osa kääntäjistä tuottaa objektikoodin, joka toimii yhdessä CPU-perheessä (esimerkiksi Intel x86 -perhe). Jopa kääntäjät, jotka tuottavat kohdekoodia useille erilaisille CPU-perheille (esimerkiksi x86, MIPS ja SPARC), tuottavat kohdekoodia vain yhdelle CPU-tyypille kerrallaan; jos tarvitset kohdekoodia kolmelle eri suorittimen perheelle, sinun on käännettävä lähdekoodisi kolme kertaa.

Nykyiset Java-kääntäjät ovat erilaiset. Sen sijaan, että tuotettaisiin lähtöä jokaiselle eri suorittimen perheelle, jolla Java-ohjelma on tarkoitettu suoritettavaksi, nykyiset Java-kääntäjät tuottavat kohdekoodin (kutsutaan J-koodiksi) suorittimelle, jota ei vielä ole olemassa.

(Aurinko on ilmoitti suorittimesta, joka suorittaa J-koodin suoraan, mutta osoittaa, että ensimmäiset Java-sirujen näytteet näkyvät vasta tämän vuoden toisella puoliskolla; tällaisten pelimerkkien täysi tuotanto alkaa ensi vuonna. Sun Microelectronicsin picoJavaI-ydinteknologia tulee olemaan Sunin oman microJava-prosessorilinjan ydin, joka kohdistuu verkkotietokoneisiin. Lisenssinsaajat, kuten LG Semicon, Toshiba Corp. ja Rockwell Collins Inc., aikovat myös tuottaa Java-siruja picoJavaI-ytimen perusteella.)

Jokaisen todellisen suorittimen, jolla Java-ohjelmat on tarkoitettu suoritettavaksi, Java-tulkki tai virtuaalikone "suorittaa" J-koodin. Tämän olemattoman suorittimen avulla sama objektikoodi voidaan suorittaa millä tahansa suorittimella, jolle on olemassa Java-tulkki.

Lähdön tuottaminen kuvitteelliselle suorittimelle ei ole Java-käyttöjärjestelmässä uutta: UCSD (Kalifornian yliopisto, San Diego) Pascal-kääntäjät tuottivat P-koodia vuosia sitten; Limbo, Lucent Technologiesin kehitteillä oleva uusi ohjelmointikieli, tuottaa kohdekoodin kuvitteelliselle suorittimelle; ja Perl luo väliohjelman esityksen ja suorittaa tämän väliesityksen sen sijaan, että luotaisiin natiivi suoritettava koodi. Internet-tajuinen JVM erottuu muista virtuaalisista suorittimien toteutuksista tarkoituksella suunnitellusti mahdollistamaan todistettavasti turvallisen, viruksista vapaan koodin luominen. Ennen Internetiä ei tarvinnut virtuaalikoneita todistamaan ohjelmat turvallisiksi ja viruksettomiksi. Tämä turvaominaisuus yhdistettynä paljon parempaan ymmärrykseen siitä, kuinka ohjelmat voidaan suorittaa nopeasti kuvitteellisille suorittimille, on johtanut JVM: n nopeaan ja laajaan hyväksymiseen. Nykyään useimmilla tärkeimmillä käyttöjärjestelmillä, mukaan lukien OS / 2, MacOS, Windows 95 / NT ja Novell Netware, joko on tai oletetaan olevan sisäänrakennettu tuki J-koodiohjelmille.

JVM, joka on olennaisesti kuvitteellinen prosessori, on riippumaton lähdekoodikielestä. Java-kieli voi tuottaa J-koodin. Mutta niin voi Ada95. Itse asiassa J-koodin isännöimät tulkit on kirjoitettu useille kielille, mukaan lukien BASIC, Forth, Lisp ja Scheme, ja on melkein varmaa, että muiden kielten toteutukset lähettävät J-koodia tulevaisuudessa. Kun lähdekoodi on muunnettu J-koodiksi, Java-tulkki ei voi kertoa, mikä ohjelmointikieli loi suorittamansa J-koodin. Tulos: siirrettävyys eri suorittimien välillä.

Etu ohjelmien (millä tahansa kielellä) kääntämisestä J-koodiksi on, että sama koodi toimii eri suorittimien perheillä. Haittapuoli on, että J-koodi ei toimi yhtä nopeasti kuin alkuperäinen koodi. Useimmissa sovelluksissa tällä ei ole merkitystä, mutta korkeimmissa huippuluokan ohjelmissa - jotka tarvitsevat joka viimeisen prosentin prosessorista - J-koodin suorituskykykustannuksia ei voida hyväksyä.

Java virtuaalisena käyttöjärjestelmänä ja käyttöliittymä: käyttöjärjestelmän siirrettävyys

Suurin osa C- tai C ++ -järjestelmällä kirjoitetuista Microsoft Windows -ohjelmista ei siirry helposti Macintosh- tai Unix-ympäristöihin edes uudelleen kääntämisen jälkeen. Vaikka ohjelmoijat huolehtivat erityisen huolellisesti C: n tai C ++: n semanttisista heikkouksista, portti on vaikea. Tämä vaikeus ilmenee myös silloin, kun portti muuhun kuin Windows-käyttöjärjestelmään tapahtuu muuttamatta suorittimia. Miksi vaikeus?

Poistettuaan semanttiset ongelmat C: ssä ja C ++: ssa sekä CPU: n siirto-ongelmat, ohjelmoijien on silti käsiteltävä erilaisia ​​käyttöjärjestelmiä ja erilaisia ​​GUI-API-kutsuja.

Windows-ohjelmat soittavat käyttöjärjestelmälle hyvin erilaisia ​​puheluita kuin Macintosh- ja Unix-ohjelmat. Nämä puhelut ovat tärkeitä ei-triviaalien ohjelmien kirjoittamisessa, joten siirto on edelleen vaikeaa, kunnes tämä siirrettävyysongelma on ratkaistu.

Java ratkaisee tämän ongelman tarjoamalla joukon kirjastotoimintoja (sisältyvät Java-toimittamiin kirjastoihin, kuten awt, hyötyja lang), jotka keskustelevat kuvitteellisen käyttöjärjestelmän ja kuvitteellisen käyttöliittymän kanssa. Aivan kuten JVM esittelee virtuaalisen suorittimen, Java-kirjastot esittävät virtuaalisen käyttöjärjestelmän / käyttöliittymän. Jokainen Java-toteutus tarjoaa kirjastot, jotka toteuttavat tämän virtuaalisen käyttöjärjestelmän / GUI: n. Java-ohjelmat, jotka käyttävät näitä kirjastoja tarvittavien käyttöjärjestelmä- ja käyttöliittymätoimintojen tarjoamiseen melko helposti.

Siirrettävän kirjaston käyttö alkuperäisten OS / GUI-puheluiden sijaan ei ole uusi idea. Tuotteet, kuten Visix-ohjelmiston Galaxy ja Protools-ohjelmiston sinkki, tarjoavat tämän mahdollisuuden C: lle ja C ++: lle. Toinen lähestymistapa, jota Java ei noudata, on valita yksi käyttöjärjestelmä / käyttöliittymä masteriksi ja tarjota pääkäyttäjäkirjastot, jotka tukevat tätä pääkäyttöjärjestelmää / käyttöliittymää kaikilla koneilla, joille haluat siirtää. Master OS / GUI-lähestymistavan ongelmana on, että siirretyt sovellukset näyttävät usein vierailta muilta koneilta. Esimerkiksi Macintoshin käyttäjät valittivat viimeaikaisesta Microsoft Word for Macintosh -versiosta, koska se näytti ja käyttäytyi kuin Windows-ohjelma, ei kuin Macintosh-ohjelma. Valitettavasti myös Java: n lähestymistavalla on ongelmia.

Java on tarjonnut vähiten yhteisen nimittäjän toiminnallisuuden OS / GUI-kirjastoissa. Vain yhdellä käyttöjärjestelmällä / käyttöliittymässä käytettävissä olevat ominaisuudet, kuten välilehtien valintaikkunat, jätettiin pois. Tämän lähestymistavan etuna on, että yhteisen toiminnallisuuden kartoittaminen alkuperäiseen käyttöjärjestelmään / käyttöliittymään on melko helppoa ja voi huolella tarjota sovelluksia, jotka toimivat odotetusti useimmissa käyttöjärjestelmissä / käyttöliittymissä. Haittana on, että natiivimoodisovelluksille on tarjolla toimintoja, jotka eivät ole käytettävissä Java-sovelluksille. Joskus kehittäjät voivat kiertää tämän laajentamalla AWT: tä; muina aikoina he eivät. Niissä tapauksissa, joissa toivottuja toimintoja ei voida saavuttaa kiertotavoilla, kehittäjät päättävät todennäköisesti kirjoittaa ei-kannettavan koodin.

Kuka välittää siirrettävyydestä?

Kolme pääryhmää välittää siirrettävyydestä: kehittäjät, loppukäyttäjät ja MIS-osastot.

Kehittäjät: Mahdollisuudet ja uhat ovat suuria

Kehittäjät ovat kiinnostuneita luomaan kannettavia ohjelmistoja. Ylhäältäpäin kannettava ohjelmisto antaa heille mahdollisuuden tukea useampia alustoja, mikä johtaa potentiaalisten asiakkaiden määrän kasvuun. Kuitenkin sama siirrettävyys, jonka avulla kehittäjät voivat kohdistaa uusille markkinoille, antaa myös kilpailijoiden kohdistaa markkinoilleen.

Lyhyesti sanottuna Java-siirrettävyys työntää sovellusohjelmistomarkkinat pois eri käyttöjärjestelmiin ja käyttöliittymiin perustuvista erillisistä markkinoista ja kohti yhtä suurta markkinaa. Esimerkiksi nykyisillä ohjelmistomarkkinoilla Microsoft on voima, joka on otettava huomioon Windows- ja Macintosh-sovellusohjelmistomarkkinoilla, mutta sillä ei ole juurikaan läsnäoloa OS / 2- ja Unix-markkinoilla. Tämä osiointi antaa OS / 2- ja Unix-markkinoilla toimiville yrityksille mahdollisuuden jättää Microsoft huomiotta kilpailijana. Java helpottaa näiden yritysten kilpailua Windows-markkinoilla, mutta mahdollistaa myös Microsoftin helpomman pääsyn OS / 2- ja Unix-markkinoille.

Käyttäjät: Siirrettävyyden välilliset edunsaajat

Käyttäjät eivät välitä siirrettävyydestä sinänsä. Jos siirrettävyys tekee heidän elämästään helpompaa ja miellyttävämpää, he ovat kaikki sen puolesta; jos ei, ne eivät ole. Siirrettävyydellä on kuitenkin myönteisiä vaikutuksia käyttäjiin, mutta nämä ovat jonkin verran epäsuoria. Positiiviset vaikutukset:

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