Programski jezik Java

Java je uistinu vrlo dobar novi programski jezik i velika vijest među programerima. Informatički časopisi još uvijek ne prestaju pisati o i oko Jave te kako će upravo Java promijeniti dosadašnje poimanje kratice WWW (World Wide Web), korisnik/poslužitelj modela razvoja aplikacija te ekonomskog modela prezentacije i korištenja programa počevši od tabličnih kalkulatora pa sve do video-igrica. Činjenice da se danas već udomaćio pojam NC (Network Computer), te da SUN tvrtka već naveliko prodaje svoje Java radne stanice bazirane na Java procesoru samo govore u prilog prijašnjoj tvrdnji. Postoji već uvriježeno mišljenje da će Java naslijediti C++ kao jezik izbora glede programiranja generalno te da je Java u stvari ono što je trebao biti C++.

No, prije nego što krenete bacati vaše knjige o C++-u, možda je sada trenutak da udahnemo malo doze realnosti u cijelu priču oko Jave: što je Java i zašto ona nije sada sve ono što su obećali da će biti. Iako trenutno Java niti u kojem slučaju nije za podcjenjivanje (a bit će sve moćniji programski jezik u budućnosti), ona naravno nije rješenje svim svjetskim problemima današnjice. Java je samo još jedan programski jezik a ne nekakav čudotvoran mehanizam koji je u stanju donijeti mir svijetu.
 
 
 

Što je Java?

Činjenica koja nam otežava jednostavno definiranje ovog pojma je ta da je Java u biti puno različitih stvari. Osim toga, pravi potencijal Jave u mnogome ovisi o kojoj Javi u biti govorimo.

Za Javu danas možemo reći da je:

  1. specifikacija programskog jezika i standardni zbir klasa
  2. implementacija navedenog programskog jezika i njegovih pratećih datoteka (libraries) u okolici prevođenja i izvođenja (compile and run time enviroment) za izradu i izvršavanje aplikacija
  3. implementacija navedenog programskog jezika kao podskup ugrađenog koda u HTML stranicama (applet)
  4. implementacija navedenog programskog jezika kao dodatak animaciji i interakciji kod 3D objekata i scena (VRML 2.0)
Možemo tvrditi da svaku od danih podstavaka prezentira drugačija implementacija Jave. Svaka od njih ima svojih prednosti kao i ograničenja. Važno je u ovom trenu razumjeti iako Java programski jezik podržava neke vrste manifestacija, to ne znači da će pojedina manifestacija biti dopuštena ili čak moguća u svim implementacijama. Gledano s praktične strane, performansa i sigurnost nam ograničavaju što danas možemo napraviti unutar Java programskog okruženja.
 
 
 

Programiranje u Javi

Svakome tko je imao prilike usporediti C++ i Java izvorne kodove bit će odmah jasno da je Java bazirana na programskom jeziku C++. Tvorci Jave su željeli napraviti programski jezik koji bi bio jednostavniji za naučiti i koristiti nego C++. Iz tog razloga bili su prisiljeni odustati od dosta pristupa i idejnih rješenja koje programeri generalno smatraju zbunjujućima (znate li nekog tko koristi templateove u C++-u) te dodati nove mogućnosti kao što je primjerice garbage collection. Krajnji rezultat je novi programski jezik koji je uistinu lakši za savladati od C++-a. Ugrađenim mogućnostima poput garbage collection i eliminiranjem pointerske aritmetike uspjeli su odstraniti najčešći izvor grešaka koje bi se javljale prilikom programiranja u C ili C++ programskim jezicima. No, kako ćemo vidjeti u daljnjem tekstu, ova poboljšanja nisu prošla besplatno...

C++ je trebao biti poboljšani C. Njegove mogućnosti korištenja objektno orijentiranih tehnika otvarale su mogućnost razvoja puno većih i bolje organiziranih programa. Pri njegovoj izradi tvorci su se pridržavali sljedećeg:

Prilikom dizajniranja Jave tvorci nisu morali poštivati nikakva pravila niti unaprijed zadane norme, tako da se Java direktno ne nadograđuje na C++ niti bilo koji drugi programski jezik. Ona naravno sadrži neke njihove karakteristike, ali za očekivati je da novi programski jezici nalikuju na starije. Međutim čini se da tvorce Jave, nažalost, nije previše zanimala efikasnost njihovog programskog jezika. Naime, potpuno optimiziran Javin izvršni kôd će prilikom izvođenja biti uvijek osjetno sporiji od ekvivalentnog programa pisanog u C-u ili C++-u. Svojim sporijim izvođenjem Java plaća prednosti kao što su garbage collection, držanje pointera svih svojih objekata unutar heap memorijskog prostora i slično. Čak i kad bi odustali od glavne Javine osobine (a to je prenosivost izvršnog koda na velik broj arhitektura i operativnih sistema) i napisali Java programski jezik kao prevodilac pravog, native koda, Java bi i dalje bila kudikamo sporija od C/C++-a, ali za daleko manji omjer nego što je danas (negdje oko 1:20).

