Java Status Report

Au trecut cinci ani de la lansarea tehnologiei Java,dar evoluia nc nu s-a ncheiat.

Poate c Java este numele cel mai vehiculat n tirile din lumea informaticii. Cum despre tehnologiile deja
consacrate presa nu mai vorbete, se poate deduce c Java este n plin evoluie. Pn unde a ajuns i n ce
direcie se ndreapt? Dou ntrebri la care ncearc s rspund acest articolul.

Eugen Rotariu
Istoria calculatoarelor este istoria unei discipline cu o evoluie spectaculoas, n care zilnic apar idei i produse noi,
se fac i se desfac aliane, se rstoarn clasamente. De aceea, e oarecum neateptat faptul c limbajele de programare
evolueaz cu vitez moderat. Ne-am atepta ca noi modaliti de exprimare a algoritmilor i interfeelor s apar n
fiecare zi i semantica acestora s se mbunteasc rapid. Dar nu e aa. Nu e aa pentru c limbajele de programare
au nevoie de timp pentru a fi descoperite i nsuite. Pentru c un limbaj de programare fr un mediu de dezvoltare
adecvat nu poate fi luat n considerare, iar mediile de dezvoltare nu sunt uor de finisat. Nu e aa pentru c un limbaj
fr interfeele de proiectare a aplicaiilor (API) aferente nu este foarte folositor iar dezvoltarea de API-uri este un
proces lent, care implic un numr mare de comisii i evaluatori. n fine, nu e aa pentru c a gsi idei care s
revoluioneze cu adevrat modul n care comunicm calculatoarelor ceea ce dorim de la ele nu e un lucru uor.
De aceea, observm cu mirare c, dei Java este un limbaj cu cinci ani vechime i suportul a zeci i sute de mii de
programatori, se vorbete despre Java n continuare ca despre cel mai nou i mai modern limbaj de programare, ca
despre un limbaj a crei evoluie i acceptare nu este complet definitivat, ca despre un limbaj al viitorului care va fi
grozav dac se va maturiza suficient. Cinci ani vechime la nivelul unui produs program poate fi foarte mult. La
nivelul unui limbaj de programare ns, cinci ani de zile pot fi echi-valeni cu ieirea din perioada de teribilism a
adolescenei i intrarea n cea de evoluie responsabil i matur.
i totui, despre Java se spune n general c a fost acceptat de ctre comunitatea programatorilor ntr-un timp record.
Poate i pentru c Java este susinut puternic de ctre o firma comercial ca Sun, care face tot posibilul pentru a
ncheia cele mai bune aliane necesare pentru impunerea limbajului i care aloc fonduri semnificative pentru
mbuntirea mediilor de dezvoltare i a API-urilor necesare unui limbaj matur. Desigur, aceast dependen de o
firm comercial aduce i dezavantaje majore, precum refuzul unor firme de a-l lua n considerare sau nemulumirea
altora cauzat de direcia pe care o ia limbajul. Sun a ncercat s rezolve aceste probleme prin promovarea unui
standard ANSI pentru Java, dar pentru c paii au fost destul de ovitori n aceast direcie, problema nu este nici
pe departe rezolvat nc.
Dar ce face din Java un limbaj atrgtor? Fr ndoial, n primul rnd faptul c este portabil. Codul Java se poate
muta de pe o platform pe alta n mod binar, atta timp ct pentru platformele respective exist un mediu de rulare a
aplicaiilor Java, pe care Sun l numete JVM (Java Virtual Machine). Mediul de rulare n sine a fost scris n C, ntrun mod ct mai portabil, dei sunt nc probleme atunci cnd se ncearc portarea bibliotecilor standard ale
limbajului, din care cele de interfa grafic utilizator i de acces hardware fac destule probleme.
n afar de portabilitate, Java este ndrgit i pentru c este un limbaj bine proiectat, orientat obiect, foarte robust
prin lipsa pointerilor i existena colectrii automate de reziduuri de memorie (GC). De altfel Java este un limbaj
care motenete semnificativ de la perechea C/C++, ncercnd s evite unele dintre problemele acestora, pstrnd
ns sintaxa suficient de familiar pentru a facilita conversia programatorilor de C/C++ ctre Java. API-urile Java
sunt i ele bine proiectate, diverse i independente de platform iar programele i obiectele scrise n Java pot
comunica elegant cu programele sau obiectele dezvoltate n alte limbaje de programare.
i, nu n ultimul rnd, Java este ndrgit de muli programatori din simplul motiv c este vzut ca un bastion de lupta
declarat mpotriva dominaiei Microsoft pe piaa de produse software. Microsoft nsui a ncercat s evite aceasta
problem prin dezvoltarea propriei sale versiuni de Java, dar faptul c Sun controleaz standardul limbajului a dus la
procese interminabile i la refuzul Microsoft, mai mult sau mai puin deschis, de a sprijini limbajul n continuare.
Evoluia limbajului
Java este un limbaj complet orientat obiect, cu tipuri de date sigure. Sintaxa lui este foarte asemntoare cu C/C++,
dar a preluat de la predecesorii si un minim de trsturi absolut necesare, renunnd la unele periculoase precum ar
fi pointerii, la altele puin utilizate precum ar fi motenirea multipla, sau nu foarte recomandabile precum rescrierea
operatorilor. n schimbul motenirii multiple, Java definete un mecanism extrem de flexibil i util care este
mecanismul de interfee. n ceea ce privete alocarea dinamic, veti bune i aici: Java are un mecanism de colectare
automat de reziduuri de memorie, scutind programatorul de necesitatea de a elibera explicit memoria alocat

