Noviteti i brzina

Aleksandar Petrović Milan Maksimović

Java je dovoljno zreo proizvod da polako prestajemo da opisujemo šta ona može, i koncentrišemo se na pitanje kako to radi. Uporedili smo performanse različitih Java okruženja, a bacićemo pogled i na novitete iz Sun-ove i IBM-ove kuhinje.

Današnje vreme svakako pripada integrisanim okruženjima: trenutno samo Netscape nudi izvršno okruženje u okviru browser -a dok ostali, pored implementacije Java VM, nude i svoja razvojna okruženja. Kao i uvek, sve ima svoju cenu, pa je rudimentarna funkcionalnost besplatna, a za komfor mora da se plati. Na stranicama našeg časopisa čitali ste pre svega prikaze komercijalnih Java okruženja, a videli smo da se do zanimljivih alata može doći i pomoću modema, Internet pristupa i strpljenja. Pre nego što prikažemo rezultate uporednog testa performansi Java okruženja, pogledajmo kakve novitete donose Sun JDK 1.1 , IBM ADK beta1 i Microsoft Java SDK.

Sun-ov JDK

Tek što su se ustalile stabilne verzije Java virtuelnih mašina za različite operativne sisteme i odgovarajuća razvojna okruženja, Sun je izbacio novu specifikaciju sa oznakom 1.1. Iako skok u verziji deluje skromno (prethodna je bila 1.0.2), nema ni jedne komponente Jave koja nije doživela drastično unapređenje. Ovo ćemo ilustrovati podatkom da je broj paketa, klasa i interfejsa više nego udvostručen u odnosu na prethodnu specifikaciju. Pored niza novih API-ja, i sam jezik je proširen uvođenjem onoga što je u C++-u poznato pod imenom ugnježdene klase ( nested class ) - sada se i u Javi može definisati klasa unutar neke druge klase.
Veliki nedostatak Jave je sporost u prenošenju .class fajlova i potrebnih resursa (slike i zvuci), pošto su podaci nekomprimovani, a za svaki se uspostavlja nova HTTP konekcija, što se posebno manifestovalo kod netrivijalnih apleta sa puno .class fajlova. Microsoft je problem rešio pakovanjem svih potrebnih fajlova u jedan CAB (MS format za distribuciju) koji je po potrebi potpisan. JDK 1.1 donosi slično rešenje, sistemski podržano odogovarajućim Java paketom ( java.util.zip ). U pitanju je novodefinisani JAR ( Java Archive ) format zasnovan na PKWARE-ovom ZIP formatu. Za generisanje ovih arhiva se koristi "juniksolika" alatka jar.exe , a kreirane arhive mogu po potrebi biti i potpisane ključem generisanim na osnovu RSA algoritma; koristi se priloženi program javakey.exe . Proba je pokazala da stepen kompresije .jar arhiva ne odstupa mnogo od onih dobijenih programom PKZip 2.04g - .jar arhivu uglavnom možete da raspakujete običnim PKUNZIP-om, koji će se doduše pobuniti oko zaglavlja, ali će sve uraditi kako treba. Problemi se javljaju jedino kod fajlova sa egzotičnim imenima poput neko.ludo.ime.fajla.
Međunarodna priroda Interneta donosi niz poteškoća vezanih za formate teksta, brojeva, datuma, valuta i druge tipove podataka koji figurišu u programima. Novi API omogućava lakše prevazilaženje ovih problema, kroz tri paketa: novi java.text i dopunjeni java.util i java.io . Za razliku od dosadašnjeg pristupa. gde je lokalizacija bila rešavana na globalnom nivou "podmetanjem" fiksnih resursa, u ovoj verziji Jave je obezbeđen niz klasa dizajniranih tako da fleksibino reše pokrivanje raznih aspektata regionalnih specifičnosti.
Uvedene su, recimo, klase Calendar i TimeZone , čija se svrha vidi iz imena; obzirom da je Calendar apstraktna bazna klasa koja konvertuje različite vrednosti protekle od trenutka 00:00:00 1. Januara 1970, iz nje je izvedena klasa koja definiše konkretan lunarni kalendar, npr. Gregorijanski. U zavisnosti od potreba i važećeg kalendara, mogu da se definišu i druge klase, recimo Julijanska za baratanje sa datumima Pravoslavnih praznika. Stara klasa Date ograničena isključivo na datumsku aritmetiku, dok se ispis datuma i vremena sada obavlja putem novih klasa u kombinaciji sa klasom DateFormat.

