Metoda Oracle Jrockit

CUPRINS

CAPITOLUL I : NOȚIUNI INTRODUCTIVE.

1.1 Motivație

1.2 Obiectivele lucrării

1.3 Structura lucrării

CAPITOLUL II: TEHNOLOGII JAVA ACTUALE

2.1 Tendinte actuale

2.2 Prezentarea tehnologiilor

2.3 Comparatie intre tehnologii

CAPITOLUL III: TEHNOLOGIA JRockit

CAPITOLUL IV : PREZENTAREA APLICAȚIEI

Mediul de lucru

Prezentare structural a aplicatiei

Prezentare functionala a aplicatiei

CAPITOLUL V : CONCLUZII

BIBLIOGRAFIE

CAPITOLUL I : NOȚIUNI INTRODUCTIVE

1.1 Motivație

Scriu această lucrare ca finalizare a celor 3 ani de studiu aprofundat al informaticii și prin aceasta vreau ofer departamentului de Informatică un studiu mai îndeaproape a metodei Oracle JRockit.

1.2 Obiectivele lucrării

Această lucrare își propune să ofere o incursiune în domeniul dezvoltării aplicațiilor pentru dispozitivele mobile. În capitolele ce urmează este prezentată metoda Oracle JRockit și ce presupune folosirea ei în dezvoltarea aplicațiilor.

Se vor prezenta caracteristicile metodei Oracle JRockit, cum a luat naștere, ce presupune utilizarea ei, ce fel de aplicații se pot dezvolta folosind această metodă și mai ales pentru ce tipuri de dispozitive se poate folosi.

De asemenea va fi prezentată structura metodei Oracle JRockit și desigur competențele acesteia. Se vor discuta și despre avantaje și dezavantaje, precum si despre cerințe ale acesteia.

La final va fi prezentată o aplicație folosind această metodă, pentru a demonstra funcționalitatea unei astfel de aplicații folosind o parte din funcțiile metodei Oracle JRockit.

1.3. Structura lucrării

Prezenta lucrare este structurată în 5 capitole, astfel :

– Capitlolu 1 – Noțiuni introductive, oferă o introducere în conceptele de Java JRockit și obiectivele urmărite pe parcursul lucrării.

– Capitolul 2 – Tehnologii JAVA actuale, sunt prezentate tendințele actuale, o prezentare a acestor tehnologii și o comparație între acestea.

– Capitolul 3 – Acest capitol prezinta JRockit JVM si JRockit Mission Control. Aici se explica cum se poate obtine software-ul si care este matricea de baza pentru diferite platform se evidentiaza lucrurile de care trebuie tinut cont atunci cand oscilam intre JVMs de la furnizori diferiti, si se explica schema versiunilor pentru JRockit JVM si JRockit Mission Control.

– Capitolul 4 – Prezentarea aplicației cu detalii de implementare, prezentarea mediului de lucru, resurse folosite și detalii de funcționare.

– Capitolul 5 – Concluzii legate de metoda Oracle JRockit, dezvoltarea de aplicații mobile, avantaje și limitări.

CAPITOLUL II: TEHNOLOGII JAVA ACTUALE

2.1. Tendințe actuale

Java este unul dintre cele mai utilizate limbaje de programare în zilele noastre, având niște avantaje de necontestat. Printre acestea se numară: securitate, independentă de platformă, limbaj intuitiv, bine structurat și open-source.

Următoarele tendințe impun caracteristicile noilor generații de aparate mobile:

– Utilizatorii sunt tot mai sofisticați, cerând aplicații cum ar fi jocurile, servicii informative, mesagerie, servicii de localizare și multe altele.

– Mărimea ecranelor este mai mare oferind o rezoluție mai mare si mai multe culori, permițând o grafică mult mai complexă cum ar fi 2D, 3D, animații și altele.

– Conectarea în rețea este mult mai rapidă, permițând descărcarea de aplicații mult mai mari și mult mai complexe.

– Firmele utilizează aplicații mobile muncitorilor care necesită securitate sporită și stabilitate platformelor care le stau la bază.

Dorința de a obține performanțe mai bune în mediile de implementare Java a condus firma Sun la dezvoltarea implementării mașinilor virtuale Java CLDC HotSpot, cu scopul de a obține:

– Performanțe mai rapide

– O platforma mult mai stabilă

– Timp mai rapid pe piață.

Implementarea CLDC HotSpot utilizează tehnici avansate de reglare și de performanță utilizate atât pe platformele Java 2 Standard Edition (J2SETM) cât și pe java 2 Enterprise Edition (J2EETM), și mai mult decât atât reduce amprenta pentru a se potrivi dispozitivelor mici. În plus implementarea CLDC HotSpot încorporează câteva inovații în design care permit mașinii virtuale să ruleze în dispozitive limitate în resurse, și îi permite să:

• Furnizeze performanțe de vârf.

• Furnizează timp scurt de pornire al aplicațiilor.

• Necesită amprentă minimă.

• Reduce eforturile de portare.

• Mărește viața bateriei.

2.2. Prezentarea tehnologiilor

Java reprezintă baza pentru aproape toate tipurile de aplicații în rețea și este standardul global pentru dezvoltarea și implementarea de aplicații mobile, jocuri, conținut pe web și software la nivel de companie. Cu peste 9 milioane de dezvoltatori la nivel mondial, Java vă permite să dezvoltați și să implementați eficient aplicații și servicii performante. Cu instrumente complexe, un ecosistem avansat și performanțe ridicate, Java asigură portabilitatea aplicațiilor chiar și în mediile de calcul cu o compatibilitate redusă.

Mai jos sunt prezentate tehnologiile Java:

Java Platform, Enterprise Edition (Java EE) reprezintă standardul în domeniu pentru calcul Java la nivel de companie. Cu funcții noi, optimizate pentru HTML5, productivitate sporită pentru dezvoltatori și îmbunătățiri suplimentare privind modul în care pot fi satisfăcute cerințele companiei, Java EE 7 permite dezvoltatorilor să scrie mai puțin cod reutilizabil, să dispună de asistență îmbunătățită pentru cele mai noi aplicații și cadre de lucru web și să poată beneficia de scalabilitate îmbunătățită și de funcții mai performante și mai simple.

Java Platform, Standard Edition (Java SE) este o soluție proiectată pentru a vă permite să dezvoltați aplicații sigure, portabile și extrem de performante, pentru cea mai extinsă gamă de platforme de calcul posibilă. Datorită disponibilității aplicațiilor în medii eterogene, companiile pot îmbunătăți productivitatea utilizatorilor finali, comunicarea și colaborarea și pot reduce semnificativ costul de deținere, atât pentru aplicațiile de întreprindere, cât și pentru cele destinate consumatorilor.

Java integrat.

Java Platform, Micro Edition (Java ME) este utilizată de un mare număr de dezvoltatori de telefoane mobile, operatori de telefonie mobilă și producători de echipamente originale pentru a crea diferite produse de telefonie peste tot în lume. Oracle este cel mai important furnizor de tehnologie pentru telefoane mobile, tehnologie utilizată până în prezent pentru peste trei miliarde de dispozitive.

Oracle Java Cloud Service asigură o platformă la nivel de companie pentru dezvoltarea și implementarea aplicațiilor de afaceri în mediul cloud. Asigură maximizarea productivității și acces instantaneu la medii cloud care acceptă orice aplicație Java EE standard, precum și securitate integrată și acces la bazele de date — toate acestea sunt asigurate de Oracle WebLogic Server.

2.3. Comparație cu alte tehnologii

J2EE și .NET sunt platformele viitorului. Ne propunem o privire comparativă asupra tehnologiilor Java și .Net, singurele alternative profesionale pentru dezvoltarea de aplicații în mediul de afaceri. Dupa succesul înregistrat de Java în ultimii zece ani, Microsoft a introdus pe piață .Net, o creație proprie și proprietară, care să concureze tehnologia Java. Evoluția ingineriei software în ultimii 7-8 ani a minimalizat utilizarea limbajelor 4GL, asa cum limbaje ca Smalltalk au fost înlocuite de Java, iar conceptul de „fat client” a fost înlocuit de o arhitectură multinivel. În compensație s-au impus diferite tehnologii web si XML (Extended Markup Language). Inițiative de tip middleware cum ar fi Distributed Computing Environment (DCE) sau Common Object Request Broker Architecture (CORBA) sunt înlocuite treptat cu infrastructuri tehnice de mare complexitate.

Astăzi au rămas în esență numai două platforme tehnologice pentru aplicații noi: Java 2 Enterprise Edition (J2EE) și Microsoft .NET. Pentru a lua o decizie corectă pentru viitor, utilizatorii trebuie să ia în considerare două criterii importante:

potențialul de dezvoltare și comprehensibilitate susținut de o anumită

platformă;

oferta de soluții proprii ale platformei, necesare pentru a se menține pe

piață.

Limbajul Java a cunoscut o dezvoltare deosebită în ultimii cinci – șapte ani, de la un „capriciu” al împătimiților pentru limbajele orientate obiect la o tehnologie larg răspândită. Această evoluție se datorează mai puțin farmecului limbajului și mai mult forței platformei tehnice asociate. Acum și Microsoft oferă o platformă tehnologică asemănătoare. Cei din Redmond au început cu Distributed InterNet Architecture (DNA), care avea însă multe defecte. Pe lângă problemele cu registrul și conflictele de la nivelul DLL-urilor, a apărut conceptul de model obiect componentă (COM), care a devenit prea complex din cauza suportului pentru diferite limbaje. De asemenea procesarea distribuită cu soluții DCOM pe baza conceptului Microsoft RPC și a registrului Windows nu s-a dovedit a fi compatibilă cu Internetul.

Începând cu .NET, Microsoft a realizat o importantă schimbare față de DNA, compania lui Bill Gates deschizând problema tehnologiei predecesoare. La momentul lansării .NET-ului, la capitolul arhitectură și funcționalitate .NET și J2EE erau foarte asemănătoare, dar Microsoft oferea o soluție tehnică mai modernă, prin implementarea tehnologiilor web și a limbajului XML. De asemenea, noul limbaj C# si mașina virtuală (CLR) sunt idei provenite din Java. Există și alte diferențe de importanță strategică:

J2EE nu este un produs, ci o specificație, pentru care diferite companii oferă produse. Aplicațiile sunt independente de proprietarul suportului middleware. Astfel, companiile obțin nu numai o independență față de un anumit furnizor, dar pot să-și dezvolte propriile platforme tehnologice.

.NET este o colecție de produse ale unui singur producător și rulează numai împreună cu Windows. Se asigură integrarea diferitelor componente și utilizarea unor caracteristici speciale ale sistemului de operare Windows.

J2EE este independent de conceptul de sistem de operare. Portabilitatea este asigurată de Java Runtime Environment, iar serverul de aplicații și alte produse middleware pot fi programate in funcție de sistemul de operare.

Pe lângă aceste aspecte, mai există și alte criterii importante în luarea unei decizii în privința acestor două tehnologii, cum ar fi nivelul de comprehensibilitate si dezvoltare, ceea ce analiștii de la Gartner numesc „completeness of vision”. Avantajul J2EE constă în existența interfețelor API (Application Programming Interface), care creează o independență tehnologică a aplicațiilor.

Aceasta facilitează dezvoltarea ulterioară a tehnologiei cu efecte secundare reduse. Modelul componentelor Java este mai metodic și mai elaborat, iar arhitectura bazată pe conectori oferă baza pentru o mai mare interoperabilitate decit facilitatile corespondente în tehnologia .Net.

Prin dezvoltarea propriei mașini virtuale Microsoft rezolvă problemele datorate interpretorului din Java. Multe functionalități ale sistemului de operare Windows pot fi utilizate direct, cum ar fi serverul web IIS, Active Directory, OLEDB și Windows Load Balancing. Cuplarea eficientă cu sistemul de operare este cauza performanțelor îmbunătățite ale aplicațiilor .NET, comparativ cu cele ale aplicațiilor J2EE, deși este dificil de estimat obiectivitatea testelor respective. Totuși performanțele pot varia, astfel performanțele mașinii virtuale Java pe același suport hardware variază cu un factor egal cu trei, iar această variație e chiar mai mare pentru serverele de aplicații Java. Experiența arată ca produsele software complexe au nevoie de ani de zile pentru a fi dezvoltate. Asta se întâmplă cu bazele de date, cu aplicațiile de monitorizare a tranzacțiilor sau cu aplicațiile Java, ceea ce face ca dezvoltarea unui nou produs construit pe un nucleu de componente mai vechi să nu constituie un dezavantaj. Produsele J2EE au căpătat în timp un grad ac această variație e chiar mai mare pentru serverele de aplicații Java. Experiența arată ca produsele software complexe au nevoie de ani de zile pentru a fi dezvoltate. Asta se întâmplă cu bazele de date, cu aplicațiile de monitorizare a tranzacțiilor sau cu aplicațiile Java, ceea ce face ca dezvoltarea unui nou produs construit pe un nucleu de componente mai vechi să nu constituie un dezavantaj. Produsele J2EE au căpătat în timp un grad acceptabil de maturizare. Pentru .NET experiența practicilor în dezvoltarea aplicațiilor proprii a demonstrat un grad mare de performanță. Este încă foarte greu să se facă o comparație. Dincolo de criteriile de performanță, managerii IT trebuie să țină cont de eficiența platformei și de productivitatea furnizată în dezvoltarea aplicațiilor. Dacă se măsoară productivitatea numai pe baza „numărului de linii de cod”, .NET prezintă avantaje clare în fața J2EE. Crucial este însă cât dintre aceste linii de cod trebuie să fie scrise la mână. Aici intervine atât procesul automatizat de dezvoltare cât și inteligența mediului de dezvoltare software. În Java există diferențe semnificative între uneltele de dezvoltare, care sunt subliniate de furnizori în campaniile lor de marketing. IDE-urile (Integrated Development Environment) pornind de la Jbuilder, Forte și ajungând până la noul Eclipse 3.x oferta suport optimal pentru dezvoltare, debug și versionare de proiecte oricât de complexe, lasând totusi programatorului întregul control și transparență perfectă față de codul Java rezultat. Uneltele „Visual Studio .NET” de la Microsoft pot fi comparate cu cele mai eficiente medii de dezvoltare din Java.

AVANTAJE

Java este o platforma independentă, ea rulează pe majoritatea platformelor și sistemelor de operare importante, fie cu software JVM direct de la Oracle, prin intermediul unuia dintre numeroșii parteneri din ecosistemul Java, fie ca parte a comunității OpenJDK.

Java are niște performanțe excelente, HotSpot și JRockit sunt exemple de tehnologii de mașini virtuale just-in-time care fac ca Java să fie unul dintre cele mai rapide medii de programare.

Optimizările integrate pentru medii multi-fir îi conferă chiar și mai multă rapiditate.

Java este limbajul de programare preferat de universități și instituții de învățământ din întreaga lume. Modelul Java de gestionare a memoriei, utilizare în medii multi-fir și tratare a excepțiilor îl transformă într-un limbaj puternic, atât pentru dezvoltatorii începători, cât și pentru cei experimentați.

Java este un limbaj bazat pe standarde, limbajul Java și tehnologiile conexe evoluează prin Java Community Process, un mecanism pentru dezvoltarea specificațiilor tehnice pentru tehnologia Java.

Java are medii de execuție consecvente, Java vă permite o implementare fiabilă, cu o gamă largă de medii de execuție, de la Java SE pentru desktop, la Java SE pentru dispozitive integrate și Oracle Java Micro Edition Embedded Client.

Limbajul Java este optimizat pentru integrare, Java SE pentru dispozitive integrate satisface cerințe cheie, cum ar fi procesor integrat, gestionarea alimentării, impactul redus asupra mediului și altele.

Oracle Java ME Embedded Client se bazează pe tehnologia Connected Device Configuration (CDC), inclusă în platforma Java SE și permite obținerea unor performanțe îmbunătățite pentru dispozitivele cu resurse limitate.

Java atinge performanțe maxime, asigurând simultan portabilitatea pe o gamă largă de procesoare și sisteme de operare integrate(performanțe de excepție, aplicații portabile).

Un model de securitate testat, acest limbaj oferă un mediu de aplicații avansat și extrem de sigur, ideal pentru aplicațiile în rețea.

Java EE 6 este combinația perfectă dintre profilul web suplu, care permite dezvoltarea unor aplicații web extrem de avansate și puterea absolută a platformei Java EE 6 pentru aplicații de întreprindere.

Dezvoltatorii beneficiază de mai multe adnotări și elemente POJO, pachete simplificate de soluții și configurare XML redusă.

Tehnologia implementată în realizarea unei aplicații trebuie aleasă având în vedere obiectivul droit.

Pentru interfețe :Silverlight, Flash sau Ajax

pentru animații complexe se folosește Flash

pentru putere industrială se folosește Java

CAPITOLUL III: TEHNOLOGIA JROCKIT

Acest capitol prezintă JRockit JVM și JRockit Mission Control. Aici se explică cum se poate obține software-ul și care este matricea de bază pentru diferite platform se evidențiază lucrurile de care trebuie ținut cont atunci când oscilăm între JVMs de la furnizori diferiți, și se explică schema versiunilor pentru JRockit JVM și JRockit Mission Control. Tot aici va fi prezentată generarea codurilor într-o rulare adaptativă. Voi explica de ce generarea codurilor adaptative este mai greu de realizat într-un JVM decât într-un mediu static, dar și de ce poate fi mult mai puterinca în mod potențial. Conceptul de „a paria” pe performanță este de asemenea prezentat. Voi examina generarea codurilor JRockit și optimizarea transmiterii, printr-un exemplu concret. Optimizarea codurilor adaptative și clasice sunt dezbătute, în finalul capitolului, introducând diferite dispozitive și documente directive care pot fi utilizate pentru a controla generarea codurilor în JRockit. . Voi dezbate managementul memoriei într-o rulare adaptativă. Voi explica cum funcționează metodă de eliberare a memoriei, din punct de vedere al conceptului de management automat al memoriei și al algoritmilor specifici. Sunt prezentate anumite detalii despre repartizarea obiectivelor într-un JVM, și metainformatii despre metodă de eliberare a memoriei și modul în care rulează. Finalul acestei părți este dedicat celor mai importante interfețe pentru programarea de aplicații JAVA pentru manangementul controlului memoriei.

De asemenea, voi prezenta produsul JRockit Time, care poate produce latente determinante într-o aplicație Java. În ultima parte sunt prezentate dispozitivele pentru controlarea sistemul de management al memoriei JRockit JVM.

Thread-urile și sincronizarea sunt două unități importante în Java și într-un JVM. Vom explica cum aceste două concepte funcționează în limbajul Java și cum sunt implementate în JVM, dar vom vorbi și despre nevoia existenței unui Java Memory Model și despre complexistatea intrinsecă pe care o aduce cu șine. Optimizarea adaptativă bazată pe rularea feedback este prezentată și aici, dar și în alte arii ale JVM. Câteva importante anti-tipare precum double-checked locking sunt introduse, alături de câteva dintre capacanele comune din programarea paralelă. În final vom dezbate blocarea profilării în JRockit și vom introduce dispozitivele care controlează sistemul de thread-uri. Voi discuta despre relevanță benchmarking-ului și importantă obiectivelor performanței și a măsurării. Voi explica cum se poate creă un benchmark potrivit pentru un anumit set de probleme. Voi prezența câteva benchmark-uri industriale pentru Java, iar la sfârșitul capitolului, vom discuta în detaliu modificarea comportamentului aplicației și a JVM bazate pe feedback-ul benchmarking-ului. Sunt prezentate aici și exemple ample de dispozitive command-line pentru JRockit JVM. Tot aici este prezentat setul de unelte JRockit Mission Control. Sunt prezentate detalii despre pornirea și configurarea anumitor setări, de asemenea explicând administrarea JRockit Mission Control în Eclipse, alături de câteva sfaruri pentru setarea JRockit pentru a administră Eclipse de unul singur. Sunt prevăzute numeroase căi de a permite accesul de la distanță a JRockit Mission Control la o administrare a JRockit, împreună cu diferite sfaturi în cazul unor troubleshooting-uri. Centrul de operatie BEA JRockit este un set de instrumente puternice oferite prin JRockit BEA 5.0 R26 JDK. Aceste instrumente ofera planuri avansate si discrete de monitorizare si management JVM, potrivite pentru utilizare atât în mediile de dezvoltare cat și in cele de producție.