Možemo tvrditi da je Java više objektno orijentirana u odnosu na C++. U Javi je apsolutno sve klasa tako da svi podaci i procedure moraju biti dio neke klase, dok C++ podržava i proceduralni stil programiranja naslijeđen od C-a. Također Java smanjuje broj sintaksnih elemenata. Primjerice: 

klasa::procedura() postaje klasa.procedura()
objekt->procedura() postaje objekt.procedura()
Nadalje, programirajući u Javi ograničeni ste na korištenje već definiranih sučelja (interface). Java je u tom dijelu dosta slaba. Postojeće klase daju mogućnost Java programu izvršavanje samo sljedećih operacija: Navedene operacije vrlo su jednostavne za upotrebu (tako izvorni kod jednostavnije korisnik/poslužitelj komunikacije preko mreže možemo iskodirati u kojih 30-tak i manje linija), no ako su vaše potrebe veće od prije navedenih mogućnosti koje Java pruža, za to se morate sami pobrinuti. Primjerice, ako želite komunicirati sa vanjskim uređajem koristeći serijski port vašeg računala, morat ćete napisati posebno korisničko sučelje jer Java ne može koristiti već postojeće funkcije iz C/C++ library datoteka kao što su /lib/libproc.so.1.11 ili C:\windows\system\odbc32.dll. Istina je da sâm Java prevodilac isto kao i Java interpreter koristi neke library datoteke ali to je i razumljivo kad se podsjetimo da su to u biti native programi pisani u C-u. Korisničko sučelje pišemo na sličan način kao kad bi pisali normalne funkcije u C-u s tom razlikom da moramo na specifičan način pisati imena funkcija. Pored toga, ne možemo direktno pristupati varijablama koje koristimo u našim Java klasama, već na posredan način, preko specijalnih funkcija odnosno tipova varijabli, ovisno kakvo korisničko sučelje izrađujemo (običan native ili JNI). Naš se posao na kraju svodi na izradu u neku ruku filtra ili omotača (wrapper) koji će poslužiti kao posrednik između ugrađenih funkcija u C-u i njihove implementacije u Javi. Više o toj temi možete naći u Dodatku B teksta ovog diplomskog rada.
 
 
 

Java kao jezik za pisanje aplikacija

Mnogo ljudi misli (čak i autor ovog teksta do prije par mjeseci) da Javu koristimo samo kao dodatak vlastitim Web HTML stranicama tako da rade interesantne efekte sa slikama ili računaju koliko ste dana ili minuta stari. Međutim, Javu možemo koristiti isto kao C++ za pisanje stand-alone aplikacija. Postupak je sljedeći:
  1. prevodimo Java izvorni kod u tzv. bajtni kod
  2. izvršavamo bajtni kod interpretiranjem unutar JVM (Javine Virtualne Mašine)
Vidimo da je po strukturi implementacije programskog jezika Java negdje na prijelazu između dosad kristalno jasnih definicija pojmova kompajler i interpreter. Ona spada u obje klasifikacije dok uistinu nije potpuno niti jedna od njih.

Sâm bajtni kod je dosta manji od ekvivalentnog izvršnog koda, recimo, C-a, ali brzina njegovog interpretiranja daleko zaostaje naspram brzine izvršavanja ekvivalentnih programa pisanih u C-u. Alternativno rješenje je u korištenju tzv. just-in-time interpretiranja, gdje Javina Virtuelna Mašina prebacuje bajtni kod u native kod prije samog izvršavanja. To za manje aplikacije pruža razumnu performansu uz zadržanu prenosivost izvršnog koda.

Međutim, čak i toliko naglašavana prenosivost možda ne počiva na čvrstim temeljima. Iole veće aplikacije će vjerojatno uslijed ograničenja nametnutih standardnim Java okruženjem biti prisiljene koristiti vlastita korisnička sučelja u vidu native library datoteka (JNI) čijim se funkcijama proširuju mogućnosti Jave. U tom slučaju mada je osnovna aplikacija prenosiva, morat će se prilagođavati od operativnog sistema do različitih arhitektura računala library datoteke pisane u C/C++-u bez kojih osnovna aplikacija neće moći raditi.
 
 
 

