PREZENTĂRI - Java Development Kit 1.1

Proiectarea şi scrierea de programe s-a mutat de mult din zona de cercetare în zona industrială. Iar atunci când vorbim despre industrie, vorbim despre componente prefabricate care trebuiesc asamblate împreună. Aşa se face că, la succesul unui mediu de programare, cel mai mult contează aceste două lucruri: componentele prefabricate conţinute în bibliotecile sau colecţiile de clase ale mediului şi componentele care există pe piaţă şi sunt compatibile cu mediul. Structurile sintactice ale limbajului de programare care însoţeşte respectivul mediu de programare rămân doar o bază, mai mult sau mai puţin flexibilă, cu ajutorul căreia se poate clădi funcţionalitatea.

La apariţia limbajului Java toată lumea a fost entuziasmată de noul limbaj, de portabilitatea şi de securitatea pe care acesta le oferă. Plus un set de clase care sunt într-adevăr portabile între platformele pe care rulează Java. Nu e puţin lucru şi totuşi: timpul a trecut şi o dată cu el entuziasmul a lăsat locul aplicaţiilor concrete. Şi odată cu scrierea acestor aplicaţii au apărut şi primele probleme: ierarhia standard de clase Java avea o mulţime de lipsuri. Nu existau posibilităţi de arhivare sau internaţionalizare, nu exista suport pentru serializarea obiectelor, nu exista suport pentru accesul la baze de date sau suport pentru crearea de componente software indispensabilă mediilor de dezvoltare interactive şi vizuale după standardele moderne. Ba chiar s-au auzit voci care au criticat clasele care construiau suportul pentru construcţia de interfeţe grafice utilizator acestea nefiind nici destul de puternice şi nici destul de flexibile.

În aceste condiţii, unii dezvoltatori s-au simţit înşelaţi şi s-au întors la vechile iubiri în timp ce alţii au încercat să umple aceste goluri dezvoltând noi pachete de clase care să le satisfacă cerinţele. Din păcate aceste pachete de clase, negăsindu-se standard în distribuţia Java, trebuiau descărcate din reţea sau instalate folosind căile clasice de distribuţie software.

Dar problema nu a fost foarte gravă atâta timp cât toţi dezvoltatorii au respectat regulile jocului, şi anume să scrie clasele de aşa natură încât ele să fie disponibile pe orice platformă pe care rulează maşina virtuală Java. Problema s-a agravat atunci când au apărut implementării ale maşinii virtuale Java şi clase care erau dependente de maşina pe care rulau şi imposibil de portat pe alte maşini. Dintre acestea face parte maşina virtuală Java distribută de Microsoft, care oferă suport COM/DCOM disponibil doar pe maşinile care rulează sub sisteme de operare Microsoft (dar nu DOS). Desigur, pentru Microsoft tentaţia a fost prea mare atâta timp cât nu a existat un standard pentru dezvoltarea de componente software: suportul COM a permis introducerea în ecuaţie a controalelor ActiveX, noile jucării promovate de Microsoft.

Datorită acestor ultime evoluţii, însuşi conceptul care stă la baza limbajului şi mediului de execuţie Java a fost pus în pericol, lumea dezvoltatorilor fiind din nou pusă în situaţia de a alege între Microsoft şi restul lumii. Ca răspuns la această situaţie, JavaSoft a luat două măsuri mai importante: Prima dintre ele este lansarea iniţiativei "100% pure Java" care certifică aplicaţiile care sunt 100% compatibile cu standardele Java şi pot rula pe orice maşină virtuală Java standard. Această primă măsură, deşi interesantă şi susţinută de foarte multe dintre firmele interesate în dezvoltarea aplicaţiilor Java, nu poate avea efect fără cea de-a doua măsură: urgentarea terminării specificaţiilor şi implementării specificaţiilor pentru componentele care lipsesc din pachetele de clase Java. Cea de-a doua măsură s-a concretizat la mijlocul lui februarie 1997 prin apariţia JDK 1.1, după mai bine de 3 luni de stagiu beta.

Desi nu poartă numele de JDK 2.0, noul JDK nu este doar o actualizare cosmetică a vechiului produs ci este un pas semnificativ în direcţia impunerii mediului Java ca un mediu puternic, capabil să suporte cerinţele unor aplicaţii diverse şi complexe. Am putea spune că, odată cu apariţia JDK 1.1, Java a ajuns în sfârşit la maturitate.

Componente noi în JDK 1.1

