Evoluia Java

Java reprezint azi mai mult dect un limbaj, o main virtual i un set de biblioteci; reprezint un fenomen.
Vasile Gaburici & Irina Athanasiu

Limbajul Java a devenit vizibil ca limbaj obinut prin rafinarea limbajului C++ asigurnd portabilitatea prin execuia
interpretat i permind mbogirea paginilor de Web cu componente dinamice care se execut direct pe
calculatoarele celor care vizualizeaz paginile Web. Foarte repede numele Java a ajuns s desemneze nu numai un
limbaj de programare ci o colecie de tehnologii legate de Internet.
ntr-o perioad relativ scurt fenomenul a atins proporii la care puini se ateptau. A scrie azi despre fenomenul Java
n general este dificil datorit numeroaselor domenii n care Java are o prezen. A ptruns n fortreaa aplicaiilor
pentru baze de data Oracle, i propune s ofere suport pentru aplicaii distribuite JINI, i au existat tentative chiar
dac nu ntotdeauna ncununate de succes, ca JavaOS sau microprocesorul PicoJava .
n acest articol ne vom limita analiza la JDK (Java Development Kit), produsul prin care Sun distribuie nucleul
tehnologiei Java, dar care reprezint numai o parte a fenomenului Java. Ne vom concentra atenia asupra versiunii
1.2 a JDK, versiune ce mplinete aproape un an de la lansare sa din decembrie 1998 i care conine o serie de
tehnologii considerate deja mature de ctre Sun.
Probabil pentru a sublinia importana acestei noi versiuni, Sun a mers pn acolo nct s o denumeasc Java 2. n
ciuda acestei denumiri care ar sugera modificri majore la nivelul limbajului, situaia este invers fa de tranziia de
la versiunea 1.0 la 1.1. Atunci limbajul primea o serie de adugiri importante, cum ar fi suportul pentru clase
interioare (inner classes) sau clase anonime i noi biblioteci (cea mai important fiind probabil RMI care a introdus
n Java elementul distribuit).
Lansarea JDK 1.2 a dus la modificri mai puin semnificative la nivelul limbajului, dar i la modificri importante la
nivelul mainii virtuale i la un influx masiv de noi biblioteci.
Limbajul
La nivelul limbajului singura modificare const din introducerea unui nou cuvnt cheie (strictfp) a crui obscur
funcionalitate este de a pstra compatibilitatea operaiilor n virgul mobil cu versiunile anterioare ale JDK. n
lipsa acestui modificator maina virtual poate optimiza operaiile pentru procesorul pe care ruleaz ceea ce duce
evident la o cretere a vitezei de execuie, dar introduce o posibilitate de incompatibilitate.
Absena unor modificri mai substaniale poate conduce la concluzia c pentru obiectivele actuale pe care i le
propune limbajul, Java a atins maturitatea. Obiectivele urmrite de Java sunt n continu evoluie, prin urmare este
posibil ca n viitor s asistm la modificri mai spectaculoase. Dac de exemplu Java i va propune s ofere suport
pentru aplicaii numerice (eventual distribuite) atunci ne putem atepta la introducerea unor elemente de genul celor
propuse n [1].
Modificri ale mainii virtuale
Cu toate c iniial portabilitatea a fost sinonim cu execuia interpretat, aceast abordare limita considerabil viteza
de execuie. Ulterior au aprut soluii comerciale de accelerare a execuiei prin translatarea codului claselor n cod
nativ n momentul execuiei. Un astfel de compilator numit JIT (Just In Time) este inclus i n JDK 1.2 i este
implicit activ.
Securitatea
Un punct forte al tehnologiei Java l constituie securitatea integrat n maina virtual. Acest mecanism este ntr-un
fel cheia de bolt a mecanismului execuiei applet, deoarece n lipsa acestuia nimeni nu ar accepta execuia de cod
strin adus de navigatorul Web pe maina sa.
Conceptul de securitate n Java a pornit de la modelul cutiei cu nisip (sandbox) introdus n versiunea 1.0. Acest
model presupune executarea codului recepionat de la distan sub controlul unui manager de securitate care poate
interzice sau permite codului strin (untrusted code) accesul la resursele locale. Pentru appleturi ns aceasta se
traducea invariabil prin interzicerea accesului la anumite clase de resurse (de exemplu fiiere).
Acest gen de restricii pot fi acceptabile pentru applet-uri care urmresc mbogirea aspectului paginilor web, dar
ridic probleme greu de rezolvat pentru applet-uri care necesit interaciunea direct cu maina pe care se execut.
Pentru a evita acest gen de probleme n versiunea 1.1 a JDK s-a introdus noiunea de applet semnat. Aceasta
nsemna practic acordarea de drepturi depline unui applet care oferea o semntur digital acceptabil.
ntre cele dou extreme: drepturi depline i cutia cu nisip exist o dihotomie de tipul totul sau nimic. Pentru a oferi o
real flexibilitate era fr ndoial necesar introducerea unui mecanism configurabil de securitate. n acest sens
JDK 1.2 a introdus politici de securitate. Acestea se implementeaz sub forma unui fiier de configurare ce permite
diferenierea drepturilor acordate codului aflat n execuie n funcie de originea sa (adresa de provenien) i se
aplic att appleturilor ct i aplicaiilor.