dinamic. Unii ar zice ns c astea sunt veti proaste, pentru c s-a pierdut controlul deplin asupra momentului n
care se face eliberarea reziduurilor din memorie.
Java ruleaz n propria lui main virtual, un fel de protecie n jurul aplicaiilor care le scutete pe acestea de
necesitatea de a ti prea multe despre hardul pe care ruleaz. Din acest motiv, portarea unei aplicaii Java de pe o
platform pe alta este imediat, fr nici un efort. Tot ce trebuie fcut este s se foloseasc o portare standard a
mainii virtuale Java. i asta nu e tot: Java vine cu propriile API-uri pentru principalele funciuni de care are nevoie
o aplicaie complet: interfa grafic, multithreading, operaii matematice, comunicaii pe reea, acces hardware,
etc. Prin definirea acestor API-uri, portarea aplicaiilor trece ntr-o nou etap, de la portarea la nivel de surs, la
portarea la nivel binar. Desigur, portarea unora dintre aceste API-uri n sine pe un sistem de operare sau altul nu este
trivial, dar vestea bun este c se face o singur dat, i nu de ctre fiecare proiectant de aplicaii Java n parte. n
fine, tot maina virtual Java face posibil i o securitate avansat i un control deplin al drepturilor pe care le are o
aplicaie n timpul execuiei datorit faptului c execuia este controlata instruciune cu instruciune.
Acestea sunt cteva dintre trsturile care au adus succesul limbajului Java n ultimii ani. Din pcate unele dintre ele
aduc i dezavantaje cu care creatorii limbajului s-au luptat din greu n ultimii ani, ncercnd s-l extind sau s-l
modifice corespunztor.
Una dintre problemele acut resimite de ctre cei care vin dinspre C++ este imposibilitatea de a controla exact
eliberarea obiectelor Java. Existena colectorului automat de reziduuri de memorie face ca sistemul s ia singur
decizia momentului n care elibereaz obiecte. Desigur, exist aa-numiii "finalizatori" care sunt apelai n
momentul n care sistemul ncearc s elibereze un obiect, dar acest suport nu e suficient. n acelai timp, sunt
probleme cu creterea excesiv a memoriei ocupate de o aplicaie Java datorit faptului c obiectele nu sunt
terminate imediat dup ce nu mai este nevoie de ele. Pe parcursul timpului, proiectanii au gsit diverse trucuri de a
fora execuia colectorului de reziduuri la un moment bine precizat, dar soluia definitiv se las nc ateptat.
Pn atunci, ncepnd cu JDK 1.2, Sun a introdus aa-numitele obiecte referin care permit pstrarea unei referine
ctre un obiect, lsndu-l n acelai timp pe acesta s fie eligibil pentru colectorul de reziduuri. Astfel se pot
implementa, de exemplu, mecanisme de cache care s pstreze obiectele n memorie doar att timp ct spaiul nu
devine critic. Desigur, obiectele de tip referin au i un suport de tip callback prin care aplicaia este intiinat c
ele urmeaz s fie eliberate. Fr aceste obiecte, aplicaia fie pstra referine la obiecte i acestea nu erau eliberate de
loc, fie nu pstra referine pentru a le elibera, dar atunci nu mai putea folosi obiectele dect n momentul incert n
care se apela finalizatorul.
Tot legat de finalizare, Sun a observat c finalizatorii de clase definii n specificaia iniiala a limbajului Java pot fi
foarte uor reimplementai cu ajutorul finalizatorilor de obiecte. La aceast constatare, se adaug i faptul c nu
garanta nimeni apelarea finalizatorilor de clase i de fapt nici nu a existat vreodat un JVM care s implementeze aa
ceva. n consecin, aceast facilitate a fost eliminat definitiv din specificaia limbajului.
Modificri au fost fcute i n definiia numerelor flotante. n plus, s-au fcut o mulime de precizri i reformulri n
textul specificaiei pentru clarificarea anumitor faciliti sau probleme de compilare.
Cea mai semnificativa modificare a fost ns fcut ncepnd cu JDK 1.1, prin introducerea claselor i interfeelor
interioare (inner classes). Acestea sunt clase anonime care se pot declara n interiorul altor clase i care pot fi
folosite doar local, n interiorul claselor respective. Clasele interioare permit de exemplu crearea elegant a unor
adaptori de callback, exact la locul unde este nevoie de ei i nu ntr-o clas public exterioar, aflat probabil ntr-un
alt fiier surs. n plus, codul acestor clase poate fi mult mai bine optimizat la folosire i generare pentru c lipsete
overhead-ul necesar claselor care pot fi apelate din exterior.
Evoluia mediilor de execuie
Poate cea mai important dintre problemele cu care se confrunt programatorii este viteza de execuie a aplicaiilor
scrise n Java. Acestea, rulnd n interiorul unei maini virtuale, sunt n principiu semi-interpretate, ceea ce duce la o
performan net inferioar aplicaiilor native. Rezolvarea acestei probleme poate veni n principal din dou direcii:
crearea unui hardware care s ruleze aplicaii Java n mod nativ sau crearea unor maini virtuale din ce n ce mai
performante i eventuala compilare ctre cod nativ a binarelor Java n momentul ncrcrii acestora de ctre maina
virtual.
Prima soluie, aceea de dezvoltare de procesoare Java, a fost pus n discuie nc de la apariia limbajului ca o
promisiune din partea firmei Sun. Din pcate, nici pn astzi procesoarele Java nu au aprut i nu s-au rspndit pe
pia, dei ncercri au fost. Sun a lansat acum civa ani o tehnologie, numit picoJava Core (I i II) ca un prim pas
n aceasta direcie, iar tehnologia a fost liceniat deja de companii precum Fujitsu, IBM, LG, NEC sau Rockwell.
PicoJava Core este gndit pentru a fi componenta central a unui posibil microprocesor Java. Acest microprocesor
poate rula la fel de bine aplicaii Java ca i aplicaii C++ la performanele unui procesor RISC. Apariia produselor
comerciale bazate pe picoJava Core ar putea schimba semnificativ percepia utilizatorilor asupra performanei
aplicaiilor Java.