Da li je sigurno?

Čuveno pitanje iz čuvenog filma Maratonac... Na sigurnosti se uvek insistiralo, što je razumljivo kada na svom računaru treba da "ugostite" apl(et)ikacije nepoznatih autora. Sigurnost Jave se do sada u najvećoj meri oslanjala na doslednu i kvalitetnu implementaciju virtuelne mašine - loše napisana VM mogla je da naruši sigurnosne granice postavljene pred aplete. Ilustraciju raznih (više ili manje uspešnih) načina za probijanje sigurnosnih mehanizama možete pogledati na www.math.gatech.edu/~mladue/HostileApplets.html .
JDK 1.1 specifikacija proširuje kontrolu bezbednosti uvodeći dodatne klase koje tretiraju digitalne potpise, sigurnosne ključeve, liste kontrole pristupa, a u sprezi sa java.util.zip , i rad sa potpisanim .jar paketima. Digitalni potpisi nisu nova stvar, sa tim je upoznat svako ko je ikad koristio PGP, a od početka širenja Jave se špekulisalo o njihovom uvođenju na sistemskom nivou. Za potpisivanje koda treba generisati javni i privatni ključ, a potom potvrdu o autentičnosti tog javnog ključa, da bi strane koje ga koriste bile sigurne u njegovu validnost.
Zbog pretenzija Jave na prilagođenost ditribuiranim okruženjima koja po svojoj prirodi opslužuju mnoštvo korisnika, drugi bitan novitet je uvođenje ACL ( Access Control List ) objekata. Lista kontrole pristupa je struktura podataka koja kontroliše nivoe pristupa određenim resursima na nivou pojedinaca i grupa. Ključni objekti za ovu svrhu su Group, Principal, Acl i AclEntry , čijom se kombinacijom određuju prava pristupa nezavisno od resursa, načina provere, ili kriptovanja podataka koji putuju mrežom.

Daljinska kontrola

Paket java.io je pretrpeo izmene kojima je još više približen modelu C++ tokova ( streams ), tako da je, osim binarnog, uveden ulaz i izlaz prilagođen radu sa karakterima širine 16 bita, što je osnova za UNICODE 2.0 standard. Klase Reader, Writer i iz njih izvedene klase su zadužene za baferisani ulaz/izlaz karaktera, nizova karaktera i Java stringova.
Posebno zanimljiva novina je RMI, Remote Method Invocation . Radi se o ekvivalentu RPC ( Remote Procedure Call ) mehanizama koji je na nizu operativnih sistema definisao OSF ( Open Software Foundation ). Za razliku od znanja i alata koje morate da savladate (MIDL jezik i kompajler, posebne biblioteke) da biste koristili RPC, Java RMI se potpuno prirodno uklapa u objektno Java okruženje. Stvari su rešene zaista elegantno i jednostavno (koliko je to moguće), tako da su dobar način za upoznavanje principa dizajniranja distribuiranih aplikacija. Za razliku od RPC mehanizama koji su morali da budu koncipirani što opštije, radi uklapanja u razne operativne sisteme i jezike, RMI na najprirodniji mogući način omogućava pozivanje metoda udaljenih objekata.
Za RMI treba napraviti tri stvari: program-server, program-klijent i interfejs koji ih povezuje. Pri pisanju klijent-programa, dovoljno je na početku preuzeti referencu na interfejs i dalje se sa njim radi kao sa objektom na lokalnoj virtuelnoj mašini. Praktična prednost svega ovoga se manifestuje u smanjenom protoku informacija kroz mrežu: umesto prebacivanja svih klasa do klijenta, otvara se perspektiva za pravu klijent-server arhitekturu, tako da će se prebacivati samo neophodan front end aplet koji poziva funkcije objekata na udaljenom serveru i prikazuje rezultate.
U kombinaciji sa RMI, uvedeni su i mehanizmi za serijalizaciju i perzistentnost lake kategorije. Perzistentan objekat je onaj koji u svakom trenutku može da snimi svoje stanje na neki medijum i restaurira ga po potrebi. Ovakvi objekti treba da podržavaju Serializable i Externalizable interfejse, a odgovarajuću funkcionalnost treba dopisati u klasu. Reflection mehanizmi su dodati kao proširenje osnovnih RTTI ( Run-Time Type Information ) mogućnosti uvođenjem nekoliko klasa ( Class, Constructor, Modifier ...), čime se omogućava detaljnije ispitivanje tipova pri izvršavanju.