Java kao HTML proširenje (APPLET)

Vjerojatno ćete se složiti da se Javina vizualno i funkcionalno najinteresantnija primjena manifestira u Java Appletima, malim djelićima Jave koji se automatski dobavljaju sa mreže i izvršavaju na vašem Internet pretraživaču.

Applet ugrađujemo u HTML Web stranicu korištenjem oznake APPLET. Također moramo naznačiti Internet pretraživaču koliko će mjesta morati rezervirati za grafičku prezentaciju appleta. Proizvoljno još možemo ubaciti PARAM oznake ukoliko su appletu potrebni ulazni parametri. Na kraju taj dio izgleda nekako ovako: 

<APPLET CODEBASE="PGP/Client" CODE="MainApplet.class" WIDTH=463 HEIGHT=360>
<param name=hostname value="localhost">
<param name=port value="4444">
<param name=KeyID value="0x9F9B08EB36329519">
<param name=UserID value="Zoran Rajic <zox@imagine.cc.fer.hr>">
<param name=debug value="true">
<H1 align=center>Your browser does not support <b>APPLET</b> tag</H1>
</APPLET>
Primijetite da se na pretraživačima koji su u stanju prikazivati applete sve unutar APPLET oznake zamjenjuje grafičkim prikazom appleta, dok na tekstualnim pretraživačima koji ne mogu pokazivati applete kao što je popularni lynx grafički prikaz appleta obično zamjenjuje alternativnim HTML oznakama.

Applet je odgovoran za sve manifestacije unutar njemu dodijeljenog prostora. On ne može mijenjati ostali sadržaj HTML dokumenta, ali zato može komunicirati sa drugim appletom pod uvjetom da se taj nalazi na istoj HTML stranici. Također je u stanju komunicirati sa našim pretraživačem i naložiti mu da dohvati neku novu HTML stranicu. Applet u pravilu svoje vizualno djelovanje ograničava na njemu pridijeljen prostor.

U neku ruku, applet je kao slika. Isto kao i sliku moraju mu se zadati dimenzije opisujući pretraživaču koliki pravokutan prostor treba rezervirati za applet. U jednoj stvari su slike čak i u prednosti nad appletima. One nasljeđuju informaciju o boji pozadine pretraživača tako da se primjerice prozirni dijelovi GIF slika prikazuju korektno. Applet na žalost ne nasljeđuje tu informaciju tako da je upravo njegov zadatak koju će boju pozadine postaviti ispod slika te koji će font (oblik slova) pridijeliti tekstovima i na koliko primjetan način se uklopiti u okolinu HTML dokumenta.

Kad zatražimo putem našeg pretraživača prikaz HTML stranice koji u sebi sadrži applet, po jednakim principima kao i slike, bajtni kod appleta se dohvaća zajedno sa samim dokumentom. Ukoliko applet nije uobičajena objektna klasa bazirana na java.applet.Applet klasi nego se referencira na neke druge klase, svaka od referenciranih klasa se opet zasebno dohvaća. Izuzetak čine standardne klase koje su obično dio programskog paketa pretraživača tako da se dohvaćaju lokalno. Nakon toga, kada smo dobavili sve dijelove applet klase koji sada egzistiraju u istom adresnom prostoru, bajtni kod appleta se provjerava zadovoljava li sigurnosne norme. Tek nakon te provjere applet se počinje izvršavati. Gledano sa programerske strane, aplikacije i appleti pisani u Javi su vrlo slični. Međutim, sigurnosni zahtjevi sprečavaju applete u mnogo čemu što su aplikacije bez problema u stanju napraviti.

Sigurnost je vrlo važna stavka Javinog programskog okruženja. Lagano je izvedivo da korisnik zajedno sa HTML stranicom dohvati i applet a da i ne shvati kakav je "poklon" usput dobio, niti primijeti da se applet počeo izvršavati. Kad bi appleti bili u stanju nekontrolirano pisati po čvrstom disku, kad bi mogli uništiti svaku datoteku kojoj mogu pristupiti, pokretati raznorazne naredbe kao C:\DOS>format, samoinicijativno dohvaćati HTML-stranice, koristiti Web-servise umjesto vas (mailto:franjo@vlada.hr ?!) ili slati vaše privatne informacije natrag na Web poslužioc, korištenje appleta bi donijelo više štete nego koristi. Iz tog razloga što appleti mogu, a što ne mogu raditi striktno je unaprijed određeno. Kako trenutno stvari stoje, po standardima koje je definirao Netscape, appleti...