JDK 1.1 aduce o mulţime de pachete şi clase noi care completează fucţionalitatea în multe dintre ariile de interes pentru dezvoltatorii Java. Să vedem pe scurt care sunt acestea.

Internaţionalizare

Suportul pentru internaţionalizare permite dezvoltarea de apleturi Java localizabile în diverse limbi. Cu alte cuvinte, putem scrie cod independent de limba care va fi folosită la rularea programului şi să lăsăm apoi mediul de execuţie să hotărască pentru noi, în funcţie de limba curentă, care este formatul în care trebuie afişate numerele, data, care este mesajul corect pentru o anumită limbă şi aşa mai departe.

Suportul de internaţionalizare din JDK 1.1 oferă următoarele facilităţi: se pot afişa caractere Unicode oarecare, ceea ce permite scrierea corectă a mesajelor în orice limbă, există un mecanism de setare a limbii curente, un mecanism de localizare a mesajelor pe care le afişează aplicaţia, un mod de afişare a datei, ore şi numerelor senzitiv la limba curentă, servicii pentru sortarea şirulilor de caractere în funcţie de alfabetul limbii curente, convertoare de seturi de caractere, suport pentru formatarea parametrizată a mesajelor (plecând de la nişte şabloane şi înlocuind în acestea parametrii potriviţi) şi suport pentru separarea cuvintelor şi propoziţiilor într-un enunţ în funcţie de limbă.

Suportul pentru arhive Java (JAR)

JAR este un format de fişier arhivă independent de platformă, fişier în interiorul căruia se pot stoca mai multe fişiere diferite. Principala idee este legarea împreună, în acelaşi fişier-arhivă, a tuturor componentelor necesare pentru execuţia unui aplet Java (sau eventual mai multor apleturi) şi descărcarea acestora din reţea printr-o singură tranzacţie HTTP. În acest fel, se minimizează timpul de creare a conexiunilor Internet necesare descărcării tuturor componentelor unui aplet. În plus, formatul JAR suportă comprimarea fişierelor din interiorul arhivei ceea ce reduce şi mai mult timpul de descărcare prin reducerea dimensiunii totale a arhivei. În fine, formatul JAR suportă semnarea componentelor individuale din interiorul unei arhive, făcând astfel posibilă autentificarea originii componentelor. Appletviewer-ul care vine cu JDK 1.1 permite apleturilor semnate digital să ruleze pe sistemul gazdă cu drepturi identice cu cele ale unei aplicaţii Java. Cu alte cuvinte, apleturile semnate au dreptul să acceseze sistemul de fişiere local, să iniţieze conexiuni TCP cu alte sisteme decât cel de pe care au fost descărcate, etc. JavaSoft promite pe viitor un control mai precis asupra permisiunilor pe care le are un aplet semnat digital.

Formatul JAR este implementat integral în Java, fiind astfel foarte uşor extensibil.

Suport pentru securitate şi semnarea apleturilor

Noul API pentru securizarea apleturilor include suport pentru ca dezvoltatorii să-şi poată securiza apleturile pe mai multe nivele. API-ul, deşi specificat complet, este doar parţial implementat în JDK 1.1. Printre facilităţile implementate se numără semnăturile digitale, clasificarea mesajelor, managementul cheilor şi listele de control la acces.

Suportul pentru semnături digitale foloseşte algoritmi de tip DSA şi este util pentru generarea de perechi de chei publice şi chei private precum şi semnarea şi autentificarea datelor. Clasificarea mesajelor, cu algoritmi de tip MD5 şi SHA-1 este utilă pentru crearea unor amprente digitale ale datelor care pot fi folosite în semnături digitale şi în indexarea şi identificarea rapidă a datelor. De exemplu, Marimba Castanet foloseşte o semnătură generată cu algoritmul MD5 pentru a identifica fişierele care s-au modificat în interiorul unui canal Castanet. Managementul cheilor este o abstracţie care permite controlul unor entităţi precum utilizatorii şi grupurile de utilizatori, cheile şi certificatele acestora. Această facilitate permite aplicaţiilor să implementeze propriul sistem de management al cheilor şi să interopereze cu alte sistem de acest tip. Implementarea unor formate de certificate specifice precum X.509 v3 este amânată pentru o versiune viitoare a JDK. Listele de control la acces sunt utile pentru a specifica drepturile de acces pentru enităţi ca utilizatorii sau grupurile de utilizatori. JDK 1.1 nu foloseşte intern această facilitate şi JavaSoft anunţă că acest API va suporta modificări ulterioare.