Novi AWT

Najradikalnije izmene doživeo je Abstract Windowing Toolkit , valjda zbog toga što je na njega postavljano najviše primedbi. Unapređeno je prenošenje podataka između vizuelnih kontrola ( Clipboard ), poboljšano je uklapanje Java programa uvođenjem objekta za usklađivanje sa sistemskom paletom, a sada može da se radi i sa delovima slike, u cilju povećanja brzine. Animacija je poboljšana unapređenim tehnikama duplog baferisanja nalik onima iz WinG API-ja, a omogućeno je i skidanje dela slike u celobrojnu matricu.
Oko štampanja su se svi pravili nevešti: to u Javi naprosto nije postojalo. Konačno se i tu napredovalo, na način poznat Windows programerima: Graphics objekat preko koga se iscrtava proširen je objektom za štampač i klasom PrintJob , koja priprema i obavlja štampanje. U Windows i Mac okruženju odgovarajući grafički izlaz će biti upućen na device context štampača, dok će na Solarisu biti generisan odgovarajući PostScript izlaz.
Zanimljiv dodatak je podrška desnom tasteru miša, čime je prekršena izjava iz dokumentacije JDK verzije 1.0.2 da bi to bilo previše zavisno od tipa hardvera. Desni taster će se koristiti u sprezi sa drugim novitetom - popup menijima, koji se dodaju određenim AWT komponentama i čiji je rad dobro uklopljen u okolinu na nivou API-ja. Vizuelne komponente su približene onome na šta smo navikli i uvođenjem mogućnosti navigacije Tab tasterom i prečicama za komande menija a skrolovanje, koje do sada zahtevalo dosta programerskog napora, je automatizovano dodavanjem novog "pametnog" ScrollPane kontejnera.
Najveće unapređenje AWT-a je koncepcijske prirode. Bez obzira što su vizuelne komponente i u ranijem AWT-u realizovane preko samostalnih objekata, rukovanje događajima je bilo potpuno prepušteno glomaznoj switch-case konstrukciji nalik onoj iz Windows C programa, ili podeli dužnosti po nasleđenim AWT objektima. Oba pristupa su uvodila dosta problema pri izradi netrivijalnih programa, pa je uveden delegation model. Promene su brojne i korenite, a njihov opis prevazilazi okvire ovog letimičnog prikaza, tako da ćemo detalje ostaviti za neki drugi put. Reći ćemo samo da je sada daleko lakše povezati Java AWT sors sa generatorima aplikacija i vizuelnim editorima GUI elemenata. Biće zanimljivo uporediti ovaj pristup sa Java AFC bibliotekom koju najavljuje Microsoft , a koja takođe pretenduje da reši manjkavosti postojećeg AWT-a.

IBM za 16 bita

