Iarna este anotimpul propice pentru vise. Vremea când copii de toate vârstele aștern în gânduri sau pe hârtie scrisori către Moș Crăciun. Se pare că în acest an, atitudinea aceasta a fost contagioasă și s-a transmis și echipei din spatele JDK 9 care și-a așternut pe foile WWW-ului gândurile cu referire la JEP-urile ce vor deveni (sperăm!!!) la începutul lui 2016 realitate. Desigur, dacă luăm în considerare vorba românească,socoteala de-a acasă nu-i la fel cu cea din târg, lista aceasta poate suferi scurtări, corecturi și adăugiri. Dar e momentul să fim optimiști.
De luat în seamă este faptul că lista este într-o continuă evoluție.
Acei dintre voi care l-au necăjit pe moș au fost destul de „norocoși” și au lucrat cu API-ul din Java pentru manipularea proceselor.Imaginația v-a ajutat să ocoliți limitările lui. Începând cu JDK 8, acest API a primit îmbunătățiri, direcția fiind urmată. Astfel acest JEP promite să aducă următoarele abilități API-ului:
Evangheliștii performanței pentru aplicații Java, consideră că performanța unei aplicații Java poate fi foarte eficient îmbunătățită prin micșorarea pe cât posibil a concurenței și implicit a blocurilor de sincronizare. Dacă JDK 9 va conține următoarele modificări, importanța acestei reguli va fi cu siguranță diminuată:
Titlul acestui JEP este cât se poate de explicit. Acei dintre voi ce au avut de-a face cu aplicații complexe Java, cu siguranță v-ați ciocnit o dată sau de două ori de log-uri ale colectorului de gunoi al mașinii virtuale Java. Nu știu voi, dar pe mine m-a făcut să mă scarpin în creștet cantitatea de informație ce am găsit-o în acele log-uri. Mai fain, a fost momentul post migrare între versiuni java, moment în care îți dai seama că log-ul din noua versiune nu prea mai seamăna cu cel din versiunea anterioară, iar orice încercare de-a fi automizat procesul este rapid executată. Dar, să ne concentrăm pe îmbunătățirile aduse de noua versiune cu promisiunea ca după ce noua versiune va fi disponibilă, ne om tângui că înainte era mai bine.
Se pare că JDK încearcă să se alinieze cel puțin din punct de vedere estetic cu alte librării de logare Java (precum log4j). Deci, vom avea diferite nivele de criticitate pe care vom putea loga informația (eroare, avertisment, informativ, detaliat, extrem de detaliat). Pentru a nu afecta performanța aplicațiilor aflate în medii de producție, JEP-ul vine cu directive menite să crească performanța. Astfel nivelele corespunzătoare erorilor și avertismentelor nu ar trebui să afecteze performanța aplicațiilor, mai ales că celelalte nivele nu au constrângeri din această perspectivă. O linie de log inițială ar putea arăta:
[gc][info][6.456s] Old collection complete Pentru a asigura flexibilitatea mecanismului de logare, acesta va putea fi adaptat prin parametrii mașinii virtuale Java, intenția fiind să existe o abordare unificată în această direcție. Pentru a oferi conformitate cu parametrii versiunilor anterioare, aceștia vor fi echivalați cu noii parametri ori de câte ori este posibil. Pentru a fi cât se poate de potrivit pentru aplicațiile în execuție, configurarea logurilor poate fi modificată prin apeluri prin intermediul jcmd-ului sau MBean-urilor. Desigur, implementarea acestui JEP nu înseamnă că logurile existente vor fi automat mai lizibile - scopul acestui JEP este doar de a oferi mecanismele prin care logurile pot fi mai facil de citit nu și schimbarea manierei în care diferitele librării scriu în loguri.
Cum probabil știți, platforma Java folosește compilare instantă pentru asigurarea execuției optimă a aplicațiilor. În acest moment există două compilatoare în cadrul platformei Java, denumite foarte intuitiv C1 și C2. Ele corespund parametrilor -client respectiv -server ai mașinii virtuale Java. Scopul acestui JEP este îmbunătățirea controlului(până la nivel de metodă) asupra acestor compilatoare. Mai precis posibilitatea de a schimba opțiunile în timpul execuției, desigur totul fără înrăutățirea performanței.
Se pare că îmbunătățirea performanței este una dintre țintele Java 9, luând în vedere că și acest JEP are ca țintă îmbunătățirea performanței prin:
Luând în considerare omniprezența JSON-ului, acest JEP nu este surprinzător. Surprinzător din punctul meu de vedere este că nu a fost disponibil mai devreme, mai ales că JSON a înlocuit XML-ul ca principală manieră de a exprima datele. Țintele acestui JEP sunt următoarele:
Desigur, JDK-ul va fi aliniat cu JSR 353 și de asemenea adaptarea la stilul de programare impus de JDK 8 prin adăugirea lambda și a fluxurilor de date.
sjavac este un utilitar care extinde capacitățile deja faimosului javac. Noul utilitar are ca intenție performanțe îmbunătățite pentru proiectele de mărime considerabile, primul scop al acestui JEP fiind oferirea posibilității de a compila proiectul JDK folosind sjavac. Mai mult oferirea posibilității de a compila și alte proiecte mari folosind sjavac.
Primii pași în această direcție au fost făcuți pentru implementarea proiectului jigsaw, având ca scop final reorganizarea codului sursă ca module extinzând capacitățile utilitarelor de compilare la a construi module și la a respecta limita modulelor.
Odată cu integrarea acestui JEP numărul de avertismente din secțiunile de import a claselor, va descrește. Motivul principal fiind curățarea claselor din această perspectivă.
Numărul crescut de protocoale ce folosesc UDP (precum SIP) au crescut îngrijorarea când vine vorba de securitate. Având în vedere că protocoale precum TLS au nevoie de protocoale garantate (precum TCP), este nevoie de implementarea protocolului de securitate DTLS în versiunea 1.0 (RFC 4347) și 1.2 (RFC 6347).
Acest JEP vine ca o completare naturală a JEP 201, cu intenția clară de a restructura structura JDK-ului și a mediului de execuție java astfel încât să poată găzdui module și să îmbunătățească performanța, securitatea și mentenanța.
Îndepărtarea posibilității de a cere (folosind -version) versiunea Java pentru o aplicație JRE pornită va fi efectuată în două etape: prima, afișarea unui avertisment în versiunea 9 a Java și a doua etapă, renunțarea completă la această posibilitate începând cu Java 10 și aruncarea unei exepții.
Cam așa arată lista JEP pe baza cărora se va construi JDK 9. Să vă spun sincer, deși schimbările nu sunt cele mai revoluționare, eu sunt nerăbdător să văd noua versiune. Având în vedere că e destul de lucru, eu vă încurajez să implicați în implementarea Java 9.
Acest articol face parte din seria Java Advent Calendar, mai multe articole din serie pe www.javaadvent.com.
Calendarul Java pentru Advent este o inițiativă clujeană de a întâmpina Crăciunul în fiecare an (începând cu 2012) cu o suită de articole tehnice legate de Java sau JVM. Aceste articole sunt publicate în intervalul 1-24 Decembrie pe www.javaadvent.com, ulterior fiind promovate pe diverse site-uri de specialitate. Până în acest moment, grupul contribuitorilor a fost unul internațional cu participanți din toată lumea. Un Crăciun fericit și vă așteptăm alături de noi ca voluntar,cititor sau contribuitor sau chiar și toate trei simultan.
de Ovidiu Mățan
