Versiunea Long-Term-Support (LTS) a limbajului Java și a platformei de rulare Java 17 a fost lansată pe 14 septembrie 2021. Să aflăm ce este nou în Java 17 și dacă ar trebui să faceți upgrade.
Multe aplicații folosesc versiuni mai vechi de Java, inclusiv versiunile LTS anterioare ale Java: Java 11 și Java 8.
De ce ar trebui companiile să facă upgrade la cea mai recentă versiune Java? Upgrade-ul la Java 17 necesită efort, în principal pentru a profita la maximum de noile caracteristici și funcții din interiorul JVM.
Multe companii folosesc imagini Docker și Docker pentru a trece cu ușurință la Java 17, cu efort și timp minim. Dezvoltatorii își pot defini conductele de integrare/implementare continuă (CI/CD) și pot rula totul în imaginile Docker. Acest lucru nu va afecta alte echipe care utilizează versiuni Java mai vechi, deoarece pot utiliza imagini Docker vechi.
Cuprins
Caracteristici JAVA 17
Asistență macOS și AArch64
Una dintre caracteristicile JVM critice adăugate acestei versiuni este îmbunătățirea suportului pentru macOS pe arhitectura AArch64 folosind JEP 391. Acesta va suporta cea mai recentă serie de procesoare (M1) lansată de Apple împreună cu computerele lor în ultimul an.
Nu este neapărat o mare problemă pentru utilizatorii de pe acele platforme, deoarece unii furnizori au lansat versiuni de JDK care acceptă această arhitectură și chiar returnează suport de la Java 8. Cu toate acestea, sigiliul oficial de aprobare este esențial pentru a asigura întreținerea și suportul viitoare pentru platforma. În comparație, suportul pentru platforma Linux/AArch64 a fost adăugat la Java 9 și Windows/AArch64 în Java 16.
Clase sigilate
Sealed Classes este o caracteristică care a fost introdusă în Java 17. Caracteristica sealed Classes și-a încheiat faza de probă și a devenit o platformă și un limbaj oficial în Java 17. Permite unui dezvoltator să specifice subtipurile permise pe care le poate avea un tip și împiedică alții să o extindă sau să o implementeze într-un mod care nu este intenționat.
De asemenea, clasele sigilate permit compilatorului să genereze erori în timpul compilării atunci când încercați să convertiți un tip nesigilat într-un subtip nepermis. Java 17 aduce, de asemenea, o nouă conductă de randare pentru aplicațiile AWT/Swing care rulează pe macOS folosind API-ul Apple Metal în loc de OpenGL. Are un API îmbunătățit și funcții îmbunătățite pentru a genera numere aleatorii.
Modificări, ștergeri și limitări în Java 17
Java 17 aduce, de asemenea, mai multe modificări, ștergeri și noi limitări.
Încapsularea JDK Internals
O schimbare este încheierea procesului de încapsulare a JDK Internals. Prima dată când aceasta a fost introdusă a fost în Java 9 și ar oferi avertismente în timpul rulării atunci când un utilizator încerca să folosească reflection sau similar pentru a evita restricțiile obișnuite privind utilizarea API-urilor interne. Argumentele din linia de comandă au fost, de asemenea, adăugate pentru a reglementa acest comportament.
Din Java 9, au fost create diverse API-uri pentru a oferi o modalitate uniformă de a efectua sarcinile cele mai frecvent utilizate; utilizatorii ar utiliza aceste API-uri intern. Cu Java 16, valoarea implicită a fost schimbată de la un avertisment la dezactivarea accesului la lansarea unei excepții. Cu toate acestea, folosește argumentul liniei de comandă pentru a modifica comportamentul.
Cu Java 17, argumentul liniei de comandă este eliminat și este posibil să se dezactiveze această restricție. Aceasta înseamnă că tot accesul neautorizat la acele API-uri interne este acum protejat.
Semantică întotdeauna strictă în virgulă mobilă
O „înlăturare” suplimentară poate fi descrisă ca reintroducerea semanticii în virgulă mobilă întotdeauna strictă. Java 1.2 a introdus modificări la semantica implicită în virgulă mobilă în Java, care permite JVM-ului să tranzacționeze o cantitate mică de precizie în calculele în virgulă mobilă pentru a îmbunătăți performanța. În clasele și metodele în care trebuia folosită semantică strictă, a fost adăugat un cuvânt cheie strictfp. De atunci, diferite tipuri de seturi de instrucțiuni au fost introduse în procesoare, făcând ca semantica strictă în virgulă mobilă să fie utilizată fără costuri inutile. Necesitatea implementării unei semantici implicite sau stricte a fost eliminată.
Java 17 elimină semantica implicită anterioară și toate operațiunile în virgulă mobilă sunt executate strict. Termenul strictfpis încă prezent. Cu toate acestea, nu are niciun efect și provoacă un avertisment în timpul compilării.
Compilare Ahead-of-Time (AOT).
Java 9 a introdus compilarea ahead-of-time (AOT) ca o caracteristică experimentală care utilizează compilatorul Graal, iar un cod JIT a fost scris folosind Java. Java 10 a făcut compilatorul Graal utilizabil ca compilator JIT în OpenJDK prin încorporarea interfeței JVMCI. De când a fost lansat, a fost o îmbunătățire enormă. Compilatorul Graal a cunoscut progrese extraordinare și are JVM-ul său sub numele de GraalVM.
Activare RMI
Activarea RMI a fost eliminată în JEP 407 după eliminarea sa din Java 8 și în cele din urmă depreciate și marcate ca o cerință pentru eliminare în Java 15. Activarea RMI a furnizat o metodă de a activa resursele la cerere pentru obiecte distribuite folosind RMI. Cu toate acestea, a cunoscut o utilizare minimă și o alternativă mai bună este disponibilă în prezent. Restul RMI nu este afectat de eliminarea porțiunii de activare.
Îndepărtarea API-ului Applet
API-ul Applet a fost în sfârșit desemnat pentru eliminare de către JEP 398, eliminat inițial în Java 9. API-ul Applet a oferit o modalitate de a integra controalele Java AWT/Swing într-o pagină web dintr-un browser. Cu toate acestea, niciun browser modern nu poate suporta acest lucru, ceea ce înseamnă că Appleturile au fost în esență inaccesibile în ultimul deceniu sau cam asa ceva.
Manager de securitate
Cea mai importantă depreciere este că este managerul de securitate ( JEP 411). Security Manager a fost utilizat de ceva vreme de la Java 1.0. A fost conceput pentru a restricționa ceea ce Java ar putea face local pe mașină, cum ar fi limitarea accesului la rețele, fișiere și alte resurse de rețea. De asemenea, încearcă să sandbox cod care nu este de încredere prin blocarea reflectării și API-uri specifice.
Sfârșitul Managerului de securitate a început în Java 12. A fost adăugat un argument de linie de comandă pentru a bloca utilizarea managerului de securitate în timpul execuției. Modificarea făcută în Java 17 înseamnă că va fi generată un avertisment de rulare în JVM atunci când se încearcă setarea unui Manager de securitate, fie din linia de comandă, fie dinamic în timpul rulării.
Funcții pentru incubator și previzualizare
Mulți s-au întrebat dacă Java 17 va avea caracteristici de previzualizare și incubator, având în vedere că Java 17 a fost promovat ca o versiune acceptată pe termen lung. Java 17 are două module de incubator și o funcție de previzualizare!
Vector API
Vector API ( JEP 414) se află în prezent la a doua fază a incubatorului. API-ul permite dezvoltatorilor să definească calculul vectorial pe care compilatorul JIT îl va converti apoi în instrucțiunea vectorială adecvată, suportată de arhitectura CPU pe care rulează JVM-ul (de exemplu, folosind cele din seturile de instrucțiuni SSE sau AVX).
Înainte, dezvoltatorii trebuiau să folosească funcții scalare sau să construiască biblioteci native care erau specifice platformei. Implementarea Vector API în Java oferă, de asemenea, un mecanism de rezervă fără întreruperi, care a fost complicat în versiunile anterioare.
Standardizarea Vector API permite claselor din JDK să-l folosească. Metodele de nepotrivire Java Arrays() ar putea fi modificate pentru a fi rulate pe Java, eliminând cerința de a menține și scrie mai multe implementări specifice platformei în cadrul JVM.
API-ul pentru funcții străine și memorie
O caracteristică suplimentară a incubatorului se numește API-ul Funcție străină și memorie ( JEP 412). Este o evoluție și o fuziune a altor două module incubatoare ale Java 16, care este API-ul Foreign Linker ( JEP 389) și API-ul de memorie străină ( JEP 393). Ambele oferă acces la memoria și codul nativ prin utilizarea de programare tip static scrisă în Java.
Potrivirea modelului pentru comutator
Caracteristica finală a previzualizării limbii inclusă în Java 17 este includerea Pattern Matching pentru Switch ( JEP 406). Această caracteristică de limbaj extinde expresiile și instrucțiunile de comutare în funcție de tip, similar sintaxei utilizate prin potrivirea modelelor (JEP 394), care a devenit standard cu Java 16.
În trecut, dacă doriți să efectuați diferite acțiuni bazate pe natura dinamică a unui obiect, vi se va cere să construiți un lanț if-else folosind o instanță de verificări, cum ar fi:
String type(Object o) {
if (o instanceof List) {
return "A List of things.";
}
else if (o instanceof Map) {
return "A Map! It has keys and values.";
}
else if (o instanceof String) {
return "This is a string.";
}
else {
return "This is something else.";
}
}
Combinând expresia comutatorului, precum și noua funcție de potrivire a modelului pentru comutatoare, procesul poate fi redus la ceva similar cu:
String type(Object o) {
return switch (o) {
case List l -> "A List of things.";
case Map m -> "A Map! It has keys and values.";
case String s -> "This is a string.";
default -> "This is something else.";
};
}
După cum probabil ați observat, există declararea unei variabile în procesul de verificare. Ca și celelalte variabile din Pattern, potrivirea instanței indică faptul că acest obiect a fost verificat de tip și proiectat și este disponibil din variabilă în zona sa curentă.
Funcția de previzualizare este un alt pas către potrivirea modelelor. Următorul pas este să includeți capacitatea de a deconstrui matrice și înregistrări.
Ar trebui să faceți upgrade la Java 17?
Da, trebuie să faceți upgrade constant la cea mai recentă versiune, dar nu de îndată ce prima zi. Este posibil ca software-ul și bibliotecile pe care le utilizați să nu fi fost actualizate pentru a include compatibilitatea cu Java 17, așa că ar putea fi necesar să așteptați ceva timp până când se termină.
Dacă sunteți blocat cu o versiune LTS de Java, cum ar fi Java 8 sau Java 11, există numeroase opțiuni în limbaj și în JVM în sine care necesită o actualizare până la Java 17. Fiind o versiune de întreținere pe termen lung, există o șansă mare ca mediul dumneavoastră de producție să fie în cele din urmă actualizat și la Java 17.
Dacă începeți un proiect complet nou sau sunteți în proces de pregătire și pregătire a proiectului pentru Java 17, trecerea la Java 17 mai devreme decât mai târziu este probabil cea mai eficientă alegere, deoarece reduce costurile de mutare. Acest lucru permite, de asemenea, dezvoltatorilor care lucrează la proiect să utilizeze toate cele mai recente caracteristici și partea operațională.
Puteți profita de numeroasele îmbunătățiri care au apărut în ultimii ani, cum ar fi suport îmbunătățit pentru containerele care rulează pe Java, precum și noile implementări de colectare a gunoiului cu latență redusă.