{"id":165062,"date":"2026-03-17T23:11:55","date_gmt":"2026-03-17T21:11:55","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm"},"modified":"2026-03-17T23:11:55","modified_gmt":"2026-03-17T21:11:55","slug":"vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pt\/blog\/news\/vypusk-java-se-26-i-openjdk-26-proekt-po-integraczii-podderzhki-javascript-i-python-v-jvm","title":{"rendered":"Lan\u00e7amento do Java SE 26 e OpenJDK 26. O projeto de integra\u00e7\u00e3o de suporte a JavaScript e Python na JVM.","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Ap\u00f3s seis meses de desenvolvimento, a Oracle lan\u00e7ou a plataforma Java SE 26 (Java Platform, Standard Edition 26), sendo o projeto aberto OpenJDK utilizado como implementa\u00e7\u00e3o de refer\u00eancia. Exceto pela remo\u00e7\u00e3o de alguns recursos obsoletos, o Java SE 26 mant\u00e9m a compatibilidade com vers\u00f5es anteriores da plataforma Java \u2014 a maioria dos projetos Java escritos anteriormente funcionar\u00e1 sem altera\u00e7\u00f5es ao serem executados na nova vers\u00e3o. As vers\u00f5es pr\u00e9-compiladas do Java SE 26 (JDK, JRE e Server JRE) est\u00e3o dispon\u00edveis para Linux (x86_64, AArch64), Windows (x86_64) e macOS (x86_64, AArch64). A implementa\u00e7\u00e3o de refer\u00eancia do Java SE 26, desenvolvida como parte do projeto OpenJDK, \u00e9 totalmente aberta sob a licen\u00e7a GPLv2 com exce\u00e7\u00f5es do GNU ClassPath, permitindo vincula\u00e7\u00e3o din\u00e2mica com produtos comerciais. <\/p>\n
O Java SE 26 \u00e9 classificado como uma vers\u00e3o de suporte comum, com atualiza\u00e7\u00f5es sendo lan\u00e7adas at\u00e9 o pr\u00f3ximo lan\u00e7amento. Para vers\u00f5es com suporte prolongado (LTS), deve-se utilizar Java SE 25, Java SE 21 ou Java SE 17, cujas atualiza\u00e7\u00f5es ser\u00e3o disponibilizadas at\u00e9 2033, 2031 e 2029, respectivamente (p\u00fablicas at\u00e9 setembro de 2030, 2028 e 2026). O suporte ampliado da linha LTS do Java SE 8 se estender\u00e1 at\u00e9 2030, enquanto o Java SE 11 at\u00e9 2032. <\/p>\n
As mudan\u00e7as no Java SE 26 (1, 2, 3, 4): <\/p>\n
\n
Foi implementada uma advert\u00eancia ao usar reflex\u00e3o profunda para modificar campos marcados com a palavra-chave \u2018final\u2019. No futuro, est\u00e1 previsto desabilitar por padr\u00e3o recursos inseguros da linguagem e, entre outras coisas, tornar os campos marcados como final completamente imut\u00e1veis, eliminando a maneira de alter\u00e1-los por meio de reflex\u00e3o profunda (API Reflection).\n
A API Applet (java.applet.Applet*, javax.swing.JApplet) foi removida, a qual era utilizada para executar aplicativos Java em navegadores. Essa API tornou-se obsoleta ap\u00f3s o fim do suporte ao plugin Java para navegadores e foi declarada obsoleta em 2021.\n
Foi implementada a possibilidade de usar cache pr\u00e9-compilado (AOT \u2014 ahead-of-time) com quaisquer coletores de lixo, incluindo ZGC (Z Garbage Collector). A mudan\u00e7a implica no suporte \u00e0 carga sequencial de objetos Java em cache para a mem\u00f3ria, utilizando um formato universal e independente do coletor de lixo, em vez de mapeamento direto para as representa\u00e7\u00f5es espec\u00edficas do cache na mem\u00f3ria. O uso do cache AOT reduz o tempo de inicializa\u00e7\u00e3o e acelera a atualiza\u00e7\u00e3o da m\u00e1quina virtual HotSpot.\n
Na API HTTP Client, foi adicionada a compatibilidade com o protocolo HTTP\/3, permitindo que aplicativos e bibliotecas acessem servidores via HTTP\/3 ap\u00f3s altera\u00e7\u00f5es m\u00ednimas no c\u00f3digo.\n
Aumentou-se o desempenho do coletor de lixo G1, gra\u00e7as \u00e0 redu\u00e7\u00e3o de bloqueios para sincroniza\u00e7\u00e3o entre threads de aplicativo e threads do coletor de lixo.\n
Um segundo pr\u00e9-lan\u00e7amento da API foi proposto para codifica\u00e7\u00e3o e decodifica\u00e7\u00e3o de objetos com chaves criptogr\u00e1ficas, certificados e listas de certificados revogados, utilizando o formato PEM (Pivacy-Enhanced Mail).\n
Foi proposto para testes o sexto pr\u00e9-lan\u00e7amento da API de concorr\u00eancia estruturada (Structured Concurrency), simplificando o desenvolvimento de aplicativos multithread ao tratar v\u00e1rias tarefas executadas em diferentes threads como um \u00fanico bloco.\n
Foi adicionada a segunda vers\u00e3o preliminar da API Lazy Constants para trabalhar com objetos que cont\u00eam dados imut\u00e1veis e s\u00e3o processados na JVM como constantes. A essas entidades aplicam-se otimiza\u00e7\u00f5es de desempenho semelhantes \u00e0quelas dos campos com a palavra-chave \"final\". Diferente do \"final\", a nova API separa a cria\u00e7\u00e3o de valores constantes de sua inicializa\u00e7\u00e3o, garantindo que o valor possa ser inicializado apenas uma vez, reduzindo o tempo de inicializa\u00e7\u00e3o dos programas e permitindo que otimiza\u00e7\u00f5es de dobra de constantes (constant-folding), anteriormente usadas somente no c\u00f3digo interno do JDK, sejam aplicadas no c\u00f3digo do usu\u00e1rio. class Application { \/\/ Antes: \/\/ static final UserService USERS = new UserService(); \/\/ Agora \u00e9 poss\u00edvel: static final StableValue USERS = StableValue.of(); public static UserService users() { return USERS.orElseSet(UserService::new); } }\n
No mecanismo de correspond\u00eancia de padr\u00f5es, foi proposta uma quarta vers\u00e3o preliminar da possibilidade de uso de tipos primitivos (int, byte, char e outros tipos b\u00e1sicos que n\u00e3o s\u00e3o objetos) em todos os tipos de padr\u00f5es, no operador \"instanceof\" e em blocos \"switch\". switch (x.getStatus()) { case 0 -> \"okay\"; case 1 -> \"warning\"; case 2 -> \"error\"; case int i -> \"status desconhecido: \" + i; } if (i instanceof byte b) { ... b ... }\n
Foi proposta uma d\u00e9cima primeira implementa\u00e7\u00e3o de teste da API Vector, que fornece fun\u00e7\u00f5es para c\u00e1lculos vetoriais realizados usando instru\u00e7\u00f5es vetoriais dos processadores x86_64 e AArch64, permitindo aplicar opera\u00e7\u00f5es simultaneamente a v\u00e1rios valores (SIMD). Diferentemente das capacidades de vetoriza\u00e7\u00e3o autom\u00e1tica de opera\u00e7\u00f5es escalares oferecidas pelo compilador JIT HotSpot, a nova API oferece a possibilidade de gerenciar explicitamente a vetoriza\u00e7\u00e3o para processamento paralelo de dados. <\/ul>\n
Al\u00e9m disso, a Oracle anunciou o projeto Detroit, que se desenvolver\u00e1 dentro do OpenJDK e visa melhorar a portabilidade entre Java, JavaScript e Python. No \u00e2mbito do projeto, pretende-se oferecer a capacidade de incorpora\u00e7\u00e3o no runtime da JVM com o motor JavaScript V8 e o interpretador CPython. Anteriormente, a Oracle havia desenvolvido o motor JavaScript Nashorn, que funcionava sobre a m\u00e1quina virtual JVM, mas interrompeu o projeto devido \u00e0 dificuldade de desenvolver uma implementa\u00e7\u00e3o separada do JavaScript em um contexto em que o ecossistema principal \u00e9 baseado no motor V8. <\/p>\n
Adicionalmente, podemos notar a publica\u00e7\u00e3o da atualiza\u00e7\u00e3o da plataforma para a cria\u00e7\u00e3o de aplicativos com a interface gr\u00e1fica JavaFX 26. Nas pr\u00f3ximas horas, tamb\u00e9m se espera o lan\u00e7amento da m\u00e1quina virtual universal GraalVM 26, que suporta a execu\u00e7\u00e3o de aplicativos em JavaScript (Node.js), Python, Ruby, R, quaisquer idiomas para JVM (Java, Scala, Clojure, Kotlin) e idiomas para os quais pode ser gerado c\u00f3digo bitcode LLVM (C, C++, Rust). \n Fonte: opennet.ru<\/a> <\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"