Un alt aspect legat de securitate este noua facilitate introdus la nivelul mainii virtuale de a nclca explicit
modificatorii restrictivi de acces la membrii unei clase (de exemplu private). Acest gen de nclcri sunt utile spre
exemplu pentru a serializa un obiect. Compilatorul nu permite ns acest gen de violri ale limbajului, deci aceast
facilitate se poate exploata doar la execuie prin introspecie (reflection) i cade sub incidena unor verificri de
securitate efectuate de maina virtual.
Extensions Framework
Acest mecanism ofer posibilitatea de a extinde bibliotecile disponibile pe o main virtual. Exist dou tipuri de
extensii n funcie de modul n care se face instalarea acestora.
Pachetele instalate local (installed extensions) au aceleai drepturi ca bibliotecile standard, putnd utiliza i cod nativ
al platformei pe care se instaleaz. Un numr de produse Sun care nu fac parte propriu-zis din JDK (JavaServlet,
Java3D, .a.) pot fi instalate n acest mod i poart denumirea de extensii standard.
Pachete instalate dinamic (download extensions) sunt aduse i instalate n timpul execuiei mainii virtuale i servesc
ca biblioteci pentru applet-uri; o arhiv Java (jar) ce conine un applet poate specifica extensiile de care are nevoie,
iar acestea sunt aduse automat de maina virtual.
Reference Objects
JDK 1.2 introduce i suport pentru obiecte referin. Este de fapt vorba de referine slabe similare n funcionalitate
cu referinele din C++ (sunt immutable). Trei tipuri de referine sunt introduse: soft, weak i phantom. Acestea
modific substanial modul n care colectorul de memorie disponibil "vede" un obiect. Exist acum 5 stri de
accesibilitate ale unui obiect: strong, soft, weak, phantom i inaccesibil.
Obiectele referite doar prin referine soft pot fi distruse prin decizia colectorului de memorie disponibil ca urmare
de exemplu a unei cereri de alocare de memorie. Referinele soft pot s fie utilizate pentru implementarea unor
cache-uri de obiecte, n care obiectele referite sunt distruse dac maina virtual are nevoie de memorie
suplimentar.
Obiectele accesibile weak pot fi finalizate n orice moment de ctre colectorul de memorie disponibil. De exemplu
clasa WeakHashMap se bazeaz pe acest tip de referine pentru a implementa o tabel asociativ n care lipsa unei
referine externe (strong) la o cheie duce la tergerea automat a acesteia din tabel. La ce folosete aa ceva? De
exemplu pentru a implementa variabile care au o valoare specific pentru fiecare fir de execuie (ThreadLocal).
Evident este preferabil ca la dispariia unui fir de execuie s dispar automat i valoarea specific a variabilei.
Referinele phantom permit cod mai flexibil de finalizare, deoarece obiectele referite n acest mod nu sunt distruse
automat dup finalizare ci rmn accesibile phantom pn cnd referinele sunt eliberate explicit.
Pentru toate tipurile de obiecte referin este posibil nregistrarea acestora la o coad. n momentul n care are loc o
modificare a strii de accesibilitate a obiectului, referina este automat pus n coada la care era nregistrat.
Anumite componente JDK 1.2 folosesc deja aceast schem considerabil mai complex pentru a face anumite
optimizri. Un exemplu n acest sens este implementarea RMI. Rmne de vzut dac aplicaiile utilizatorului
"obinuit" vor putea profita de aceste faciliti, avnd n vedere c utilizarea lor optim este destul de dificil.
Biblioteci
n ceea ce privete bibliotecile introduse n JDK 1.2 trebuie observat c puine dintre acestea sunt noi, majoritatea
sunt produse care i-au dovedit anterior viabilitatea i au fost incluse pur i simplu n JDK.
JFC
Fr ndoial c cea mai important bibliotec integrat n JDK 1.2 este JFC (Java Foundation Classes). Dei numele
aduce oarecum aminte de biblioteca MFC (Microsoft Foundation Classes), obiectivele urmrite de JFC sunt diferite,
deoarece JFC i propune s se ocupe exclusiv de interfaa grafica a aplicaiilor i applets.
JFC nglobeaz acum AWT (Abstract Windowing Toolkit) care era n versiunile anterioare ale JDK singura
bibliotec pentru crearea interfeelor grafice. Pe lng AWT ns, n JFC sunt incluse o serie de noi biblioteci dintre
care cea mai important este Swing.
Swing i propune s reconstruiasc de la zero practic conceptul de interfa grafic portabil "100% Java pur".
Dac n AWT componentele grafice erau implementate prin intermediul componentelor oferite de sistemul de
ferestre peste care rula maina virtual (Motif, MS Windows, .a.) de cele mai multe ori printr-o mapare direct, n
Swing acestea sunt desenate folosind primitive grafice, ceea ce permite consistena aspectului componentelor pe
toate platformele.
AWT suferea de problema celui mai mic numitor comun n sensul c putea oferi doar acele primitive grafice care
erau suportate pe toate platformele. Aceast limitare fiind eliminat de Swing, paleta componentelor oferite este
acum larg diversificat.
Probabil c aspectul cel mai spectaculos al Swing este personalizarea aspectului i comportamentului componentelor
(pluggable look and feel - PL&F). Aspectul i chiar comportamentul componentelor poate fi modificat dinamic n