Extensii ale Abstract Window Toolkit (AWT)

După cum aminteam mai sus, AWT 1.0x a fost ţintă a repetate atacuri din partea celor care au încercat să dezvolte interfeţe utilizator elaborate în Java. Poate tocmai de aceea au apărut deja diverse pachete care rescriu sau completează AWT, cel mai cunoscut fiind, desigur Internet Foundation Classes (IFC) dezvoltat de Netscape. Un alt toolkit, secondat şi de un utilitar de editare rapidă a interfeţelor este Bongo de la Marimba. În fine, anunţat, dar încă nelansat pe piaţă, este toolkit-ul Microsoft AFC (Java Foundation Classes). AFC va fi lansat împreună cu Internet Explorer 4.0.

Ca urmare a acestor critici şi pachete alternative de clase, JavaSoft a rescris AWT obţinând în acelaşi timp funcţionalitate şi performaţă superioară. Noua implementare a AWT are o arhitectură modificată pentru a permite dezvoltări ulterioare importante, are API-uri pentru imprimare (estenţiale pentru aplicaţiile comerciale), un sistem mult mai bun de derulare a conţinutului ferestrelor şi mult mai uşor de utilizat, meniuri popup, suport de tip clipboard care oferă facilităţi de cut&paste, specificarea formei cursorului pentru fiecare componentă a interfeţei în parte, un model de evenimente modificat bazat de delegare, extensii în zona de afişare şi prelucrare a imaginilor şi, desigur, un suport superior pentru specificarea fonturilor, absolut necesar API-ului de internaţionalizare. În ceea ce priveşte implementarea AWT pentru Win32, aceasta a fost integral rescrisă pentru a mări performanţa şi pentru a obţine consistenţă deplină cu celelalte platforme pe care a fost portat JDK.

Extensii în clasele de reţea

S-a introdus suport pentru o parte dintre opţiunile de lucru cu sockets din BSD în pachetul de clase java.net, şi anume TCP_NODELAY, SO_LINGER, SO_TIMEOUT şi IP_MULTICAST_IF. Au ramas in continuare de implementat SO_KEEPALIVE, MSG_OOB, SO_OOBINLINE (date out-of-band) şi RAW/ICMP SOCKETS. Alte extensii includ transformarea claselor Socket şi ServerSocket din clase finale în clase extensibile, adăugarea de noi clase derivate din SocketException pentru a mări fineţea mesajelor semnalate de mecanismul de excepţii şi mutarea clasei MulticastSocket din pachetul sun.net în pachetul java.net, clasa devenind astfel standard. Desigur, alte extensii se referă la îmbunătăţirea performaţei şi la eliminarea bug-urilor din vechea versiune.

Extensii în clasele de intrare/ieşire

Pachetul de intrare/ieşire a fost puternic extins prin apariţia unor clase destinate lucrului cu stream-uri de caractere. Acest nou tip de stream-uri este similar cu cel de octeţi dar lucrează cu caractere Unicode de 16 biţi. Această extensie a fost absolut necesară pentru a se putea cu şiruri oarecare de caractere şi pentru a se oferi suport de internaţionalizare. Aproape toată funcţionalitatea specifică stream-urilor de octeţi este disponibilă şi pentru cele de caractere. Cele două clase principale care implementează stream-urile de caractere sunt clasa java.io.Reader şi clasa java.io.Writer.

Extensii ale pachetului matematic

Sau introdus două noi clase, BigInteger şi BigDecimal. În cazul BigInteger, această clasă reprezintă întregi de precizie arbitrară, similari cu celelalte tipuri întregi din Java. În plus, pachetul java.lang.math are acum suport pentru calculul celui mai mare divizor dintre două numere, verificarea faptului că un număr este prim sau nu, generarea numerelor prime şi manipularea numerelor întregi la nivel de bit. Clasa BigDecimal este destinată numerelor zecimale cu semn de precizie arbitrară, utilă operaţiilor care implică sume de bani.

Apelul metodelor la distanţă (RMI)

