Després de sis mesos de desenvolupament, Oracle plataforma (Java Platform, Standard Edition 15), el projecte OpenJDK de codi obert s'utilitza com a implementació de referència. Java SE 15 manté la compatibilitat amb versions anteriors de la plataforma Java tots els projectes Java escrits anteriorment funcionaran sense canvis quan s'executen amb la nova versió. Compil·lacions de Java SE 15 llestes per instal·lar (JDK, JRE i Server JRE) per a Linux (x86_64), Windows i macOS. Implementació de referència desenvolupada pel projecte OpenJDK és de codi obert totalment sota la llicència GPLv2, amb excepcions de GNU ClassPath que permeten l'enllaç dinàmic amb productes comercials.
Java SE 15 es classifica com una versió de suport general i continuarà rebent actualitzacions fins a la propera versió. La branca de suport a llarg termini (LTS) hauria de ser Java SE 11, que continuarà rebent actualitzacions fins al 2026. La branca LTS anterior de Java 8 serà compatible fins al desembre de 2020. El proper llançament de LTS està programat per al setembre de 2021. Us recordem que a partir del llançament de Java 10, el projecte va passar a un nou procés de desenvolupament, la qual cosa implicava un cicle més curt per a la formació de nous llançaments. Ara es desenvolupa una nova funcionalitat en una branca mestra que s'actualitza constantment, que inclou canvis ja fets i des de la qual es ramifiquen cada sis mesos per estabilitzar les noves versions.
D' :
- suport per a l'algoritme de creació de signatura digital EdDSA (Edwards-Curve Digital Signature Algorithm) ). La implementació EdDSA proposada no depèn de les plataformes de maquinari, està protegida dels atacs de canal lateral (es garanteix un temps constant de tots els càlculs) i té un rendiment més ràpid que la implementació ECDSA existent escrita en llenguatge C, amb el mateix nivell de protecció. Per exemple, EdDSA que utilitza una corba el·líptica amb una clau de 126 bits presenta un rendiment similar a l'ECDSA amb una corba el·líptica secp256r1 i una clau de 128 bits.
- suport experimental per a classes i interfícies segellades, que no poden ser utilitzades per altres classes i interfícies per heretar, ampliar o anul·lar la implementació. Les classes segellades també proporcionen una manera més declarativa de restringir l'ús d'una superclasse que els modificadors d'accés, basant-se en una llista explícita de les subclasses permeses per a l'extensió.
paquet com.example.geometry;
Forma de classe pública segellada
permet com.example.polar.Circle,
com.example.quad.Rectangle,
com.example.quad.simple.Square {…} - suport per a classes ocultes que no es poden utilitzar directament pel bytecode d'altres classes. El propòsit clau de les classes ocultes és utilitzar-les en marcs que generen classes dinàmicament en temps d'execució i les utilitzen indirectament, mitjançant . Aquestes classes solen tenir un cicle de vida limitat, de manera que mantenir-les per accedir des de classes generades estàticament no es justifica i només comportarà un augment del consum de memòria. Les classes ocultes també eliminen la necessitat de l'API no estàndard sun.misc.Unsafe::defineAnonymousClass, que està previst que s'elimini en el futur.
- El col·lector d'escombraries ZGC (Z Garbage Collector) s'ha estabilitzat i es reconeix com a llest per a un ús generalitzat. ZGC funciona en mode passiu, minimitza la latència a causa de la recollida d'escombraries tant com sigui possible (el temps d'aturada quan s'utilitza ZGC no supera els 10 ms.) i pot funcionar tant amb munts petits com grans, amb una mida que oscil·la entre diversos centenars de megabytes a molts terabytes.
- Estabilitzat i preparat per a ús general
abocador , treballant amb pauses mínimes (Recollidor d'escombraries de baixa pausa). Shenandoah va ser desenvolupat per Red Hat i destaca per l'ús d'un algorisme que redueix el temps d'aturada durant la recollida d'escombraries executant la neteja en paral·lel amb l'execució d'aplicacions Java. La mida dels retards introduïts pel recol·lector d'escombraries és previsible i no depèn de la mida del munt, és a dir. per a munts de 200 MB i 200 GB els retards seran idèntics ( més enllà de 50 ms i normalment dins dels 10 ms); - S'ha estabilitzat el suport i s'ha introduït a la llengua - una nova forma de literals de cadena que us permet incloure dades de text de diverses línies al codi font sense utilitzar l'escapament de caràcters i conservant el format del text original al bloc. El bloc està emmarcat per tres cometes dobles.
Per exemple, en lloc de codi
String html = " » +
"\n\t" + " » +
"\n\t\t" + " \"Java 1 ja és aquí!" » +
"\n\t" + " » +
"\n" + " ";pots especificar:
String html = """
»Java 1\
és aquí!
"""; - API DatagramSocket heretada. Les antigues implementacions de java.net.DatagramSocket i java.net.MulticastSocket s'han substituït per una implementació moderna que és més fàcil de depurar i mantenir, i també és compatible amb els fluxos virtuals desenvolupats dins del projecte. . En cas de possible incompatibilitat amb el codi existent, la implementació antiga no s'ha eliminat i es pot activar mitjançant l'opció jdk.net.usePlainDatagramSocketImpl.
- Segona implementació experimental proposada a l'operador "instanceof", que us permet definir immediatament una variable local per accedir al valor marcat. Per exemple, podeu escriure immediatament "si (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}" sense definir explícitament "String s = (String) obj".
Era:
if (obj instanceof Group) {
Grup grup = (Grup) obj;
var entrades = group.getEntries();
}Ara podeu prescindir de la definició "Group group = (Group) obj":
if (instància objecte del grup del grup) {
var entrades = group.getEntries();
} - segona implementació experimental de la paraula clau "", que proporciona una forma compacta per definir classes, que us permet evitar definir explícitament diversos mètodes de baix nivell com ara equals(), hashCode() i toString() en els casos en què les dades només s'emmagatzemen en camps el comportament dels quals no canvia. Quan una classe utilitza implementacions estàndard dels mètodes equals(), hashCode() i toString(), pot prescindir de la seva definició explícita:
registre públic Transacció bancària (data LocalDate,
doble quantitat
descripció de la cadena) {}Aquesta declaració afegirà automàticament implementacions dels mètodes equals(), hashCode() i toString() a més dels mètodes constructor i getter.
- una segona vista prèvia de l'API d'accés a la memòria estrangera, que permet a les aplicacions Java accedir de manera segura i eficient a les regions de memòria fora del munt de Java manipulant les noves abstraccions MemorySegment, MemoryAddress i MemoryLayout.
- i va desaprovar la tècnica d'optimització de bloqueig esbiaixat utilitzada a la JVM HotSpot per reduir la sobrecàrrega de bloqueig. Aquesta tècnica ha perdut la seva rellevància en sistemes amb instruccions atòmiques proporcionades per les CPU modernes, i és massa laboriosa per mantenir-la a causa de la seva complexitat.
- mecanisme obsolet , que s'eliminarà en una versió futura. Cal assenyalar que l'activació RMI està obsoleta, relegada a la categoria d'una opció a Java 8 i gairebé mai s'utilitza a la pràctica moderna.
- Motor JavaScript , que estava obsolet a Java SE 11.
- ports per als processadors Solaris OS i SPARC (Solaris/SPARC, Solaris/x64 i Linux/SPARC). L'eliminació d'aquests ports permetrà a la comunitat accelerar el desenvolupament de noves funcions d'OpenJDK sense perdre temps mantenint les funcions específiques de Solaris i SPARC.
Font: opennet.ru