Lançamento oficial do Java 25 / JDK 25

• Java 25 e sua implementação de referência JDK 25 foram lançados oficialmente
• Esta versão inclui 18 novos JEPs (Java Enhancement Proposal)
• Foram aplicadas mudanças importantes como remoção da porta x86 de 32 bits, Scoped Values, Structured Concurrency e melhorias em Primitive Types

---

Java 25 / JDK 25: lançamento oficial

• O JDK 25, ou seja, a implementação de referência do Java 25, foi lançado oficialmente como versão pronta para produção
• Em 15 de agosto de 2025, foi disponibilizado o segundo release candidate, build 36, e desde então não houve relatos de bugs críticos (P1).
• O build 36 é a versão final GA (General Availability) e pode ser usado também em ambientes de produção

• O build OpenJDK baseado em licença GPL é fornecido oficialmente pela Oracle, e versões compiladas por vários outros fornecedores também devem ser distribuídas em breve

Link oficial de download do OpenJDK

Principais recursos e melhorias

Este lançamento inclui 18 JEPs (Java Enhancement Proposal)

• 470: Codificação de objetos criptográficos baseada em PEM (preview)
• 502: Stable Values (preview)
• 503: Remoção da porta x86 de 32 bits
• 505: Structured Concurrency (5º preview)
• 506: Scoped Values
• 507: Suporte a Primitive Types em pattern, instanceof e switch (3º preview)
• 508: Vector API (10ª versão incubadora)
• 509: Perfilamento de tempo de CPU no JFR (recurso experimental)
• 510: Key Derivation Function API
• 511: Declarações de importação de módulo
• 512: Compact Source Files e método main de instância
• 513: Flexible Constructor Bodies
• 514: Otimização Ahead-of-Time da linha de comando
• 515: Perfilamento de métodos Ahead-of-Time
• 518: Amostragem cooperativa do JFR
• 519: Compact Object Headers
• 520: Temporização e rastreamento de métodos no JFR
• 521: Generational Shenandoah

Além dos JEPs acima, esta versão também incorpora centenas de pequenas melhorias de funcionalidades e milhares de correções de bugs

Mais informações sobre o lançamento e os detalhes dos JEPs podem ser consultados na
página do projeto OpenJDK JDK 25

[ahwjdekf]

O mesmo mala do ano passado não morreu e voltou de novo, eeeh, lá vai ele... por que você fica aparecendo toda hora?

[click]

É um recurso que entrou no JDK 24, mas como há uma forte tendência de usar apenas versões LTS em Java, também vale destacar que, com o JEP 491: Synchronize Virtual Threads without Pinning, o fenômeno de pinning das virtual threads ao usar a palavra-chave synchronized deixou de existir.
Em benchmarks de virtual threads no mundo real, às vezes o desempenho era pior, e na maioria dos casos a causa era o pinning.

[GN⁺]

Opiniões do Hacker News

• Acho que mais programas novos deveriam ser escritos em Java ou sobre a JVM; quase todos os motivos da queda de popularidade do Java no passado praticamente desapareceram, e hoje o ecossistema é muito estável e maduro. Um programa em Clojure que escrevi há 10 anos ainda roda sem problema, enquanto programas escritos em TypeScript precisam de manutenção e atualizações em 6 meses.
  • A questão com a Oracle pesa bastante; é incômodo ter que tomar cuidado para não violar a EULA da Oracle ao usar Java. Talvez usar OpenJDK resolva, mas eu preferiria usar outra linguagem sem essa preocupação. C# também oferece um ambiente parecido com o Java e pode ser usado sem preocupação com a Oracle. Acho melhor simplesmente escolher outra linguagem do que estudar como usar Java com segurança. Java também não é algo indispensável, então há muitas alternativas.
  • Java continua extremamente popular e amplamente usado em grandes sistemas de backend. Fico surpreso que pareça haver pouca gente aqui lidando com esse tipo de sistema. Pela minha experiência, quase sempre encontro Java.
  • Tenho uma esperança discreta de que Kotlin e Compose tragam de volta os apps desktop na JVM.
  • Acho que a área em que Java continua correndo risco em termos de adoção é a cultura ao redor dele. Desenvolvedores Java antigos e programas Java legados costumam ser escritos de forma desnecessariamente verbosa, mesmo que a linguagem em si já tenha recursos para escrever de forma concisa como outras linguagens modernas. Ainda assim, Java é grande o bastante para conseguir mudar.
  • Fico curioso se o fato de um programa em Clojure de 10 anos atrás ainda funcionar bem é mérito da JVM ou do estilo próprio do Clojure. Também tive experiência parecida com projetos em ClojureScript; scripts antigos de nbb ainda rodam direto sem grandes problemas (às vezes só precisa ajustar um pouco as dependências do npm). Já com Python, às vezes passo meio dia sofrendo com dependências e gerenciamento de venv.