Napomena:
Naravno da je ovo samo definicija standarda ponašanja, međutim praksa bilježi nekoliko sigurnosnih rupa koje su promptno "zakrpane", tako da možemo zaključiti da po uvijek iznova potvrđenoj definiciji koja glasi "nema sigurnog računala na Internetu, kao ni programa koji se je nemoguće razbiti" možemo pretpostaviti da nismo čuli zadnje oko propusta u sigurnosnom sistemu appleta.

Razumljivo je da striktna ograničenja iz sigurnosnih razloga doprinose drastičnom smanjenju iskoristivosti punog potencijala appleta. Primjerice, možemo dohvatiti applet program koji predstavlja tablični kalkulator (tvrtka AppliX), ali sve naše kalkulacije ne možemo pohraniti na tvrdom disku našeg računala, već eventualno na računalu sa kojeg smo applet dohvatili. Ne bi bili u stanju koristiti ogromne rječnike koji su nam na raspolaganju na Internetu za pravopisnu i gramatičku analizu naših tekstova jer ne možemo natjerati applet da dohvati datoteku sa našeg računala i istu poslije obrade pohrani natrag.

Što nam ostaje? Jesu li uopće appleti korisni? Pored zanimljivih animacija i grafičkih efekata tu je uvijek i daleko veća interaktivnost koju možemo ostvariti upotrebom appleta.

Izmislimo jedan konkretan primjer: recimo da Nacionalno Sveučilišna Knjižnica želi prenosivo i jednostavno riješiti narudžbu i predbilježbu na pojedine knjige. Iskoristimo dosad standardno rješenje preko FORM oznake unutar HTML dokumenta te korištenje tzv. formi koje bi studenti popunjavali i slali putem pretražioca natrag. Ukoliko imamo velik broj interesenata za taj mrežni servis, lagano bi dolazilo do zagušenja prometa poruka. Zadatak poslužioca je da osigura dohvaćanje HTML dokumenta korisniku. Unutar dokumenta korisnik popuni svoj zahtijev uz vlastiti identifikacijski broj. Tada putem submit metode popunjeni podaci sa forme putuju nazad do poslužitelja gdje se kontroliraju, te provjerava ispravnost unesenih podataka. Na kraju ako podaci nisu ispravo unijeti, poslužitelj ponovo mora kontaktirati korisnika i zahtijevati novi unos podataka u formu. Prezentirano rješenje nije previše efikasno jer s jedne strane zagušuje informacijski promet mrežom, dok s druge strane neravnomjerno raspoređuje resurse: dok studentski moćni Pentiumi vrše funkciju neinteligentnog grafičkog terminala, poslužioc mora obrađivati i kontrolirati hrpu zahtijeva za obradom.

Sad pretpostavimo da koristimo applet za unos podataka. Applet se izvršava na korisničkoj strani, što znači da niti najmanje ne smeta radu poslužioca. On može biti dovoljno "inteligentan" da sam prekontrolira valjanost unesenih podataka. Ukoliko se radi o većoj količini informacija, možemo čak dodati mogućnost kompresije podataka prije slanja. Na kraju, kad podatci stignu natrag do poslužioca možemo ih tako gotove, bez naknadnog kontroliranja pohraniti u zbirnu datoteku.

Valja napomenuti da nismo samo ograničeni na Javu. Ovaj problem bi se jednako efikasno mogao riješiti i korištenjem Netscapeovog JavaScript jezika koji je također podržan od strane popularnih Internet pretraživača. Međutim, u korist Jave mogli bi navesti činjenicu da je cijelo korisničko sučelje prezentirano unutar jednog jedinog entiteta, dakle jednom datotekom klase. Ostale prednosti Jave pred JavaScriptom postaju sve izraženije kako problem koji trebamo programski riješiti postaje kompleksniji.

Nadalje, HTML ima još manje sposobnosti prikazivanja promjenljivih slika (ne nužno animacija) nego što ima mogućnosti interakcije. Možemo, primjerice, izvesti da poslužioc svako malo mijenja sadržaj HTML dokumenta (refresh), u našem konkretnom slučaju slike, te prisiliti pretraživač da svako malo dohvaća novu sliku. Možete li pretpostaviti kolika je tek ovdje iskoristivost i opterećenje mrežnih resursa? Javinim appletom možemo postići glatku animaciju bez konstantnog dohvaćanja sadržaja sa poslužioca. Možda se neki neće složiti ovdje sa autorom ovog teksta, napominjući primjere još brže i glatkije animacije putem animiranih slika u specijalnom GIF formatu. Tu bi bili u pravu, jer ne postoji jednostavan način poboljšati glatkoću animacije u Javi jer starije verzije Jave imaju velikih problema pri sinkroniziranju. No, cijela ova usporedba je kao da uspoređujete igrani film i video igricu. Možete li pretpostaviti kolika bi razlika bila da snimite na informatički materijal (primjerice CD) igricu sa svojih pola sata animacije i animirani film također od pola sata. Da ne pričamo o interaktivnosti jednog naspram drugog.