Mimo svih očekivanja, pojavilo se Java razvojno okruženje za 16-bitni Windows . Pored Microsoft -a, samo IBM ima ljudske resurse za ovaj nezahvalni posao, a rezultat je zbilja vredan hvale. Pored činjenice da je Java sama po sebi 32-bitna, treba imati u vidu poseban problem realizovanja multithreading -a u ne- preemptive okruženju.
Za rad IBM ADK-a je potreban Windows 3.1 proširen Win32s ver. 1.3 dodatkom i 16-bitna WinG biblioteka. Instalacija je poverena poznatom InstallShield programu, pri čemu sam ADK zauzima 7 MB na disku. Pored toga, paket zahteva minimum 8 MB RAM memorije da bi uopšte radio, a IBM preporučuje 10 MB za rad bez mreže i 12 MB RAM-a za rad sa TCP/IP mrežom. Po tvrdnjama ljudi iz IBM-a, ADK je napravljen za korisnike 16-bitnog Windows -a, mada preporučena konfiguracija bez problema može da podnese Windows 95 i originalni Sun -ov ili MS Java SDK.
ADK obuhvata kompletnu implementaciju Sun JDK 1.0.2 , uz četiri dodatna alata koja služe za prevazilaženje razlika između Win16 i Win32 platformi. Ti alati su: ADKEdit, ADKFile, ADKConsole i konzolni Win32 program Hslmappr . Verovatno se pitate kako su pomirena duga imena fajlova, neophodna za rad Java progrma, sa DOS 8+3 konvencijom. Rešenje je u fajlu javamap.hsl , koji postoji u svakom direktorijumu i u kome je definisana veza između dugog i kratkog imena fajla. Svi ADK alati "znaju" da koriste ovaj mehanizam: pri učitavanju fajla sa dugim imenom u tabeli, traži se odgovarajući 8+3 fajl, a pri snimanju se generiše dugo ime i u tabeli vezuje za odgovarajuće kratko. Za Java pakete koji su pisani nezavisno od ADK-a i ne slede njegovu LFN konvenciju, treba upotrebiti alat HSLMappr , kojim se generiše potrebna tabela. Ovaj alat radi samo u pravim 32-bitnim okruženjima kod kojih su duga imena podržana, ali IBM-ov način generisanja kratkih imena ne odgovara Microsoft -ovom, pa bi originalna duga imena fajlova bila izgubljena.
Ukratko, za isprobavanje postojećih (ne-ADK) Java apleta i aplikacija, potreban je Windows 95 i Windows 3.1x . U prvom ćete pomoću 32-bitnog arhivera raspakovati arhivu i dobiti originalna duga imena, zatim pokrenuti HSLMMappr koji generiše ADK-ovu tablicu konverzije i tek onda ući u Windows 3.1 i pokrenuti ADK. Ne možemo da se ne zapitamo koliko sve ovo ima smisla.

Priloženi alati

Posle ekvilibristike sa mapiranjima imena fajlova na red dolaze ostale alatke. ADKEdit je jednostavan tekst editor, iz koga možete da pokrenete Java kompajler i interpreter; loša mu je osobina što je bez autoindent -a mučno pisati Java programe. Omogućeno je samo elementarno pokretanje alata, što znači da, ako zatražite izvršavanje class fajla čiji je sors u međuvremenu promenjen, neće biti izvršen automatski make .
ADKConsole zamenjuje Java konzolu, pa iz ovog alata može da se pokrene interpreter, kompajler i appletviewer . ADKFile je najupotrebljiviji alat u celom paketu - to je kopija Windows File Manager -a, dopunjena podrškom za duga imena fajlova, ali samo na ADK način. ADKFile omogućava automatsko pokretanje ostalih alata u zavisnosti od ekstenzije izabranog fajla. Čini nam se da je najjednostavnije koristiti ADKFile kao komandni centar, iz koga se pokreću ostali alati.
Pravo razočarenje su, nažalost, performanse. Pošto se ovde radi o sporom Sun JDK 1.0.2 , prekompajliranom i prilagođenom za Win32s platformu, nema reči o JIT kompajleru niti ikakvim dodatnim ubrzanjima, pa je ADK višestruko sporiji od originala za pravu Win32 platformu. Koliko je sporiji nismo uspeli da utvrdimo, pošto ni posle sat vremena nije uspeo da završi prvi od niza testova - bubblesort 10000 brojeva. Izvršavanje testa je prekinuto, a da nije, verovatno bismo još uvek pisali ovaj takst. ADK boluje i od drugih dečijih bolesti: ne može da se pokrene više od jedne Java VM u istom trenutku, ako se izvršavanje Java programa nasilno prekine, Java VM ponekad ostaje aktivna, sprečavajući pokretanje drugih Java programa, za šta je jedini lek restartovanje Windows -a. Ruku na srce, u pitanju je beta, a ovi nedostaci (ili bar većina) će verovatno biti ispravljeni u finalnoj verziji.

Brzinski test