La sfritul anului 1997, Sun a lansat i un procesor complet, microJava-701, bazat pe picoJava core II. Din pcate,
sistemele cu succes comercial bazate pe acest procesor n-au aprut nc.
Sun a fcut, desigur, i pai n direcia crerii de plci construite special pentru a rula aplicaii Java, care sa poat fi
foarte uor integrate n sisteme la cheie de tipul calculatoarelor de reea. Un pas semnificativ n aceast direcie este
JavaEngine 1, care este o plac destinata OEM-urilor. Placa este bazat pe un procesor microSparc II ep i are suport
pentru JavaOS for Consumers, sistemul de operare Java dezvoltat de Sun pe baza nucleului ChorusOS i pe baza
tehnologiei desktop JavaViews, care include i browserul HotJava. JavaStation a fost primul calculator de reea
bazat pe aceast tehnologie lansat de Sun, dar succesul nu a fost prea mare, datorit performanelor nesatisfctoare
ale calculatorului. n prezent, Sun ncearc s refac acest drum cu un nou calculator de reea numit Sun Ray 1, care
va lsa i mai mult din greutatea procesrii pe umerii serverelor Solaris din reea. Sun sper c Sun Ray 1 va nlocui
cu timpul staiile Win-dows pe birourile utilizatorilor, preul de catalog fiind de doar 499$. n plus, Sun va oferi
diverse posibiliti de leasing care vor duce preul n jos la doar 9.99$ pe lun.
Dar pn n momentul n care vom avea hardware suficient de performant care s ruleze Java nativ sau care s fie
optimizat perfect pentru maina virtual Java, va trebui s mai zbovim un timp pe sistemele clasice care ruleaz
Java ntr-o main virtual clasic i sa ncercm s optimizm ct putem execuia aplicaiilor Java pe acest tip de
platforme. Ceea ce ne duce la cea de-a doua alternativ de cretere a vitezei, tehnologia de compilare JIT (Just In
Time). Aceast tehnologie a fost i ea anunat nc de la apariia limbajului Java, suportul pentru ea existnd chiar n
definiia mainii virtuale. Firme mari precum Borland, Symantec, IBM, Microsoft i Sun au implementat astfel de
extensii ale mainii virtuale, cu grade diferite de reuit. n plus, exist i o pleiad de implementri deschise,
gratuite, precum JIT-ul inclus n maina virtual Kaffe (nederivat din sursele Sun) sau shuJIT, care suport maina
virtual Sun 1.1 pentru procesoare Intel n modul n care a fost ea portat pe Linux de proiectul Blackdown. Dintre
ele, efortul Kaffe este remarcabil, pentru c el ncearc s inteasc platforme traditional neglijate de Sun, precum
Linux sau FreeBSD. Kaffe este nc n beta i suport JDK 1.1 i doar parial 1.2. Exist i un proiect de portare a lui
Kaffe pe BeOS. Din pcate, Kaffe este nc foarte lent, chiar dac are suport JIT. Chiar i n cadrul proiectului
Mozilla se dezvolt o nou main virtual Java dotat cu un JIT, numit ElectricalFire, care suport Windows i
Linux x86.
Se pare ns c cea mai reuit implementare JIT o are n continuare Borland (Inprise) pe Windows, la concuren
direct cu implementarea IBM. IBM deine ns supremaia pe Linux, unde testele arat o vitez de trei ori mai bun
dect portarea Blackdown a surselor Sun i de patru ori mai bun dect Kaffe.
Cei de la Sun i-au ncercat i ei ansele de implementare JIT cu tehnologia HotSpot, care din pcate nu a reuit nc
s ofere performana promis iniial (se vorbea la un moment dat de creterea vitezei de execuie a aplicaiilor Java
de 10 ori!). n final, HotSpot reuete s accelereze aplicaiile doar cu aproximativ 100%, dup o perioad exagerat
de lung de dezvoltare a tehnologiei. Performana sczut a HotSpot 1.0 a fost probabil factorul determinant care a
mpins firma Sun s lanseze produsul gratis, dei iniial a fost anunat ca un produs comercial.
Sun lucreaz acum la HotSpot 2.0, care va oferi o accelerare suplimentar cu nc 30%. Probabil c seria versiunilor
HotSpot va continua n ncercarea de a oferi versiuni din ce n ce mai performante. Oricum, Sun pare s fie mulumit
de aceast tehnologie, din moment ce o va distribui mpreun cu noul JDK 1.3, aflat nc n beta.
O problem a tehnologiei HotSpot este c ea suport doar platforma Java 2. Ceilali concureni care i-au lansat
implementrile JIT mult mai repede, suporta i platforma JDK 1.1. Din pcate, unii dintre ei, cum sunt IBM sau
Microsoft, nu suport nc Java 2.
n fine, n noul JDK 1.3, Sun lanseaz i suport pentru crearea unor componente grafice AWT cu desenare n mod
nativ. Acest lucru va accelera probabil semnificativ viteza de afiare a aplicaiilor Java.
Evoluia interfeelor de programare
Partea care a evoluat cel mai spectaculos pe parcursul ultimilor ani este, desigur, pleiada de API-uri oferite de Sun n
mod standard i gratuit mpreun cu mediul de execuie Java. Acestea sunt extrem de importante pentru ca permit,
dup cum spuneam, dezvoltarea de aplicaii independente de platform.
n cazul n care aceste API-uri sunt complet implementate n Java, treaba este extrem de simpl, pentru c portarea
de pe o platforma pe alta este asigurat de JVM. Din pcate, exist i un alt fel de API-uri, care sunt direct legate de
hardware, din aceasta cauz fiind scrise n limbaje compilabile n cod nativ i care trebuie reimplementate pentru
fiecare platform pe care este portat maina virtual Java. Sun a depus un efort uria n ultimii ani pentru a putea
specifica ct mai bine aceste API-uri i pentru a aduna opiniile i acceptul a ct mai multe companii cu putin
pentru noile specificaii. O parte dintre ele au fost deja implementate, altele sunt n diverse stadii beta sau exist doar
pe hrtie. Oricum, aceste API-uri dau sau vor da aplicaiilor Java posibilitatea de a accesa plci de sunet, s
comunice pe linii seriale, s acceseze ct mai multe dintre facilitile plcilor video care n-ar fi posibil s fie
accesate altfel, etc.

