Despois de seis meses de desenvolvemento, Oracle plataforma (Java Platform, Standard Edition 15), o proxecto OpenJDK de código aberto úsase como implementación de referencia. Java SE 15 mantén a compatibilidade con versións anteriores da plataforma Java; todos os proxectos Java escritos anteriormente funcionarán sen cambios cando se executen baixo a nova versión. Compilacións Java SE 15 listas para instalar (JDK, JRE e Server JRE) para Linux (x86_64), Windows e macOS. Implementación de referencia desenvolvida polo proxecto OpenJDK é de código aberto totalmente baixo a licenza GPLv2, con excepcións de GNU ClassPath que permiten conexións dinámicas con produtos comerciais.
Java SE 15 está clasificado como versión de soporte xeral e seguirá recibindo actualizacións ata a próxima versión. A rama de Soporte a longo prazo (LTS) debería ser Java SE 11, que seguirá recibindo actualizacións ata 2026. A anterior rama LTS de Java 8 será compatible ata decembro de 2020. O próximo lanzamento de LTS está programado para setembro de 2021. Lembrámosvos que a partir do lanzamento de Java 10, o proxecto pasou a un novo proceso de desenvolvemento, o que implica un ciclo máis curto para a formación de novos lanzamentos. Agora desenvólvese unha nova funcionalidade nunha rama mestra que se actualiza constantemente, que inclúe cambios xa feitos e da que se ramifican cada seis meses para estabilizar as novas versións.
De :
- soporte para o algoritmo de creación de sinatura dixital EdDSA (Edwards-Curve Digital Signature Algorithm) ). A implantación proposta de EdDSA non depende de plataformas de hardware, está protexida de ataques de canle lateral (garantizase o tempo constante de todos os cálculos) e ten un rendemento máis rápido que a implementación ECDSA existente escrita en linguaxe C, co mesmo nivel de protección. Por exemplo, EdDSA que utiliza unha curva elíptica cunha clave de 126 bits presenta un rendemento similar ao de ECDSA cunha curva elíptica secp256r1 e unha clave de 128 bits.
- soporte experimental para clases e interfaces seladas, que non poden ser usadas por outras clases e interfaces para herdar, estender ou anular a implementación. As clases seladas tamén proporcionan un xeito máis declarativo de restrinxir o uso dunha superclase que os modificadores de acceso, baseándose na lista explícita das subclases permitidas para a extensión.
paquete com.example.xeometry;
clase pública selada Forma
permite com.example.polar.Circle,
com.example.quad.Rectángulo,
com.example.quad.simple.Square {…} - soporte para clases ocultas que non poden ser utilizadas directamente polo bytecode doutras clases. O propósito fundamental das clases ocultas é usar en marcos que xeran clases dinámicamente en tempo de execución e utilízanas indirectamente, a través de . Tales clases adoitan ter un ciclo de vida limitado, polo que mantelas para o acceso desde as clases xeradas de forma estática non está xustificada e só levará a un aumento do consumo de memoria. As clases ocultas tamén eliminan a necesidade da API non estándar sun.misc.Unsafe::defineAnonymousClass, que está programada para a súa eliminación no futuro.
- O colector de lixo ZGC (Z Garbage Collector) foi estabilizado e está recoñecido como preparado para un uso xeneralizado. ZGC funciona en modo pasivo, minimiza a latencia debido á recollida de lixo na medida do posible (o tempo de parada cando se usa ZGC non supera os 10 ms.) e pode funcionar tanto con montóns pequenos como enormes, que van desde varios centos de megabytes ata moitos terabytes.
- Estabilizado e listo para uso xeral
colector de lixo , traballando con pausas mínimas (Recollidor de lixo de baixo tempo de pausa). Shenandoah foi desenvolvido por Red Hat e destaca polo uso dun algoritmo que reduce o tempo de parada durante a recollida do lixo ao executar a limpeza en paralelo coa execución de aplicacións Java. O tamaño dos atrasos introducidos polo colector de lixo é previsible e non depende do tamaño do montón, é dicir. para pilas de 200 MB e 200 GB os atrasos serán idénticos ( máis alá de 50 ms e normalmente dentro de 10 ms); - O apoio estabilizouse e introduciuse na lingua - unha nova forma de literais de cadea que lle permite incluír datos de texto de varias liñas no código fonte sen usar escape de caracteres e conservando o formato de texto orixinal no bloque. O bloque está enmarcado por tres comiñas dobres.
Por exemplo, no canto de código
String html = " » +
"\n\t" + " » +
"\n\t\t" + " \"Java 1 xa está aquí\" » +
"\n\t" + " » +
"\n" + " ";podes especificar:
String html = """
»Java 1\
é aquí!
"""; - API DatagramSocket heredada. As implementacións antigas de java.net.DatagramSocket e java.net.MulticastSocket foron substituídas por unha implementación moderna que é máis fácil de depurar e manter, e tamén compatible con fluxos virtuais desenvolvidos dentro do proxecto. . En caso de posible incompatibilidade co código existente, a implementación antiga non se eliminou e pódese activar mediante a opción jdk.net.usePlainDatagramSocketImpl.
- Segunda implementación experimental proposta no operador "instanceof", que permite definir inmediatamente unha variable local para acceder ao valor marcado. Por exemplo, pode escribir inmediatamente "se (obj instanceof String s && s.length() > 5) {.. s.contains(..) ..}" sen definir explícitamente "String s = (String) obj".
Foi:
if (obj instancia do grupo) {
Grupo grupo = (Grupo) obj;
entradas var = group.getEntries();
}Agora podes prescindir da definición "Group group = (Group) obj":
if (obj instanceof Group Group) {
entradas var = group.getEntries();
} - segunda implementación experimental da palabra clave "", que proporciona unha forma compacta para definir clases, o que lle permite evitar definir explícitamente varios métodos de baixo nivel como equals(), hashCode() e toString() nos casos en que os datos se almacenan só en campos cuxo comportamento non cambia. Cando unha clase usa implementacións estándar dos métodos equals(), hashCode() e toString(), pode prescindir da súa definición explícita:
rexistro público Transacción bancaria (data LocalDate,
dobre cantidade
Descrición da cadea) {}Esta declaración engadirá automaticamente implementacións dos métodos equals(), hashCode() e toString() ademais dos métodos construtor e getter.
- unha segunda vista previa da API de acceso á memoria estranxeira, que permite ás aplicacións Java acceder de forma segura e eficiente a rexións de memoria fóra do montón de Java manipulando as novas abstraccións MemorySegment, MemoryAddress e MemoryLayout.
- e desaprobou a técnica de optimización de bloqueo sesgado usada na JVM HotSpot para reducir a sobrecarga de bloqueo. Esta técnica perdeu a súa relevancia en sistemas con instrucións atómicas proporcionadas polas CPU modernas, e é demasiado laboriosa para manter debido á súa complexidade.
- mecanismo obsoleto , que se eliminará nunha versión futura. Nótase que a activación RMI está desactualizada, relegada á categoría de opción en Java 8 e case nunca se usa na práctica moderna.
- Motor JavaScript , que estaba en desuso en Java SE 11.
- portos para os procesadores Solaris OS e SPARC (Solaris/SPARC, Solaris/x64 e Linux/SPARC). A eliminación destes portos permitirá á comunidade acelerar o desenvolvemento de novas funcións de OpenJDK sen perder tempo en manter as funcións específicas de Solaris e SPARC.
Fonte: opennet.ru