Aplicaţiile distribuite sunt o realitate în zilele noastre, aşa că suportul pentru apelul metodelor la distanţă este esenţial pentru un mediu care vrea să se impună. RMI permite crearea unor aplicaţii Java în care metodele obiectelor dintr-o maşină virtuală Java pot fi apelate din altă maşină virtuală Java, care eventual poate rula pe un al calculator. Pentru a apela o metodă a unui obiect depărtat este suficient să se poată obţine o referinţă către acel obiect. Această referinţă se poate obţine căutând în registry-ul maşinii pe care rulează obiectul sau se poate primi referinţa ca parametru sau ca valoare de retur dintr-o metodă. Obiectele pot apela obiectele de pe un server în timp ce serverul poate acţiona şi el ca un client al altor servere de obiecte. Registry-ul este o aplicaţie de tip server care permite înregistrarea obiectelor cu un nume extern, uşor de identificat. Aplicaţiile pot face apel la facilităţile clasei java.rmi.Naming pentru a obţine o referinţă către un obiect dacă cunosc serverul pe care a fost înregistrat obiectul şi numele sub care a fost acesta înregistrat.

Pentru a putea transmite parametrii şi valorile de retur, RMI utilizează API-ul de serializare a obiectelor.

Serializarea obiectelor

Serializarea obiectelor este o interfaţă de programare care exinde clasele de intrare/ieşire cu posibilitatea de a transfera obiecte. Serializarea permite deci transformarea obiectelor într-un şir de octeţi. Dacă din interiorul unui obiect sunt referite alte obiecte, atunci acestea sunt serializate împreună cu obiectul care le referă. Şirul de octeţi obţinut este în aşa fel generat încât se pot construi oricând din el înapoi obiectele iniţiale şi legăturile dintre ele.

Serializarea este utilizată pentru o persistenţă simplificată şi pentru transmiterea obiectelor în reţea şi ca parametrii sau valoare de retur pentru RMI.

Pentru fiecare tip de obiecte există o serializare standard, operată automat de către sistem, dar dezvoltatorul este liber să-şi dezvolte şi propria implementare a serializării. Implementarea implicită protejează membrii privaţi ai obiectelor şi nu transmite variabilele care au fost declarate tranziente. În cazul în care un obiect este referit de mai multe ori, el este serializat o singură dată în prima poziţie în care apare, iar în următoarele poziţii se memorează doar o trimitere către forma serializată a obiectului. Dacă dezvoltatorul a ales să-şi implementeze propria serializare, atunci formatul este dependent doar de dezvoltator. Clasele de obiecte care pot fi serializate trebuie să implementeze interfaţa nou introdusă java.io.Serializable.

API-ul de reflexie

API-urile de serializare precum şi JavaBeans cer să existe o posibilitate de a investiga membrii unei clase (constructori, metode, variabile) în momentul execuţiei. Desigur, aceste operaţii trebuie să se găsească sub restricţii de securitate severe pentru a împiedica deconspirarea informaţiilor private din interiorul claselor şi instanţelor acestora. În cazul unui aplet nevalidat, accesul se poate face doar la membrii publici în timp ce un aplet validat şi clasele sistem au drepturi sporite.

API-ul permite investigarea pornind de la o declaraţie de clasă sau de la o instanţă pe baza clasei acesteia din momentul execuţiei. În plus, API-ul de reflexie poate fi utilizat şi pentru a modifica membrii unei clase şi pentru a accesa şi eventual modifica tablouri de elemente.

API-ul defineşte trei noi clase în pachetul java.lang.reflect pentru accesul membrilor unei clase numite Constructor, Method şi Field plus o a patra clasă utilizată pentru accesarea tablourilor numită Array. În plus, API-ul adaugă funcţionalitate la clasa java.lang.Class.

JavaBeans

Componentele software reprezintă una dintre cele mai interesante descoperiri din ultimul timp în materia de tehnologie de dezvoltare a aplicaţiilor. După această metodologie, se pot dezvolta componente prefabricate din care programatorii pot dezvolta produse complete doar punându-le una lângă cealaltă şi făcâdu-le să comunice între ele. Programarea cu componente software tinde să se asemene cu un joc Lego care ne permite construcţia unor modele complet diferite pornind de la aceleaşi componente. Numai că aceste componente nu mai sunt de mult privite ca un joc. Există pe piaţă la ora actuală firme care trăiesc (foarte bine) numai din construcţia şi vânzarea de componente software.

Pentru a dezvolta componente software este nevoie de specificaţii care să fie respectate atât de cei care produc componentele precum şi de cei care utilizezază componentele în mod direct sau prin intermediul unui mediul de dezvoltare vizuală. Istoria componentelor software nu este mai lungă de patru cinci ani şi include specificaţii precum VBX, OCX, ActiveX de la Microsoft, CORBA/IIOP, OpenDoc/Live Objects şi, mai nou, JavaBeans în cadrul JDK 1.1.