n afar de aceste API-uri dependente de hardware, Sun a dezvoltat i restul API-urilor standard i a introdus altele
noi, pentru a oferi proiectanilor Java ct mai mult funcionalitate prefabricat. Voi face n continuare o trecere n
revist foarte rapid a ctorva dintre cele mai importante.
AWT a fost prima generaie de API-uri destinate construciei de interfee grafice utilizator. Acest API a fost nlocuit
ulterior cu un altul, mult mai elaborat, care se numete Swing i care ofer toate funcionalitile necesare unei
interfee moderne. Swing nu este o extensie a AWT ci o rescriere a acestuia pe principii foarte profund mbuntite.
Din pcate, Swing continu s fie destul de lent i de aceea se pot gsi nc foarte multe aplicaii Java care continu
s foloseasc vechiul AWT. Iar noul suport pentru componente native AWT va duce i el probabil la meninerea
pentru un timp a AWT-ului n topul preferinelor, mpreun cu faptul c Swing adaug 2 MB la kitul de distribuie a
aplicaiilor care l folosesc.
O alt piatr unghiular a mediului Java este specificaia JavaBeans, care a definit ncepnd cu JDK 1.1 modul n
care pot fi create componente soft-ware pentru mediile de dezvoltare Java i cum se pot defini evenimente, metode
i proprieti ale acestora. Prin acest API, Sun a adus un rspuns flexibil i uor de utilizat la COM-ul lui Microsoft.
Java-Beans se bazeaz, n partea de introspecie a claselor Java, pe un alt API nou dezvoltat de Sun, numit API-ul de
reflecie, care permite investigarea numelui i tipului variabilelor precum i a numelui, tipului i parametrilor
metodelor din interiorul unei clase Java n format binar la momentul execuiei.
Sun s-a preocupat i de crearea suportului pentru crearea, regsirea i accesarea de obiecte distribuite n reea i de
comunicaie ntre acestea prin introducerea API-ului RMI (Remote Method Invocation) i, ulterior, introducerea
suportului pentru IDL-ul CORBA i crearea unui pod ntre cele dou tehnologii. Acest pod a fost creat prin
introducerea unui produs care permite accesarea uoar a obiectelor RMI ca obiecte CORBA, prin tehnologia RMIIIOP. n fine, acest efort a fost n final completat cu o tehnologie, numit Jini, care permite construirea i regsirea
obiectelor care ofer servicii n reea, precum i contractarea i autorizarea folosirii acestor servicii.
n ceea ce privete grafica, Sun a introdus n acelai timp un API pentru grafic performant 2D, ct i un pachet de
grafic 3D. Pachetul 2D este un pachet extrem de puternic care vine standard cu mediul de dezvoltare Java ncepnd
cu platforma Java 2. Java 3D este pe moment un API independent, bazat pe principii avansate de modelare a
obiectelor 3D, proiectat special pentru lucrul n reea. Java 3D a fost implementat pe diverse platforme folosind APIuri 3D de nivel jos, precum Direct3D sau OpenGL.
Sun nu a neglijat nici zona de multimedia, oferind un API de lucru cu sunet i video, numit Java Media Framework
(JMF), API care are suport pentru formate ca WAV, MIDI, AU, AVI, MPEG-1, MPEG-2 sau QuickTime. Prima
versiune JMF 1.0 oferea doar suport playback, dar JMF 2.0 ofer i suport de captur, dezvoltare de noi codec-uri,
broadcasting n timp real sau salvare n fiiere a fluxurilor video sau audio.
Pentru lucrul cu baze de date, a fost dezvoltat un API numit Java DataBase Connection (JDBC), care permite
accesarea unor baze de date SQL locale sau la distan pe baza unor drivere specifice fiecrui tip de baz de date n
parte. Exist la ora actual drivere pentru principalele baze de date aflate pe pia, precum i un pod JDBC-ODBC
care permite folosirea driverelor dezvoltate deja pentru tehnologia Microsoft.
Pentru cei care lucreaz cu servere Web, s-a creat o specificaie care permite dezvoltarea de extensii pentru serverul
Web, numit Java Servlets, i care a fost implementat pe majoritatea serverelor de Web importante, inclusiv pe
Apache prin modulul Jserv care tocmai a ieit n beta. n plus, pentru dezvoltarea uoar de pagini Web ce conin
scripturi care se execut pe partea de server, s-a dezvoltat o tehnologie numit Java Server Pages (JSP) care permite
introducerea de scripturi Java n paginile Web. Sun dezvolt aceast tehnologie mpreun cu cei de la IBM i
Apache.Org.
n fine, alte API-uri i tehnologii dezvoltate n ultimul timp de Sun includ parsere XML, API-uri pentru
internaionalizarea aplicaiilor, API-uri de criptografie, de lucru cu protocoale de pot electronica, comunicaie
serial, telefonie, cartele magnetice etc. Lista acestora este foarte mare i crete constant.
Platforme Java
Facilitile oferite de mediul Java sunt foarte multe dar, n funcie de context, cei care folosesc Java pot avea nevoie
doar de un subset a acestora. Subsetul respectiv este definit n funcie de ce face aplicaia precum i de platforma
hardware care este intit de aplicaie. Vor exista diferene semnificative n lista de API-uri folosite de o aplicaie
pentru staii de lucru, o aplicaie destinat serverelor mari sau o aplicaie destinat sistemelor n-globate (embedded),
n care disponibilitile de memorie i vitez de calcul sunt limitate.
Cu cteva luni n urm, Sun a ncercat s fac o clasificare a platformelor Java pentru o mai bun clarificare a
facilitilor pe care fiecare dintre acestea le ofer. Astfel, Sun a nceput s vorbeasc despre Platforma Java Standard
(Java Standard Edition), Platforma Java pentru ntreprinderi (Java Enterprise Edition) i Platforma Micro Java (Java
Micro Edition). Cele trei platforme au, desigur, la baz aceleai principii i tehnologii, dar acestea au fost adaptate
unui anumit mediu ctre care intesc aplicaiile.