Acest capitol prezintă o introducere la centrul de operatie JRockit, descriind principalele componente ale suitei, diferentele dintre componentele suitei si tehnologiile concurente, și cum le puteți folosi pentru va gestiona implementările JRockit JVM.

Obținerea JRockit JVM

Pentru a înțelege pe deplin această lucrare de licență se necesită cea mai nouă versiune a JRockit JVM. Pentru versiunile JRockit anterioare lui R27.5, era necesară o cheie de licență pentru a accesa unele dintre cele mai avansate caracteristici ale JRockit. Ca parte a achiziției Oracle a BEA Systems, sistemul de licență a fost înlăturat iar acum este posibilă accesare tuturor caracteristicilor JRockit fără folosirea cheii de licență, ceea ce face mai facilă evaluarea și folosirea programului în dezvoltare. Pentru a utiliza JRockit în producție, va fi necesară totuși cumpărarea unei licențe. Pentru clienții Oracle această este o problemă foarte rară deoarece JRockit este inclus în majoritatea seturilor de aplicații, de exemplu, orice set care conține WebLogic Server va include de asemenea JRockit.

În acest moment cel mai ușor mod de obținere a JRockit JVM este cel de descărcare și instalare JRockit Mission Control a setului de ustensile de diagnostic și profilare pentru JRockit. Schema folderului de distribuție Mission Control este aproape identică cu cea a oricărui JDK și poate fi folosită cu ușurință ca un JDK. Autoriilor le-ar plăcea să poată furniza un JVM independent de JDK pentru JRockit, dar acest idee se află deocamdată numai la nivel de propunere, sperandu-se că pe viitor să se poată concretiza.

Înainte că JRockit Mission Control este descărcat, fiți sigur că folosiți o platformă potrivită. Partea de server a Mission Control este tolerată pe toate platformele pe care JRockit este permis.

Următoarea schema este matricea platformei pentru JRockit Mission control 3.1 x:

Următoarea schemă este matricea platformei pentru JRockit Mission Control 4.0.0:

Trebuie observat că JRockit Mission Control nu este încă admis (încă) pe Solaris, dar că baza Windows-ului de 64-bit a fost adăugată în 4.0.0.

Cea mai ușoară metodă de a ajunge la home page-ul JRockit este de a accesa motorul de căutare preferat și să a tastă „descarcare JRockit”. Ar trebui să ajungeți pe o pagină a Oracle Technology Network de unde pot fi decarcate JVM și setul Mission Control. Procesul de instalare variază între platforme, însă ar trebui să fie destul de clar.

Migrarea către JRockit

Pe parcursul acestei lucrări de licență ne vom referi la folderul în care JRockit JVM este instalat drept că JROCKIT_HOME. Poate simplifica lucrurile făcând JROCKIT_HOME un sistem varabil țintind spre o traiectorie anume. După ce instalarea este gata, este o idee bună să puneți bin folderul JROCKIT_HOME pe acea traiectorie și să actualizați scriptul oricărei aplicații Java care poate migra catr JRockit. Configurarea variabilei de mediu a JAVA_HOME la JROCKIT_Home este recomandată. În majoritatea privințelor JRockit este cauza scăderii bruște în înlocuirea altor JVM-uri, dar anumite argumente de startup, spre exemplu argumentele care controlează comportamentul eliberării memoriei, în mod obișnuit diferă între JVM-urile anumitor furnizori. Însă argumente comune precum argumentele configurării unui heap de mărime maximă, tinde să fie standardizat într JVM-uri.

Opțiunile liniilor de comandă

Sunt trei tipuri principale de linii de comandă la JRockit a€“ proprietățile sistemului, opțiunile standardizate (-Xflags) și unele nestandardizate (-XXflags).

Proprietățile sisemului

Argumentele de pornire ale unui JVM vin în diferite moduri, argumente începând cu „a”. Dar e interpretat ca un folder pentru setare unei proprietăți de sistem . Astfel de proprietăți de sistem pot furniza setări de configurări pentru variate părți ale claselor Java, spre exemplu RMI. JRockit Mission asigură informații despre debugging dacă începeți cu com.jrockit.mc.debug=true. În versiunile JRockit anterioare R28, utilizarea proprietăților sitemului furniza parametrii la care JVM a fost depreciate. În schimb, majoritatea opțiunilor JVM sunt asigurate prin opțiuni non-standardizate și prin noul Hot Spot style VM flags.

Opțiuni standardizare

Configurarea setărilor pentru JVM încep în mod tipic cu X pentru setările care sunt suportate în mod comun printre furnizori. Spre exemplu, opțiunea pentru a seta mărimea maximă a heap-ului, -Xmx, este la fel în majoritatea JVM-urilor, inclusiv JRockit. Însă sunt și câteva excepții, dispozitivul JRockit a€“ Xverbose furnizează logarea cu sub module opționale. Dispozitivul similar, însă mai limitat dn HotSpot este denumit averbose.

Opțiuni non-standardizate

Opțiunilor de configurare specifice furnizorulor sunt de obicei prefixate cu a€“XX. Aceste opțiuni ar trebui tratate că potențial nesuportate și predispuse la schimbări fără a notifica asta. Dacă oricare configurare JVM depinde de un a€“XX a€“ opțiune prefixată, aceste dispozitive ar trebui îndepărtate sau portate înainte că o aplicație este pornită pe un JVM de către un alt furnizor.

Odată ce opțiunile JVM au fost determinate, aplicația utilizatorului poate fi pornită. De obicei, mutând o aplicație existența în JRockit conduce către o creștere în performanță rulării și o ușoară creștere în consumul memoriei.

Documentele JVM ar trebui să fie intodeauna consultate pentru a determină dacă opțiunile liniilor de comandă non-standardizate au aceleași sens între diferiți JVM și versiuni JVM.

Dispozitive VM

În versiunile JRockit succedate de R28, este de asemenea un subset de opțiuni non-standardizate numite dispozitive VM. Dispozitivele VM foloses sintaxa -XX:<flag>=<value> . Aceste dispositive pot fi citite de asemenea și, în funcite de dispozitivul în șine, scrierea utilizând linia de comandă JRCMD după JVM a fost pornită.

Schimbări în comportament

Uneori de regăsesc anumite schimbări în comportamentul de rulare atunci când ne mutăm de la un JVM la un altul. De obicei se ajunge la diferite interpretări ale JVM în specificațiile limbajului Java sau în cele ale Java Virtual Machine, interpretări diferite, însă corecte. În mai multe cazuri există o variabilă în specificații care permite intodeauna furnizorilor să implementeze funcționalitatea în cel mai bun mod în care poate îngloba arhitectura furnizorului. Dacă o aplicație se bazează prea mult pe o anumită implementare a specificațiilor, atunci în mod sigur aplicația va da greș atunci când va comuta la o altă implementare.