timpul execuiei programului conform unei personaliti (L&F) care confer omogenitate componentelor.
Personaliti predefinite ca Windows L&F sau Motif L&F sunt incluse n JFC.
Pe lng AWT i Swing, JFC mai include Java 2D - o biblioteca de prelucrare a imaginilor, precum i suport pentru
Drag & Drop i suport pentru persoanele cu handicap (Accessibility).
JDK 1.2 integreaz versiunea 1.1 a JFC, dar o versiune mai recent a JFC (1.1.1) a fost lansat separat de JDK.
Conform anunului fcut de realizatorii JFC, acest model de dezvoltare permite testarea separat a JFC iar pe msur
ce codul se stabilizeaz este inclus n JDK.
Collections Framework
Ca i n alte limbaje, n Java s-a impus o standardizare a bibliotecilor corespunztoare structurilor de date i
algoritmilor generici. Dac n cazul C++ au fost necesari muli ani pentru ca proiectul STL (Standard Template
Library) [2] iniiat de Alexander Stepanov s capete o acceptare larg pentru a fi introdus n standardul ANSI/ISO
C++, n cazul Java evoluia a fost puin diferit. Un echivalent Java al STL a fost creat de compania ObjectSpace
sub denumirea JGL (The Generic Collection Library for Java) [3]. Putem presupune c decizia Sun de a introduce n
JDK Collections Framework s-a datorat cel puin n parte succesului de care s-a bucurat JGL. ns Sun nu a adoptat
JGL ca atare invocnd complexitatea excesiv datorat calchierii STL, ci a preferat rescrierea poriunilor mai
frecvent utilizate. Comparativ, JGL se compunea din aproximativ 130 de clase i interfee, pe cnd Java Collections
are doar 25.
Sunt oferite trei tipuri de colecii (containere): liste, mulimi i tabele asociative (map). Pe lng interfeele care
standardizeaz utilizarea efectiv, sunt oferite mai multe implementri. Pentru liste exist vectori redimensionabili i
liste nlnuite, iar pentru mulimi i tabele asociative exist implementri bazate pe tabele de dispersie i arbori
echilibrai. Pentru parcurgerea acestor structuri se folosete mecanismul devenit standard al iteratorilor. De
asemenea se ofer algoritmi clasici de cutare, sortare, etc.
Din pcate structurile de date nu sunt cu adevrat generice ci doar polimorfe, datorit lipsei suportului pentru
programarea generic (templates) n limbajul Java.
Vechile structuri de date oferite de versiunile JDK anterioare (Vector i Hashtable) au fost modificate doar ca
implementare i se ncadreaz i ele n Framework. Deoarece interfaa nu a fost schimbat, nu apar probleme pentru
aplicaiile care utilizau aceste structuri de date.
JavaBeans
Suportul pentru programarea orientat pe componente denumit JavaBeans a fcut parte din JDK nc de la versiunea
1.1. Aceasta a permis printre altele dezvoltarea de medii integrate de dezvoltare (IDE) care s permit realizarea
vizual a interfeelor aplicaiilor i appleturilor.
Dei suportul pentru JavaBeans este inclus n JDK nu sunt incluse i beans care s poat fi folosite pentru
dezvoltarea efectiv de aplicaii cu att mai puin un mediu de dezvoltare. Pentru cei interesai Sun ofer BDK
(JavaBeans Development Kit) [4] n aceleai condiii de liceniere ca i JDK. Scopul BDK nu este ns proiectarea
vizual al aplicaiilor ci dezvoltarea i testarea de "beans" per se. BDK include printre altele BeanBox - un program
care permite interaciunea cu beans ntr-un mod similar cu cel al unui IDE "adevrat".
Cei care doresc s foloseasc aceast tehnologie pentru dezvoltarea vizual a aplicaiilor i appleturilor au nevoie de
un mediu de dezvoltare comercial cum ar fi IBM Visual Age, Inprise JBuilder sau Symantec Caf.
JDK 1.2 include ediia Glasgow a JavaBeans. Aceasta aduce n plus fa de versiunile anterioare, mbuntiri la trei
capitole: interaciunea cu mediul, procesarea flexibil a datelor n funcie de tipul acestora i suport pentru Drag &
Drop.
Extensible Runtime Containment and Services Protocol permite unui bean s afle informaii despre mediul n care
ruleaz. Aceasta permite de exemplu ca ntr-o ierarhie de beans s existe cooperare.
JavaBeans Activation Framework (JAF) ofer practic suport pentru detectarea tipului datelor cu care se lucreaz i
invocarea unui bean specializat. Specificarea tipului datelor se face prin intermediul MIME (Multipurpose Internet
Mail Extensions).
Java IDL
Sub aceast denumire nu tocmai fericit se ascunde suportul pentru CORBA [5]. Denumirea este oarecum modest
deoarece JDK 1.2 ofer un ORB (Object Request Broker) ce implementeaz standardul CORBA/IIOP 2.0. Pe lng
standard, JavaIDL ofer i suport pentru serviciul de nume (Naming Service) dar n JavaIDL nu exist un IR
(Interface Repository).
n ciuda denumirii, din JavaIDL lipsete tocmai compilatorul propriu-zis de IDL, acesta fiind nc n perioada de
teste beta la lansarea JDK 1.2. Acest compilator (idltojava) poate fi ns obinut via JDC (Java Developer
Connection).
RMI

