JDK 13 – Tot ce trebuie sa stii despre Text Block si noile Switch-uri

De cand Oracle a schimbat politica de incrementare a versiunilor (decizie intampinata cu multa dezamagire de mai multi experti din domeniu) – update-urile au inceput sa se contureze, tinzand catre modelul altor tehnologii aflate pe piata in momentul de fata. Odata cu JDK 13, s-au introdus cateva schimbari ale API-ului ce sta la baza Java, cat si unele elemente aditionale care sa usureze lucrul cu cele mai populare structuri de date in aplicatiile enterprise.

            In acest articol iti voi expune modificarile introduse in aceasta versiune, alaturi de cateva bucati de cod care sa te ajute sa intelegi ce se va schimba in viata ta de programator daca alegi sa iti actualizezi proiectele existente.

JEP355 – Text Blocks (blocuri complexe de text)

Acest feature se afla inca in stadiul de Preview – adica folosirea lui poate cauza probleme in aplicatii complexe si nu este recomandat pentru proiectele aflate deja in productie.

            Motivatia care a stat la baza introducerii acestei noi reprezentari ale String-ului este nevoia programatorilor de a manipula structuri de date precum JSON sau XML in cadrul metodelor lor, fara a fi nevoie de artificii de afisare precum apendarea unui line-break ( ‘\n’ ). Asadar, daca dorim sa reprezentam un obiect de tip String pe mai multe linii, vom putea folosi o suita de 3 ghilimele, in loc de una, care era standardul pana acum. Declararea obiectului si numele sau raman aceleasi:

Exemplu String de o singura linie:

String jdkVersionName = “JDK 13”;

Exemplu String multi-line:

String myJson = “”” 
		{
                    “name” : “Java Development Kit”,
                    “version”: 13
		}
		“””;

            Tine cont de urmatoarele reguli:

  1. Nu poti initializa valoarea unui obiect de tip String de o singura linie folosind cele 3 ghilimele (“””) – facand acest lucru te vei trezi cu o eroare de forma “illegal text block open delimiter sequence, missing line terminator”.
  2. Escaparea ghilimelelor (“) in acest caz va trebui facuta doar in cazul in care se regasesc 3 ghilimele in serie, una dupa alta – deci poti reprezenta blocuri JSON, HTML si XML fara a-ti face probleme de escapare a ghilimelelor din acestea.
  3. Indentarea finala a blocului de text este dependenta de locatia celor 3 ghilimele care-l inconjoara – in exemplul de mai sus, indentarea va porni de la nivelul primului set de ghilimele, deci prima acolada din JSON va fi la nivelul 0, apoi fiecare element-copil va avea indentarea relativa la acest nivel (i.e: elementul “name” va fi la nivelul 1, etc).
  4. In exemplul de mai sus, in cazul afisarii variabilei “myJson” se va observa un rand aditional gol aflat dupa ultima acolada din reprezentarea JSON – pentru a-l elimina, poti muta cele 3 ghilimele de incheiere pe acelasi rand cu aceasta acolada.

Cum precizam mai sus, acest feature este inca in stadiul Preview – asadar, pentru a avea acces la el trebuie sa activezi tot pachetul de astfel de feature-uri prin execturea comenzii:

java --enable-preview 

Odata cu acest nou sistem de reprezentare a stringurilor multi-line, obtinem si 3 noi metode parte din clasa String:

  1. formatted() – aceasta metoda foloseste chiar valoarea stringului din care este apelat drept formatter.
  2. stripIndent() – metoda care va elimina spatiile in plus fata de indentarea standard si va lasa structura finala curata cu indentare standard.
  3. translateEscapes() – metoda care va inlocui caracterele de escapare (precum \r) cu valoarea lor Unicode.

Poti citi mai multe despre TextBlock aici si aici.

JEP354 – Expresii switch noi

            In minunatul univers al structurilor decizionale ale limbajului Java, cel mai refactorizat bloc este switch-ul. Dupa update-ul “major” care ne-a permis sa facem switch peste String-uri, baietii s-au gandit putin la scenariile de utilizare a acestei structuri, rezultand un artificiu interesant si folositor in peste 70% din cazurile din lumea reala.

            Eu unul evit switch-urile cat mai mult deoarece nu consider ca sunt usor de inteles pentru orice alta persoana care interactioneaza cu codul meu si, poate cel mai important, este foarte complicat de refactorizat sau actualizat. De multe ori am vazut cum oamenii folosesc switch-ul ca o portita spre spaghetti code si am citit astfel de blocuri de zeci de linii aflate fara noima intr-un switch ce a inceput de la 8 linii.

Pssst…: Daca vrei sa inveti Java de la 0, sau vrei sa iti aprofundezi cunostintele, am cursul perfect pentru tine – vezi aici

            Hai sa vedem ce ne permite noul switch, aflat tot in stadiul Preview:

int numberRating =  switch (starRating) {
		case ONESTAR:
		case TWOSTAR:
			yield 5;
		case THREESTAR:
			yield 7;
		case FOURSTAR:
			yield 9;
		case FIVESTAR:
			yield 10;
		default:
			throw new IllegalStateException(“Star not identified: “ + starRating);
		}

Asadar, daca vrem sa schimbam valoarea unei variabile in functie de branch-ul de switch in care intra conditia noastra, vom putea folosi yield + valoare in loc de asignarea valorii + break; cum eram obisnuiti pana acum – eu stiu sigur ca voi putea inlocui multe if/else si switch-uri vechi cu aceasta noua structura.

            Ai grija la tratarea cazului default, pentru ca poti ajunge in situatia in care nu poti trata logic exceptia aruncata. In cazul in care vrei o valoare default a variabilei schimbate, asigura-te ca se potriveste cu logica de business unde o folosesti. Riscurile acestui nou switch sunt asemanatoare cu cele ale transformarilor lambda ale structurilor din Java 5 / 6 / 7, nu te grabi in a decide avantajele folosirii unei structuri decizionale sau a alteia, ci incearca pe cat posibil sa gasesti cea mai sustenabila metoda de a-ti scrie codul.

Concluzie

Nu uita ca stadiul Preview aduce cu sine posibile buguri sau lipsuri in implementarea noilor functionalitati si ca te poti trezi cu metodele marcate drept deprecated de la o versiune la alta. De altfel vei observa ca metodele noi din String sunt deja marcate astfel in ideea in care, in functie de feedback-ul developerilor, ele pot suferi modificari sau pot fi chiar eliminate si te vei trezi cu erori de compilare greu de digerat.

            Daca iti place sa experimentezi sau vrei sa fii cu un pas in fata ciclului de update-uri JDK, incearca sa alegi 2-3 clase dintr-un proiect in care se preteaza una din cele doua noi concepete si treci la refactorizat – nu uita sa creezi un branch nou in care sa remodelezi codul si, in cazul in care ele vor iesi din preview neafectate, vei un avantaj maricel in ceea ce priveste nivelul tehnologic la care se va afla aplicatia ta.

Lasă un comentariu

Adresa ta de email nu va fi publicată. Câmpurile obligatorii sunt marcate cu *