JavaBeans este deci o specificaţie de construcţie a componentelor software, împreună cu un set de clase care să faciliteze inspectarea şi punerea în execuţie a acestor componente. Împreună cu Beans Development Kit, inclus şi în JDK 1.1, JavaSoft s-a grăbit să lanseze şi JavaBeans-ActiveX bridge un produs care permite rularea unui componente JavaBeans în orice context în care se poate folosi o componentă ActiveX.

JavaBeans este o specificaţie complexă despre care vom avea cu siguranţă ocazia să mai vorbim. Până atunci, să spunem doar că JavaBeans a fost foarte rapid adoptat de majoritatea mediilor de dezvoltare vizuală care există pe piaţă, începând desigur cu Symantec Visual Café şi terminând cu viitorul JBuilder anunţat de Borland.

API-ul pentru SQL (JDBC)

JDBC este un API pentru execuţia instrucţiunilor SQL. JDBC este o colecţie de clase şi interfeţe dezvoltate complet în Java care fac posibilă scrierea aplicaţiilor care lucrează cu baze de date direct în Java. Ideea de bază a JDBC este aceea de a putea păstra independenţa de platformă a programelor Java chiar şi când acestea accesează baze de date. Cu JDBC este posibil să se scrie o aplicaţie care execută instrucţiuni SQL fără să fie nevoie să cunoşti dinainte dacă aceste instrucţiuni vor rula pe un server Oracle, Sybase sau Microsoft.

JDBC nu este un API foarte complex. Cu ajutorul lui, se pot face doar următoarele operaţii: se poate conecta o bază de date, se poate executa pe ea o instrucţiune SQL şi se pot prelucra rezultatele. Cu alte cuvinte, JDBC este doar un API de nivel jos, deasupra căruia se pot implementa API-uri de nivel înalt.

JDBC poate accesa direct o dază de date pe baza unui driver sau poate accesa o bază de date prin ODBC, folosind un bridge JDBC-ODBC. Desigur s-ar fi putut accesa direct driverele ODBC, dar în acest caz s-ar fi pierdut independenţa de platformă şi eficienţa datorită faptului că ODBC este în principal proiectat pentru C, deci folosind pointeri. JDBC interpune aplicaţie şi baza de date un nivel scris în Java care este portabil şi care este supus tuturor restricţiilor de sercuritate necesare. De altfel, noile produse din zona de baze de date de la Microsoft numite RDO, ADO şi OLE DB merg în aceeaşi direcţie.

În ceea ce priveşte standardul SQL folosit de JDBC, sunt de făcut câteva precizări: Este binecunoscut faptul că, deşi există un nucleu standard de funcţionalitate SQL în toate sistemele relaţionale, acestea au şi multe extensii care nu sunt conforme întotdeauna cu standardele SQL de ultimă oră. JDBC rezolvă această situaţie de fapt permiţând transmiterea instrucţiunilor SQL nestandard. Desigur, aplicaţiile trebuie să fie pregătite să primească în locul rezultatelor un cod de eroare.

Interfaţa nativă Java

Această interfaţă este proiectată pentru a oferi o cale comună de scriere a metodelor native Java precum şi o cale de a apela maşina virtuală din aplicaţii scrise în cod nativ. Principalul scop al acestei interfeţe este acela de a oferi compatibilitate bibliotecilor de funcţii native între maşinile virtuale Java rulând pe acelaşi tip de platformă. Cu alte cuvinte, aceeaşi bibliotecă să poată fi folosită şi sub maşina virtuală Sun pentru Win32 şi sub maşina virtuală implementată de Microsoft pentru acelaşi Win32 sau sub maşina virtuală implementată în Asymetrix SuperCede Java Edition.

Clase interioare

Clasele interioare sunt clase care se pot defini în interiorul unor alte clase, în interiorul unui bloc de instrucţiuni sau chiar într-o expresie (caz în care sunt anonime). Până la apariţia acestei specificaţii, în Java clasele puteau definite doar la nivelul cel mai de sus al sursei, în interiorul unor pachete.

Concluzii

JDK 1.1 aduce cu siguranţă un nou suflu în lumea dezvoltatorilor de Java şi este de aşteptat ca cele mai importante firme să îmbrăţişeze în curând noua versiune. În ceea ce priveşte JavaSoft, această firmă şi-a portat deja toate produsele pe noua platformă, incluzând aici Serverul Web Java (Jeeves) şi navigatorul HotJava care este deja în final beta şi va fi lansat oficial la sfârşitul lunii Martie.

Java Development Kit 1.1