• Java tem sido por muito tempo uma base técnica surpreendentemente sólida. Não é a linguagem mais atraente, mas sempre mostra estabilidade. Um app feito em Java 1.4 roda bem em Java 21 LTS, e pretendo migrar em breve para Java 25. Java é bom demais.
  • Fico imaginando onde o Java estaria hoje sem as excelentes ferramentas da JetBrains e seu inteligente programa para estudantes.
  • Mantendo certa distância, ainda lembro do app do Gmail feito em Java que rodava no meu celular Symbian touch em 2009. Era realmente fofo e funcionava muito bem.
  • Pela minha experiência, não concordo totalmente. Em várias empresas, toda vez que aumentávamos a versão da JVM sempre havia grandes problemas, muito retrabalho e necessidade de reteste. Parei por volta do Java 17~18, mas as pessoas com quem trabalho quase nunca usavam versões novas. Em 2022, em um projeto, precisei atualizar uma JVM 1.5, mas bibliotecas terceiras importantes só suportavam versões anteriores ao Java 1.7, então houve muitas dificuldades. Tentei obter o código-fonte e compilar por conta própria, mas o escopo foi crescendo. Foi difícil por causa do desalinhamento com os gestores, e no fim decidi sair de um cliente de altíssimo nível da Fortune 10. Ouvi dizer que esse sistema ainda não foi atualizado.
  • Queria voltar a usar um app em Swing que escrevi no passado, e acho que consigo ressuscitá-lo sem grandes mudanças, então pretendo tentar.
  • A JVM e seu ecossistema também podem ser usados junto com outras linguagens, como Scala e Clojure, o que permite usos diversos e atraentes.
• É impressionante que tenha demorado tanto para permitir validação e conversão de parâmetros antes da chamada de super no construtor. Sempre achei isso algo que contrariava a intuição.
  • Uso Java desde antes do JDK 1.0, e isso sempre me incomodou, mas agora já me adaptei e me acostumei com soluções de contorno.
  • Se você já vinha usando uma função static para o processo de validação nos parâmetros de super, na prática ela já era chamada antes do super, então o compilador não reclamava.
• Não sou desenvolvedor Java, mas pessoalmente não gosto muito do sistema de importação de módulos. Sintaxes como import * facilitam escrever o código, mas tornam a leitura muito mais difícil, especialmente para desenvolvedores que não conhecem a linguagem ou a base de código. C# e Nim também seguem esse estilo, e sem IDE eu quase não consigo ler. Por isso acho melhor algo como os apelidos curtos do Python (import torch.nn.functional as F).
  • Em bases de código grandes, o principal problema dos imports é: "de onde isso veio?". Imports explícitos são indispensáveis. Isso é ainda mais importante quando o build quebra ou quando há confusão com versão de dependência. Em bases pequenas, tanto faz. Como os editores hoje em dia escondem a linha de import, quase nunca preciso olhar para ela diretamente; eu só clico no código ou uso um atalho para ir direto, então nem penso muito em import.
  • Acho que a experiência ruim com C# vem de não usar o Visual Studio de verdade. VSCode é bom, mas eu nunca abriria arquivos csproj ou sln no VSCode. Aliás, o Visual Studio pode ser comprado aqui por US$ 500 com licença perpétua, sem precisar de assinatura separada.
  • Não consigo entender reclamar de construções de linguagem que são difíceis de entender sem IDE. Se você está vendo o código na IDE, não vejo problema. Quem não usa IDE está escolhendo se colocar nessa situação. E ver código no GitHub normalmente não envolve analisar referências em profundidade, então dá para tolerar esse incômodo em troca da concisão.
  • Pelo que sei, esse estilo foi pensado para facilitar a escrita de programas de arquivo-fonte único.