RMI (Remote Method Invocation) este acum un acronim care apare constant cnd se vorbete despre ceva distribuit.
Puin lume a auzit probabil de HORB [6]. Iniiat n 1995 de Hirano Satoshi, HORB a fost prima bibliotec care
oferea apeluri de metode la distan peste JDK 1.0. Apoi Sun a introdus RMI n JDK 1.1 i a propulsat Java n
domeniul distribuit.
n JDK 1.2 RMI se mbogete cu obiecte activabile la distan. Ideea este de a putea activa obiecte server doar
atunci cnd este nevoie de ele i de a folosi identificatori persisteni pentru a putea referi obiectele i atunci cnd
acestea sunt inactive. Aceasta conduce evident la o folosire mai eficient a memoriei pe maina server.
De lansarea n execuie a acestor obiecte activabile (Activatable) este responsabil un demon (rmid) care ocup foarte
puin memorie. Demonul lanseaz maini virtuale Java n care ruleaz efectiv obiectele. Pentru a nu crea un numr
excesiv de maini virtuale i pentru a permite cooperarea ntre obiectele server, acestea pot fi adunate n grupuri de
activare; toate obiectele din acelai grup fiind executate n aceeai main virtual.
O alt facilitate introdus n JDK 1.2 este aceea de a permite utilizatorului s redefineasc mecanismul de generare
al soclurilor folosite de implementarea RMI (Custom Socket Factories). Aceasta permite spre exemplu utilizarea
RMI peste SSL (Secure Sockets Layer) asigurnd astfel prin criptare securitatea comunicaiilor.
Viitorul acum
Ciclul de producie a noi versiuni se pare c se accelereaz. JDK 1.3 beta a fost deja lansat. Se pare c criticile cu
privire la performanele mai sczute ale JDK 1.2 fa de versiunile anterioare n anumite domenii nu au rmas fr
urmri. JDK 1.3 include printre altele numeroase optimizri la nivelul mainii virtuale incluznd printre altele
tehnologia HotSpot n versiunea client, iar compilatorul de Java a fost rescris. JDK 1.3 include de asemenea suport
pentru noul standard CORBA 2.3. Este inclus de asemenea un compilator IDL (idlj).
RMI-IIOP
Pn nu demult implementarea unei aplicaii distribuite n Java 2 ridica dilema alegerii ntre o soluie CORBA care
oferea avantajul interoperabilitii i RMI, o soluie n exclusivitate Java, care ns oferea avantaje specifice cum ar
fi transferul automat de cod executabil la distan, cunoscut i sub denumirea de transfer de comportament.
Cu toate c n Java 2 suportul pentru CORBA i RMI sunt standard, o aplicaie scris peste RMI are probleme n
realizarea interoperabilitii cu obiecte CORBA. Scrierea unui server care s ofere suport pentru ambele este un
exerciiu de virtuozitate. Protocoalele Internet pe care se bazeaz cele dou tehnologii de asemenea difer: RMI
utilizeaz "RMI Wire Protocol" iar CORBA se bazeaz pe IIOP n reele TCP/IP.
Pentru a rezolva aceast problem a fost creat RMI-IIOP. Acest pachet ncapsuleaz practic apelurile RMI n
protocolul IIOP permind ca o aplicaie scris pentru RMI s dialogheze cu obiecte CORBA la cellalt capt al
firului.
Dei pentru moment acest pachet nu face parte din distribuia standard JDK 1.2.x ci se instaleaz ca o extensie
standard, RMI-IIOP a fost inclus n JDK 1.3 beta, deci va deveni n curnd mult mai larg rspndit.
Java Naming and Directory Interface
Disponibil separat pentru JDK 1.2, aceast bibliotec inclus n JDK 1.3 ofer o interfa uniform pentru diversele
servicii de nume. Este o unificare binevenit deoarece RMI i JavaIDL (ca s lum dou exemple) ofer servicii de
nume diferite ca interfa.
Rolul JNDI este de a oferi un serviciu de mapare relativ simplu: pentru un nume dat se face cutarea ntr-o tabel
asociativ i dac este gsit se ntoarce obiectul denumit. Obiectul poate fi orice: imprimanta, serviciu RMI, etc.
Mecanismul efectiv de stocare al maprii poate fi LDAP, serviciul de nume CORBA sau registrul RMI, etc.
Un fel de concluzii
Dup cum se poate observa att din suportul pentru CORBA ct i din dezvoltarea RMI, Sun continu s promoveze
Java n direcia aplicaiilor distribuite. Oficial att JavaIDL ct i RMI sunt considerate "enterprise features".
Totodat se constat c distribuia "oficial" este cea care impune noile tehnologii. Exemple concludente n acest
sens le constituie HORB i JGL; tehnologiile oferite de aceste pachete s-au impus doar dup ce Sun a inclus pachete
echivalente n JDK.
Un alt aspect interesant n dezvoltarea JDK l constituie votarea modificrilor. nceput nti ca o votare a prioritii
corecturilor (remedierea bug-urilor) s-a ajuns acum i la votarea modificrilor dorite n JDK. Aceast "democraie"
este implementat prin intermediul JDC (Java Developer Connection) [7], un sit Internet unde utilizatorii nregistrai
pot vota pentru trei modificri care au fost deja raportate i pe care le doresc rezolvate cu prioritate. nregistrarea la
JDC este gratuit. De exemplu "bug-ul" care a primit cele mai multe voturi pentru JDK 1.3 beta a fost introducerea
suportului pentru imagini n format PNG (Portable Network Graphics).
O alt noutate este modul n care s-a modificat politica de portare a JDK [8]. Sun ofer n continuare celor interesai
sursele pentru a porta JDK pe o nou platform, dar impune acum prin licen ca o implementare s nu fie lansat
(declarat "released") pn cnd nu trece toate testele JCK (Java Compatibility Kit), iar acestea nu sunt puine (cca.

13000). Aceasta a ncetinit rspndirea JDK 1.2 n afara platformelor suportate direct (Windows i Solaris), dar va
asigura n final o calitate i o compatibilitate mult mai ridicat pe celelalte platforme.
Dei a trecut aproape un an de la lansare JDK 1.2 nc nu a ptruns n cele dou navigatoare Web cu cea mai mare
popularitate: Netscape Navigator i Microsoft Internet Explorer. Achiziionarea Netscape de ctre America Online i
lupta n justiie dintre Sun i Microsoft au fost fr ndoial factori care au influenat aceast ncetineal n
introducerea JDK 1.2. Cu toate acestea applet-urile Java 2 pot rula n cele dou navigatoare pe anumite platforme
folosind Java Plug-in.