Pokušali smo da na jednom mestu objedinimo sve dostupne implementacije Java virtualne mašine; u igri su bili Netscape Navigator 2.0 i 3.0, Netscape Communicator 4.0 beta, Microsoft Internet Explrorer 3.0, MS Java SDK, Sun JDK 1.0.2 i 1.1, kao i IBM ADK 1.0 beta. Test programe smo skinuli sa Symantec -ovog sajta, gde su stavljeni kao reklama za njihov novi JIT kompajler, čiji komercijalan proizvod za sada nije u širokoj upotrebi.
Baterija testova se sastoji od devet Java aplikacija koje implementiraju sledeće algoritme: bubblesort , dvosmerni bubblesort, quicksort, sieve (izdvajanje prostih brojeva), hanojske kule, dhrystone (standardni sintetički test za celobrojne operacije), računanje članova Fibonačijevog niza, array (popunjavanje niza od milion celobrojnih članova slučajnim brojevima) i umetanje slučajnih brojeva u stablo.
Bilo je problema sa testovima: IBM-ov 16-bitni ADK je otpao na samom početku trke, pošto čak ni prvi test ( bubblesort 10000 slučajnih brojeva) nije uspeo da završi ni za jedan sat. Drugi problem je predstavljao Netscape 2.01 , koji je zbog svog poznatog baga odbio da startuje aplete sa lokalnog diska, zbog čega je, silom prilika, diskvalifikovan.
Programe smo prilagodili tako da se izvršavaju i kao apleti i kao aplikacije, da bismo utvrdili postojanje eventualnih razlika između ova dva režima izvršavanja. Ispostavilo se da su razlike akademske, tako u testu nismo dali odvojena vremena izvršavanja - funkcionalno ekvivalentni apleti i aplikacije se izvršavaju istom brzinom. Treba odmah reći da ovakvi testovi izrazito pogoduju JIT kompajlerima, pošto se uglavnom zasnivaju na velikim petljama. Takođe, ovo su standardni testovi sa kojima se ispituju performanse raznih programskih jezika i platformi, pa verovatno u određenoj meri zanemaruju specifičnosti Jave (npr. garbage collection ) i ne opisuju ulazno-izlazne operacije - akcenat je na memorijskim i aritmetičkim operacijama. Poslednji test ( Tree ) je posebno indikativan za performanse alokatora, pri čemu se Netscape i u ovom slučaju pokazao problematičnim, tako da smo broj prolaza morali da smanjimo za faktor 10. Rezultate testa vidite na dijagramu.

Komentar

Najbolje se pokazao Microsoft Internet Explorer sa svojom Java podrškom - ova Java VM je preko dva puta brža od sledećeg na tabeli, Netscape -a 3.0. Microsoft je nenadmašen u skoro svim testovima, a posebno razočarenje predstavlja Netscape 4.0 beta, koji po performansama zaostaje za svojim prethodnikom. Rezultati su približni samo u testovima sortiranja, dok je kod dhrystone testa novi Netscape drastično podbacio (66:27), a prava katastrofa je poslednji test. koji Netscape 3.0 završava za 33 sekunde, skoro tri puta brže nego Netscape 4.0 .
Na začelju su Sun -ovi JDK 1.0.2 i JDK 1.1, koji po prirodi stvari ne mogu biti konkurencija navedenim okruženjima, zbog odsustva JIT kompajlera. Ipak, oba okruženja imaju očigledno dobro urađene alokacione mehanizme, tako da su na poslednjem testu do nogu potukli Netscape -ov JIT kompajler, a i kod pretposlednjeg testa ( array ) rezultati JDK 1.1 su prilbližni rezultatima koje postiže Netscape . Primetno je da je Sun u međuvremenu poradio na performansama, jer je interpreter iz JDK 1.1 duplo (i više) brži od "starijeg brata". Ne treba biti suviše strog ni prema rezultatima koje postiže Netscape 4.0 beta, jer ipak se radi o preliminarnoj verziji, a postoje indicije da će Netscape licencirati Symantec -ovu JIT tehnologiju, za sada jedinu koja može da trči rame uz rame sa Microsoft -ovom. Čekamo Java čipove!