• Os novos recursos estão bem organizados na página oficial do OpenJDK 25. Java 25 é uma release LTS.
  • Espero que chegue logo o dia em que, daqui a 10 anos, eu tenha que fazer uma migração do 17 para o 25.
• É uma impressão pessoal, mas sinto que Java, apesar de ser uma linguagem antiga, evoluiu de forma constante nos últimos 10 anos, enquanto C++ ficou ainda mais difícil.
• Infelizmente, structured concurrency ainda não foi lançada por completo. Estou realmente ansioso por esse recurso. Em compensação, fico feliz com a adição de Scoped Values. Só isso já me parece suficiente para estruturar código em Java num estilo "rails-like" sem abusar de god-class ou god-object.
  • Em comparação com a situação confusa do C++, com recursos padronizados sem implementação atual, acho muito melhor o caminho gradual por preview que o Java vem seguindo.
  • Espero que structured concurrency pareça um avanço real, e não algo açucarado demais como async/await. Só pelos exemplos ainda não estou convencido, mas vou observar mais.
• Recentemente decidi migrar do JDK8 e fui direto para o JDK21. Como o 25 já está logo ali, escolhi o 21 em vez de passar pelo 17. Pelo que vejo, a migração do 8 para o 11 foi a mais difícil, por causa do novo sistema de módulos, e depois disso ficou fácil. Fiz a prova de conceito com jdk17, e praticamente a mesma coisa funcionou no jdk21 também (só o guice precisou de upgrade major). Aliás, acho que usar outra linguagem da JVM em vez de Java também ajudou.
  • Para a nossa equipe, o difícil foi passar do 8 para o 17. Usávamos muita coisa não oficial, como pacotes sun, e a mudança de javax para jakarta também pesou. Depois de vencer essa etapa, ir para o 21 ou 25 parece fácil. Espero que daqui para frente acompanhar versões recentes seja mais tranquilo do que antes.
  • Java 9 foi o momento Python 3 do ecossistema, mas agora sinto que isso já foi resolvido sem problemas.
  • Só para constar, migrei recentemente do 17 para o 21 e não tive problema nenhum. Houve pequenas questões ao atualizar o Gradle junto (o que é essencialmente outro assunto).
• Os novos recursos do Java 25 estão bem resumidos neste post do baeldung.
• Fico curioso sobre a situação atual do uso de Java do ponto de vista jurídico, tanto em open source quanto em uso comercial. A Oracle prende ótimas tecnologias como Truffle ao Java, então queria saber até que ponto é sensato usá-lo em projetos novos.
  • OpenJDK é basicamente a versão aberta licenciada diretamente pela Oracle. Se você não gosta da Oracle, pode usar versões feitas por outros, como Eclipse Foundation, Microsoft e Amazon. A longevidade do Java é grande, o que também explica por que ainda se usam versões antigas como 8/11. Uma vez escrito, ele realmente roda por muito tempo. Em recursos, avança mais devagar que os concorrentes, mas é suficiente para desenvolvimento importante. Se você depende da JVM, recomendo Kotlin (principalmente porque Java ainda não tem nullable type e NullPointerException é comum). Se não gostar de Kotlin, C# também é bom. Ainda assim, Java é perfeitamente utilizável.
  • Hoje em dia, no caso da distribuição da Oracle, dá para pensar que só a LTS mais recente pode ser usada livremente. Versões abaixo disso ficam sob licença OTN, então só podem ser usadas para fins pessoais ou de desenvolvimento, não em produção. Se você não precisa especificamente da marca Oracle, OpenJDK ou JDKs de terceiros não trazem preocupação com licença.
  • OpenJDK é totalmente open source, então não há absolutamente nada com que se preocupar.
  • Se você usar algo como OpenJDK, fica completamente livre das questões relacionadas à Oracle.
  • A menos que você vá criar e distribuir sua própria implementação de Java, questões legais quase não entram na equação.