De exemplu, în timpul testului milestone pentru o versiune mai veche a Eclipse, unele dintre țeste au început să dea greș atunci când au rulat pe JRockit. Aceasta a fost din cauza interdependențelor testelor, iar acest set particular de țeste se bazau exact pe acestea pentru a produce rularea testelor într-o anumită ordine. Implementarea JRockit a listării reflective de metode (Class#getDeclaredMethods) nu a restuit metodele în aceiași ordine că alte JVM-uri, ceea ce potrivit specificațiilor este în regulă. Mai târziu a fost decis de către echipă de dezvoltare a Eclipse că bazarea pe o metodă anume de ordonare era un bug, iar testele au fost modificate.

Dacă o aplicație nu a fost scrisă din punct de vedere al specificațiilor, ci mai degrabă al comportamentului JVM de la un anumit funizor, poate eșua. Poate chiar eșua chiar atunci când rulează cu o versiune mai nouă a JVM de la același furnizor. Când sunteți în dubiu, consulatati specificațiile limgajului Java și documentația pentru JDK.

Diferențele în performanță pot fi de asemenea o problemă atunci când comutăm JVM-urile pentru o aplicație. Bug-urile latente care nu au fost problematice la un JVM pot fi la fel de bine extreme de problematice cu un altul. Drept exemplu, diferențele în performanță cauzează evenimentele să se desfășoare înaintea timpului prevăzut sau mai târziu. Aceste lucruri tind să genereze probleme în support însă se întâmplă în mod izolat din cauza JVM-ului.

De exemplu, un client a raportat că JRockit a clacat după numai o zi. Investigațiile au concluzionat că aplicațiile au clacat de asemenea cu un JVM al altui furnizor, însă a durat mai multe zile înainte că acestea să clacheze că un întreg. De asemenea, s-a aflat că această clacare a programelor s-a produs mai rapid în JRockit și că problemă, o scurgere de memorie a ieșit la lumina mult mai repede decât era prevăzut.

În mod natural orice JVM, JRockit inclus, poate avea bug-uri. Pentru a primi accesul sub umbrella Java, o implementare Java Virtual Machine trebuie să treacă un set de țeste extensive, the Java Compatibility Kit (JCK).

JRockit este în continuare supus la o mulțime de țeste utilizând o test de system distribuit. Seturi de țeste, în care JCK este una dintre component, sunt rulate pentru a asigură că JRockit poate fi lansat că stabil, compatibil Java și certificate JVM.

Seturile de țeste din variate de produse de înalt profil, precum Eclipse sau WebLogic Server, dar și teste de stradă proiectate în mod special sunt rulate pe toate platformele compativile înainte că o lansare poate lua loc. Continuă testare în ciuda regresiunilor de performanță sunt de asemenea o parte fundamental a infrastructurii QA. Astfel, bug-urile au loc. Dacă JRockit clachează, ar trebui raportat către inginerii de suport Oracle.

Unde să optimizezi?

Programatorii tind să optimizeze programele Java prematur, ceea ce este complet de neînțeles. JVM-ul bazei aplicației nu poate să facă ceva în mod optim cu un nivel atât de ridicat precum cel al codului sursei Java Bineînțeles că această este parțial posibil, dar chiar și în acest mod JVM-ul nu poate înțelege în totalitate ceea ce programul face, acesta lucrează cu ceea ce are la dispoziție.

Este surprinzător cât de repede poate un program rula după o optimizare adaptivă automată, doar pentru că JVM-ul este bun la detectarea tiparelor într-un mediu de rulare mult mai larg decât cel al unui om. Pe cealaltă parte, unele dispozitive rulează mai bine după o optimizare manuală.

Acest lucru nu înseamnă că toate optimizările codurilor ar trebui lăsate în seama JVM-ului, însă așa cum am specificat mai sus, optimizarea explicită la nivel de bytecode este un lucru ce ar trebui evitat.

Este o mulțime de oportunități pentru scrierea eficientă în Java și situații când o rulare adaptativă nu poare fi de ajutor. De exemplu, un JVM nu va putea niciodată transforma un algoritm pătratic într-unul liniar, înlocuind BubbleSort-ul cu un QuickSort. Un JVM nu va putea niciodată să-și inventeze propriul cache atunci când ar fi trebuit să aibă unul făcut în mod manual. Aceste cazuri contează în limbajul Java. JVM-ul nu poate face minuni, optimizarea adaptativă nu va putea niciodată să substituie algoritmii greșiți cu unii corecți. Cel mult îi va face pe cei greșiți să ruleze mai redepe ca de obicei.

Cu toate aceste, un JVM poate lucra cu multe construcții în codul standard object-oriented. Programatorul va avea de câștigat foarte puțin prin evitarea declarației unei variabile extra sau prin copierea și lipirea a câmpurilor de sarcini în loc de a apela un reproducător sau dezvoltator. Acestea sunt exemple de micro-optimizări care fac codul Java mai greu de citit și care nu ajută codul compilat JIT să execute mai repede.

Este totul mult prea ușor pentru a confunda ceea ce măsori atunci când ai drept comparație o performanță bottleneck. Nu orice problemă poate fi spartă în benchmark-uri așa cum nu orice benchmark nu reflectă în mod precis problema examinată. Partea a doua a acestei lucrări va acoperi diferite componente ale setului JRockit Mission Control, care este un set ideal pentru analiză performanței.

Urmarea codului JRockit

Având în minte idea că întreaga compilare JIT a încetat cu folosirea bytecode-ului, trecând la altă formă mai ușor de procesat, cu toții ne întrebăm ce urmează. În mod obișnuit, codul trece prin mai multe niveluri de transformare și optimizare, cu fiecare nivel devening din ce în ce mai dependent de platform. Nivelul final al unui cod este codul native pentru o anumită platformă. Codul native este emis într-un buffer de coduri și este executat în momentul în care funcția pe care o reprezintă rulează.

Într-o manieră logică, este necesar să păstrezi compilarea JIT portabilă pe cât de mult posibil. Deci, majoritatea optimizărilor sunt de obicei executate atunci când codul intermediar este încă independent de platform. Astfel este mult mai ușor să portezi compilarea JIT la diferite construcții.

Cu toate acestea, la nivel minim, optimizarea specifică platformei trebuie să fie în mod obligatoriu implementate pentru a obține performanță la nivel industrial. Această secțiune descrie cum compilarea JIT trece de la bytecode la codul native și stagiile străbătute. Ne vom concentra pe compiarea JRockit JIT, dar la nivel general procesul de generare al codurilor native este similar între JVM-uri.

De ce JRockit nu are cititor de bytecode?

JRockit folosește strategia de generare a compilării JIT.

Când proiectul JRockit a demarat în 1998, dezvoltatorii JVM au remarcat că în partea a server-side-ului Java era o nișă până atunci neexploatata, iar JRockit era original creeat pentru a fi un server-side JVM. Majoritatea aplicațiilor server-side, deși a fost dezbătută această idee, pot rulă pentru mult timp și poate dură ceva pentru a ajunge într-un stadiu stabil. Astfel, pentru un server-side funcțional doar JVM, s-a ajuns la concluzia că timpul de generare a codurilor era o mai mică problemă decât eficiența execuției.

Această ne-a salvat de la a ne pierde timpul în a implementa atat o compilare JIT și un cititor bytecode, cât și manevrarea tranzițiilor dintre ele.

S-a observat repede că o compilare a fiecărei metode contribuie la adăugarea unui timp adițional de pornire. Această nu a fost considerate drept o problemă majoră intial. Aplicațiile server-side, odată pornite și rulate, pot rulă pentru un timp îndelungat.

Mai târziu, odată cu devenirea JRockit drept un JVM la modă, cunoscut pentru performanțele sale, nevoia de diversificare a codurilor viitoare în părțile destinate clienților și a serverelor s-a făcut cunoscută. Și totuși nu a fost adăugat niciun alt cititor. Cu atât mai mult, JIT a fost modificat pentru a diferenția mai apoi codurile cale și reci, permițând o mai rapidă generare a codurilor atunci când această metodă a fost pentru prima dată folosită. Aceasta a dus la o îmbunătățire simțitoare a timpului de pornire, dar bineînțeles, nu putea atinge viteza unui cititor cu o abordare de compilare. Un alt aspect care ne ușurează muncă la un cititor este debuggability.

Bytecode-ul conține meta-informații despre variabile de nume sau numere de linie. Acestea sunt lucruri necesare unui debugger. Pentru a susține această debuggability, JRockit-ul JIT a trebuit să propage această informație de la bază per-bytecode-ului până la baza instructivă a per-nativului.

Dintre opțiunile noastre, JRockit este singul mecanism virtual care permite utilizatorului să folosească debug pe un cod optimizat.

Problemele majore ale strategiei bazate doar pe compilare în JRockit sunt extinderea codurilor (rezolvată de către dispozitivele de eliberare de memorie cu metode care nu mai sunt la momentul actual folosite) și timpul de compilare pentru metode mari (rezolvat prin posesia unui mod “sloppy” pentru JIT)

Bootstrapping

“Creierul” JRockit JVM este timpul de rulare în șine. Acesta observă ceea ce se întâmplă în jurul sau în timp ce include execuția mediului virtual. Sistemul de rulare știe întotdeauna care clase și metode Java fac parte din acel sistem și necesită generarea de coduri să le compileze la timpul necesar și la niveluri și coduri calitative.

Pentru a simplifica lucurile, primul lucru pe care rularea dorește să îl demareze atunci când JVM-ul este pornit, este să pună în mișcare metodă principală (main) a respectivului program Java. Această este realizată printr-un impuls standard al JNI către JVM-ul nativă, la fel precum către oricare aplicație nativă care ar folosi JNI să ajungă la codul Java.

Pentru a ajunge la metodă principală (main) se declanșează un mecanism complex de acțiuni și interdependente. O mulțime de alte metode Java necesare pentru bootstrapping și pentru comportamentul fundamental JVM trebuie să fie generat mai întâi pentru a rezolvă funcția de bază (main). Iar când în final această este gata și compilată de un cod nativ, JVM-ul poate execută prima parte dintr-un native Java și poate comută controlul de la JVM la programul Java.

Timpul de rulare a generării codurilor

Compilarea totală a JIT este un process încet. Dacă orice altă metodă sau clasă ar putea sezisa o altă metodă întreg generată într-un anumit timp de referință, atunci atunci ar fi o întreagă generare a codurilor peste măsură. De asemenea, doar pentru că o clasă face sesizare la un cod nu înseamnă că toate metodele din respective clasă trebuie compilate pe loc sau chiar că orice alte metode vor fi executate. Controlarea decursului programului.Java poate lua o altă traiectorie.

Această problemă nu există, în mod evident, într-un mod mixt de soluții, în care totul pornește că un bytecode interpretat că neavând nevoie de o executare a compilării.

Trampoline

JRockit rezolvă această problemă prin generarea unei părți a codului pentru metode noi, dar încă negenerate. Aceste părți sunt numite trampolines, și sunt formate, în general din linii de coduri native ce pretind că sunt versiunea finală a metodei. Când metoda primește impulsul pentru prima data, iar controlul comută la un trampoline, tot ceea ce face este să execute un impuls care să transmită JRockit-ului că metodă reală trebuie să fie generate.

Generatorul codului îndeplinește cererea și înapoiază adresa de pornire a metodei reale, către care trampoline-ul va expedia controlul. Pentru utilizator va părea că metoda Java a fost apelată în mod direct, dar de fapt aceasta a fost generată de prima data de când impulsul a fost trimis.

0x3000: method C

call method B @ 0x2000

0x4000: The "real" method B

…

0x1000: method A

call method B @ 0x2000

0x2000: method B (trampoline) call JVM.Generate(B) ->

start write trap @ 0x2000

goto start @ 0x4000

Având în vedere exemplul anterior, method A, al cărei cod generat trimite la adresa 0x1000 execută un apel către method B, despre care se crede că este plasată la adresa 0x2000. Această este primul apel către metodă Mever. Prin urmare, tot ceea ce este la adresă 0x2000 este un trampoline.

Primul lucru pe care îl execută un trampoline este să emită un impuls native către JVM, transmițându-i să genereze adevatata method B. Execuția se va opri mai apoi pentru că cererea de generare a codului este îndeplinită, și o adresă de start pentru method B este primită, de exemplu 0x4000. Trampoline-ul va expedia mai apoi controlul către method B prin comutarea la acea adresă.

A se observa că pot există deja apeluri către codul method B, indicând către adresă trampoline 0x2000. Să luăm, de exemplu, apelul către method C, care nu a fost încă executat. Aceste apeluri trebuie actualizate, fără că method B să fie regenerate. JRockit rezolvă această prin scrierea unei instrucțiuni ilegale către adresă 0x2000, atunci când trampoline-ul este în rulare. În acest mod sistemul va bloca apelurile, în caz că sunt mai multe de unul. JVM-ul are un sistem special pentru controlarea acestor apeluri, dar și alte mici părți, patch-uri, pentru a trimite impulsuri care trampoline astfel încât să indice către metoda reală. În acest caz înseamnă că apelul este suprascris la 0x2000 în method C cu un apel în 0x4000. Acest process se numește back patching.

Cererile de generări de coduri

În JRockit, cererile de generări de coduri sunt trimise către generatorul de coduri încă din timpul de rulare al unei metode care trebuie complicate. Cererile pot fi sincronice sau asincronice.

Cererile sincronice de generări de coduri pot face una dintre următoarele:

Să genereze în mod rapid o metodă pentru JIT, cu un nivel specific sau o anumită eficiență;

Să genereze o metodă optimizată, cu un nivel specific sau o anumită eficiență.

O cerere asincronică este:

Un act asupra unei ipoteze invalidate, de exeplu, să forțeze regenerarea unei metode sau a unui patch a unui cod nativ sau a unei metode.

La nivel intern, JRockit păstrează cererile sincronice de generări de coduri într-un rând de generări de coduri și optimizări, depinzând de tipul de cerere. Rândurile se diminuează prin una sau mai multe generări de coduri și/sau thread-uri de optimizare, depinzând iarăși de configurația sistemului.

Rândul de generări de coduri conține cereri de generări pentru metode care au nevoie de execuțiile programelor. Aceste cereri, exceptând anumite cazuri special din timpul boostrapping-ului, sunt essential generate de trampoline-uri. Impulsul de a “generare” pe care îl are fiecare trampoline, inserează o cerere în rândul de generări de codduri și blochează până când generarea metodei este completă. Valoarea returnată a impulsului este adresa în memoria căruia nouă adresă a memoriei debutează, la care comută în final trampoline-ul.

Cererile de optimizare

Cererile de optimizare sunt adăugate în rândul optimizazrilor oricând o metodă este găsită că fiind "fierbinte”, adică atunci când timpul de rulare a unui system a realizat că petrecem îndeajuns de mult timp executând codul Java al respectivei metode pentru că optimizarea să fie garantată.

Rândul optimizărilor rulează la un nivel mai scăzut de prioritate față de rândul de generări de coduri deoarece rezultatele acțiunilor sale nu sunt necesare pentru execuția codurilor, ci doar pentru performanță acestora.

De asemenea, o cerere de optimizare de obicei ia ordine referitoare la mărime mai lungi decât îi ia unei cereri de generare de coduri să o execute, dând la schimb timpul de compliare pentru un cod eficient.

ABATERI

O complicație ce poate apărea este prezența abaterilor, care dacă este consecvent cu acest model, ar trebui să formeze comutări condiționale de la fiecare operare de bytecode care poate avaria către un set adecvat de capcane, unde una este valabilă.

Această s-ar tranforma în mod rapid într-o explozie combinatorie în fluxul graficului (și prin urmare a seturilor de bază), ce influenteaa în mod negative orice O(|V||E|) (nodes x edges) grafic algoritmic transversal care necesită să lucreze pe cod.

Această schemă arată blocul grafic de baza printr-un exemplu mai vast. Metoda de intrare este la Block 0 care are trei ieșiri – două normale, care conțin o ramură conditional și un edge pentru abateri. Aceasta înseamnă că Block 0 este un set care pornește la Block 3. Același set blochează Block 1 și Block 2 de asemenea. Această metodă poate ieși fie prin declanșarea abaterii și finalizându-se în Block 3 sau prin căderea efectivă în Block 5. Ambele seturi blocheaza ieșirea cu instrucții de reîntoarcere.

Chiar dacă singurele instrucțiuni pot declanșa o abatere, acestea sunt date prin Block 2 (se divide prin 0, setul cuprinde câteva noduri pentru ca acesta este felul în care bytecode-ul (și sursa codului) arată. Dezvoltatorii pot alege daca vor lucra la asta sau nu.

Compilarea JIT

Următoarea schemă ilusteaza diferitele stadii ale viitorului cod JRockit:

BC2HIR HIR2MIR MIR2LIR RegAlloc EMIT

Generarea HIR

Primul modul în care codul generator, BC2HIR, este în interfața împotriva bytecode-ului, iar scopul său este acel de a traduce bytecode-uri în IR. HIR, în acest caz, este un acronim pentru High-level Intermediate Representation. Pentru md5_F method, unde nu este prezent niciun flux al controlului în formă condițională sau necodițională a comutărilor, obțiem doar un set de baza.

Următorul fragment de cod arată metoda md5_F în formă de bytecode:

public static int md5_F(int, int, int);

Code: Stack contents: Emitted code:

0: iload_0 v0

1: iload_1 v1

2: iand (v0&v1)

3: iload_0 (v0&v1), v0

4: iconst_m1 (v0&v1), v0, -1

5: ixor (v0&v1), (v0^-1)

6: iload_2 (v0&v1), (v0^-1), v2

7: iand (v0&v1), ((v0^-1) & v2)

8: ior ((v0&v1) | ((v0^-1) & v2))

9: ireturn return ((v0&v1) | ((v0^-1) & v2));

JIT funcționează prin calcularea unui grafic de flux de control pentru IR prin examinarea comutarilor din cadrul bytecode-urilor și apoi prin completarea codurilor bazelor setului. Codul este construit prin emularea conținuturilor din depozitul mulțimii de evaluări la orice locație din program. Emularea operărilor unui bytecode rezultă în schimbări în cadrul generării evaluărilor și/sau codurilor. Acest exemplu a fost adnotat cu conținutul unor mulțimi de evaluări iar generarea codurilor după fiecare bytecode a fost procesată. Așa cum putem vedea, prin reprezentarea conținutului unor variabile ale mulțimii de evaluări cu o manipulare flexibilă, putem reconstrui expresiile de la sursă originală a codului. De exeplu, instrucțiunea iload_0, care înseamnă “apasa conținutul variabilei 0” se transformă în “variable 0” în cadrul mulțimii emulate. În acest exeplu, emulatorul formează gradual o din ce în ce mai compleza expresie în privință mulțimii, iar atunci când este timpul să o returneze, această expresie poate fi folosită în întregime pentru a forma un cod.

Această este expresia a ceea ce a fost prezentat precedent, HIR sau High-level IR:

params: v1 v2 v3

block0: [first] [id=0]

10 @9:49 (i32) return {or {and v1 v2} {and {xor v1 -1} v3}}

Indecșii variabili au fost atribuiți de către JRockit și diferă de către cei din bytecode. Trebuie a se observa că operațiunile pot conține alte operațiuni precum operantii săi, similare cu codul original Java. Aceste expresii suprapuse sunt de fapt un by-produs util al transformării mulțimii bytecode-urilor la forma inițială a expresiilor. Astfel obținem o reprezentare High-level în daună unei compilări tipice și plate cu un transfer de variable temporare, unde operațiunile nu pot conține la rândul lor alte operațiuni. HIR-ul se împarte pe sine către unele optimizări care sunt mai greu de procesat în alt format; de exemplu, descoperind dacă o sub-expresie (în forma unui subarbore) este prezent de două ori într-o expresie. Apoi sub-expresia poate fi pliată într-o variabila temporară, salvând-o de la a fi evaluate de două ori.

Emularea mulțimii bytecode-urilor pentru a forma HIR nu se desfășoară fără probleme, cu toate acestea. Întrucât la timpul de compilare, știm decât ce expresie este în cadrul mulțimii, dar nu și valoarea să, ne putem confruntă cu variate probleme. Un exemplu al fi cel al situațiilor în care mulțimea este folosită ca memorie. Luăm drept exemplu construcția result = x ? a : b.

Bytecode-ul se compilează în ceva de genul acesta:

/* bytecode for: "return x ? a : b" */

static int test(boolean x, int a, int b);

0: iload_0 //push x

1: ifeq 8 //if x == false then goto 8

4: iload_1 //push a

Când emulatorul ajunge la instrucțiunea ireturn, valoarea care apare poate fi fie a (local variable 1) sau b (local variable 2). Deoarece nu putem exprima “a” sau “b” că variabile, trebuie să înlocuim sarcinile la ramificare cu 4 și 8, cu scrieri la una și aceiași temporală variabilă, și să plasăm această în mulțime în locul celeilalte.

Modulul BC2HIR care transformă bytecodeurile în grafice de flux de control cu expresii nu este complex din punct de vedere al calculului. Cu toate acestea, el conține diferite alte cazuri special, similare cu cel prezentat mai devreme, care sunt în afară subiectului acestei lucrări de licență.

Majoritatea dintre ele au legătură cu lipsă de structură din cadrul bytecode-ului și cu metaforă mulțimii de evaluare. Un alt exemplu ar fi nevoia de asociere a bytecode-ului monitorenter cu corespondentul monitorexit(s).

JRockit Mission Control este numele colectiv atribuit instrumentelor prevăzute cu JRockit 5.0 R26 JDK. Este un set de aplicații Swing care pot fi utilizate pentru a colecta și analiza informații din timpul functionarii JRockit în moduri diferite. Următoarea versiune a centrului de operatie JRockit se va baza pe platform Eclipse Rich Client și pe instrumentele disponibile separat sub forma de plug-in-uri Eclipse.

Cele mai multe dintre tehnologiile utilizate în prezent pentru a monitoriza, gestiona, și crea profilul de execuție Java pot fi inoportune, cum ar fi codul de instrumentatie byte code și JVMPI (acum învechită și înlocuită de JVMTI ). Principalul obiectiv al centrului de operatie JRockit este de a executa instrumentatia necesara cu impactul cat mai redus asupra sistemului de operare.

Tehnologia utilizată permite, de asemenea aplicatiei sa ruleze la viteză maximă o dată cu deconectarea uneltei de la JVM. Prin urmare, centrul de operatie JRockit este potrivit pentru utilizarea în mediile de producție. Costurile de intretinere minime reduc, de asemenea, efectul Heisenberg și pot furniza date mai reprezentative pentru aplicația dvs. decât alte tehnici predispuse la costuri de intretinere mai ridicate.

Să analizam diferitele componente ale centrului de operatie JRockit.

Consola JRockit pentru management este o consolă bazată pe JMX folosita pentru a gestiona și monitoriza JVM JRockit. Acesta oferă date de referinta privind conditia de functionare a programului și o modalitate de a controla caracteristicile de rulare ale JVM JRockit. Printre atributele pe care le puteti monitoriza sunt setul ‘live’, cifra consumului, încărcarea CPU, precum și orice alt atribut expus de MBeans si înregistrat în platforma interna JVM de server MBean.

Consola JRockit pentru management include, de asemenea, un mod de a implementa costuri de intretinere reduse si un contor pentru exceptiile de la regula.

Pentru a monitoriza un JVM JRockit cu ajutorul unei console JRockit pentru management, în primul rând agentul de management JVM ce urmeaza a fi monitorizat trebuie să fie pornit. Acest lucru poate fi realizat prin pornirea JRockit JVM cu Xmanagement-flag (a se vedea documentația consolei JRockit pentru management), prin utilizarea JRCMD, sau folosind Ctrl-Break Handler. Puteți folosi, de asemenea, JRCMD și Ctrl-Break Handler pentru a închide agentul de management.

Consola JRockit pentru management este formata dintr-un agent care rulează în procesul de JRockit, expunând MBeans-urile înregistrate in platform interna JVM de server MBean, și o aplicație Swing a consolei JRockit pentru management care ruleaza separat.

Dupa cum ilustreaza fig. 1, mai multe console JRockit pentru management pot fi conectate la un singur JRockit JVM, iar o singură consolă pentru management poate fi conectată la mai multe JVM JRockit. Consolele pentru management ar trebui fie sa ruleze pe diferite aparate fie sa se foloseasca de setarile flag option pentru a utiliza fișiere diferite din setări. Rețineți că, deoarece consola poate utiliza mai multe JVM JRockit, de obicei nu este nevoie de sa rulati mai multe console pentru management pe același aparat.

Dintr-o perspectivă arhitecturală la nivel înalt, JRockit-urile monitorizate includ:

• Un set de interfețe de extensii JRockit la interfețele java.lang.management.

Mai exista de asemena si un MBean generat dinamic expunând toată contoarele de performanță JRockit că atribute, de asemenea, există.

Aceste extensii sunt denumite la nivel intern extensiile java.lang.management, sau, pe scurt, JLMEXT.

• Un agent ce expune aceste interfate- comunicarea cu consola este realizata prin folosirea JMX la distanță peste RMI.

• PDC (JRockit Discovery Protocol) Server-consola pentru management efectuează detectarea automată prin utilizarea de multicasting pentru a comunica locația JRockit-ului vizat. Serverul JDP este opțional. Pentru a activa JDP aveți nevoie sa porniti JVM cu optiunea proprietate sistem -Djrockit.managementserver.autodiscovery = true.

Profilerul metodei oferă o modalitate cu costuri reduse de a afla de cât de multe ori o metodă este invocată, și cât de mult timp este petrecut în această metodă, Metodele de interes sunt regenerate simplist cu o cantitate mică de cod de instrumentatie, care este eliminat momentul in care profilerul este oprit. Costurile de intretinere ce apar ca urmare a folosirii profielerului pentru metod sunt suportate numai atunci când ați selectat metode de profilare, și numai pentru metodele selectate. Javadocs-urile pentru interfețele-JRockit specifice sunt publicate pe homepage-ul de centrului de operatie.

Dintr-o perspectiva arhitecturala la nivel inalt, aplicatia Swing pentru consola de management include:

• RJMX (servicii JRockit Remote JMX)-Furnizează servicii cum ar fi persistența, the attribute subscription abstraction, și cadrul de notificare.

• Clientul PDC descoperă automat JVM JRockit-urile care au PDC activat.

• GUI pentru consola de management (a se vedea figura 2)- aplicatia Swing.

Aplicația Management Console introduce conceptul de Attribute Subscription, care, oarecum simplificată, este definită de MBean ObjectName, numele atributului și intervalul de abonament. Consola permite utilizatorului să adauge reguli pentru notificări și date persistente de la astfel de abonamente. Abonamentele se bazează pe atributele JMX MBean obișnuite, pe date individuale compuse ale unui atribut, sau pe date din notificările JMX (unde intervalul de abonare nu prezintă interes din cauza livrarii desincronizate a evenimentelor de la un astfel de abonament). Puteți crea propriul pachet de abonamente care depinde de alte abonamente pentru a-si obține datele, sau chiar își pot crea abonamente sintetice, în care datele le furnizează chiar implementatorul.

Pentru a rezuma, JRockit Management Console este un instrument JMX flexibil de monitorizare și gestiune, care oferă o multitudine de caracteristici:

• Trasarea a oricărui atribut numeric

• Persistența oricărui set de atribute pentru analiza offline

• Abonamente special pentru plotting usor al timpilor de pauza, utilizarea set live, și utilizare continuă heap

• Reguli de notificare, care pot lua măsuri atunci când apare o condiție specificată de utilizator pentru un anumit atribut

• Posibilitatea utilizatorilor de a introduce propriul cod atât pentru acțiunile de notificare, cât și pentru limitare

• Managementul runtime-ului Java, inclusiv schimbarea dinamică a modalității de colectare a gunoiului strategie, dimensiune heap, dimensiunea nursery-ului, afinitatea procesului Jrockit, permițând activarea/ dezactivarea verbosity flags, etc.

• A low overhead method profiler

• Un contor pentru excepții

• Un mijloc pentru a începe înregistrările JRockit Runtime Analyzer

• Un mijloc de a invoca dinamic operațiunile MBeans

• O modalitate de a invoca JRockit Ctrl-Break Handler

JRockit Analyzer Runtime (ARJ) este o aplicație Java și JVM profiler. Acesta a fost în jur de ceva timp în echipa de dezvoltare JRockit, și a fost inițial creată pentru a permite dezvoltatorilor JRockit să găsească bune modalități de a optimiza JVM bazat pe aplicatii din lumea reală, dar acesta s-a dovedit a fi foarte utilă pentru clienți pentru rezolvarea problemelor privind atât producția cât și dezvoltarea. Există multe motive pentru care utilizatorii de JVM, pur și simplu nu pot oferi dezvoltatorilor JVM acces la întreaga lor aplicație. ARJ funcționează ca un înregistrator de zbor; se înregistrează modul în care aplicația Java și JVM se comportă pentru o perioadă de timp prestabilită. Înregistrarea poate fi apoi analizată folosind aplicația ARJ, unde, de exemplu, pot fi analizate call tracers-urile pentru metodele mai performante, sincronizarea nereușită, și alte aplicații importante/ comportamentul JVM. Organizația BEA Suport folosește în mod frecvent înregistrări ARJ de la clienți pentru a ajuta clienții BEA în rezolvarea problemelor.

ARJ este format din două părți: motorul de înregistrare în JVM, și aplicația GUI pe care o puteți utiliza pentru a analiza înregistrarea rezultată. Motorul de înregistrare folosește mai multe surse de informare, inclusiv JRockit Hot Spot Detector (de asemenea, folosit de către motorul de optimizare pentru a decide ce metode să optimizeze), sistemul de operare, sistemul de memorie JRockit (mai ales colector de gunoi), și JRockit lock profiler , dacă este activat.

Cu instrumentul ARJ se poate analiza cu ușurință informațiile conținute în înregistrarea ARJ prin mijloace grafice (vezi Figura 3). Graficele arată ori pauză, utilizarea masivă, și dimensiunea masivă operată în timpul perioadei de înregistrare. Orice colectare individuală a gunoiului (GC) pot fi selectate, fiind furnizate informații foarte detaliate ale acestuia. Se pot obține call tracers pentru metodele mai performante – nu numai call tracers-urile care au dus la metoda acestuia, dar, de asemenea, call tracers-urile ce reprezintă viitorul. Call tracers-urile arată, de asemenea, dacă a fost sau nu numită o versiune optimizată a metodei.

O histogramă heep este luată la începutulși la sfârșitul înregistrării, dezvăluind utilizarea heep pe clasă, pentru cazuri de clase care ocupă mai mult de 0,5 la sută din spațiul heap utilizate. Informațiile heep colectate sunt, de asemenea, utilizate pentru a face diagrame care arată utilizarea grămadă.

Overhead-ul în timpul înregistrării este foarte scăzut-de obicei, mai puțin de douăprocente. Cu toate acestea, deoarece ARJ forțează o colecție completă a gunoiului la începutulși la sfârșitul înregistrării pentru a genera datele histogramei heep, poate exista un vârf la începutul și la sfârșitul unei înregistrări.

Există mai multe moduri de a începe o înregistrare ARJ:

• Utilizați Consola de ManagementJRockit.

• Utilizați JRCMD.

• Utilizați extensiileJRockit la clasele java.lang.managementactivat-JMX.

• Utilizați parametrii de linie de comandă ARJ-XXjra.

Înregistrările ARJ pot fi, de asemenea,declanșate din Consola de administrare folosind reguli de notificare; de exemplu, o regulăpoate fi create pentru a începe o înregistrare ARJ când încărcarea procesorului a fost mai mare de 90 procente pentru un minut.

După cum puteți observa, ARJ este un puternic JVM șiaplicațieJava profiler care oferă:

• Eficiență (de obicei mai putin de 3 la suta aeriene) înprofilarea atât JVM și a aplicației Java.

• Metoda de masă hot spot, care arată au fost invocate cel mai des.

• Statistici foarte detaliate de colectare a gunoiului, arătând ceea ce sa întâmplat în timpul fiecărui GC individ.

• Schimbări de strategie de colectare a gunoiului.

• Parcelegrafice de utilizare heap șipausetimes.

• Histograme heep arată utilizarea heap pe clasă, la începutul și sfârșitul înregistrării.

• Diagrame plăcintă de utilizare heep pe mărimea obiectului, inclusive fragmentarea.

• Ce metode au fost optimizate în timpul înregistrării.

Pentru mai multe informațiidespre utilizarea ARJ, consultați documentația JRockitMission Control.

JRockit Memory Leak Detector este un instrument ce vă ajuta să descoperiți rapid pierderile de memorie. Chiar dacă administrarea de memorie automată Java eliberează dezvoltatorii de povara de a aloca și elibera în mod explicit memoria folosită, pierderi de memorie pot apărea în continuare în cazul în care programul face trimiteri la obiecte care nu mai sunt folosite.

JRockit Memory Leak Detector oferă utilizatorului o analiză rapida a tendințelor detectând chiar si pierderi de memorie mai lente.Analiza tendinței prezinta utilizarea heap a aplicației per clasă.

Detectorul de scurgeri de memorie JRockit oferă, de asemenea, mijloacele de a detecta rapid cauza scurgerii. Un tip suspect poate fi selectat în tabelul de analiza a tendințelor, și toate tipurile care au cazuri ce indică spre tipul selectat pot fi prezentate într-un graphic.

Nodurile graficului pot fi extinse arbitrar pentru a permite utilizatorului sa le urmareasca pana la ceea ce blochează referințele. Instanțe ale uneiclase pot fi afișate și analizate, iar toate instanțele care indică catre instanța selectată pot fi afișate într-un graphic al instanțelor. Optiunea “Alocation traces”poate fi activate astfel încât toate alocările unei anumite clase pot fi urmărite.

Pentru exemple și îndrumări cu privire la modul de a utilizaacest instrument, consultați documentația “JRockit Mission Control”, și “Memory Leaks, Be Gone!”,articol pe dev2dev.

Atunci când este inițiată o sesiune de Memory Leak Detector, un Server Memory Leak (SML) pornește. În funcție de versiunea JDK JRockit la care te conectezi, va fi folosit fie conectorul JMX în JLMEXT (5.0), fie Rockit Management Protocol (PMR) (1.4). Exte important faptul că protocoalele diferă și că există diferențe în caracteristicile de rețea și securitate. Un Memory Leak Server este un server nativ cu care se desfășoară restul comunicării din timpul sesiunii. În ceea ce privește clientul, API Java este utilizat pentru a comunica cu serverul nativ (figura 5). Motivul pentru care se utilizează un server nativ este că, în cazul în care apare o afecțiune gravă de memory leak și JRockit rămâne fără Java heap, JRockit nu va mai fi capabil să ruleze cod Java.

Detector Memory Leak se agață de faza de marcare a gunoiului, folosind contabilitatea pentru a înregistra histogramele heap (Statisticile de memorie heap agregate pe clasă), și pentru a genera analiza tendințelor. O soluție comună pentru a găsi pierderile de memorie din competing tools este de a face mai multe instantanee a întregului heap dintr-un sistem, iar apoi de a compara instantaneele. Într-un sistem cu sute de gigabytes de heap sau un sistem într-un mediu de producție, această abordare nu poate fi fezabilă. Cu Detectorul JRockit Memory Leak, doar informațiile de care sunteți interesat sunt trimise, astfel încât cerințele bandă sunt foarte mici. Atunci când se utilizează funcționalitatea alocării call trace-ului, doar codul care implică site-uri de alocare pentru clasa selectată este instrumentat. De asemenea, de îndată ce sesiunea este terminată, sau trace-urile de alocare sunt oprite, instrumentatia este eliminată, iar codul care implică aceste site-uri de alocare revine la viteza maximă.

Pentru a rezuma, Detectorul JRockit Memory Leak este un instrument de analiză avansată, cu un număr de caracteristici noi:

• Se poate efectua o analiză a tendințelor care descoperă pierderi de memorie mai lente.

• Ea face analiza online, folosind JRockit Memory Manager, în loc de, spre exemplu, întreaga grămada de la client de mai multe ori și examinarea diferența.

• Acesta oferă o interfață de utilizator avansată care vă permite să găsiți și să examinați legătura dintre tipul de scurgere și alte tipuri, sau instanța de scurgere și alte instanțe.

• Detectorul are un overhead foarte scăzut și poate fi folosit în producție pentru a face analiza online.

• Nu se folosește nici un fel de intstrument bytecode; atunci când este analizat cu Detector Memory Leak, codul Java va continua să execute ca și cum nu ar fi fost conectat. Nu va fi modificat nici un cod Java.

Detectorul JRockit Memory Leak este, fără îndoială, clasat drept cel mai bun instrument pentru a găsi cauza pierderilor de memorie Java. Pentru mai multe informații despre Detector JRockit Memory Leak, consultați documentația JRockit Mission Control.

O parte din acest capitol este dedicată componenței de management din JRockit Mission Control. Voi introduce conceptul de diagnostic commands și monitorizarea online a unei instanțe JVM.

JRockit Runtime Analyzer este o contructie la comandă pentru profilare care produce înregistrări detaliate despre JVM și despre aplicația pe care o rulează. Profilul înregistrat poate fi analizat offline utilizând plugin-ul JRA Mission Control. Datele înregistrate conțin profilarea metodelor și blocărilor, dar și a informației de eliberare a memoriei, decizii de optimizare, statistica obiectivelor și evenimente de latență. Voi învață cum să detectez unele dintre cele mai comune probleme dintr-o înregistrare JRA și cum funcționează analizatorul de latență.

JRockit Flight Recorder a înlăturat JRA-ul în versiunile mai noi ale setului Jrocit Mission Control. Aici detaliem caracteristicile care au fost adăugate pentru a facilita complicată metodă de rulare a înregistrărilor. Diferențele de funcționalitate și GUI sunt dezbătute de asemenea.

Ultima unealtă adăugată în setul JRockit Mission Control este JRockit Memory Leak Detector. Voi explică astfel conceptul de memory leak sau de scurgere de memorie și vom discută unele dintre cazurile în care este necesară utilizarea Memory Leak Detector. Acesta nu numai că poate fi folosit pentru a găsi retenția anumitor obiecte neintenționate într-o aplicație Java, dar funcționează și că un analizator universal. Unele dintre detaliile impementarilor interne sunt explicate, fiind dezbătut de asemenea și faptul că această unealtă rulează cu un scăzut overhead.

Unealtă de linie de comandă JRCMD este și ea prezentată aici, ea permițând utilizatorului să interacționeze cu toate JVM care rulează pe într-un anumit mecanism și să emită comenzi de diagnosticare. Acest capitolul are formă unui ghid de referință și explică cele mai importante valablile ale comenzilor de diagnostic. Aceste comenzi pot fi folosite pentru a examină sau a modifica stare unei aplicații JRockit JVM în rulare.

Utilizarea JRockit pentru managementul interfețelor pentru programarea de aplicații (API). Aici se regăsesc explicațiile pentru accesul programatic al unor funcționalități din JRockit JVM, modul incare setul de unelte JRockit Mission Control funcționează. Sunt prezentate pentru întâia oară interfețele API JMAPI și JMXMAPI. În timp ce nu sunt pe deplin alimentate, câteva priviri în interiorul mecanismului JVM pot facilita înțelegerea lor.

JRockit Vitual Edition, această parte va fi dedicată explicării virtualizării într-un mediu „cloud-based” modern. Voi introduce produsul JRockit Virtual Edition. Înlăturarea stratul OS de pe o configurație Java este mai puțin problematică decât ne-am putea închipui, ajutându-ne de asemenea să scăpam de anumite rulări ale overhead-uri care sunt în mod tipic asociate cu virtualizarea. Voi continua cu explicare ideii ca aceasta poate reduce virtualizarea ovearhead-ului Java la niveluri imposibile chiar și pentru hardware-ul fizic.

Urmărind finalizarea achiziționării a Sun Microsystems, Oracle a anunțat în Java One 2010 că cele mai bune caracteristici ale JRockit vor fi implmentate în OpenJDK.

În mai 2011, Oracle a anunțat că JRockit a devenit gratuit, confirmând că aceștia plănuiesc să aducă unele proprietăți ale JRockit în OpenJDK.

JRockit, proprietetea Java Virtual Machine (JVM) inițial dezvoltată de Appeal VirtualMachines și achiziționată de BEA Systems în 2002, devine parte a Oracle Fusion Middleware în 2008.

Codul de bază JRockit și mecanismul virtual HotSpot de la Sun Microsystems (acum Oracle) sunt în prezent integrate împreună, cu obiectivul lansării a JVM cu un cod de bază combinat în jurul datei de lansării a JDK 8.

JRockit a fost pus la poziția publicului în mod gratuit în mai 2011.

Multe categorii de documente JRE distribuite cu JRockit le reproduc pe cele HotSpot.

JRockit extinde categoriile de documente care sunt în strânsă legătură cu cele JVM, reținând astfel compatibilitatea API, și dezvoltând în același timp performanță JVM.

Oracle susține că utilizarea JRockit poate aduce o performanță semnificantă. Evaluările servarelor pe Java Virtual Machines mai vechi tind să arate că performanță servarului la HotSpot a fost mai bună, dar că JRockit a avut o mai bună scalabilitate.

TIPURI DE CPU SUPORTATE

• Intel x86

• Intel x86-64

• Intel Itanium (support has ended)

• Sun/SPARC

JRockit JVM este un JMV de înaltă performanță, creat pentru a oferi stabilitate, manevrabilitate și flexibilitate pentru aplicațiile Java. JRockit JVM îmbunătățește performanță aplicațiilor Java dezvoltate pe arhitecturile Intel 32-bit (Xeon) și 64-bit (Xeon și SPÂRC) la un preț semnificativ mai scăzut pentru întreprindere. Mai mult decât atât, este singurul JVM pentru întreprinderi optimizat pentru arhitectură Intel ce poate fi folosit pe multiple aparate și sisteme de operare indiferent de configurația acestora. JRockit JVM face posibilă operarea aplicațiilor Java la un nivel optim atât în Windows cât și Linux (32 sau 64 de biți). JRockit JVM funcționează ideal cu un server Oracle WebLogic.

JRockit Mission Control

JRockit 5.0 R26 colectează un set de unelte numite JRockit Mission Control. Uneltele conțin:

consola de management interactivă, care vizualizeaza procesul de elibereare a memoriei (garbage-collection) și alte statistici ale performanței

O unealtă de descriere a performanței de rulare numită Runtime Analyzer

O unealtă de analizare a memoriei numita Memory Leak Detector

De la lansarea R27.3, setul de unelte include de asemenea și o unealtă de analizare a latenței care vizualizează grafic când threads (filamentele) se opresc din cauza sincronizării, a documentelor/rețelelor I/O, alocării memoriei și a pauzelor eliberării memoriei. JRockit JDK este similar cu HotSpot JDK în ceea ce privește organizarea fișierelor, cu excepția faptului că JRockit JDK include un nou JRE în JRockit JVM. Librăriile au același comportament la JRockit JDK că și la HotSpot JDK. Fiecare copie JRockit JVM vine împreună cu câteva versiuni Java. Spre exemplu, JRockit JVM R28.0 vine împreună cu versiunile 5.0 și 6 Java SE. O versiune Java poate fi compatibilă cu multiple versiuni ale JRockit JVM.

Seria produsului este constituită din următoarele elemente:

Numărul versiunii JRockit JVM (Rnn.nn.nn)

Versiunea Java (J2SE 5.0 sau Java SE 6)

De exemplu, Oracle JRockit JDK 6 R28.0.0 indică versiunea 28.0.0 a JRockit JVM folosită împreună cu Java SE 6; în mod similar, Oracle JRockit JDK 5.0 R28.0.0 indică versiunea 28.0.0 a JRockit JVM folosită împreună cu J2SE 5.0. Un exemplu complet al unei serii:

R28.0.0-637-126675-1.6.0_17-20100111-2121-windows-ia32

În acest exemplu, R28.0.0 reprezintă versiunea JRockit JVM, 1.6.0_01 este versiunea Java, iar windows-ia32 indică platforma pe care aceasta varianta poate fi rulată.

Oracle JRockit JDK este compatibil cu J2SE 5.0 și Java SE 6.

Compatibilitatea între JRockit JDK și HotSpot

Java APIs

Toate API-urile Java se ghidează după declarația de compatibilitate.

Proprietatile API-urilor în cadrul JRockit JVM

API-urile oficiale (JMAPI, JRockit JMX beans) nu pot fi scoase sau modificate decât între versiuni JDK majore. Noi API-uri pot fi adăugate în orice moment.

API-urile neoficiale dar acceptate (jrockit.ext.*) nu pot fi scoase în service pack-uri.

API-urile interne (toate jrockit.* cu excepția jrockit.ext.*) pot fi modificate în orice moment.

Opțiuni ale comenzilor de linie.

Opțiunile standard (de exemplu, -server) aderă la declarația de compatibilitate Java.

Opțiunile nonstandard -X aderă la declarația de compatibilitate Java

Opțiunile nonstandard -XX sunt folosite în felul următor:

Nu pot fi înlăturate decat în cadrul unui update major JDK.

Pot fi dezactivate iar modul de implementare poate fi schimbat în orice moment.

Noi opțiuni de tip –XX pot fi adăugate în orice moment.

CAPITOLUL IV : PREZENTAREA APLICAȚIEI

Veți avea nevoie de o versiunea corect instalată a JRockit JVM și de un mediu de rulare. Pentru a înțelege toate explicațiile acestei lucrări de licență, recomandăm versiunea JRockit R28 minim.

Totuși, versiunea R27 va funcționa de asemenea. Pentru dezvoltatorii RCP/Plug-în, veți mai avea nevoie de o versiune corect instală a Eclipse, mai ales dacă veți dori să încercați diferite căi pentru a extinde JRockit Mission Control și/sau pentru a lucra cu programele folosind codul bundle.

Această lucrare de licență se adresează celor care au cunoștințe practice în limbajul Java, precum dezvoltatori sau administratori cu experiență din ani de lucru profesional cu limabjul Java sau din managementul instalațiilor Java.

Aplicația implementată în cadrul acestei lucrări este o aplicație, dezvoltată cu ajutorul mediului integrat NetBeans. NetBeans oferă suport pentru implementarea și rularea aplicațiilor midlet cu ajutorul unui emulator. Acest emulator simulează funcționalitățile unui telefon mobil, permițând testarea aplicațiilor pentru dispozitive mobile pe perioada dezvoltării.

Crearea unui proiect în IDE trebuie să respecte câțiva pașii simpli, dar esențiali :

1. Deschidem Netbeans IDE.

2. În IDE, selectăm File > New Project (Ctrl-Shift-N), așa cum vedem în următoarea figură.

3. În expertul New Project, se extinde categoria Java și selectați Java Application așa cum se arată în figura de mai jos. Apoi faceți clic pe Următorul.

4. În pagina cu numele și locația expertului, faceți următoarele (după cum se arată în figura de mai jos):

– În câmpul Project Name, de tip EvidentaSatFoisor.

– Lăsați Directorul dedicat de utilizare pentru biblioteci, Stocarea casetei neselectate.

– În Creare domeniul Class este principal, de tip evidentasatfoisor.EvidentaSatFoisor.

5. Apăsăm click pe Finish ( Terminare) pentru a începe crearea aplicației.

Proiectul este creat și deschis în IDE. Se vor vedea următoarele componente:

– Fereastra Projects, care conține o vedere arborescentă a componentelor proiectului, inclusiv fișierele sursă, biblioteci, care depinde cod, și așa mai departe.

– Fereastra Source Editor cu un fișier numit EvidentaSatFoisor deschis.

– Fereastra Navigator, pe care le puteți folosi pentru a naviga rapid între elementele

din clasa selectată.

NetBeans este un proiect open-source, cu o bază de utilizatori foarte mare, o comunitate în creștere și peste 100 de parteneri (în creștere!) din toată lumea. Sun Microsystems a fondat proiectul open source NetBeans în iunie 2000 și continuă să fie principalul sponsor al proiectului. Astăzi există două produse: NetBeans IDE și platforma NetBeans.

NetBeans IDE este un mediu de dezvoltare – un instrument pentru programatori, pentru scrierea, compilarea, testarea, depanarea, proiectarea și instalarea programelor. Este scris în Java – dar poate accepta orice limbaj de programare. De asemenea, există un număr imens de module pentru extinderea NetBeans IDE. NetBeans IDE este un produs gratuit, fără restricții legate de modul de utilizare.

NetBeans IDE oferă suport complet de primă clasă pentru cele mai noi tehnologii Java și de cele mai recente îmbunătățiri Java înainte de alte IDE. Este primul IDE oferind suport pentru JDK 7, Java EE 7, și JavaFX 2.

Cu îmbunătățirea continuă Java Editor, are multe caracteristici bogate și o gamă largă de instrumente, șabloane și probe, NetBeans IDE stabilește standardul pentru dezvoltarea de tehnologii avansate din cutie.

Un IDE este mult mai mult decât un editor de text. NetBeans Editor liniuțe linii, meciuri cuvinte și brațele, și codul sursă Repere punct de vedere sintactic și semantic. Acesta prevede, de asemenea șabloane de cod, sfaturi de codificare, și instrumente de refactoring.

Editorul acceptă mai multe limbi de Java, C / C + +, XML și HTML, PHP a, Groovy, Javadoc, JavaScript și JSP. Deoarece Editorul este extensibil, puteți conecta în suport pentru multe alte limbi.

NetBeans IDE este un instrument dezvoltator modular pentru o gamă largă de tehnologii de dezvoltare de aplicații. Baza IDE include un editor avansat multi-lingvistic, Debugger și Profiler, precum și instrumente de control al versiunilor și de colaborare dezvoltator.

IDE oferă șabloane de proiect și proiecte de probă care vă ajută să creați aplicații Java SE, aplicații Java EE, aplicații Java ME, aplicații HTML5, aplicații Platforma NetBeans, aplicații PHP și C / C + +.

Puteți porni și opri baze de date și servere direct în IDE. Atunci când se lucrează cu baze de date, puteți adăuga, elimina și modifica datele din IDE. Când ați implementat o aplicație la un server, puteți gestiona resursele desfășurate, deoarece acestea sunt afișate în nodul Servers. Vă puteți conecta la o bază de date bug-uri, cum ar fi IssueZilla sau Bugzilla,

și emite rapoarte lista pentru proiect chiar în IDE.

Păstrează o imagine de ansamblu clară a aplicațiilor mari, cu mii de foldere și fișiere, și milioane de linii de cod, este o sarcină descurajantă. NetBeans IDE oferă puncte de vedere diferite ale datelor dvs., de la ferestre mai multe proiecte la instrumente utile pentru crearea aplicațiilor și gestionarea lor eficientă, permițându-vă să detalia în date rapid și ușor, în timp ce oferindu-vă versiuni instrumente prin Subversion, Mercurial, Git și integrare din cutie.

Când noi dezvoltatorii se alătură proiectului, ei pot înțelege structura cererii, deoarece codul este bine-organizat.

NetBeans IDE 8.0 – IDE util în dezvoltarea aplicațiilor java

Proiectare și implementare

CAPITOLUL V : Concluzii

Java este unul dintre cele mai utilizate limbaje de programare în zilele noastre, datorită unor avantaje de necontestat. Printre acestea putem menționa: securitate, independență de platformă, limbaj intuitiv, bine structurat și open-source.

Cu milioane de programatori și distribuții în toată lumea, Java este o platformă foarte utilizată și populară.

Prima parte este axată pe modul în care o Java Virtual Machine lucrează și ceea ce face în mod concret. Va vorbi despre calitățile și slăbiciunile unei rulări, în general, dar și a uneia JRockit, în mod particular, încercând să explice unele dintre cele mai bune practici de coduri Java. Vom arunca o privire în „cutia neagra”, în acest caz, în sistemul JVM vom furniza o posibilitatea de a privi în interiorul sistemului Java atunci când rulează. Informațiile din prima parte a lucrării vor ajuta dezvoltatorii și arhitecții să înțeleagă consecințele anumitor decizii de design și să îi ajute să ia alte decizii mai bune.

Utilizarea JRockit poate aduce o performanta semnificanta. Evaluarile servarelor pe Java Virtual Machines mai vechi tind sa arate ca performanta servarului la HotSpot a fost mai buna, dar ca JRockit a avut o mai buna scalabilitate.

Utilizarea JRockit Mission Control face aplicațiile Java să ruleze mai optimizat. Această parte a lucrării va fi utilă administratorilor și dezvoltatorilor care vor să configureze JRockit astfel încât să ruleze în mod particular aplicațiile dorite cu maximum de performanță. Este de asemenea utilă dezvoltatorilor care vor să configureze aplicațiile Java pentru o mai bună utilizare a resurselor și a performanței. Însă trebuie ținut cont de faptul că prin configurarea JVM, problemele simple sau complexe dintr-o aplicație, dacă sunt rezolvate, poate aduce creșteri de performanță masive. Vom arăta cum setul JRockit Mission Control va ajută să găsiți bottleneck-uri și să tăiați din costurile hardware și de procesare.

BIBLIOGRAFIE

1. Java sau/și .NET, http://profs.info.uaic.ro.

2. Learn About Java Technology, http://www.java.com/en/about.

3. Oracle Jrockit: The Definitive Guide, De Marcus Hirt, Marcus Lagergren, June 2010.

4. Oracle JRockit Documentation, http://www.oracle.com/technetwork/middleware

5. About the Oracle JRockit JDK, http://docs.oracle.com.

6. 5 Technology Trends for 2014,http://blog.credera.com.

7. Java Software, http://www.oracle.com/

BIBLIOGRAFIE

1. Java sau/și .NET, http://profs.info.uaic.ro.

2. Learn About Java Technology, http://www.java.com/en/about.

3. Oracle Jrockit: The Definitive Guide, De Marcus Hirt, Marcus Lagergren, June 2010.

4. Oracle JRockit Documentation, http://www.oracle.com/technetwork/middleware

5. About the Oracle JRockit JDK, http://docs.oracle.com.

6. 5 Technology Trends for 2014,http://blog.credera.com.

7. Java Software, http://www.oracle.com/