Platforma Java Standard include majoritatea API-urilor despre care am discutat mai sus, ca un suport pentru aplicaii
independente care ruleaz n general pe sisteme desktop. Dac dorim crearea de aplicaii multi-user, distribuite la
nivel de ntreprindere, atunci vom recurge probabil la Platforma Java pentru ntreprinderi, care cuprinde JavaBeans
n varianta extins pentru ntreprinderi (Enterprise JavaBeans), JDBC, CORBA, API-urile de Servlets i Java Server
Pages, ntr-un cuvnt tot ce este nevoie pentru dezvoltarea de aplicaii pe mai multe nivele, care cuprind servere cu
acces multi-utilizator, baze de date i obiecte binare distribuite n reele eterogene. n ceea ce privete extensia
pentru ntreprinderi a JavaBeans, aceasta nu este nimic altceva dect extinderea specificaiei de creare de
componente software JavaBeans cu suportul pentru crearea de componente software de tip server care ruleaz n
interiorul unui server de aplicaii Java.
n fine, Platforma Micro Java este destinat sistemelor nglobate n care memoria i viteza procesorului sunt limitate.
inta sunt sistemele de tip echipamente portabile handheld sau palmtop, telefoanele Java sau mobile, echipamente
casnice inteligente dotate cu microprocesor, etc. Maina virtual pe care se bazeaz aceast platforma este K Virtual
Machine (KVM), construit special pentru cazurile n care memoria nu depete 128K. KVM n sine ocup doar
40K. Procesoarele pe care ruleaz KVM sunt n general procesoare RISC de 16 sau 32 de bii. Aceast main
virtual va putea rula probabil unul dintre subseturile limbajului i API-urilor Java cuprinse n specificaiile de
EmbeddedJava sau PersonalJava. Pentru aceast platform au fost proiectate API-uri avansate precum JavaCard
pentru rularea codului Java n interiorul cartelelor magnetice sau Java TV, un API destinat operatorilor de cablu TV
care vor s transmit semnal video i audio digital.
Portarea pe diferite platforme
Maina virtual Java a fost portat pn n prezent pe majoritatea sistemelor de operare i procesoarelor existente.
Din pcate, stadiul port[rilor este foarte diferit de la o platform la alta. Pe moment, Sun continu s suporte doar
platforma Solaris (SPARC i Intel) i platforma Windows. Pentru celelalte platforme, Sun ofer doar suportul
minimal de portare i, acum o jumtate de an, Sun a fcut public tot codul sursa al platformei Java 2. Printre
sistemele care nu au nc o portare Java performant se numr din pcate i mult ludatul BeOS, sistemul de
operare proiectat special pentru aplicaiile media.
Majoritatea portrilor suporta JDK 1.1 i doar pri din JDK 1.2. n plus, platformele sufer uneori de mici diferene
de rulare a acelorai aplicaii, datorate unor bug-uri n portare sau deficiene ale platformei. Acestea se fac simite
mai ales n zona de multithreading, interfa grafic utilizator i comunicaii cu socket-uri.
n plus, multe dintre browserele actuale vin mpreun cu un mediu de rulare a applet-urilor Java, de obicei n
versiunea JDK 1.1. Din pcate, versiunea Java suportat de browsere era actualizat foarte rar, ceea ce a dus la
decizia Sun de a crea o component numit Java Plug-in. Aceast component ofer practic suport pentru ultima
versiune de JDK Sun, pentru browserele standard precum Netscape Navigator sau Internet Explorer. Astfel, creatorii
de applet-uri Java pot folosi ultimele versiuni de API-uri Java imediat ce ele apar.
Ce urmeaz?
Sun face eforturi extraordinare pentru a reui s impun tehnologia Java ca o tehnologie a viitorului. Marile
companii de calculatoare i software din lume au preri mprite i grade de interes diferite n ceea ce privete
aceast tehnologie. Cert este c toat lumea, inclusiv Microsoft, cocheteaz cu limbajul i investete sume
semnificative n dezvoltarea de API-uri i de noi portri ale platformei Java.
Ceea ce se poate ns constata este o lips destul de mare n zona aplicaiilor end-user scrise n Java. Toat lumea
pare s se concentreze pentru crearea de scule pentru proiectanii de aplicaii Java, medii de dezvoltare, componente,
servere. Pare ns ca proiectanii n-au fost nc ndeajuns convini c Java este soluia pentru viitor. Probabil c
aceast situaie este generat i de faptul c vremea produselor software mamut a trecut i c ne ndreptm spre o era
n care o aplicaie nu va fi nimic altceva dect o mulime de componente de dimensiuni mici sau medii, care
comunic ntre ele ntr-un limbaj standard comun. i dac ntr-acolo ne ndreptm, atunci Java va fi rspunsul,
pentru c exceleaz n suportul pentru astfel de scenarii.
Dar chiar dac viitorul acestei tehnologii este nc nesigur, pe moment ea rmne una dintre cele mai dinamice de pe
piaa de software de la aceast or.