ABONAMENTE VIDEO REDACȚIA
RO
EN
NOU
Numărul 140
Numărul 139 Numărul 138 Numărul 137 Numărul 136 Numărul 135 Numărul 134 Numărul 133 Numărul 132 Numărul 131 Numărul 130 Numărul 129 Numărul 128 Numărul 127 Numărul 126 Numărul 125 Numărul 124 Numărul 123 Numărul 122 Numărul 121 Numărul 120 Numărul 119 Numărul 118 Numărul 117 Numărul 116 Numărul 115 Numărul 114 Numărul 113 Numărul 112 Numărul 111 Numărul 110 Numărul 109 Numărul 108 Numărul 107 Numărul 106 Numărul 105 Numărul 104 Numărul 103 Numărul 102 Numărul 101 Numărul 100 Numărul 99 Numărul 98 Numărul 97 Numărul 96 Numărul 95 Numărul 94 Numărul 93 Numărul 92 Numărul 91 Numărul 90 Numărul 89 Numărul 88 Numărul 87 Numărul 86 Numărul 85 Numărul 84 Numărul 83 Numărul 82 Numărul 81 Numărul 80 Numărul 79 Numărul 78 Numărul 77 Numărul 76 Numărul 75 Numărul 74 Numărul 73 Numărul 72 Numărul 71 Numărul 70 Numărul 69 Numărul 68 Numărul 67 Numărul 66 Numărul 65 Numărul 64 Numărul 63 Numărul 62 Numărul 61 Numărul 60 Numărul 59 Numărul 58 Numărul 57 Numărul 56 Numărul 55 Numărul 54 Numărul 53 Numărul 52 Numărul 51 Numărul 50 Numărul 49 Numărul 48 Numărul 47 Numărul 46 Numărul 45 Numărul 44 Numărul 43 Numărul 42 Numărul 41 Numărul 40 Numărul 39 Numărul 38 Numărul 37 Numărul 36 Numărul 35 Numărul 34 Numărul 33 Numărul 32 Numărul 31 Numărul 30 Numărul 29 Numărul 28 Numărul 27 Numărul 26 Numărul 25 Numărul 24 Numărul 23 Numărul 22 Numărul 21 Numărul 20 Numărul 19 Numărul 18 Numărul 17 Numărul 16 Numărul 15 Numărul 14 Numărul 13 Numărul 12 Numărul 11 Numărul 10 Numărul 9 Numărul 8 Numărul 7 Numărul 6 Numărul 5 Numărul 4 Numărul 3 Numărul 2 Numărul 1
×
▼ LISTĂ EDIȚII ▼
Numărul 30
Abonament PDF

Promisiunile JDK 9: O scrisoare pentru Moș Crăciun?!

Olimpiu Pop
Senior Software Developer
@Ullink



PROGRAMARE

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.

JEP 102 - Actualizarea API-ului pentru manipularea proceselor

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:

  1. extragerea numărului de identificare al procesului și lista proceselor create de acest API;
  2. posibilitatea de a numi și de a extrage numele mașinii virtuale Java pe care rulează programul;
  3. posibilitatea de a enumera mașinile virtuale Java și procesele sistemului;
  4. posibilitatea de a manipula arbori de procese, mai ales posibilitatea de a opri execuția unor astfel de arbori;
  5. posibilitatea de a gestiona sute de sub proces.

JEP 143 - Îmbunătățirea sincronizării

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ă:

JEP 158 - Logare unificată pentru JVM

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.

JEP 165 - Controlul compilatorului

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.

JEP 197 - Cache pentru cod segmentat

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:

JEP 198 - API pentru JSON

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.

JEP 199 - Compilare inteligentă, faza a II-a

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.

JEP 201 - Cod sursă modular

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.

JEP 211 - Renunțarea la avertismentele din timpul compilării la nivelul secțiunii de import

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ă.

JEP 219 - Securitate pentru transportul datagramelor

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).

JEP 220 - Imagini de execuție modulare

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.

JEP 224 - Adaptarea documentației Java la standardul HTML 5

JEP 231 - Renunțarea la posibilitatea de a selecta versiunea în timpului execuției unei aplicații Java

Î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.

NUMĂRUL 138 - Maps & AI

Sponsori

  • Accenture
  • BT Code Crafters
  • Accesa
  • Bosch
  • Betfair
  • MHP
  • Connatix
  • BoatyardX
  • .msg systems
  • Yardi
  • Colors in projects

INTERVIURI VIDEO