Primijetite da jedino putem just-in-time načina izvođenja bajtnog koda možemo ubrzati applete. Primjena native izvršavanja ovdje ne dolazi u obzir. Čak i da teoretski izvedemo da poslužioc na neki način prepozna arhitekturu i operativni sistem koji korisnik upotrebljava, čak i ako u svojoj bazi podataka nađe i dohvati ispravnu verziju native programa te ga proslijedi korisniku, na korisnikovoj strani ne bi bilo moguće prekontrolirati osnovne norme sigurnosti analizom dobivenog koda, barem ne u nekom prihvatljivom vremenu.
 

 

Java i VRML

Novi i sve popularniji VRML (Virtual Reality Modeling Language -- grubo prevedeno: jezik programiranja i modeliranja virtualne stvarnosti) u svojim specifikacijama koristi Javu za dodavanje dimenzija animacije i interaktivnosti u svoje već postojeće 3 dimenzije modela i scena. Interakcija između Jave i VRML-a je značajno drugačija od puno poznatije, Jave i HTML-a. U slučaju VRML-a njegova interakcija sa Javom je daleko tješnja. Ovdje se mali dijelovi Java koda koriste za manipuliranje dijela 3D scene kao reakciju na promijene u (realnom?) vremenu ili vanjske pobuđaje.
 

 

Popularnost Jave

Postoji puno drugačijih programskih jezika koji se koriste ili se tek razmatraju moguće upotrebe glede Internet pretražioca. Ono što daje velik korak prednosti Javi pred ostalim programskim jezicima je njena podržanost (postoji na svim operativnim sistemima gdje postoji Netscape program, što znači mnogo operativnih sistema), besplatnost za nekomercijalnu upotrebu (barem do ovog časa) te prenosivost izvršnog tj. bajtnog koda uz garantirano izvršavanje bez obzira na arhitekturu ili operativni sistem računala (naravno, ako se radi o istoj verziji Java prevodioca i interpretera te uz uvjet da ne koristimo native metode proširivanja standardnog zbira Javinih instrukcija).

Po primjerima iz prakse, dosad je programiranje HTML-baziranih servisa činila papazjanija sačinjena od FORM oznake i forme unutar HTML stranice, perl i sh skripti ili C-programa za obradu podataka pribavljenih sa forme, te driver programa za pristup bazi podataka pisanog najčešće u C-u. Ako ste se željeli baviti programiranjem mrežnih HTML-baziranih servisa, obično je preporuka glasila da pored osnovnog znanja barem HTML 2.0 specifikacija naučite programirati u C-u i perl-u a koristiti i pisati sh skripte ćete ionako "usput" naučiti.

Sada je nužno i dovoljno znati da vam od HTML specifikacija treba 

<html><body><applet code="MyApplet.class" width=XXX height=YYYY></applet></body></html>
.. te znanje programiranja u Javi.

Sama Java je daleko od savršenog programskog jezika. Zabilježene su duge rasprave o tome kako bi bilo izvedivo napisati drugačiji compiler ili točnije cross-compiler program koji bi prevodio neki drugi, jednostavniji i bolji izvorni kod u postojeći Javin bajtni kod. Na taj način se ne bi izgubilo apsolutno ništa od trenutnih dobrih karakteristika kao što je prenosivost bajtnog koda i njegovo izvršavanje na svim podržanim platformama računala.

Osim toga, veliki dijelovi Jave kao programskog jezika su već odbačeni kao neadekvatni, gledajući unatrag prema nižim verzijama. Izvrstan primjer toga je AWT (Abstract Window Toolkit -- zbir grafičkih alata) za koji sami tvorci Jave tvrde da je hack (na brzinu napravljen samo da proradi) i za to optužuju Netscape koji ih je manirama robovlasnika tjerao na pridržavanje rokova te da što ranije završe sa projektom.



[<<Natrag] [Doma] [Sadržaj] [Šalji pismo] [Naprijed>>]