Guia do Java

Novidades e o futuro do JUnit by Marc Philipp

2025-08-25T13:10:00.000-03:00

Olá, pessoal!

Hoje vamos mergulhar nas novidades e no futuro do JUnit, o framework de testes mais popular do Java. Vamos fazer um resumo de uma sessão com Marc Philipp, o team lead da equipe JUnit, que está agora trabalhando em tempo integral no projeto, graças ao financiamento do Sovereign Tech Fund. Preparem-se para um resumo didático sobre o que há de novo e o que está por vir!

O JUnit em um Relance: Um Legado de Testes

O JUnit é um dos projetos open source Java mais antigos, criado por Kent Beck e Erich Gamma em 1997. É um projeto independente, sem o apoio de uma única empresa, e grande parte do trabalho é feita no tempo livre dos colaboradores, embora Marc esteja em tempo integral atualmente.

Existem algumas gerações do JUnit:

JUnit 4.x: Ainda muito utilizado, com baseline no Java 5 e agora em modo de manutenção, recebendo apenas correções críticas e de segurança.
JUnit 5.x: Lançado em 2017, com baseline no Java 8 e suporte a recursos modernos do Java. É o foco principal das discussões atuais.
JUnit 6.0: A próxima geração, que promete simplificar a migração e trazer novos requisitos, como o Java 17.
Marc Philipp, que é um committer desde 2012 e team lead desde 2016, tem trabalhado em várias melhorias importantes.

As Mais Recentes Melhorias no JUnit 5.13

As versões mais recentes do JUnit 5.x, especialmente a 5.13, trouxeram recursos muito aguardados:

1. Relatórios de Teste Aprimorados

O JUnit agora oferece relatórios de teste muito mais legíveis e ricos, um avanço significativo em relação aos formatos legados.

Open Test Reporting XML Format: Introduzido na versão 5.9, este novo formato XML é pensado para substituir o antigo, que não suportava recursos modernos do JUnit Platform, como tags, estruturas hierárquicas e testes aninhados. Ele funciona de forma baseada em eventos (início e fim de cada nó da árvore de testes) e também em um formato hierárquico, que é um pouco mais legível por humanos, embora ainda seja XML.
Relatório HTML: A grande novidade é a capacidade de gerar um relatório HTML completo a partir dos arquivos XML. Isso torna a análise dos resultados dos testes muito mais amigável.
- Como Funciona: Você precisa adicionar a dependência junit-platform-reporting e ativar a geração do formato XML via configuração. Em seguida, uma ferramenta CLI do projeto Open Test Reporting converte esses arquivos XML em um relatório HTML.
- Recursos do Relatório HTML:
  - Visão Geral Clara: Barra de status (verde para sucesso, vermelho para falha), informações sobre o ambiente de execução (OS, JVM) e até mesmo o status do repositório Git no momento da execução.
  - Árvore de Testes: Uma representação hierárquica clara dos seus testes, similar ao que você vê na IDE.
  - Detalhes de Falha: Em caso de falha, você obtém a stack trace completa, com a opção de copiá-la facilmente para sua IDE.
  - Entradas de Relatório: Possibilidade de publicar dados arbitrários (como string-string maps) ou anexar arquivos (textos são mostrados inline, imagens são incorporadas) diretamente no relatório, o que é útil para testes de UI, por exemplo.
  - Modo Escuro: Sim, porque todo mundo gosta!
- Integração com CI: Embora não haja uma integração direta com a UI do GitHub Actions para HTML completo, é possível arquivar o relatório HTML como um artefato. O arquivo HTML é self-contained, facilitando o compartilhamento.
- Formato Agnóstico: O esquema XML subjacente é agnóstico à plataforma, o que significa que outras frameworks de teste (como PHPUnit) já estão começando a adotar esse formato.

2. Classes de Teste Parametrizadas

Esta é uma funcionalidade altamente solicitada, que permite parametrizar uma classe inteira de testes, em vez de apenas métodos individuais.

Motivação: Evitar a duplicação de código quando múltiplos métodos de teste precisam ser executados com o mesmo conjunto de parâmetros. Imagine testar diferentes implementações de uma interface (como List) com o mesmo conjunto de testes.
Como Usar:
- Anote sua classe com @ParameterizedClass.
- Use anotações de origem (SourceAnnotation) no nível da classe (como @MethodSource ou @ValueSource) para fornecer os argumentos.
- Os parâmetros podem ser injetados via injeção de campo (anotando o campo com @Parameter) ou injeção de construtor (ideal para classes record ou com construtores personalizados).
- Cuidado com Dados Mutáveis: Se os dados ou instâncias injetadas forem mutáveis, a ordem de execução dos testes pode importar, levando a flaky tests. O ideal é usar dados imutáveis ou implementar métodos @AfterEach para resetar o estado.
- Conversores Customizados: Você pode usar @ConvertWith para converter strings ou outros tipos para seus objetos, especialmente útil com @ValueSource.
- Métodos de Ciclo de Vida Específicos: Há suporte para métodos static @BeforeParameterizedClassInvocation para inicializações complexas.
Combinando Recursos: É possível combinar classes parametrizadas com testes aninhados e até mesmo métodos de teste parametrizados, embora isso possa levar a uma "explosão" de combinações de testes.

3. Relato de Problemas de Descoberta de Testes

Um pesadelo para qualquer desenvolvedor é escrever um teste e ele não ser executado. Antes da versão 5.13, o JUnit silenciosamente ignorava testes malformados. Agora, ele protege você contra isso!

O Problema: Métodos anotados com @Test que não são válidos (por exemplo, retornam um int em vez de void ou Unit no Kotlin, classes aninhadas estáticas) eram descartados sem aviso.
A Solução: O JUnit Platform agora coleta e relata esses problemas.
- Warnings e Erros Críticos: Problemas não críticos são logados como warnings. Problemas críticos podem fazer a execução do teste falhar.
- Severidade Configurável: A severidade padrão para falha é "error", mas você pode configurá-la para "warning" ou "info", garantindo que qualquer problema leve à falha da build, semelhante ao tratamento de warnings como erros em compiladores.
- Exemplos: Retorno de tipo incorreto em @Test ou @TestFactory, classes aninhadas declaradas como static.
Assistência da IDE: IDEs como o IntelliJ IDEA já oferecem inspeções para muitos desses problemas, mas nem sempre os desenvolvedores prestam atenção aos avisos visuais. A falha da build torna isso impossível de ignorar.

O Roteiro para o JUnit 6.0

A próxima grande versão do JUnit, a 6.0, trará algumas mudanças importantes:

Migração Simplificada: A boa notícia é que não será uma migeração drástica como a do JUnit 4 para o 5. A API do JUnit Jupiter permanecerá amplamente a mesma.
Requisitos de Versão:
- Java 17: Será o baseline mínimo necessário.
- Kotlin 2.2: Também será um requisito.
Novidades:
- JSpecify: Informações de anulabilidade (nullability) estarão disponíveis em todas as APIs.
- Remoção de APIs Deprecadas: APIs que estavam deprecadas desde o 5.10 (há cerca de 3 anos) serão removidas, incluindo o JUnitPlatformRunner (um adaptador para rodar testes JUnit 5 em ambientes JUnit 4).
- Depreciação de Camadas de Compatibilidade: O JUnit Vintage Engine (necessário para rodar testes JUnit 3 e 4 na plataforma JUnit 5) será deprecado, mas não para remoção imediata, sendo uma solução temporária para migrações.
Suporte de Longo Prazo para 5.13: Para aqueles que não podem migrar para Java 17 imediatamente, o JUnit oferecerá suporte de longo prazo (LTS) para a versão 5.13, com correções de bugs e segurança, mas sem novos recursos.

Conclusão

O JUnit continua evoluindo, trazendo ferramentas cada vez mais robustas e amigáveis para garantir a qualidade do seu código. Os novos relatórios HTML, as classes de teste parametrizadas e a detecção proativa de problemas de descoberta de testes são adições fantásticas que certamente farão a diferença no dia a dia dos desenvolvedores.

Experimente os novos recursos, especialmente os relatórios HTML e as classes parametrizadas, e não deixe de dar seu feedback no repositório do GitHub. É assim que o projeto continua a melhorar! E fique de olho no JUnit 6.0, que promete ser uma atualização mais tranquila e poderosa.

Até a próxima!

Referências

Principais Novidades do Ecossistema Java: Agosto 2025

2025-08-16T11:19:00.000-03:00

Principais Novidades do Ecossistema Java: Agosto 2025

Agosto tem sido marcado por anúncios importantes no universo Java, especialmente com os lançamentos e milestones de Spring Framework 7 e Spring Boot 4 e o anúncio oficial do Java 25 como próxima versão LTS. Essas novidades representam mudanças profundas para quem desenvolve aplicações modernas em Java, trazendo recursos de resiliência, modularidade e integração com os padrões mais atuais do mercado. Neste post, vamos destacar os principais acontecimentos, sugerir tópicos para estudo e detalhar as principais.

Lista dos Tópicos da Semana

Java 25: Lançamento oficial da versão LTS

O Java 25 chega à maturidade com data de lançamento prevista para 16 de setembro de 2025, consolidando-se como uma versão de suporte de longo prazo repleta de inovações para a comunidade.

Spring Framework 7 & Spring Boot 4:
Novas versões trazem arquitetura modular, resiliência nativa, APIs modernizadas e integração aprimorada com o ecossistema Java.

Java 25: O Novo LTS está Chegando

O que mudou?

O Java 25 chega como versão LTS em 16 de setembro de 2025, após um ciclo de release candidates em agosto.

Traz pelo menos 18 novos recursos, desde melhorias no JDK Flight Recorder (monitoramento e criação de perfil), API para codificações PEM, otimizações de desempenho em String e avanços em criptografia.

Por que é relevante?

Por ser LTS, terá suporte estendido da Oracle (mínimo de 5 anos).
Foco em estabilidade, performance, segurança e usabilidade.
Possibilita modernização de aplicações e adoção segura pelas empresas.

Principais melhorias e recursos

Perfil de tempo de CPU no Linux via JFR.
Codificação/decodificação PEM para objetos criptográficos.
Otimização da função String::hashCode para apps que usam muitas strings como chave.

Links para saber mais

OpenJDK JDK 25 Release

Detalhes InfoQ Java News

DIO.me — JDK 25 LTS

Spring Framework 7 & Spring Boot 4

Novidades mais relevantes e o que mudou

Spring Framework 7: foco em resiliência (@Retryable e @ConcurrencyLimit nativos), JMS Client fluente, mensagem unificada, novo suporte para Hibernate ORM 7/JPA 3.2, melhor integração com Ecossistema Java (Kotlin 2.2, Jakarta EE 11, GraalVM 24), Jackson 3.x e null safety via JSpecify.

Spring Boot 4: código modular, dependências em Maven Central, novo metadata para propriedades, relatório SSL melhorado, múltiplos TaskDecorator automáticos e auto configuração do JMS Client.

Por que é relevante?

Permite construção de microserviços mais robustos e modernos.
Aumenta a produtividade em projetos enterprise e facilita a migração de versões antigas.
Integra-se com as tendências atuais de Cloud Native e programação reativa.

Principais melhorias

Resiliência nativa para métodos críticos.
API de JMS mais legível, modelo builder.
Arquitetura modular para as dependências.
Frequentemente publicada em Maven Central, agilizando CI/CD.
Compatibilidade com as últimas versões de frameworks e linguagens parceiros.

Links para saber mais

Blog Foojay.io — Preparing for Spring Framework 7 and Spring Boot 4

Spring Framework 7 Release Notes

Spring Boot 4 Migration Guide

Conclusão

Agosto de 2025 marca uma evolução relevante para quem trabalha com o ecossistema Java. O lançamento do Java 25 como LTS e a chegada de Spring Framework 7 e Spring Boot 4 reforçam o compromisso da comunidade com inovação, segurança e produtividade. Fique atento às datas, teste os recursos novos e compartilhe sua opinião: comente abaixo o que mais te chamou atenção ou envie sugestões de pauta!

Referências

Foojay.io — Preparing for Spring Framework 7 and Spring Boot 4

OpenJDK — JDK 25 Release Schedule

DIO.me — JDK 25: Uma Versão LTS com Inovações para Desenvolvedores Java

InfoQ — Java News Roundup August 2025

Spring Framework 7.0.0 M7 — Release Notes

Java 30 anos

2025-05-07T21:41:00.001-03:00

Java 30 anos | Guia do Java

Java 30 anos

Em maio de 2025, a linguagem Java completa 30 anos desde seu lançamento oficial pela Sun Microsystems, marcando três décadas de inovação, evolução e onipresença no desenvolvimento de software mundial. De sua origem como projeto "Green" na Sun, passando por sua adoção massiva como linguagem empresarial, até seu papel atual em cloud computing, microsserviços e inteligência artificial, o Java não apenas sobreviveu às intensas mudanças na indústria de tecnologia, mas se reinventou continuamente. Este marco de 30 anos celebra uma tecnologia que revolucionou a forma como desenvolvemos software, estabelecendo o paradigma "Write Once, Run Anywhere" que influenciou gerações de programadores e continua relevante hoje com sua sólida comunidade, rico ecossistema de frameworks, e constante evolução tecnológica.

Do Oak ao Java: Os Primórdios da Linguagem (1989-1995)

Embora tenha 30 anos, o início ocorreu ainda na década de 80. Em 1989, James Gosling, então engenheiro da Sun Microsystems, criou uma linguagem chamada "Oak" (Carvalho), nome inspirado na árvore que podia ser vista da janela de seu escritório. Nesta época em que a internet ainda engatinhava e a necessidade por linguagens multiplataforma era crescente.

O desenvolvimento mais formal começou em 1991, quando Mike Sheridan, Patrick Naughton e James Gosling iniciaram o "Projeto Green" na Sun Microsystems. A ideia inicial era criar uma tecnologia para programação de dispositivos inteligentes, como eletrodomésticos - algo revolucionário para a época.

O nascimento do "Star7"

Em setembro de 1992, a equipe fez a primeira demonstração da nova plataforma, incluindo o sistema operacional Green, a linguagem Oak, as bibliotecas e o hardware. Eles apresentaram o "Star7", um dispositivo PDA com interface gráfica e um assistente inteligente chamado "Duke" - que posteriormente se tornaria o mascote oficial do Java.

No entanto, o mercado de dispositivos eletrônicos inteligentes não decolou como esperado, e a equipe precisou reavaliar a direção do projeto. Foi quando perceberam o potencial de sua tecnologia para a internet, que estava começando a crescer exponencialmente.

De Oak para Java

Em 1994, após uma pesquisa de marca revelar que "Oak" já era uma marca registrada pela Oak Technology, a linguagem foi renomeada para "Java". Há várias histórias sobre a origem deste nome, mas a mais conhecida é que foi escolhida durante uma sessão de brainstorming enquanto os desenvolvedores tomavam café (java, em gíria americana).

Finalmente, em 23 de maio de 1995, a Sun Microsystems anunciou oficialmente a linguagem de programação Java ao mundo, em uma conferência de imprensa 5. Este é considerado o nascimento oficial do Java como produto.

Os Primeiros Anos: Estabelecendo as Bases (1996-2000)

O primeiro lançamento estável, JDK 1.0.2, chegou em 23 de janeiro de 1996, trazendo apenas 8 pacotes Java básicos: java.applet, java.awt, java.awt.image, java.awt.peer, java.io, java.lang, java.net e java.util. Estes pacotes formaram a base inicial do que viria a se tornar um dos ecossistemas mais robustos de desenvolvimento.

A popularização através dos applets

Um dos fatores que impulsionou a popularidade inicial do Java foram os "applets" - pequenos programas que podiam ser executados dentro de navegadores web. Isso permitiu que páginas da internet tivessem funcionalidades dinâmicas em uma época em que o HTML era predominantemente estático.

A evolução acelerada

O ritmo de evolução foi impressionante nos primeiros anos:

1997: JDK 1.1 introduziu inner classes, JavaBeans e a API de Reflection, melhorando o tratamento de eventos e internacionalização.
1998: Java 2 (J2SE 1.2) trouxe uma grande reestruturação com a divisão em três edições principais: Java SE (Standard Edition), Java EE (Enterprise Edition) e Java ME (Micro Edition). Também foram introduzidos o Swing GUI toolkit e o framework de coleções.
2000: J2SE 1.3 adicionou a Java Sound API e JNDI (Java Naming and Directory Interface).

A Maturidade Empresarial: Java nas Corporações (2001-2009)

Durante a primeira década dos anos 2000, o Java se estabeleceu firmemente como a linguagem preferida para o desenvolvimento empresarial.

J2EE: Dominando o Mercado Corporativo

O Java 2 Enterprise Edition (J2EE, posteriormente Java EE) proporcionou uma plataforma robusta para o desenvolvimento de aplicações corporativas escaláveis e seguras. Esta plataforma incluía tecnologias como Servlets, JSP, EJB e JMS, que se tornaram fundamentais para o desenvolvimento de sistemas empresariais.

As Grandes Evoluções da Linguagem

2002: J2SE 1.4 trouxe assertions, API de Logging e suporte nativo a expressões regulares.
2004: J2SE 5.0 representou uma das maiores atualizações da linguagem, introduzindo generics, annotations, enumerações, autoboxing/unboxing e o enhanced for loop.
2006: Java SE 6 focou em melhorias de desempenho e introduziu a API do Compilador Java e API de Scripting.

O Surgimento do Spring Framework

Em 2002, Rod Johnson lançou o livro "Expert One-on-One J2EE Design and Development", que trazia ideias revolucionárias sobre como desenvolver aplicações Java corporativas de forma mais simples e elegante. Essas ideias se materializam no Spring Framework, cuja primeira versão oficial (1.0) foi lançada em março de 2004. O Spring se tornaria um dos frameworks mais importantes do ecossistema Java, oferecendo alternativas mais leves e produtivas ao J2EE tradicional.

A Aquisição pela Oracle

Em 2009, um marco importante na história do Java ocorreu quando a Oracle Corporation adquiriu a Sun Microsystems por aproximadamente 7,4 bilhões de dólares, assumindo assim o controle da plataforma Java. Essa transição gerou inicialmente muita incerteza na comunidade sobre o futuro da linguagem.

A Era Oracle: Evolução e Modernização (2010-2018)

Sob a gestão da Oracle, o Java continuou sua evolução, enfrentando novos desafios como a adaptação à computação em nuvem e às necessidades de desenvolvimento mobile.

Modernização da Linguagem

2011: Java SE 7 introduziu o try-with-resources, o operador diamond, strings em switch e a nova API NIO.2.
2014: Java SE 8 trouxe uma das maiores revoluções na linguagem com a introdução de expressões lambda, interfaces funcionais, streams e a nova API de Data/Hora. Esta versão é considerada por muitos como o ponto de virada para um Java mais moderno e funcional.

Novos Ciclos de Lançamento

Em 2017, a Oracle anunciou uma mudança significativa no ciclo de lançamento do Java, passando para atualizações semestrais (a cada seis meses) a partir do Java 9, com versões LTS (Long-Term Support) a cada três anos. Este modelo visava permitir a introdução mais rápida de novidades sem comprometer a estabilidade para usuários empresariais.

A Transição do Java EE

Também em 2017, a Oracle anunciou que transferiria o Java EE para a Eclipse Foundation. Após a transferência, devido a questões de marca registrada, a plataforma foi renomeada para Jakarta EE em 2019, iniciando um novo capítulo para o desenvolvimento empresarial em Java.

Java na Era Moderna: Inovação Contínua (2019-2025)

Os últimos anos têm sido marcados por inovações significativas que mantêm o Java relevante em um cenário tecnológico em rápida evolução.

Project Loom e Virtual Threads

A partir de 2021, o Project Loom introduziu o conceito de threads virtuais, permitindo a criação de milhões de threads leves que revolucionaram o modelo de concorrência em Java. Em 2024, houve avanços significativos com threads virtuais sem "pinning", melhorando ainda mais o desempenho e a escalabilidade.

GraalVM: Compilação Nativa e Multilinguagem

O GraalVM, cuja primeira versão pronta para produção foi lançada em maio de 2019, trouxe novas possibilidades para o ecossistema Java, incluindo compilação ahead-of-time para melhor inicialização e menor consumo de recursos, além de interoperabilidade entre diferentes linguagens de programação.

Lançamentos Recentes e Futuros

2021 (setembro): Java 17 LTS, trazendo estabilidade e recursos como sealed classes.
2023 (setembro): Java 21 LTS, com melhorias em virtual threads e pattern matching.
2024 (setembro): Java 23 (planejado).
2025 (março): Java 24 (planejado).
2025 (setembro): Java 25 LTS (planejado) - coincidindo com o 30º aniversário do Java.

O Impacto do Java no Desenvolvimento de Software

Ao longo destes 30 anos, o Java transformou fundamentalmente o desenvolvimento de software em vários aspectos:

"Write Once, Run Anywhere"

O lema "Escreva uma vez, execute em qualquer lugar" não foi apenas um slogan, mas uma realidade que revolucionou o desenvolvimento de software. A portabilidade oferecida pela Máquina Virtual Java (JVM) permitiu que desenvolvedores escrevessem código independente de plataforma, economizando tempo e recursos significativos.

Influência em Outras Linguagens

O design do Java influenciou muitas outras linguagens de programação como C#, Kotlin e Scala. Sua abordagem orientada a objetos, gerenciamento automático de memória e sistema de tipos estáticos se tornaram padrões da indústria.

O Futuro do Java: Para Onde Caminha a Plataforma

Olhando para o futuro, o Java continua se adaptando e evoluindo para enfrentar os desafios modernos do desenvolvimento de software:

Melhorando a Produtividade dos Desenvolvedores

A tendência de simplificar a sintaxe sem sacrificar a segurança de tipos continua, com recursos como pattern matching, records e inferência de tipos tornando o código mais conciso e expressivo.

Otimizando para Cloud e Microsserviços

Com projetos como Loom (threads virtuais), GraalVM (compilação nativa) e melhorias contínuas no tempo de inicialização e consumo de memória, o Java está se adaptando bem ao ambiente de nuvem e arquiteturas de microsserviços.

Integração com IA e Machine Learning

O ecossistema Java está expandindo para facilitar o desenvolvimento de aplicações de IA e Machine Learning, com bibliotecas e frameworks como DeepLearning4J e integração com tecnologias como TensorFlow.

Sustentabilidade e Comunidade

A transição de partes do ecossistema para governança de fundações abertas, como a Eclipse Foundation (Jakarta EE) e a fundação OpenJDK, garante que o Java continue sendo uma plataforma aberta e dirigida pela comunidade.

Conclusão: Celebrando 30 Anos e Olhando para o Futuro

Enquanto celebramos os 30 anos do Java em 2025, é impressionante refletir sobre como uma linguagem criada inicialmente para dispositivos embarcados evoluiu para se tornar a espinha dorsal do desenvolvimento empresarial e uma força motriz na inovação tecnológica.

O Java provou ser mais do que apenas uma linguagem de programação – é uma plataforma completa, um ecossistema vibrante e uma comunidade global de desenvolvedores apaixonados. Sua capacidade de evoluir e se adaptar às mudanças na indústria, mantendo a compatibilidade com versões anteriores, é uma das razões principais para sua longevidade.

Para desenvolvedores novatos, o Java continua sendo uma excelente primeira linguagem para aprender, oferecendo conceitos fundamentais de programação em um ecossistema maduro com amplas oportunidades de emprego. Para veteranos, a plataforma continua trazendo novidades empolgantes que mantêm o desenvolvimento interessante e produtivo.

Que venham mais 30 anos de inovação do Java! E você, qual sua memória favorita com Java? Compartilhe nos comentários abaixo e continue acompanhando o Guia do Java para mais conteúdos sobre esta incrível plataforma!

Linha do tempo

Ano	Versão/Evento	Principais Características
1989	Criação do Oak	James Gosling desenvolve a linguagem inicial na Sun
1991	Projeto Green	Início do desenvolvimento formal
1992	Demonstração do Star7	Primeira demonstração pública da tecnologia
1994	Renomeação para Java	Oak se torna Java após questões de trademark
1995	Lançamento oficial	Sun anuncia Java em 23 de maio
1996	JDK 1.0	Primeiro lançamento estável
1997	JDK 1.1	Inner classes, JavaBeans, Reflection
1998	J2SE 1.2 (Playground)	Divisão em SE, EE e ME; Swing; Collections
2000	J2SE 1.3 (Kestrel)	Java Sound API, JNDI
2002	J2SE 1.4 (Merlin)	Assertions, Logging, Regex
2004	J2SE 5.0 (Tiger)	Generics, Annotations, Enums, Autoboxing
2006	Java SE 6 (Mustang)	Melhorias de desempenho, Compiler API
2011	Java SE 7 (Dolphin)	Try-with-resources, Diamond operator, NIO.2
2014	Java SE 8	Lambdas, Streams, Date/Time API
2017	Java SE 9	Modularização (Project Jigsaw), JShell
2018	Java SE 10	var para inferência de tipo local
2018	Java SE 11 (LTS)	HTTP Client, remoção de Java EE, CORBA e JavaFX
2019	Java SE 12	Switch Expressions (preview)
2019	Java SE 13	Text Blocks (preview)
2020	Java SE 14	Records (preview), Pattern Matching (preview)
2020	Java SE 15	Sealed Classes (preview), ZGC aprimorado
2021	Java SE 16	Records e Pattern Matching estáveis
2021	Java SE 17 (LTS)	Sealed classes, Pattern Matching (preview)
2022	Java SE 18	UTF-8 por padrão, melhorias em Simple Web Server
2022	Java SE 19	Virtual Threads (preview), Pattern Matching para switch
2023	Java SE 20	Continuação de Virtual Threads e Pattern Matching
2023	Java SE 21 (LTS)	Virtual threads estáveis, sequenced collections
2024	Java SE 22	Novos recursos incrementais (ciclo semestral)
2024	Java SE 23	Novos recursos incrementais (ciclo semestral)
2025	Java SE 24	Novos recursos incrementais (ciclo semestral)
2025	Java SE 25 (LTS)	Próximo lançamento LTS, 30 anos de Java

Principais Novidades e Tendências de Abril de 2025 | Guia do Java

Principais Novidades e Tendências de Abril de 2025

2025-04-24T05:46:00.006-03:00

Principais Novidades e Tendências de Abril de 2025 | Guia do Java

Principais Novidades e Tendências de Abril de 2025

Manter-se atualizado é essencial para qualquer desenvolvedor Java, especialmente em um ecossistema tão dinâmico e inovador. Abril de 2025 foi marcado por lançamentos importantes, tendências emergentes e eventos que moldam o futuro da plataforma. Confira o resumo do mês, com links para as fontes originais.

Destaques do Mês

JDK 25: Cronograma Oficial e Novidades
Atualizações Críticas de Segurança no OpenJDK
Spring Framework 7.0.0 M4 e Spring Boot 4
Tendências: Project Loom, GraalVM, Java Cloud-Native e Integração com IA
Eventos e Comunidades: JDConf 2025, Jakarta EE 11 e mais

Resumo das Principais Notícias

JDK 25: Cronograma e Recursos

O cronograma do JDK 25 foi oficialmente divulgado, com a General Availability (GA) prevista para 16 de setembro de 2025. As fases de rampdown e release candidates ocorrem entre junho e agosto. Entre os recursos em destaque estão melhorias de performance, novos recursos de linguagem (como Module Import Declarations e Instance Main Methods) e avanços em estabilidade. A recomendação é que desenvolvedores testem as early-access builds e reportem bugs.

Release notes e cronograma JDK 25

Atualizações e Patches Críticos no OpenJDK

Abril trouxe o tradicional Critical Patch Update (CPU) para múltiplas versões do JDK: 8u451, 11.0.27, 17.0.15, 21.0.7 e 24.0.1. Esses updates corrigem vulnerabilidades e bugs, sendo essenciais para manter ambientes seguros e estáveis. Distribuições como Oracle, BellSoft (Liberica) e Microsoft Build of OpenJDK acompanharam os lançamentos.

Spring Framework 7.0.0 M4 e Ecossistema Spring

O Spring Framework 7.0.0 alcançou sua quarta milestone, trazendo melhorias em documentação, upgrades de dependências e novos recursos como suporte aprimorado a Optional e APIs para manipulação de bytecode Java. O Spring for GraphQL 1.4.0 RC também foi lançado, focando em observabilidade e melhorias em operações reativas. O ecossistema Spring segue como referência em produtividade e inovação para aplicações Java modernas.

Release notes Spring Framework 7.0.0 M4

Tendências Emergentes em Java

Abril confirmou a adoção massiva de tendências como:

Project Loom e Virtual Threads: Simplificação da concorrência e escalabilidade para aplicações de alta performance.
GraalVM e Native Images: Compilação ahead-of-time para aplicações leves e rápidas, ideais para cloud e serverless.
Cloud-Native Java: Jakarta EE 11 e MicroProfile 7 avançam como padrões para microservices e integração com Kubernetes.
Integração com IA: Frameworks como DeepLearning4J e Tribuo tornam Java mais relevante para machine learning em produção.
Programação Reativa: Frameworks como Project Reactor e Akka ganham espaço para aplicações responsivas e escaláveis.

Eventos e Comunidades

JDConf 2025: Evento virtual da Microsoft reuniu novidades sobre Java Cloud-Native, observabilidade, Project Loom, GraalVM e práticas modernas de desenvolvimento. As sessões destacaram desafios e soluções para Java em ambientes cloud e serverless.
Jakarta EE 11: O roadmap avança com milestones e release candidates, consolidando o padrão para aplicações corporativas cloud-native.

Conclusão

O mês de abril de 2025 reforçou o Java como uma plataforma inovadora, segura e pronta para os desafios do futuro. Fique atento aos próximos lançamentos, participe das comunidades e contribua para o ecossistema! Deixe seus comentários, compartilhe este resumo e sugira pautas para as próximas edições.

Referências

Segurança do Java resiste a computação quântica?

2025-02-16T19:59:00.001-03:00

Potenciais ameaças à segurança representadas por computadores quânticos e como os aplicativos Java podem ajudar a resistir a essas ameaças

Os computadores quânticos têm o potencial de quebrar os algoritmos criptográficos que protegem dados e comunicações. Isso ocorre porque eles podem resolver certos problemas matemáticos muito mais rápido do que os computadores clássicos. Isso representa uma ameaça à segurança de dados e comunicações, pois pode permitir que invasores decifrem informações confidenciais.

Para lidar com essa ameaça, os aplicativos Java podem usar a API Key Derivation Function (KDF), o Module-Lattice-Based Key Encapsulation Mechanism (ML-KEM) e o Module-Lattice-Based Digital Signature Algorithm (DSA). Essas APIs, algoritmos e padrões como a Criptografia de Chave Pública Híbrida RFC 9180 são áreas em desenvolvimento e direções potenciais de soluções mais amplas resistentes ao Quantum

Também é importante se atualizar para soluções de segurança resistentes a quantum o mais rápido possível. Isso ocorre porque os invasores podem potencialmente roubar dados agora e descriptografá-los mais tarde, quando os computadores quânticos se tornarem mais amplamente disponíveis.

No JDK 21 foi implementado a KEN API
Para o JDK 24 (disponível em 18/03/2025) foram implementadas:

JEP 478: Key Derivation Function API (Preview)
JEP 496: Quantum-Resistant Module-Lattice-Based Key Encapsulation Mechanism
JEP 497: Quantum-Resistant Module-Lattice-Based Digital Signature Algorithm

Para saber mais

Em Inglês:

HPKE: Standardizing public-key encryption: https://blog.cloudflare.com/hybrid-public-key-encryption/

NIST Post Quantum Encryption Standards: https://www.nist.gov/news-events/news/2022/07/nist-announces-first-four-quantum-resistant-cryptographic-algorithms

Cloud Security Alliance: https://cloudsecurityalliance.org/

Conclusão

Os computadores quânticos são uma tecnologia nova e empolgante, mas também representam uma ameaça à segurança de nossos dados e comunicações. Ao usar aplicativos Java e atualizar para soluções de segurança resistentes a quantum, podemos ajudar a nos proteger dessas ameaças.

Espero que esta postagem do blog tenha sido útil. Se você tiver alguma dúvida, sinta-se à vontade para deixar um comentário abaixo.

Referências

Quantum-Resistant Cryptography

Java Security

Inside Java Newscast: https://youtu.be/4k23rwIdJas

O que esperar do ecossistema Java em 2025

2025-02-09T12:03:00.001-03:00

Em 2025, o ecossistema Java está pronto para o crescimento e evolução contínuos, impulsionados por diversas tendências importantes

Lançamento do Java 24

O projeto OpenJDK que mantém a linguagem Java e a JVM/JDK adotou a cadência de releases a cada 6 meses. Sempre em Março e Setembro.

Programado para março de 2025, o Java 24 apresenta melhorias significativas:

JEP 483: Ahead-of-Time Class Loading & Linking: É um novo recurso do JDK 24 que visa melhorar o tempo de inicialização de aplicativos Java armazenando definições de classe e vinculando informações em um cache AOT (head-of-time).
Compact Object Headers - JEP 470: reduz a sobrecarga de memória, melhorando o desempenho para aplicativos de grande escala.
Threads virtuais: simplifica a programação simultânea, permitindo o manuseio eficiente de vários threads.
Pattern Matching: melhora a legibilidade do código e reduz o boilerplate, tornando o Java mais amigável ao desenvolvedor.
Scoped Values (Fourth Preview) - JEP 487: Valores com escopo oferecem uma alternativa para variáveis locais de thread, permitindo o compartilhamento de dados imutáveis dentro de partes específicas de um programa. Essa abordagem aumenta a confiabilidade e a manutenibilidade em código concorrente ao limitar o tempo de vida e o escopo de dados compartilhados.
Primitive Types in Patterns, instanceof, and switch (Second Preview) - JEP 488: Este recurso estende a correspondência de padrões para suportar tipos primitivos em todos os contextos de padrões, incluindo instruções instanceof e switch. Ele simplifica o código reduzindo boilerplate e eliminando casts inseguros.
Vector API (Ninth Incubator) - JEP 489: A Vector API permite que os desenvolvedores escrevam cálculos vetoriais que são compilados em tempo de execução para instruções vetoriais ideais em arquiteturas de CPU suportadas, melhorando o desempenho de operações paralelas de dados.
Synchronize Virtual Threads without Pinning - JEP 491: Melhorias em threads virtuais permitem que elas montem e desmontem threads de plataforma mesmo dentro de métodos sincronizados. Essa melhoria previne problemas de escalabilidade ao evitar a fixação de threads virtuais em threads de plataforma durante a sincronização.
Flexible Constructor Bodies (Third Preview) - JEP 492: Esse recurso permite instruções antes de chamadas do construtor para super(...) ou this(...), permitindo validação de entrada e computação antes da inicialização da superclasse, resultando em um código mais conciso e sustentável.
Module Import Declarations (Second Preview) - JEP 494: As declarações de importação de módulos permitem a importação implícita de todos os pacotes exportados por um módulo, simplificando a reutilização de bibliotecas modulares e reduzindo a verbosidade de múltiplas importações de pacotes sob demanda.
Simple Source Files and Instance Main Methods (Fourth Preview) - JEP 495: Destinado a iniciantes, esse recurso permite escrever programas simples sem declarações de classe e permite métodos main de instância, simplificando o processo de aprendizado e reduzindo o código clichê.
Structured Concurrency (Fourth Preview) - JEP 499: A simultaneidade estruturada melhora a confiabilidade e a observabilidade do código simultâneo gerenciando o ciclo de vida dos threads de maneira estruturada, garantindo que todas as subtarefas dentro de uma tarefa pai sejam concluídas ou canceladas juntas.

Esses desenvolvimentos refletem o compromisso contínuo do Java em evoluir de maneiras que melhorem a clareza, a segurança e o desempenho do código, mantendo a linguagem robusta e moderna para os desenvolvedores. Alem disso, a plataforma Java é preparada para os seguintes cenários/desafios:

1. Desenvolvimento nativo para nuvem

Arquitetura de microsserviços: Java continua sendo uma escolha popular para construir microsserviços, com frameworks como Spring Boot e Micronaut fornecendo suporte robusto para essa arquitetura.
Computação sem servidor: Java está sendo cada vez mais usado para funções sem servidor em plataformas como AWS Lambda e Google Cloud Functions, permitindo que desenvolvedores criem e implantem aplicativos escaláveis sem gerenciar servidores.
Conteinerização: Aplicativos Java estão cada vez mais sendo conteinerizados usando Docker e implantados em plataformas como Kubernetes, aumentando a portabilidade e a escalabilidade

2. Desempenho e eficiência

Project Loom: Espera-se que a introdução de threads virtuais no Project Loom revolucione a programação simultânea em Java, permitindo que os desenvolvedores escrevam aplicativos altamente escaláveis e responsivos com o mínimo de esforço.
GraalVM: Esta JVM de alto desempenho para Java e outras linguagens permite a geração de imagens nativas, resultando em tempos de inicialização mais rápidos e menor consumo de memória para aplicativos Java.

3. Recursos de linguagem moderna

Records: introduzidos no Java 14, os "registros" fornecem uma sintaxe concisa para criar classes de dados imutáveis, reduzindo o código boilerplate e melhorando a legibilidade do código.
Classes seladas: este recurso, introduzido no Java 15, permite que os desenvolvedores restrinjam quais classes podem estender ou implementar uma determinada classe ou interface, aumentando a segurança do tipo e a manutenibilidade.
Pattern Matching for instanceof: simplifica a verificação de tipos permitindo que você extraia valores de objetos dentro da própria verificação instanceof.
Encapsulamento forte por padrão: fortalece ainda mais o sistema de módulos, dificultando o acesso às APIs internas dos módulos, melhorando a segurança e a manutenibilidade.
Foreign Function & Memory API: fornece uma maneira mais eficiente e segura de interagir com código nativo e memória em comparação com o antigo JNI (Java Native Interface).

4. Big Data e Machine Learning

Java continua sendo uma escolha popular para processamento e análise de big data, com frameworks como Apache Hadoop e Spark fornecendo ferramentas poderosas para lidar com grandes conjuntos de dados.

A integração de Java com frameworks de machine learning como TensorFlow e PyTorch está crescendo, permitindo que desenvolvedores criem aplicativos inteligentes usando Java.

5. Comunidade e ecossistema fortes

A comunidade Java continua vibrante e ativa, com vários projetos de código aberto, conferências e grupos de usuários fornecendo recursos valiosos e suporte para desenvolvedores.

O vasto ecossistema de bibliotecas e frameworks Java continua a crescer, fornecendo aos desenvolvedores uma ampla gama de ferramentas para construir uma variedade de aplicativos.

Conclusão

No geral, o ecossistema Java está bem posicionado para o sucesso contínuo em 2025 e além, graças à sua base sólida, comunidade ativa e evolução contínua para atender às demandas do desenvolvimento de software moderno.

Referências

https://openjdk.org/projects/jdk/24/

https://bell-sw.com/blog/an-overview-of-jdk-24-features/

https://dev.to/limuss/the-latest-trends-frameworks-and-libraries-in-java-2024-2025-2ej0

https://blogs.oracle.com/java/post/the-arrival-of-java-23

Retrospectiva do Ecossistema Java 2024

2024-12-24T01:14:00.002-03:00

O ano de 2024 foi marcante para o ecossistema Java, consolidando sua posição como uma das principais linguagens de programação no desenvolvimento de aplicações modernas. Com atualizações significativas, adoção crescente de novas versões e discussões relevantes na comunidade, o Java demonstrou sua capacidade de evolução contínua para atender às demandas tecnológicas atuais.

Principais Notícias de 2024

Adoção acelerada do Java 21

Em setembro de 2023, foi lançado o Java 21, trazendo melhorias notáveis, como threads virtuais e bibliotecas aprimoradas. A adoção desta versão foi significativamente mais rápida em comparação com lançamentos anteriores. Nos seis meses subsequentes ao lançamento, 1,4% das aplicações monitoradas já utilizavam o Java 21, um aumento de 287% em relação ao mesmo período após o lançamento do Java 17. Além disso, o Java 17, lançado anteriormente, viu sua adoção crescer para 35% das aplicações, refletindo um aumento de quase 300% em um ano.

Alguns dos recursos relevantes foram:

Threads Virtuais (Projeto Loom): Simplificaram a programação concorrente, permitindo lidar com milhões de threads leves com baixo impacto de desempenho.
Scoped Values: Avançaram a gestão de dados compartilhados entre threads, tornando os sistemas concorrentes mais simples e eficientes.
Melhorias no Garbage Collector: O ZGC e G1 GC receberam ajustes que reduziram pausas e melhoraram a eficiência em ambientes de grande escala.

Desafios de Performance e Atualizações

Uma pesquisa realizada pela BellSoft revelou que 73% dos desenvolvedores acreditam que o desempenho das aplicações Java em suas empresas pode ser melhorado. Apesar das versões mais recentes, muitos ainda utilizam o Java 8 e 11 em produção. A pesquisa também destacou que 21% dos entrevistados não priorizam a migração para versões mais novas devido à falta de urgência percebida pelos gestores de negócios.

O Papel das Versões Não-TLS no Ciclo de Inovação do Java

As versões não-TLS, lançadas a cada seis meses, são fundamentais para o avanço do Java. Elas introduzem novos recursos e experimentos, permitindo feedback direto da comunidade antes de sua inclusão definitiva nas versões TLS. Em 2024, tivemos dois lançamentos significativos: Java 22 (março de 2024) e Java 23 (setembro de 2024). Apesar de não terem suporte estendido, essas versões são amplamente utilizadas em ambientes de teste e desenvolvimento para avaliar e experimentar as mais recentes inovações.

Principais JEPs (Java Enhancement Proposals) Liberados em 2024:

Threads Virtuais como Recurso PadrãoVersão: Consolidado no Java 21, evoluções nas versões não-TLS.

Objetivo: Simplificar a programação concorrente no Java, permitindo milhares de threads leves com impacto mínimo no desempenho.
Impacto: Melhoria significativa em servidores e aplicações de alta carga.

Projeto Valhalla: Primitive Classes (JEP 401)Versão: Introduzido como prévia em Java 22.

Objetivo: Fornecer uma forma de criar classes que se comportam como tipos primitivos, reduzindo overhead de memória e melhorando a performance.
Impacto: Um marco para aplicações que exigem alta eficiência, como processamento financeiro e jogos.

String Templates: Prévia em Java 22 e continuada no Java 23.

Objetivo: Introduzir interpolação de strings, simplificando a construção de strings dinâmicas.
Impacto: Reduz o uso de APIs externas como String.format() e bibliotecas de template.

Introdução ao nullability para melhor segurança: Primeira preview no Java 23.

Objetivo: Fornecer uma maneira padrão de expressar e verificar o uso de valores null no código.
Impacto: Reduz erros relacionados a NullPointerException, uma das exceções mais comuns no Java.

Projeto Loom: Scoped Values: Introduzido no Java 22.

Objetivo: Facilitar o compartilhamento de dados entre threads de forma eficiente e segura.
Impacto: Simplificação de práticas de programação para ambientes concorrentes e paralelos.

Compact Object Headers (Projeto Lilliput): Testado no Java 22.

Objetivo: Reduzir o tamanho dos cabeçalhos de objetos na JVM.
Impacto: Melhor utilização de memória em aplicações de grande escala.

Atualizações no Garbage Collector: Melhorias em G1 e ZGC no Java 23.

Objetivo: Reduzir pausas de coleta de lixo e melhorar a eficiência em sistemas com grande quantidade de memória.
Impacto: Melhor desempenho em aplicações críticas, como bancos de dados e sistemas de análise em tempo real.

Tendências Emergentes

O uso de ferramentas de inteligência artificial para auxiliar na escrita de código ganhou destaque, com 18% dos desenvolvedores adotando essas tecnologias. Além disso, a conscientização sobre a "Green Java" tornou-se um foco importante, refletindo a preocupação com a eficiência energética e sustentabilidade no desenvolvimento de software.

A IBM apresentou avanços significativos com o watsonx Code Assistant para aplicativos corporativos Java, previsto para outubro de 2024. Essa ferramenta de IA auxilia na geração de código, aumentando a eficiência e precisão no desenvolvimento de aplicações Java.

Computação Sem Servidor

A computação sem servidor (serverless) ganhou destaque no desenvolvimento Java, com a popularidade de plataformas como AWS Lambda e Azure Functions. Essa abordagem permite que os desenvolvedores construam e implantem aplicações de maneira mais rápida e eficiente, sem a necessidade de gerenciar a infraestrutura subjacente.

Referências:

https://www.oracle.com/br/news/announcement/oracle-releases-java-23-2024-09-17/

https://newrelic.com/resources/report/2024-state-of-the-java-ecosystem

https://bell-sw.com/blog/Java-Developer-Survey-2024/

Java aprimora a documentação com suporte Markdown

2024-05-31T11:55:00.002-03:00

Permite que os comentários da documentação do JavaDoc sejam escritos em Markdown, em vez de apenas em uma mistura de HTML e JavaDoc @-tags.

JEP 467, Markdown Documentation Comments, foi promovido para ser liberado no JDK 23

Objetivos da JEP

Tornar os comentários da documentação da API mais fáceis de escrever e ler no formato de origem, introduzindo a capacidade de usar a sintaxe Markdown nos comentários da documentação, juntamente com elementos HTML e tags JavaDoc.

Estende a API Compiler Tree para permitir que outras ferramentas que analisam comentários de documentação manipulem o conteúdo Markdown nesses comentários.

Não é o objetivo desta JEP, permitir a conversão automatizada de comentários de documentação existentes para a sintaxe Markdown.

Motivação

Os comentários da documentação Java tradicionalmente usam tags HTML e JavaDoc, uma escolha prática em 1995, mas desde então se tornou menos conveniente. HTML é prolixo e difícil de escrever à mão, especialmente para desenvolvedores que talvez não estejam familiarizados com ele. Tags JavaDoc embutidas, como {@link} e {@code}, são complicadas e muitas vezes exigem documentação de referência para uso adequado.

Markdown, por outro lado, é uma linguagem de marcação leve e fácil de ler e escrever. Ele oferece suporte a estruturas de documentos simples, como parágrafos, listas, texto estilizado e links, tornando-o um substituto adequado para HTML em comentários de documentação. Além disso, o Markdown permite a inclusão de HTML para construções que não suportam diretamente, proporcionando flexibilidade e reduzindo a complexidade.

Como exemplo do uso de Markdown em um comentário de documentação, considere o comentário para java.lang.Object.hashCode:

/**
* Returns a hash code value for the object. This method is
* supported for the benefit of hash tables such as those provided by
* {@link java.util.HashMap}.
* 
* The general contract of {@code hashCode} is:
* <ul>
* <li>Whenever it is invoked on the same object more than once during
* an execution of a Java application, the {@code hashCode} method
* must consistently return the same integer, provided no information
* used in {@code equals} comparisons on the object is modified.
* This integer need not remain consistent from one execution of an
* application to another execution of the same application.
* <li>If two objects are equal according to the {@link
* #equals(Object) equals} method, then calling the {@code
* hashCode} method on each of the two objects must produce the
* same integer result.
* <li>It is not required that if two objects are unequal
* according to the {@link #equals(Object) equals} method, then
* calling the {@code hashCode} method on each of the two objects
* must produce distinct integer results. However, the programmer
* should be aware that producing distinct integer results for
* unequal objects may improve the performance of hash tables.
* </ul>
*
* @implSpec
* As far as is reasonably practical, the {@code hashCode} method defined
* by class {@code Object} returns distinct integers for distinct objects.
*
* @return a hash code value for this object.
* @see java.lang.Object#equals(java.lang.Object)
* @see java.lang.System#identityHashCode
*/

Este comentário pode ser escrito em Markdown da seguinte forma:

/// Returns a hash code value for the object. This method is
/// supported for the benefit of hash tables such as those provided by
/// [java.util.HashMap].
///
/// The general contract of `hashCode` is:
///
/// - Whenever it is invoked on the same object more than once during
/// an execution of a Java application, the `hashCode` method
/// must consistently return the same integer, provided no information
/// used in `equals` comparisons on the object is modified.
/// This integer need not remain consistent from one execution of an
/// application to another execution of the same application.
/// - If two objects are equal according to the
/// [equals][#equals(Object)] method, then calling the
/// `hashCode` method on each of the two objects must produce the
/// same integer result.
/// - It is _not_ required that if two objects are unequal
/// according to the [equals][#equals(Object)] method, then
/// calling the `hashCode` method on each of the two objects
/// must produce distinct integer results. However, the programmer
/// should be aware that producing distinct integer results for
/// unequal objects may improve the performance of hash tables.
///
/// @implSpec
/// As far as is reasonably practical, the `hashCode` method defined
/// by class `Object` returns distinct integers for distinct objects.
///
/// @return a hash code value for this object.
/// @see java.lang.Object#equals(java.lang.Object)
/// @see java.lang.System#identityHashCode

Principais diferenças a serem observadas:

O uso de Markdown é indicado por uma nova forma de comentário de documentação em que cada linha começa com /// em vez da sintaxe tradicional /** ... */.

O elemento HTML não é obrigatório; uma linha em branco indica uma quebra de parágrafo.

Os elementos HTML <ul> e <li> são substituídos por marcadores de lista com marcadores Markdown, usando - para indicar o início de cada item na lista.

O elemento HTML é substituído por sublinhados (_) para indicar a alteração da fonte.

As instâncias da tag {@code ...} são substituídas por crases (`...`) para indicar a fonte monoespaçada.

Instâncias de {@link ...} para vincular a outros elementos do programa são substituídas por formas estendidas de links de referência Markdown.

Instâncias de tags de bloco, como @implSpec, @return e @see, geralmente não são afetadas, exceto que o conteúdo dessas tags agora também está em Markdown, por exemplo, aqui nos crases do conteúdo da tag @implSpec.

A imagem abaixo compara as duas versões:

Referências:

https://www.infoq.com/news/2024/05/jep467-markdown-in-javadoc/

https://openjdk.org/jeps/467

Java 22

2024-03-17T10:12:00.002-03:00

Java 22 vem aí!

O JDK 22 está chegando, sendo lançado em 19 de março. Podemos acompanhar a live de lançamento aqui https://www.youtube.com/watch?v=AjjAZsnRXtE a partir das 14 horas (horário de Brasilia)

No total, são 12 features (JEPs) a serem liberadas no JDK 22. Classificadas em final features e preview features. 4 final features, 7 preview features e 1 feature incubada. Além de inúmeros bugs corrigidos e pequenas outras novas features. O release notes pode ser acessado aqui.

Final Features

423: Region Pinning for G1

Reduzir a latência implementando a fixação de região no G1, para que a coleta de lixo não precise ser desativada durante regiões críticas da Java Native Interface (JNI). Aborda problemas de travamento de threads porque foram referenciados por objetos usados pelo código nativo. Com esta alteração, o G1 manterá os objetos nativos na região onde residem enquanto continua a executar o coletor de lixo.

454: Foreign Function & Memory API

Uma API que permite que programas Java chamem bibliotecas nativas e processem dados nativos sem a fragilidade e o perigo de JNI. Atualmente, os desenvolvedores Java ainda enfrentam obstáculos significativos no acesso a um tipo importante de recurso não-Java: código e dados na mesma máquina que a JVM, mas fora da JVM.

456: Unnamed Variables & Patterns

Melhorar a linguagem de programação Java com variáveis e padrões sem nome, que podem ser usados quando declarações de variáveis ou padrões aninhados são necessários, mas nunca usados. Ambos são indicados pelo caractere de sublinhado, _. Um exemplo de uso de variáveis sem nome:

static int count(Iterable<Order> orders) {

int total = 0;

for (Order _ : orders) // Unnamed variable

total++;

return total;

}

458: Launch Multi-File Source-Code Programs

Aprimora o inicializador de aplicativos Java para poder executar um programa fornecido como vários arquivos de código-fonte Java. Isso tornará a transição de programas pequenos para programas maiores mais gradual, permitindo que os desenvolvedores escolham se e quando se dar ao trabalho de configurar uma ferramenta de compilação. Este é um recurso que já existe desde o Java 11 (JEP 330) e esta JEP realizou melhorias.

Preview Features

447: Statements before super(...) (Preview)

Permitir que instruções sejam criadas antes da chamada a super() dentro de construtores.

Atualmente, para garantir que os construtores sejam executados de cima para baixo, a linguagem Java exige que, no corpo de um construtor, qualquer invocação explícita de outro construtor apareça como a primeira instrução; se nenhuma invocação explícita do construtor for fornecida, uma será injetada pelo compilador.

Às vezes precisamos validar um argumento que é passado para um construtor de superclasse. Podemos validar o argumento após o fato, mas isso significa potencialmente fazer um trabalho desnecessário. Este é um exemplo do problema que esta JEP quer resolver.

457: Class-File API (Preview)

Fornece uma API para processar arquivos de classe que rastreie o formato de arquivo de classe definido pela especificação da Java Virtual Machine.

Permite que os componentes do JDK migrem para a API padrão e, eventualmente, remova a cópia interna do JDK da biblioteca ASM de terceiros.

459: String Templates (Second Preview)

Os modelos de string foram originalmente propostos como um recurso de visualização pelo JEP 430 no JDK 21. Propomos aqui uma segunda visualização para obter experiência e feedback adicionais. Exceto por uma alteração técnica nos tipos de expressões do modelo, não há alterações em relação à primeira visualização.

460: Vector API (Seventh Incubator)

Este JEP propõe reincubar a API no JDK 22, com pequenas melhorias na API em relação ao JDK 21. A implementação inclui correções de bugs e melhorias de desempenho. Incluímos as seguintes alterações notáveis:

Suporta acesso vetorial com MemorySegments da heap que são apoiados por uma matriz de qualquer tipo de elemento primitivo. Anteriormente, o acesso era limitado MemorySegments da heap apoiado por uma matriz de bytes.

461: Stream Gatherers (Preview)

Aprimora a API Stream para oferecer suporte a operações intermediárias personalizadas. Isso permitirá que pipelines de fluxo transformem dados de maneiras que não são facilmente alcançáveis com as operações intermediárias atuais. Esta é uma API de visualização.

462: Structured Concurrency (Second Preview)

Simplifica a programação simultânea introduzindo uma API para simultaneidade estruturada. A simultaneidade estruturada trata grupos de tarefas relacionadas executadas em diferentes threads como uma única unidade de trabalho, simplificando assim o tratamento e cancelamento de erros, melhorando a confiabilidade e aprimorando a observabilidade. Esta é uma API de visualização.

463: Implicitly Declared Classes and Instance Main Methods (Second Preview)

Evoluir a linguagem Java para que os alunos possam escrever seus primeiros programas sem a necessidade de compreender os recursos da linguagem projetada para programas grandes. Longe de usar um dialeto separado da linguagem, os alunos podem escrever declarações simplificadas para programas de classe única e, em seguida, expandir seus programas para usar recursos mais avançados à medida que suas habilidades aumentam. Este é um recurso de visualização do idioma.

464: Scoped Values (Second Preview)

Introduz valores com escopo definido, que permitem o compartilhamento gerenciado de dados imutáveis tanto com quadros filhos na mesma thread quanto com threads filhas. Os valores com escopo definido são mais fáceis de raciocinar do que variáveis locais de thread e têm menores custos de espaço e tempo, especialmente quando usados em combinação com Virtual Threads e Structured Concurrency. Esta é uma API de visualização.

Um Scoped Values é um contêiner de objeto que permite que um valor de dados seja compartilhado de forma segura e eficiente por um método com seus chamados diretos e indiretos dentro da mesma thread e com threads filhas, sem recorrer a parâmetros de método. É uma variável do tipo ScopedValue. Normalmente, ele é declarado como um campo estático final e sua acessibilidade é definida como privada para que não possa ser acessado diretamente pelo código em outras classes.

Referências

https://openjdk.org/projects/jdk/22/

https://www.youtube.com/watch?v=T64dUc0wIZ0

Introdução ao projeto OpenJDK CRaC

2024-02-24T18:10:00.004-03:00

Projeto OpenJDK CRaC: reduzindo drasticamente o tempo de inicialização de aplicativos Java

Um pouco de história

O objetivo do Java sempre foi ser independente de plataforma. Isto é, sem precisar compilar o código novamente, é possível rodar em qualquer dispositivo compatível com a máquina virtual (JVM). O famoso slogam (write once, run anywhere)

Desafios da inicialização de aplicativos na JVM

Embora o Java seja uma linguagem popular, a inicialização de aplicativos na JVM pode ser um processo demorado. Isso ocorre porque a JVM precisa realizar várias etapas antes que um aplicativo possa ser executado. Primeiro, a JVM precisa carregar e inicializar todas as classes necessárias para o aplicativo. Isso envolve ler os arquivos de classe, desempacotar arquivos JAR e inicializar todas as dependências.

Em seguida, a JVM precisa fazer algumas otimizações de tempo de execução, como compilação just-in-time (JIT) e inlining de métodos. Essas otimizações ajudam a melhorar o desempenho do aplicativo, mas levam tempo para serem concluídas. Por fim, a JVM precisa aquecer o aplicativo, o que envolve analisar o código e determinar quais partes do aplicativo devem ser otimizadas.

Esse processo pode levar muito tempo e afetar a velocidade de inicialização. Esses desafios de inicialização são especialmente problemáticos para aplicativos que precisam ser iniciados rapidamente ou executados em ambientes de contêiner, onde várias JVMs podem competir por recursos limitados. Para cada réplica do aplicativo, o mesmo processo será repetido.

Fonte: https://pt.slideshare.net/SimonRitter/java-on-crac

O mecanismo de execução

Depois que o bytecode é carregado na memória, ele é processado pelo mecanismo de execução da JVM. O mecanismo de execução consiste em vários componentes, incluindo o interpretador, o compilador C1 JIT e o compilador C2 JIT. O interpretador pega o bytecode linha por linha e o interpreta em instruções da CPU. A JVM observa o código e traça o perfil de sua execução, contando com que frequência os métodos são chamados. Se um método for chamado com frequência, ele será colocado no compilador C1 JIT, que o compila rapidamente, sem muitas otimizações, para reduzir o tempo de inicialização. A JVM continua a criar o perfil do código e, se um método for chamado com ainda mais frequência, ele será colocado no compilador C2 JIT, que pode produzir código altamente otimizado e de alto desempenho. Essa combinação de interpretadores e compiladores JIT permite que a JVM otimize o código à medida que ele é executado, resultando em uma execução mais rápida.

OpenJDK CRaC: uma solução para a inicialização rápida de aplicativos na JVM

O Coordinated Restore and Checkpoint, ou CRaC, é uma solução que visa melhorar o tempo de inicialização da JVM. O CRaC permite pausar e restaurar um aplicativo baseado em JVM, eliminando a necessidade de interpretação, compilação e otimização durante a inicialização. Em vez disso, você pode criar um ponto de verificação do seu aplicativo em seu estado totalmente otimizado e começar a partir desse ponto, reduzindo significativamente o tempo que leva para o seu aplicativo atingir o desempenho total.

Essa solução foi desenvolvida para permitir que aplicativos na JVM sejam iniciados mais rapidamente, reduzindo o tempo necessário para carregar e inicializar classes, bem como para realizar otimizações JIT.

Como funciona

O CRaC é baseado em um recurso do Linux chamado CRIU, um projeto para implementar funcionalidade de checkpoint/restore para Linux.

Checkpoint/Restore In Userspace, ou CRIU é um software Linux criado em 2013. Ele pode congelar um contêiner em execução (ou um aplicativo individual) e verificar seu estado no disco. Os dados salvos podem ser usados para restaurar o aplicativo e executá-lo exatamente como estava durante o congelamento.

CRaC só funciona no sistema operacional Linux no momento porque a implementação do OpenJDK depende deste recurso

O CRaC exige que todos os arquivos e conexões de rede sejam fechados antes de tirar um snapshot e após restaurá-lo. É por isso que o CRaC requer suporte no tempo de execução Java e no framework. A API CRaC também permite que aplicativos Java atuem antes de um snapshot ser obtido e depois de restaurado. Os aplicativos podem obter um snapshot por meio de uma chamada de API CRaC ou com o utilitário Java jcmd. Um OpenJDK com suporte ao CRaC carrega um snapshot com a opção de linha de comando -XX:CRaCRestoreFrom.

O CRaC funciona tirando uma foto (snapshot) do estado do seu aplicativo, incluindo a memória JVM e os recursos que ele está usando, e armazenando-o em arquivos. Essa foto, ou ponto de verificação, pode então ser usada para restaurar seu aplicativo ao estado anterior. Ao restaurar a partir de um ponto de verificação, a JVM é essencialmente iniciada de onde parou, ignorando as fases de interpretação, compilação e otimização. Isso permite que seu aplicativo atinja desempenho total quase instantaneamente.

Fonte: https://pt.slideshare.net/SimonRitter/java-on-crac

Distribuições da OpenJDK com CRaC

O projeto CRaC foi aceito no OpenJDK em agosto de 2021, o que significa sua importância para o futuro do Java. Porém ainda está longe de ser incluído no projeto principal.

Algumas distribuições JDK, incluindo Azul Zulu JDK e BellSoft Liberica JDK já oferecem suporte CRaC integrado. Frameworks como Micronaut, Quarkus e Spring já integraram suporte CRaC.

Utilização de outras linguagens na JVM

O OpenJDK CRaC também permite que aplicativos escritos em outras linguagens, como Kotlin, sejam executados na JVM com a mesma rapidez e eficiência.

Benefícios

Os benchmarks mostram que o CRaC pode reduzir os tempos de inicialização em 90% ou mais, levando a tempos de resposta de serviço mais rápidos e melhor desempenho.

Os aplicativos atingem o desempenho máximo muito mais rapidamente após serem restaurados, melhorando ainda mais a capacidade de resposta resultando em melhor utilização de recursos: Menos CPU e memória são usadas durante as inicializações, liberando recursos para outras tarefas.

Existem vários benefícios em usar o CRaC para melhorar o tempo de inicialização da JVM:

Tempo rápido para desempenho total: ao iniciar seu aplicativo a partir de um ponto de verificação, você pode obter desempenho total quase instantaneamente, sem esperar pela interpretação, compilação e otimização.
Eliminação de sobrecarga de interpretação e compilação: com o CRaC, você pode ignorar as fases de interpretação e compilação durante a inicialização, reduzindo o tempo que leva para seu aplicativo ficar totalmente otimizado.
Capacidade de resposta aprimorada: ao reduzir o tempo de inicialização da JVM, seu aplicativo pode responder mais rapidamente, proporcionando uma melhor experiência ao usuário.
Economia de custos: com tempos de inicialização mais rápidos, você pode reduzir o número de nós de alta potência necessários em sua infraestrutura de nuvem, resultando em economia de custos.

Comparativo de aplicações iniciadas sem o CRaC e com o CRaC
Fonte: https://pt.slideshare.net/SimonRitter/java-on-crac

Na prática

Nesta prova de conceito, temos uma aplicação Spring Boot 3.2 rodando com a Azul Zulu JDK 21. E para que possamos testar em Sistemas Operacionais como Mac e Windows, vamos utilizar o Docker para simular um ambiente Linux.

O código fonte da aplicação está disponível em https://github.com/sandrogiacom/crac-demo

O CRaC exige que todos os arquivos e conexões de rede sejam fechados antes de tirar um snapshot e reabri-lo após restaurá-lo. É por isso que o CRaC requer suporte no tempo de execução Java e no framework. A API CRaC também permite que os aplicativos Java atuem antes de um snapshot ser obtido e depois de restaurado. Os aplicativos podem obter um snapshot por meio de uma chamada de API CRaC ou com o utilitário Java jcmd. O Azul OpenJDK carrega um snapshot com a opção de linha de comando -XX:CRaCRestoreFrom.

Para inicializar a aplicação, é necessário informar o parametro -XX:CRaCCheckpointTo=$PATH onde o $PATH é o local no disco onde a JDK irá utilizar para gravar os arquivos para posteriormente restaurar. Ex:

java -XX:CRaCCheckpointTo=cr -jar demo.jar

Com a aplicação em execução, basta obter um snapshot através do comando:

jcmd demo.jar JDK.checkpoint

Para fazer isso, abra um novo terminal, entre no container e execute o checkpoint:

Entrando no container em execução: docker exec -it demo_crac /bin/bash
Obtendo o checkpoint: jcmd demo.jar JDK.checkpoint

Neste momento serão gerados vários arquivos no local indicado na variável $PATH. A aplicação será interrompida após um snapshot ser executado com sucesso.

Para restaurar a aplicação a partir de um snapshot, execute o seguinte comando: java -XX:CRaCRestoreFrom=$PATH.

Ex: java -XX:CRaCRestoreFrom=cr

Aplicação inicializada a partir de um snapshot em 59 milisegundos

Conclusão:

CRaC apresenta uma abordagem inovadora para superar gargalos de inicialização de JVM, oferecendo lançamentos mais rápidos sem sacrificar o desempenho. Sua adequação depende das características específicas da aplicação e de considerações técnicas. Os desenvolvedores interessados em otimizar os tempos de inicialização de microsserviços devem acompanhar de perto o desenvolvimento do CRaC e avaliar seu potencial para suas necessidades específicas.

Referências

https://github.com/CRaC/docs

[VDCLUJ22] Gerrit Grunwald - What the CRaC Superfast JVM startup

https://bell-sw.com/blog/how-to-use-crac-with-java-applications/

2023-12-26T18:19:00.008-03:00

Retrospectiva 2023

2023 foi um ano interessante para o ecossistema Java. Relembrando que o Java foi lançado a quase 30 anos, e desde então, o grande desafio sempre foi a questão da performance, manter a estabilidade e retrocompatibilidade. O objetivo do Java sempre foi ser independente de plataforma. Isto é, sem precisar compilar o código novamente, é possível rodar em qualquer dispositivo compatível com a máquina virtual. O famoso slogam (write once, run anywhere)

Muitos acreditam que o peso desta responsabilidade impede que o Java inove com a velocidade que a comunidade espera. Uma vez que outras linguagens acabam liberando recursos importantes antes do Java. Isso vem mudando desde o lançamento do novo modelo de release a cada seis meses. Atualmente temos dois lançamentos anuais, sendo o primeiro em março e outro em setembro. Uma versão de longo suporte (LTS) a cada três anos. Isto proporciona que a indústria experimente novos recursos, frameworks se atualizem para a próxima versão LTS, tal como o JDK 21.

Foi preciso fazer esta breve introdução para podermos falar das grandes entregas do ecossistema Java em 2023. Java ainda é relevante na comunidade e vai conseguir continuar evoluindo para os próximos anos?

Leia o texto abaixo e tire suas conclusões. Comentários são bem vindos!

Novos Java Champions

Este ano, 18 novos membros entraram para o time, destacando os brasileiros Elias Nogueira e Francisco (Professor) Isidro.

Parabéns!!

JDK 21

Este ano (2023) foram lançadas duas versões, 20 e 21, sendo que a 21 é a mais importante por se tratar de uma versão de longo suporte e por ter entregado features relevantes como Virtual Threads, Sequenced Collections, Pattern Matching for switch, Record Patterns, String Templates (Preview) e Generational ZGC.

JVM Language Summit 2023

O JVM Language Summit é uma colaboração técnica aberta entre designers de linguagens, escritores de compiladores, construtores de ferramentas, engenheiros de runtime e arquitetos da VM. Compartilham experiências como criadores de JVM e de linguagens de programação para JVM. Também participam desenvolvedores não-JVM e tecnologias semelhantes para participar ou falar sobre seu runtime, VM ou sua linguagem favorita. A JVM LS 2023 aconteceu no início de agosto de 2023 em Santa Clara – CA.

Neste link pode-se acompanhar as palestras.

Projeto CRaC

Coordinated Restore at Checkpoint (CRaC) é um projeto que promete um mecanismo do tipo checkpoint/restore. Ele permite fechar arquivos e conexões, despejar o cache antes do ponto de verificação e reabrir/recuperar tudo quando o aplicativo for restaurado a partir da imagem. Pode ser comparado como o hibernar do seu computador. Isto significa que quando a aplicação for reiniciada, ela estará disponível quase que imediatamente.

É possível utilizar uma versão específica do OpenJDK com o CRaC inclusa. A azul disponibiliza no OpenJDK 17. https://www.azul.com/products/components/crac/

GraalVM

Em 2023, o GraalVM Community Edition se alinhou com a cadência de lançamento do JDK de seis meses. Haverá dois lançamentos de recursos por ano para oferecer suporte à versão mais recente do JDK. Um novo lançamento de recurso substitui todos os lançamentos anteriores. As versões do GraalVM são nomeadas de acordo com a versão do JDK que fornecem, por exemplo, GraalVM para JDK 21.

A GraalVM para Java 21 também passa a ter uma nova licença (GFTC). O GFTC destina-se a permitir o uso por qualquer usuário, incluindo uso comercial e de produção. A redistribuição é permitida desde que não seja mediante pagamento de taxa.

Spring Boot, Quarkus e Micronaut

Spring boot 3.2 lançado em novembro de 2023 traz como as principais novidades:

Suporte para Virtual Threads
Suporte inicial para JVM Checkpoint Restore (Project CRaC)
Melhorias para Observabilidade
Atualmente está na versão 3.2.1

Quarkus 3.0 lançado em abril de 2023, é baseado no Jakarta EE 10 e, não é a única mudança. Esta versão vem repleta de novos recursos e melhorias que foram implementadas nesta versão.

O Quarkus 3.0 agora possui uma nova Dev UI que é mais extensível e fácil de usar. Ele também tem uma aparência nova e muito melhorada.

O Eclipse MicroProfile 6.0 se alinha ao Jakarta EE 10 Core Profile e substitui o MicroProfile OpenTracing pela MicroProfile Telemetry.

Hibernate ORM 6
Suporte para Maven 3.9 e Gradle 8
Atualmente está na versão 3.6.4

Micronaut 4.0 lançado em julho de 2023.

Foi atualizado para a ter como baseline o Java 17, kotlin 1.8 e groovy 4.0
Atualmente está na versão 4.2.2

Oracle VS Code Extension

A extensão Oracle Java Platform traz desenvolvimento Java completo (editar-compilar-depurar e ciclo de teste) para projetos Maven e Gradle para VSCode. Bem como outros recursos.

https://marketplace.visualstudio.com/items?itemName=Oracle.oracle-java

The Java Playground

O Java Playground é uma ferramenta online simples que ajuda você a explorar os recursos da linguagem Java. Nenhuma configuração necessária, digite seu trecho Java e execute-o! O Java Playground atualmente é executado no Oracle JDK - Java 21 com recursos de visualização habilitados.

https://dev.java/playground/

O Java 8 ainda é dominante?

Segundo o levantamento da newrelic, mais de 56% dos aplicativos agora usam Java 11 em produção (contra 48% em 2022 e 11% em 2020). Java 8 vem em segundo lugar, com quase 33% dos aplicativos usando-o na produção (contra 46% em 2022).

Embora o Java 11 tenha mantido o primeiro lugar por dois anos consecutivos, a taxa de adoção do Java 17 excedeu em muito o que o mundo dos desenvolvedores viu quando o Java 11 foi introduzido. Mais de 9% dos aplicativos agora usam Java 17 em produção (contra menos de 1% em 2022), representando uma taxa de crescimento de 430% em um ano. Demorou anos para que o Java 11 chegasse perto desse nível.

https://newrelic.com/resources/report/2023-state-of-the-java-ecosystem

Já na pesquisa da jetbrains, o Java 8 ainda é o mais utilizado em produção:

https://www.jetbrains.com/lp/devecosystem-2023/java/#java_versions

Referências

https://youtu.be/NxpHg_GzpnY

Java 21 não é versão LTS

2023-10-08T18:41:00.004-03:00

Se você é do mundo Java, deve saber que o Java 21 foi lançado no dia 19/09/2023 e até um tempo antes, não se sabia se a versão iria ser uma versão de longo suporte ou não.

O fato é que projeto Java (OpenJDK) não oferece uma versão com longo suporte (LTS), assim como aconteceu com o Java 11 e 17. Mas como assim?

Quem oferece o suporte de longo prazo com atualizações de segurança são os fornecedores que geram suas próprias distribuições. Oracle JDK por exemplo. Além de muitas outras como Microsoft, Azul, Adoptium, Amazon, IBM, RedHat que são algumas das principais.

Para entender melhor, vamos separar o Java do JDK, OpenJDK dos seus fornecedores, manutenção e de suporte para entender melhor como tudo isso funciona.

Java 21 na verdade é um atalho para o termo: Java Platform Standard Edition 21. Mas você não pode fazer nada com isso pois não é nem código, nem um binário que você possa instalar. Ela é um conjunto de especificações que definem a linguagem, sua API, uma máquina virtual e mais algumas coisas.

Java Development Kit (JDK) é o que recebe novos commits e essa é a base de código que contém a implementação da especificação do Java 21 por exemplo. Este código por sua vez, é desenvolvido pela OpenJDK e seus códigos fontes podem ser encontrados no github. E a partir de que a versão 21 é lançada, o repositório é arquivado e muda o foco para manutenções em outro repositório, onde a comunidade mantém as atualizações para fornecer após o lançamento.

Manutenção e Suporte

Desde que a cadência de lançamento de seis meses foi implementada, Rob McKenna da Oracle, líder do projeto de atualizações do JDK, é o mantenedor de cada jdk$VERSIONu durante os primeiros seis meses. Depois disso ele deixa este cargo e começa a trabalhar na jdk$VERSION+1u e oferece a liderança do projeto jdk$VERSIONu para outro membro confiável da comunidade que queira manter.

Para algumas versões, como 11, 17 e provavelmente 21, isso acontece e o fork continua com correções contínuas. Mas não há garantias de que isso aconteça, pois não existe nenhum período de tempo definido contratualmente para para manter as atualizações. Para outras versões, o fork é fechado e ninguém mais pode atuar em atualizações.

Manutenção

Manter uma versão JDK dá muito trabalho e, portanto, requer uma quantidade considerável de tempo de algumas pessoas. Existem pessoas que utilizam o seu tempo livre para fazer isso e a maioria das contribuições vêm de grandes empresas.

Mas por que uma grande empresa investiria recursos valiosos na manutenção de um fork antigo de atualizações do JDK?

Existem muitas razões pelas quais uma empresa, mas a principal é porque lucram com uma versão do JDK bem mantida. Seja rodando na própria cloud, distribuem software que dependem do JDK ou oferecem suporte do Java para seus clientes.

Suporte

E por causa deste suporte é que empresas oferecem o "suporte a longo prazo", então resumindo:

O OpenJDK manterá o JDK 21, a implementação de referência da plataforma Java SE 21 por pelo menos seis meses, mas provavelmente por alguns anos nas versões mais utilizadas. Os fornecedores, por outro lado, construirão seus próprios JDKs a partir da base de código da OpenJDK. Eles podem disponibilizá-los gratuitamente e também podem oferecer um suporte comercial.

Comunidade

Mas então se as empresas é que definem quanto tempo vão dar de suporte e em qual versão, como temos sempre uma versão LTS e um tempo determinado?

É aí que entra a colaboração da comunidade, pois como a maior parte do código da JDK é trabalhada por todos os envolvidos, acabam optando pelas mesmas versões e prazos.

Por mais que as maiores empresas em torno do JDK sejam concorrentes diretas, existe um nível de coordenação e cooperação para elevar o Java a este nível de qualidade e organização.

Referência

Espero que tenham gostado e se preferirem ver a explicação direto no Nicolai Parlog da Oracle, é só dar play no vídeo abaixo:

Conheça o instancio

2023-07-10T21:32:00.004-03:00

Uma biblioteca Java para automatizar a configuração de dados em testes de unidade.

Neste post, vou apresentar a biblioteca instancio (www.instancio.org), uma ferramenta poderosa para facilitar a criação de testes unitários em Java. A biblioteca instancio permite instanciar objetos complexos com apenas uma linha de código, evitando a necessidade de escrever construtores, setters ou builders. Além disso, a biblioteca instancio é compatível com o Junit, o framework mais popular para testes unitários em Java.

Para ilustrar o uso da biblioteca instancio, vou usar um exemplo de um sistema de escola que oferece cursos aos alunos. O sistema possui as classes Curso, Aluno, Plrofessor e Matricula, que representam os conceitos do domínio. Cada classe possui vários atributos e métodos, que não serão detalhados aqui por questão de simplicidade. O objetivo é testar o método matricularAluno da classe Curso, que recebe um objeto Aluno e cria uma nova Matricula associada ao curso e ao aluno.

Sem a biblioteca instancio, para criar um objeto Curso e um objeto Aluno para o teste, seria necessário escrever algo como:

Curso curso = new Curso();
curso.setId(1);
curso.setNome("Java Básico");
curso.setCargaHoraria(40);
curso.setPreco(500.0);

Aluno aluno = new Aluno();
aluno.setId(1);
aluno.setNome("João");
aluno.setEmail("joao@gmail.com");
aluno.setTelefone("999999999");

Com a biblioteca instancio, basta escrever:

Curso curso = Instancio.instance(Curso.class);
Aluno aluno = Instancio.instance(Aluno.class);

A biblioteca instancio se encarrega de gerar valores aleatórios e válidos para os atributos das classes, seguindo algumas regras simples. Por exemplo, se o atributo é do tipo String, a biblioteca gera uma string alfanumérica; se o atributo é do tipo int, a biblioteca gera um número inteiro; se o atributo é do tipo boolean, a biblioteca gera um valor verdadeiro ou falso; e assim por diante. A biblioteca também suporta atributos que são outras classes, listas, enums ou interfaces.

Casos de teste

Bons testes devem cobrir todos os ramos da lógica condicional. Isso nos dá mais confiança em nosso código e, muitas vezes, revela problemas que podemos ter esquecido. Embora nosso serviço seja muito simples, ele ainda apresenta alguns cenários que precisam ser cobertos.

Depois de criar os objetos Curso e Aluno com a biblioteca instancio, basta chamar o método matricularAluno e verificar se o resultado é o esperado. Para isso, podemos usar o Junit e as suas asserções. O teste ficaria assim:

@Test
public void testMatricularAluno() {
// Arrange
Curso curso = Instancio.instance(Curso.class);
Aluno aluno = Instancio.instance(Aluno.class);

// Act
Matricula matricula = curso.matricularAluno(aluno);

// Assert
assertNotNull(matricula);
assertEquals(curso, matricula.getCurso());
assertEquals(aluno, matricula.getAluno());
}

Como podemos ver, a biblioteca instancio simplifica bastante a criação de testes unitários em Java, reduzindo a quantidade de código necessário e aumentando a legibilidade dos testes. A biblioteca instancio é gratuita e open source, e pode ser baixada no site www.instancio.org. Recomendo que você experimente a biblioteca instancio e veja como ela pode melhorar a qualidade dos seus testes unitários.

Configurando o projeto

Para usar a biblioteca instancio, você só precisa adicionar a dependência no seu projeto. Neste caso, estou utilizando maven:

<dependency>
 <groupId>org.instancio</groupId>
 <artifactId>instancio-core</artifactId>
 <version>2.16.1</version>
 <scope>test</scope>
</dependency>

A biblioteca instancio também suporta tipos genéricos, classes record e sealed, arrays e streams. Você pode criar coleções de objetos usando o método `ofList`:

List<Aluno> alunos = Instancio.ofList(Aluno.class).size(10).create();

Ou criar tipos genéricos usando o `TypeToken`:

Pair<List<Foo>, List<Bar>> pairOfLists = Instancio.create(new TypeToken<Pair<List<Foo>, List<Bar>>>() {});

Como personalizar os valores gerados

Se você precisar personalizar os valores gerados pela biblioteca instancio, você pode usar vários métodos da API para isso. Por exemplo, você pode usar o método `generate` para definir um gerador customizado para um campo específico:

Pessoa pessoa = Instancio.of(Pessoa.class)
.generate(field(Pessoa::getDataNascimento), gen -> gen.temporal().localDate().past())
.create();

Esse código cria um objeto `Pessoa` com o campo `dataNascimento` gerado usando o gerador `gen.temporal().localDate().past()`, que retorna uma data passada aleatória.

Você também pode usar o método `set` para definir um valor fixo para um campo:

Pessoa pessoa = Instancio.of(Pessoa.class).set(field(Pessoa::getNome), "João")
.create();

Esse código cria um objeto `Person` com o campo `firstName` definido como "João".

Outro método útil é o `supply`, que permite fornecer um valor dinâmico para um campo usando um `Supplier`:

Pessoa pessoa = Instancio.of(Pessoa.class)
.supply(all(LocalDate.class), () -> LocalDate.now())
.create();

Esse código cria um objeto `Pessoa` com todos os campos do tipo `LocalDate` definidos como o momento atual.

Além disso, você pode usar o método `onComplete` para executar uma ação após a criação do objeto:

Pessoa pessoa = Instancio.of(Pessoa.class)
.onComplete(all(Pessoa.class), (Pessoa p) ->
p.setNome(p.getGenero() == Genero.MASCULINO ? "João" : "Maria"))
.create();

Esse código cria um objeto `Pessoa` e depois define o campo `nome` de acordo com o campo `genero`.

Como criar modelos reutilizáveis de objetos

Se você precisar criar vários objetos com características semelhantes, você pode usar o conceito de modelos (Models) da biblioteca instancio. Um modelo é uma forma de definir um template de objeto que pode ser reutilizado em diferentes testes.

Por exemplo, se você quiser criar objetos da classe `Pessoa` que representam membros da família Simpson, você pode criar um modelo assim:

Model<Aluno> simpsons = Instancio.of(Aluno.class)
.set(field(Aluno::getSobrenome), "Simpson")
.set(field(Endereco::getCidade), "Springfield")
.generate(field(Aluno::getDataNascimento), gen -> gen.temporal().localDate().past())
.toModel();

Esse modelo define que todos os objetos `Aluno` criados a partir dele terão o sobrenome "Simpson", a cidade "Springfield" e uma idade entre 40 e 50 anos.

Depois, você pode criar objetos específicos usando esse modelo:

Aluno homer = Instancio.of(simpsons)
.set(field(Aluno::getNome), "Homer")
.set(all(Genero.class), Genero.MASCULINO)
.create();

Aluno marge = Instancio.of(simpsons)
.set(field(Aluno::getNome), "Marge")
.set(all(Genero.class), Genero.FEMININO)
.create();

Esses códigos criam objetos `Aluno` que representam o Homer e a Marge, usando os valores definidos no modelo e sobrescrevendo os valores específicos de cada um.

Principais recursos da biblioteca instancio

A biblioteca instancio possui vários recursos interessantes que facilitam a geração de dados de teste. Alguns deles são:

Dados totalmente reproduzíveis em caso de falha nos testes. A biblioteca instancio usa uma semente (seed) para gerar os dados aleatórios, que pode ser especificada ou obtida pelo usuário. Assim, é possível reproduzir os mesmos dados que causaram a falha e corrigir o problema.
Suporte para anotações de validação de beans. A biblioteca instancio pode gerar dados que respeitam as anotações de validação de beans, como `@NotNull`, `@Size`, `@Email`, etc. Isso evita que os testes falhem por causa de dados inválidos.
Opções flexíveis de configuração. A biblioteca instancio permite configurar vários aspectos do comportamento da geração de dados, como o modo estrito ou leniente, a profundidade máxima, o mapeamento de subtipos, etc. Essas configurações podem ser feitas programaticamente ou usando um arquivo de propriedades.
Integração com JUnit Jupiter. A biblioteca instancio oferece uma extensão para JUnit Jupiter que facilita a reprodução de testes falhos, a injeção de configurações e a geração de argumentos para testes parametrizados.
Interface de provedor de serviço (SPI). A biblioteca instancio permite que o usuário crie e registre suas próprias implementações de interfaces como `GeneratorProvider`, `TypeResolver` e `TypeInstantiator`, para customizar ainda mais a geração de dados.

Conclusão

Neste post, apresentei a biblioteca instancio, uma ferramenta poderosa para gerar dados de teste em Java. Mostrei como usar sua API simples e flexível para criar objetos totalmente populados com dados aleatórios, personalizar os valores gerados e criar modelos reutilizáveis de objetos. Eu também listei alguns dos principais recursos da biblioteca, que tornam a geração de dados mais fácil e confiável.

Se você se interessou pela biblioteca instancio, você pode acessar o site https://www.instancio.org/user-guide para ver mais detalhes sobre sua documentação, exemplos e artigos. Você também pode contribuir com o projeto no GitHub: https://github.com/instancio/instancio.

E como sempre, um exemplo de utilização no meu GitHub: https://github.com/sandrogiacom/school-test

Espero que você tenha gostado deste post e que a biblioteca instancio possa te ajudar a escrever testes melhores e mais concisos em Java. Até a próxima!

Referências:

https://www.instancio.org/getting-started/

https://www.baeldung.com/java-test-data-instancio

Conhecendo o serviço fly.io - Parte 1

2023-02-01T20:57:00.008-03:00

Conhecendo o serviço fly.io - Parte 1

Fly.io é uma plataforma de hospedagem em nuvem que fornece aos desenvolvedores um ambiente simplificado e altamente otimizado para hospedar seus aplicativos e sites. Ele oferece uma variedade de benefícios, incluindo maior desempenho, escalabilidade e segurança, tornando-o a escolha ideal para desenvolvedores que desejam criar e iniciar seus aplicativos de maneira rápida e fácil.

Isto aqui não é um patrocínio da plataforma, mas apenas uma ajuda para quem está procurando alguma hospedagem gratuita tal como era o Heroku.

No momento da escrita deste post, a plataforma não tem suporte ao Java, porém é possível realizar um deploy utilizando uma imagem Docker, onde vou demonstrar nos próximos posts. Abaixo pode-se conferir a lista de linguagens suportadas:

https://fly.io/docs/languages-and-frameworks/

Alguns dos principais recursos que Fly.io incluem:

Global CDN: Fly.io utiliza uma rede global de entrega de conteúdo (CDN) rápida e eficiente para fornecer conteúdo de forma rápida e confiável para usuários em todo o mundo.

Escalabilidade: Com o Fly.io, você pode facilmente escalar ou reduzir seu aplicativo conforme necessário, sem ter que se preocupar com os detalhes técnicos do gerenciamento de infraestrutura.

Integração fácil: Fly.io integra-se facilmente com ferramentas e serviços populares, como GitHub, GitLab e Jenkins, para que você possa começar de forma rápida e fácil.

Otimização de desempenho: Fly.io otimiza o desempenho do seu aplicativo, utilizando cache e outras técnicas para melhorar os tempos de resposta e reduzir a carga do servidor.

Segurança: Fly.io leva a segurança a sério e fornece uma variedade de recursos e ferramentas para ajudar a manter seus aplicativos e dados seguros, incluindo criptografia, certificados Secure Socket Layer (SSL) e muito mais.

Quanto custa?

O custo do Fly.io varia de acordo com os serviços e recursos específicos exigidos pelo usuário. O Fly.io opera em um modelo de preços conforme uso (pay-as-you-go), em que os usuários são cobrados com base no uso da plataforma. Isso inclui fatores como a quantidade de tráfego, o número de funções sem servidor e a quantidade de armazenamento usado.

O Fly.io fornece uma calculadora de custos em seu site, permitindo que os usuários estimem o custo de seu uso. Também é possível receber um orçamento da equipe Fly.io entrando em contato diretamente com eles.

É importante observar que o Fly.io oferece uma avaliação gratuita para novos usuários, permitindo que eles testem a plataforma e seus recursos antes de se comprometer com um plano pago. Isso oferece uma oportunidade para os usuários avaliarem a plataforma e determinarem se ela atende às suas necessidades.

Recursos gratuitos

Recursos incluídos gratuitamente em todos os planos:

Até 3 VMs de CPU compartilhada de 1x 256 MB*
Armazenamento de volume persistente de 3 GB (total)
Transferência de dados de saída de 160 GB

*Total de 3 VMs entre Aplicativos e Máquinas

Não existe até o momento uma regra de tempo para utilizar os recursos gratuitos. Lembrando que para fazer o seu primeiro deploy, é necessário um cadastro e um cartão de crédito válido

Referências:

https://fly.io/docs/

https://fly.io/docs/about/pricing/

AWS Lambda kickstarts Java functions

2023-01-29T18:15:00.003-03:00

AWS Lambda kickstarts Java functions

O AWS Lambda SnapStart reduz o tempo de inicialização do Java iniciando as funções antecipadamente e armazenando em cache uma foto (snapshot) do ambiente de execução já inicializado.

A AWS revelou o AWS Lambda SnapStart para Java, uma otimização de desempenho destinada a facilitar a criação de aplicativos Java responsivos e escaláveis usando o AWS Lambda, o serviço de computação sem servidor e orientado a eventos na nuvem da Amazon.

Apresentado em 28 de novembro de 2022, o AWS Lambda SnapStart para Java melhora os tempos de inicialização iniciando o código de uma função antecipadamente (ahead of time), obtendo um acesso instantâneo ao ambiente de execução inicializado e armazenando-o em cache. Quando a função é invocada e dimensionada, o SnapStart retoma novos ambientes de execução a partir do instantâneo armazenado em cache, em vez de precisar inicializá-los do zero, melhorando assim a latência de inicialização, disse a AWS.

Elaborando seu raciocínio para o serviço, a AWS disse que, para aplicativos sensíveis à latência, nos quais os usuários desejam oferecer suporte a rajadas imprevisíveis de tráfego, longas latências de inicialização podem afetar negativamente a experiência do usuário. O AWS Lambda SnapStart é ideal para aplicativos como microsserviços interativos, processamento de dados ou APIs síncronas.

Os usuários podem ativar o Lambda SnapStart para funções Lambda novas ou existentes baseadas em Java em execução no Amazon Corretto 11 por meio da API AWS Lambda, Console de gerenciamento da AWS, AWS Command Line Interface e outros recursos da AWS.

O Lambda SnapStart está disponível nas seguintes regiões da AWS: Leste dos EUA (Ohio), Leste dos EUA (N. da Virgínia), Oeste dos EUA (Oregon), Ásia-Pacífico (Cingapura), Ásia-Pacífico (Tóquio), Ásia-Pacífico (Sydney), Europa (Frankfurt), Europa (Irlanda) e Europa (Estocolmo).

Referências:

https://www.infoworld.com/article/3681549/aws-lambda-kickstarts-java-functions.html

https://aws.amazon.com/pt/about-aws/whats-new/2022/11/aws-lambda-snapstart-java-functions/

https://aws.amazon.com/pt/blogs/aws/new-accelerate-your-lambda-functions-with-lambda-snapstart/

Eclipse Migration Toolkit for Java

2023-01-01T12:00:00.001-03:00

Eclipse Migration Toolkit for Java (EMT4J) simplifica a atualização de aplicativos Java

A Adoptium apresentou o Eclipse Migration Toolkit for Java (EMT4J), um projeto Eclipse de software livre capaz de analisar e atualizar aplicativos do Java 8 para o Java 11 e do Java 11 para o Java 17. O EMT4J suportará a atualização para futuras versões LTS.

As organizações aconselham manter o Java runtime atualizado para obter segurança e melhorias funcionais. Enquanto isso, as versões Java Long Term Support (LTS) serão lançadas a cada dois anos e projetos como o Spring Framework 6 agora requerem o Java 17. Infelizmente, a adoção de novas versões Java é relativamente lenta. Por exemplo, em 2022, quatro anos após seu lançamento, o Java 11 foi usado por menos de 49% dos aplicativos Java.

Atualizar um aplicativo para uma nova versão do Java significa que os desenvolvedores precisam resolver todos os problemas introduzidos pelas alterações e remoções dentro do Java. Isso inclui funcionalidades como a remoção dos pacotes Nashorn, J2EE e Java, uma alteração nas APIs e acesso aos componentes internos do Java que se tornaram mais restritos.

O EMT4J oferece um plugin Maven (ainda não disponível na central Maven), agente Java e solução de linha de comando para analisar incompatibilidades de projetos com novas versões Java e a saída é gravada nos formatos TXT, JSON ou HTML.

Para demonstrar o EMT4J, considere o seguinte aplicativo de exemplo que faz uma chamada para o método Thread.stop() que foi removido no Java 11:

Thread thread = new Thread();
thread.stop();

Depois de clonar o repositório Git e configurar as cadeias de ferramentas Maven para JDK 8 e JDK 11, o projeto pode ser construído com:

mvn clean package -Prelease

Isso resulta em um arquivo .zip no diretório emt4j-assembly/target que pode ser extraído. Dentro do diretório extraído, a análise pode ser iniciada. Por exemplo, na linha de comando:

java -cp "lib/analysis/*" org.eclipse.emt4j.analysis.AnalysisMain -f 8 -t 17
-o java8to17.html /home/user/application/classes

Isso analisa os arquivos de classe no diretório especificado e exibe possíveis problemas ao atualizar do Java 8 para o Java 17 no arquivo java8to17.html. Alternativamente, os scripts .bat ou .sh no diretório bin do arquivo extraído podem ser usados para iniciar a análise da linha de comando. O arquivo README descreve todas as opções disponíveis para analisar classes e arquivos JAR.

O arquivo HTML resultante exibe a descrição, resolução e localização do problema:

1.1 Removed API Back to Content
1.1.1 Description
Many of these APIs were deprecated in previous releases and
have been replaced by newer APIs.
1.1.2 How to fix
See corresponding JavaDoc.
1.1.3 Issues Context
Location: file:/home/user/application/classes/App.class,
Target: java.lang.Thread.stop()V

Como alternativa, o agente EMT4J pode ser usado ao iniciar um aplicativo Java ou o plugin Maven ao criar o projeto.

O projeto contém conjuntos de regras para atualização de Java 8 para 11 e de Java 11 para 17. Por exemplo, a regra de API interna do JDK é usada para verificar se um aplicativo usa os componentes internos do JDK:

<rule desc="JDK internal API" type="reference-class"
match-type="by-package" class-package-file="jdk_internals.cfg"
result-code="JDK_INTERNAL" must-contain-in-bytecode="true"
sub-result-code="@{subResultCode}" priority="p4">
<support-modes>
<mode>agent</mode>
<mode>class</mode>
</support-modes>
</rule>

Os modos de suporte (modes) indicam se a regra pode ser usada com o modo de agente(agent) e/ou por meio da análise estática, modo de classe(class), com a linha de comando ou plugin Maven. Os pacotes de recursos de tradução são vinculados por meio do resultado do código, neste caso, JDK_INTERNAL, que mapeia para os arquivos de tradução JDK_INTERNAL.properties e JDK_INTERNAL_zh.properties dentro do diretório emt4j-common/src/main/resources/default/i18n.

O EMT4J verifica o aplicativo em busca de pacotes e classes como sun.nio e sun.reflect definidos no arquivo de pacote de classe jdk_internals.cfg no diretório emt4j-common/src/main/resources/default/rule/8to11/data/

A classe de referência do tipo de regra real está localizada dentro do diretório emt4j-common/src/main/java/org/eclipse/emt4j/common/rule/impl, pois a regra interna do JDK possui modes, agent e class.

@RuleImpl(type = "reference-class")
public class ReferenceClassRule extends ExecutableRule {

As regras existentes podem oferecer inspiração para adicionar regras personalizadas seguindo as instruções no arquivo README.

Fontes (Em Inglês):

https://www.infoq.com/news/2022/12/eclipse-migration-toolkit-java

O suporte de longo prazo e o que o LTS significa para o ecossistema Java

2022-09-10T10:32:00.000-03:00

A arte do suporte de longo prazo e o que o LTS significa para o ecossistema Java

Aqui está o que o Java 17 tem em comum com o Java 11 e o Java 8.

Em junho de 2018, há pouco mais de três anos, a Oracle e outros participantes do ecossistema Java anunciaram uma mudança no modelo de cadência de lançamento para Java SE.

Em vez de ter um lançamento principal planejado a cada dois ou quatro anos (que geralmente se torna de três a quatro anos), um novo modelo de lançamento de recursos de seis meses seria usado: a cada três anos, um lançamento seria designado como Long-Term Support (LTS) e receba apenas atualizações trimestrais de segurança, estabilidade e desempenho. Esse padrão foi emprestado descaradamente do modelo de lançamento do Mozilla Firefox, mas o ajustou para ficar mais alinhado com os requisitos de uma plataforma de desenvolvimento.

A primeira versão do Java lançada sob esse modelo foi o Java SE 11.

O lançamento do Java SE 17, o segundo lançamento do LTS sob o novo modelo, é iminente, e este artigo fornecerá uma atualização sobre como os lançamentos do Java SE funcionam. Também oferecerei alguns comentários sobre o que funcionou bem nos últimos três anos e quais refinamentos adicionais você deve esperar daqui para frente.

[Em 14 de setembro de 2021, a Oracle propôs mudar a cadência dos lançamentos do JDK LTS de três em três anos para dois em dois anos. Se aceito, isso significa que a próxima versão do JDK LTS após o JDK 17 será o JDK 21, em vez do JDK 23. —Ed.]

O modelo de lançamento de recursos de seis meses

No modelo de lançamento de recursos, os desenvolvedores da plataforma Java podem trabalhar em recursos e lançá-los em qualquer período de seis meses, mas somente quando os recursos estiverem prontos. Compare isso com o antigo modelo de lançamento principal legado, onde os desenvolvedores da plataforma Java sentiram uma enorme pressão para empurrar recursos para um lançamento; caso contrário, teriam que esperar vários anos pelo próximo ciclo.

Enquanto isso, os desenvolvedores de aplicativos agora desfrutam de uma cadência constante de recursos pequenos em uma linha do tempo previsível. Isso é muito melhor do que ter desenvolvedores Java tentando consumir centenas de alterações de uma só vez a cada poucos anos.

Tem funcionado? Três anos no novo modelo, pesquisas com desenvolvedores mostram que entre um quarto e meio dos desenvolvedores usam a versão Java mais recente de seis meses como sua versão do dia-a-dia. Metade deles disse ter aplicativos em produção na versão mais recente.

E o resto?

É bem entendido e esperado que nem todos os desenvolvedores ou organizações queiram consumir lançamentos de recursos em uma cadência de seis meses. Organizações mais conservadoras, especialmente, querem solidificar uma pilha de desenvolvimento em torno de uma única versão e não assumir riscos associados à introdução de novos recursos. É aqui que as versões Java LTS entram em jogo.

LTS se concentra na estabilidade

As versões Java LTS, como Java 11 e Java 17, são semelhantes às versões de suporte estendido do Firefox. As atualizações da Oracle para as versões Java LTS fornecem apenas melhorias de estabilidade, segurança e desempenho, não novos recursos. Isso reduz o risco de que uma atualização possa interromper a interação com uma ferramenta ou biblioteca. As organizações podem contar com lançamentos Java LTS disponíveis por pelo menos oito anos, proporcionando tempo suficiente para que as cadeias de ferramentas se solidifiquem e para que os desenvolvedores façam a transição para outro LTS vários anos depois.

O modelo LTS permite que os provedores de tecnologia se concentrem em versões específicas no suporte de longo prazo de seus produtos. Afinal, seria impraticável esperar que provedores de plataforma e cadeias de ferramentas fornecessem vários anos de suporte a cada lançamento de recurso de seis meses. Muito rapidamente haveria dezenas de versões precisando de suporte, bem como uma base de usuários fragmentada que seria impraticável de gerenciar.

O momento ideal para versões que recebem o tratamento LTS é subjetivo. Historicamente, se você olhar para trás, do Java 1.2 ao Java 8, havia três a quatro anos entre os principais lançamentos. O novo modelo de lançamento de recursos tem três anos entre o Java 11 e o Java 17. Para organizações muito conservadoras, esse intervalo de três anos é ideal, mas à medida que mais desenvolvedores usam ferramentas e técnicas modernas, há uma demanda crescente para que a Oracle ofereça versões Java LTS em um ciclo mais curto, talvez a cada dois anos.

Sejamos claros: cada provedor de binários da plataforma Java oferece seus próprios cronogramas e ofertas de suporte. O padrão na Oracle é que haverá oito anos de suporte para uma versão Java SE LTS. Para o Java 8, o LTS já foi estendido até pelo menos 2030, o que significa que esta versão terá pelo menos 16 anos de suporte quando for finalmente aposentada!

Enquanto isso, versões como Java 7 e Java 11 provavelmente não terão extensões de suporte. As extensões são baseadas simplesmente na adoção e se as organizações que fornecem os respectivos binários consideram valioso continuar oferecendo suporte (comercial).

Conclusão

As versões LTS atuais do Java são Java 7, Java 8, Java 11 e 17. Java 11 e Java 17 foram lançados sob a nova cadência de lançamento de recursos e com exatamente três anos de diferença; Java 7 e Java 8 são do modelo de versão principal legado. O suporte ainda é o mesmo, com cada versão LTS do Java recebendo apenas atualizações de desempenho, estabilidade e segurança.

A Oracle pretende oferecer suporte às versões Java LTS da seguinte forma:

Java 7 até 2022
Java 8 até pelo menos 2030
Java 11 até 2026
Java 17 até pelo menos 2029

A Oracle quer que desenvolvedores e organizações tenham o melhor dos dois mundos: somente você pode decidir se faz sentido acompanhar os lançamentos de seis meses e digerir novos recursos regularmente ou implantar em uma versão LTS específica por um longo período . As organizações, é claro, podem misturar e combinar sua abordagem, por exemplo, mantendo a cadência de seis meses durante o desenvolvimento, mas bloqueando uma versão LTS quando o código estiver em produção.

Referências

https://blogs.oracle.com/javamagazine/post/java-long-term-support-lts?_x_tr_sl=pt&_x_tr_tl=en&_x_tr_hl=pt-BR&_x_tr_pto=wapp

Java 8 ao 18: Mudanças mais importantes na plataforma Java

2022-09-09T01:30:00.006-03:00

Vamos rever muitas das mudanças mais importantes na plataforma Java que aconteceram entre a versão 8 (2014) e 18 (2022)

O Java 8 foi lançado em março de 2014 e o Java 18 em março de 2022. São 8 anos de progresso, 203 JEPs (JDK Enhancement Proposals ), entre essas duas versões. Neste post, revisaremos as mudanças mais importantes e discutiremos os benefícios e desafios da adoção de versões mais recentes do JDK para novos aplicativos e para os mais antigos compilados com versões mais antigas.

Desde a versão 9, o Java tem novos recursos a cada 6 meses e é muito difícil acompanhar essas novas mudanças. A maioria das informações na internet descreve as mudanças entre as duas últimas versões do Java. No entanto, se você estiver em uma situação semelhante à minha, não está usando uma das versões mais recentes do Java, mas uma das várias versões anteriores (Geralmente 8 ou 11 que são as versões de suporte estendido).

Então é útil saber quais novos recursos foram adicionados desde a versão que você usa agora, ou entre as versões que você usa agora e aquela que você deseja começar a usar em seguida. Portanto, compilei uma tabela com todos os novos recursos adicionados desde o Java 8 para cada nova versão do Java.

Abaixo você encontra tabelas para:

Novos recursos da linguagem Java – adições à linguagem Java ou APIs
Novas ferramentas e recursos no OpenJDK – adições fora da linguagem, como ferramentas de linha de comando ou melhorias na JVM
Recursos e APIs obsoletos/removidos

Observe que não inclui todos os novos recursos e adições de API, apenas aqueles que são úteis para a maioria dos desenvolvedores, para manter a lista curta.

Este artigo não é sobre como escolher a versão Java certa para você usar. Mas vou pelo menos resumir todas as versões do Java desde o Java 8 e para sua conveniência:

Java 8 – versão LTS (Long Term Support), última versão LTS antes do JPMS (módulos) serem introduzidos no Java 9
Java 11 – versão LTS
Java 17 – versão LTS, a versão LTS mais recente até março de 2023
Java 18 – versão não LTS, a versão mais recente em março de 2022
Todas as outras versões Java – versões não LTS

Na maioria dos casos, você deve usar apenas versões LTS em produção. Isso é, a menos que você tenha necessidades específicas para usar o maior e a mais recente versão e esteja disposto a atualizar para uma nova versão do Java a cada 6 meses. Para saber mais sobre as versões do Java LTS, você pode ler A arte do suporte de longo prazo e o que o LTS significa para o ecossistema Java da Oracle (Em Inglês).

Novos recursos da linguagem Java desde o Java 8

Feature	Desde	Preview desde
Simple Web Server (a.k.a com.sun.net.httpserver.SimpleFileServer) Java API: SimpleFileServer.createFileServer(new InetSocketAddress(9000), path, logLevel).start(); Cmd Line: jwebserver -p 9000	18
Code Snippets in Java API Documentation {@snippet : lines of code} instead of <pre>{@code lines of code }</pre>	18
UTF-8 by Default – em vez do charset definido pelo sistema.. Rode javac -encoding UTF-8 com JDK 8-17 para verificar problemas de codificação de código Java.	18
Context-Specific Deserialization Filters – Permitir que os aplicativos configurem filtros de desserialização, especifique um padrão por meio de uma propriedade do sistema ou uma fábrica de filtros por meio de uma propriedade do sistema ou por meio de ObjectInputFilter.Config	17
Pattern Matching for switch – como instanceof para switch; switch é uma expressão e pode ser atribuída: String result = switch (o) { case null -> null; case 0 -> throw new RuntimeException("Cannot be 0"); // Special cases case Integer i && i > 0 -> "Positive number"; case Integer i -> "Negative number"; // 0 and positive numbers handled by above rules case String s -> s; case Point p -> p.toString(); case int[] ia -> "Array length" + ia.length; default -> "Something else"; }		17
Foreign Function & Memory API (uma alternativa ao JNI)		16
Vector API – Cálculos expressos que compilam para instruções de hardware ideais		16
Sealed classes (herança apenas para classes permitidas): public abstract sealed class Shape permits Circle, Rectangle, Square {...}	17	15
Record type – classes de dados com métodos getters, construtores, equals, hashCode e toString implícitos: record Point(int x, int y) { }	16	14
Membros estáticos em classes internas (parte do JEP Record type) new Object() { static record MyData(String data) {}; public static final int CONSTANT = 1; };	16	16
Pattern Matching for instanceof: if (x instanceOf String s) { String a = s; }	16	14
Text blocks: String query = """ SELECT "EMP_ID", "LAST_NAME" FROM "EMPLOYEE_TB"; """	15	13
Novos métodos de String (formatted, stripIndent, translateEscapes)	15
Switch expressions: boolean isWeekend = switch (day) { case SATURDAY, SUNDAY -> true; default -> false; };	14	12
Novos métodos de String (indent, transform)	12
CompactNumberFormat class	12
Novos métodos de String (repeat, isBlank, strip, lines)	11
var type allowed in Lambda Parameters: (@NonNull var x) -> process(x)	11
New HTTP client API	11	9
TLS v1.3 – suporte para uma nova versão do protocolo SSL/TLS	11
var type allowed for local variables: var length = str.length();	10
Flow API (reactive streams)	9
Java Platform Module System (modules)	9
Collection factory methods: List.of(a, b, c); Set.of(d, e, f, g); Map.of(k1, v1, k2, v2);	9
Stream API improvements (takeWhile, dropWhile, ofNullable, iterate with condition)	9
Multi-Resolution Image API	9
Stack-Walking API	9
Process API updates (informações detalhadas sobre processos, por ex. ID, onExit, destroy)	9
new methods in CompletableFuture API (delay, timeout)	9
Interface private methods	9
since and forRemoval in @Deprecated	9
Interface Default and Static Methods	8
Method References	8
Optional class	8
Lambda expressions	8
Functional interfaces	8
Stream API	8
Effectively Final Variables	8
Repeating Annotations	8
New Date Time API	8

New JDK tools and features since OpenJDK 8

Tool / feature	Desde	Preview desde
Packaging Tool		14
Epsilon (no-op) GC		11
Experimental Java-Based JIT Compiler (Graal VM)		10
Shenandoah GC	15	12
Z GC (JEP 377)	15	11
Helpful NullPointerExceptions	14
Launching Java files as scripts	11
Flight recorder (data collection framework for troubleshooting)	11
Docker Container Support: -XX:-UseContainerSupport	10, 8u191
Flexible heap size selection: -XX:MaxRAMPercentage	10, 8u191
Application Class-Data Sharing (CDS)	10
jlink – custom JRE image, subset of JRE	9
JShell (Java REPL) – run Java commands interactively	9
Multi-Release JAR Files	9
Compact Strings	9

Deprecated/removed features and APIs:

Feature / API	Depreciado desde	Removido desde
Deprecate Finalization for Removal (finalize() and similar methods)	18
Deprecate the Security Manager for Removal	17
Constructors of primitive wrapper classes (e.g. new Integer(1))	16
ParallelScavenge + SerialOld GC Combination	14
Applet API (Deprecated For Removal in Java 17)	9
RMI Activation	15	17
Strongly Encapsulate JDK Internals (except sun.misc.Unsafe and some more) – internal JDK classes won’t be available anymore	9	17
Nashorn JavaScript Engine	11	15
Solaris and SPARC Ports	14	15
CMS GC	9	14
Pack200 Tools and API	11	14
Java FX (moved to OpenJFX)		11
Java Web Start (was only in Oracle JDK)	9	11
Java EE and CORBA modules (JAX-WS, JAXB, JAF, Common Annotations, CORBA, JTA) Look here to find replacements for the removed modules	9	11
javah Native-Header Generator		10
jhat Heap Visualizer		9
Launch-Time JRE Version Selection		9
rt.jar and tools.jar		9
The extension mechanism (java.ext.dirs property)		9
Rarely-Used GC Combinations	8	9

Para mais detalhes, o catálogo javaalmanac.io/ é muito útil para navegar pelas mudanças em Java ao longo de todo o seu histórico. Ele pode fornecer diferenças completas de APIs entre versões Java selecionadas, por exemplo, entre Java 8 e Java 11. Muito útil se você está pensando em migrar para uma versão específica do Java.

Fontes (Em Inglês):

A categorized list of all Java and JVM features since JDK 8 to 18 - Advanced Web Machinery

Java 8 to 18: most important changes in the java platform

New features between Java 8 and Java 18 - .Lost in Coding

Projeto Leyden atrasa o compilador OpenJDK AOT e otimiza o compilador JIT em vez disso

2022-07-05T22:08:00.005-03:00

Projeto Leyden atrasa o compilador OpenJDK AOT e otimiza o compilador JIT em vez disso

O objetivo do Projeto Leyden é "resolver os pontos problemáticos de longo prazo do tempo de inicialização lenta do Java, do tempo lento para o desempenho máximo". Ele queria chegar lá "introduzindo um conceito de imagens estáticas" no OpenJDK. Imagens estáticas resultam da compilação Ahead-of-Time (AOT) para executáveis nativos . Após dois anos sem atividade publicamente visível, o Projeto Leyden mudou em maio de 2022 para primeiro otimizar a compilação Just-in-Time (JIT). As " otimizações resultantes quase certamente serão mais fracas " do que o planejado inicialmente e alcançarão os principais desenvolvedores Java no final de 2025, no mínimo. O projeto Graal da Oracle já atingiu o objetivo do Projeto Leyden, mas a um custo que o projeto quer evitar por enquanto.

O projeto Graal tem origem no Oracle Labs e não faz parte do OpenJDK. Sua imagem nativa GraalVM é um compilador Java AOT que produz executáveis nativos hoje. Eles têm quatro vantagens sobre o compilador JIT do Java: inicialização rápida, menor uso de memória e CPU, menos vulnerabilidades de segurança e tamanhos de arquivo menores.

Mas essas conquistas têm um custo: o GraalVM Native Image impõe uma suposição chamada de mundo fechado em aplicativos Java que elimina toda uma categoria de aplicativos Java. Por quê? Porque Java é uma linguagem dinâmica e dá aos aplicativos muito poder em tempo de execução, como reflexões, carregamento de classes ou até mesmo construção de classes. E alguns desses recursos não funcionam no mundo fechado do GraalVM Native Image. É por isso que o Projeto Leyden agora quer "explorar um espectro de restrições, mais fracas do que a restrição do mundo fechado, e descobrir quais otimizações elas permitem". Ainda assim, Leyden "provavelmente [...] produzirá imagens totalmente estáticas", embora apenas "a longo prazo".

O OpenJDK já tentou a compilação AOT

O Project Leyden é a segunda tentativa do OpenJDK de compilação AOT. O primeiro esforço foi com a jaotc na JEP 295, Ahead-of-Time Compilation, entregue no JDK 9 em setembro de 2017. Assim como o GraalVM Native Image, utilizou o projeto Graal. Ao contrário do GraalVM Native Image, era altamente impopular: quando a Oracle removeu o jaotc de suas compilações Java 16 , "ninguém reclamou", a Oracle observou secamente com JEP 410, Remove the Experimental AOT e JIT Compiler, entregue no JDK 17.

O Projeto Leyden teve uma história incomum para um projeto OpenJDK. O arquiteto da linguagem Java Mark Reinhold o propôs em abril de 2020, seguido pelo OpenJDK que o aprovou como projeto em junho de 2020. Mas o projeto não mostrou nenhum progresso visível nos dois anos entre essa aprovação e a criação de sua lista de discussão em maio de 2022. Isso é porque o projeto está apenas começando, focando " mais em conceitos do que em código " agora. Reinhold afirmou que componentes como o HotSpot JVM, o compilador C2, o compartilhamento de dados de classe de aplicativo (CDS) e a ferramenta jlink de vinculação" são alvos de otimização. Notavelmente ausente dessa lista foi o CRaC, um projeto OpenJDK que reduz o tempo de inicialização carregando o estado do aplicativo Java do disco.

Um cálculo no verso do envelope mostra as datas de entrega possíveis. As versões LTS agora têm uma importância desproporcional no Java. Ben Evans, da empresa de monitoramento New Relic, anunciou na Devoxx UK 2022 que " nenhuma versão não LTS já ultrapassou 1% de participação de mercado ". Isso mostra que os desenvolvedores Java convencionais migram apenas de uma versão Java LTS para outra versão LTS.

Como o Projeto Leyden está em andamento, poucos resultados estarão prontos para produção em setembro de 2023 para o JDK 21, o próximo lançamento do LTS . Portanto, os desenvolvedores Java convencionais provavelmente verão apenas os primeiros resultados do Project Leyden com o lançamento do LTS depois disso, JDK 25, em setembro de 2025. Com base nessa suposição, o Project Leyden entregaria, no mínimo, a compilação AOT para executáveis nativos com o JDK 29 em setembro de 2027.

Spring Boot reage ao projeto Leyden

Pelo menos alguns dos recursos considerados para o Projeto Leyden, como jlink ou CRaC, exigem suporte à estrutura do aplicativo para funcionar melhor. É por isso que a InfoQ entrou em contato com os desenvolvedores que representam Spring Boot, Quarkus e Micronaut para sua reação inicial ao anúncio do Project Leyden.

O líder do projeto Spring Framework, Juergen Hoeller, aprova o Projeto Leyden:

O Projeto Leyden é uma iniciativa promissora alinhada com a direção geral que estamos tomando no Spring Framework 6 e Spring Boot 3.

Hoeller também adota o CRaC para o Spring:

Os snapshots de heap CRaC podem se tornar uma opção comum para melhorar o tempo de inicialização de aplicativos baseados em Spring. Tirando o snapshot bem no final da fase de inicialização do aplicativo, dificilmente haveria qualquer arquivo aberto ou recursos de rede nesse ponto, de acordo com as expectativas do CRaC. O Spring ainda redefine seus caches comuns no final de uma atualização de contexto de aplicativo, limpando metadados relacionados à inicialização antes de repovoar dinamicamente os caches com metadados relacionados a solicitações. Em termos de contexto de aplicação reagindo especificamente a um evento de snapshot ou melhorando a "snapsafety" de componentes comuns, certamente tentaremos capacitar os primeiros adotantes na medida do tecnicamente viável em nossa linha Spring Framework 6.x.

Hoeller acha que o Spring dará suporte jlink ao Java Platform Module System (JPMS) em breve:

Os marcos atuais do Spring Framework 6.0 ainda não incluem descritores de informações de módulo. Isso está no roteiro para o milestone M6 em setembro, reavaliando a prontidão do sistema de módulos do ecossistema de terceiros à medida que avançamos para nossa fase de candidatos à versão 6.0. Com o Project Leyden potencialmente transformando jlink em uma ferramenta mais poderosa e versátil, pretendemos nos preparar não apenas para jlink's as capacidades atuais, mas também para sua evolução futura.

Quarkus reage ao projeto Leyden

O cofundador e co-líder da Quarkus, Jason Greene, comentou sobre o Projeto Leyden:

Estamos muito empolgados com o objetivo do projeto Leyden de revisar a especificação da linguagem Java para oferecer melhor suporte a imagens estáticas, compilação nativa e outras tecnologias, como checkpointing JVM. Além disso, ficamos felizes em ver o mundo fechado remanescente como uma provável meta de longo prazo para o projeto.

Greene adota o CRaC para Quarkus:

O suporte inicial para o projeto de pesquisa CRaC foi recentemente contribuído para o projeto Quarkus pelo líder CRaC. Como o Quarkus realiza a otimização do tempo de compilação, independentemente do tipo de destino do tempo de execução, você ainda vê economias consideráveis ao executar no OpenJDK, não apenas no GraalVM. Adicionar uma abordagem de ponto de verificação, como CRaC, em cima do OpenJDK otimiza ainda mais o tempo de inicialização. Não traz economia de memória semelhante às imagens nativas, mas é uma opção futura interessante para aplicativos que preferem ou exigem execução de JVM.

No entanto, Greene está mais relutante em relação jlink ao JPMS em Quarkus:

A partir de hoje, jlink só traz benefícios para a sobrecarga de armazenamento de um aplicativo baseado em JVM (a sobrecarga de memória e o tempo de inicialização são essencialmente os mesmos sem ela). No entanto, a prática comum em um contêiner ou aplicativo Kubernetes é sobrepor uma imagem de base JVM padrão, o que já traz mais economia do que alternar todos os aplicativos para jlink (já que cada um agruparia sua própria JVM aparada). No caso de uma imagem nativa, os elementos refinados da JVM são compilados na imagem, então jlink não é útil neste cenário também. Da mesma forma, com o JPMS, o Quarkus já tem a noção de modularidade por meio de extensões do Quarkus, permitindo que você reduza seu conjunto de dependências apenas para o que você precisa. A abordagem adotada pelo Quarkus é compatível com o classpath simples e plano que a maioria do ecossistema Java e as ferramentas de compilação preferem hoje. Do lado do custo, mudar para um modelo de módulo JPMS puro conforme jlink necessário (sem módulos automáticos) significaria uma mudança radical não apenas no Quarkus, mas em muitas das bibliotecas nas quais o Quarkus se baseia. Antes de considerar uma mudança, gostaríamos de ver esses fatores se equilibrarem melhor.

Micronaut reage ao Projeto Leyden

Sergio del Amo Caballero, engenheiro de software principal da Object Computing, Inc. (OCI), não tinha uma declaração oficial do Micronaut Framework sobre o Projeto Leyden. Mas ele apontou para um problema recente do GitHub para adicionar suporte CRaC no Micronaut.

Caballero também compartilhou um clipe do YouTube de julho de 2020 com o criador do Micronaut, Graeme Rocher, comentando sobre o JPMS: o Micronaut suporta JPMS e publica arquivos de informações do módulo, mas precisa "equilibrar isso com o suporte ao Java 8". O JPMS foi adicionado no Java 9, mas o Micronaut 3.5, a versão atual, ainda roda no Java 8.

Conclusão

Até agora, o OpenJDK não abordou "os pontos problemáticos de longo prazo do tempo de inicialização lento do Java, do tempo lento para o desempenho máximo". Primeiro, seu jaotc compilador AOT não conseguiu ganhar força e foi aposentado. Então o Projeto Leyden começou a padronizar a compilação nativa em Java, mas ficou parado por dois anos.

Agora que o Project Leyen mudou para otimizar a compilação JIT, as coisas estão melhorando: tanto o Spring quanto o Quarkus adotam o CRaC para reduzir o tempo de inicialização. Mas quando se trata de tamanhos de aplicativos Java menores, apenas a Micronaut adere à sugestão do Projeto Leyden de usar o JPMS. O Spring planeja oferecer suporte ao JPMS na versão 6 até o final de 2022, embora o ecossistema Spring não possa. E a Quarkus atualmente não tem planos de adicionar o JPMS.

Os resultados, na forma de JEPs, do Projeto Leyden podem alcançar os principais desenvolvedores Java até o final de 2025, no mínimo. Portanto, pelo menos até então, a combinação do compilador GraalVM Native Image AOT com uma estrutura como Quarkus, Micronaut ou o próximo Spring Boot 3 continua sendo a melhor opção para evitar "tempo de inicialização lento do Java, tempo lento para desempenho máximo e grande área de cobertura ."

Fonte:

https://www.infoworld.com/article/3652336/java-19-may-be-quite-ambitious.amp.html

Java 19 pode ser grande

2022-06-02T21:00:00.019-03:00

Java 19 pode ser grande

A próxima versão do Java padrão parece pronta para incluir uma API de memória e função estrangeira (Foreign function and memory API), uma API de vetor (A vector API, correspondência de padrões para expressões de switch (Pattern matching for switch expressions), genéricos universais (Universal generics) e muito mais.

Com o lançamento do Java 18, o Java 19 está começando a tomar forma. A próxima versão do Java padrão está definida para avançar

com uma API para interoperar com o código fora do tempo de execução do Java, a primeira de

muitas propostas potenciais que podem abranger recursos que variam de genéricos universais a

uma porta RISC-V.

A proposta para o Java 19 agora flutuando na comunidade OpenJDK é uma função estrangeira e

API de memória (Foreign function and memory API), que permitiria que programas Java façam interoperação com código e dados fora do tempo

de execução Java. O recurso será visualizado no Java Development Kit (JDK) 19, que deve chegar

em setembro.

Identificada como JEP (JDK Enhancement Proposal) 424, a função externa e a API de memória invocariam o código fora da JVM acessando a memória externa.

Essa API foi apresentada em um estágio de incubadora no JDK 17 e será reincubada no JDK 18,

que está programado para ser lançado em 22 de março. Para o JDK 19, a API passaria para um

estágio de visualização, incorporando refinamentos com base no feedback. O JDK 19 será uma

versão de curto prazo do Java com suporte por apenas seis meses.

Outra possibilidade de inclusão no JDK 19 é um vetor API, que está sendo incubado pela terceira vez no JDK 18. Uma quarta incubação foi proposta.

Essa API expressaria cálculos vetoriais que compilam em tempo de execução para instruções

vetoriais ideais. A correspondência de padrões para expressões e instruções switch, que está passando por uma terceira visualização no JDK 19, é outra possibilidade.

No geral, o Java este ano está programado para continuar a evolução de quatro iniciativas,

disse a Oracle. Isso inclui o Projeto Valhalla, para incubar recursos avançados de linguagem e JVM; Projeto Panamá, para interligar código nativo e JVM; Projeto Loom, para melhorar a concorrência; e o Projeto Amber, para explorar e incubar recursos de linguagem Java menores e orientados à produtividade.

Os seguintes recursos, que são objeto de JEPs ou rascunhos de JEPs não direcionados a uma

versão específica do Java, podem muito bem chegar ao Java 19:

Uma prévia dos genéricos universais, da Valhalla. Entregues por meio de três JEPs, os
genéricos universais unificariam o tratamento de tipos de referência e primitivos no código
genérico, permitindo que as variáveis de tipo Java abrangessem os dois tipos de tipos.
Uma visualização de objetos de valor, também um aprimoramento do Valhalla, fornecendo
instâncias de classe que possuem apenas campos de instância final e não possuem identidade
de objeto. Classes de valor sem identidade seriam declaradas.
Uma visualização de padrões de registro, para desconstruir valores de registro. Isso faz parte
do Projeto Amber.
Fixação de região para o coletor de lixo G1, para reduzir a latência implementando a fixação
de região para G1 para que a coleta de lixo não precise ser desabilitada durante regiões
críticas JNI (Java Native Interface).
Uma porta Linux do JDK para RISC-V, uma arquitetura de conjunto de instruções de código
aberto e isenta de royalties.

Alguns desses recursos, se não terminarem no JDK 19, podem acabar em uma versão subsequente,

como o JDK 20, que chegaria em março de 2023, com base na cadência de lançamento de

seis meses do Java padrão. Outros podem escorregar para uma versão ainda posterior ou

talvez nunca fazer o corte para estar em Java.

Fonte:

https://www.infoworld.com/article/3652336/java-19-may-be-quite-ambitious.amp.html

Relatório do Estado do Ecossistema Java da New Relic - 2022

2022-05-30T12:07:00.002-03:00

Relatório do Estado do Ecossistema Java da New Relic

Uma visão aprofundada de uma das linguagens de programação mais populares

A New Relic publicou recentemente um novo relatório sobre o Estado do Ecossistema Java usando dados coletados em janeiro de 2022 de milhões de aplicativos anônimos que forneceram dados de desempenho.

Java 11 é o novo padrão

De acordo com o relatório, o Java 11 é o novo padrão para ambiente de produção, pois a adoção subiu de 11% em 2020 para 48% em 2022, avançando para o Java 8, um segundo próximo a 46%. Outras versões LTS do Java são muito distantes e seu uso é apenas uma pequena fração.

A imagem abaixo mostra o uso de versões Java:

O Java 17 não subiu nas paradas, mas nos poucos meses desde seu lançamento, já ultrapassou os lançamentos Java 6, Java 10 e Java 16.

O suporte para Java 7 está terminando em 2022 e, no entanto, 1,71% dos aplicativos ainda o utilizam em produção. Enquanto isso, o Java 6 não é mais suportado, mas 0,27% dos aplicativos o estão usando. A maioria dos aplicativos que estão usando Java 6 e Java 7 são aplicativos legados que não foram atualizados.

Java 14 é a versão não LTS mais popular

A partir do Java 9, o padrão de lançamento da plataforma mudou. A cada seis meses uma nova versão do Java era disponibilizada, mas essas versões só eram suportadas até o próximo lançamento. A intenção era disponibilizar novos recursos com mais frequência.

A popularidade da Oracle está diminuindo, a Amazon está em ascensão

Nos últimos anos, houve mudanças na origem das distribuições do Java Developer Kit (JDK) em uso. Onde muitos desenvolvedores costumavam obter seu JDK da Oracle, o código aberto do Java no projeto OpenJDK rendeu muitas opções.

A tabela a seguir mostra o afastamento dos binários da Oracle após o licenciamento mais restritivo de sua distribuição JDK 11 (antes de retornar a uma postura mais aberta com o Java 17). Em 2020, a Oracle foi o fornecedor mais popular, compreendendo cerca de 75% do mercado Java. Enquanto eles mantêm o primeiro lugar, sua participação é metade do que era. A Amazon subiu drasticamente para 22% do mercado (acima dos 2,18% em 2020).

Os contêineres estão rodando ao nosso redor

Os aplicativos de conteinerização tornaram-se extremamente populares, e os dados de aplicativos Java da New Relic confirmam essa tendência. Mais de 70% dos aplicativos Java que se reportam à New Relic o fazem a partir de um contêiner.

Configurações de computação em contêineres

Os contêineres afetam como as pessoas alocam recursos de computação e memória. Por exemplo, os dados da New Relic mostram uma porcentagem muito maior de aplicativos executados com menos de quatro núcleos quando em containers.

O desejo de executar menor faz muito sentido em ambientes de nuvem onde as pessoas geralmente implantam contêineres. Mas essa tendência pode apresentar problemas inesperados para alguns aplicativos. Em particular, muitos dos benefícios simultâneos do coletor de lixo G1 padrão em máquinas virtuais Java (JVMs) recentes desaparecem quando executados com menos de dois núcleos. Todas essas instâncias de núcleo único também podem estar usando o coletor serial - e pagando o custo de desempenho disso - mas muitos provavelmente nem sabem disso.

Configurações de memória em contêineres

Tendências semelhantes surgem ao comparar configurações de memória, com tendência a instâncias menores em contêineres. Os dados da New Relic mostram que apenas cerca de 80% dos aplicativos em contêiner solicitam explicitamente um limite superior na memória JVM por meio dos sinalizadores -Xmx ou -XX:MaxRAMPercentage. Os recursos de reconhecimento de contêiner na JVM, desde a versão 9, significam que isso provavelmente não é um problema de segurança para esses aplicativos como costumava ser, desde que a JVM seja o único processo em execução em cada contêiner.

Garbage in, garbage out

Dada a sua função central no desempenho da JVM, a coleta de lixo (GC) continua sendo um tópico de muita discussão na comunidade.

Os dados da New Relic mostram mudanças distintas no uso do coletor de lixo após o Java 8. Isso não é surpreendente, considerando os padrões atualizados e o maior desempenho disponível com o coletor G1 no Java 11 e posterior.

G1 é o favorito claro para aqueles que deixaram o Java 8 para trás. Outros coletores experimentais que surgiram após o Java 8 (ZGC e Shenandoah) ainda mostram um uso pequeno em sistemas de produção, mas isso é esperado, pois nenhum deles atingiu o status de pronto para produção até recentemente.

G1 é o favorito para aqueles que deixaram o Java 8 para trás. Outros coletores experimentais que surgiram após o Java 8 (ZGC e Shenandoah) ainda mostram um uso pequeno em sistemas de produção, mas isso é esperado, pois nenhum deles atingiu o status de pronto para produção até recentemente.

Sobre a New Relic

A New Relic é uma empresa que desenvolve uma das principais plataformas de observabilidade fornecendo aos desenvolvedores métricas, eventos, logs e rastreamentos.

A versão completa do relatório de 2022 está disponível no site da New Relic.

Java ainda é relevante?

2022-05-28T21:28:00.008-03:00

Java ainda é relevante?

Esta é uma tradução/adaptação do artigo original em inglês.

Java é amplamente usado de diferentes maneiras, especialmente por plataformas populares que você pode usar com frequência, como Twitter, Google, Amazon, Spotify e YouTube.

Java ainda é comumente usado em nossa vida diária de diferentes maneiras. Ele toca todos os campos de desenvolvimento de software e é usado por plataformas populares que você pode usar com frequência, como Twitter, Google, Amazon, Spotify e YouTube. Com esse amplo uso, a conclusão é simples — Java veio para ficar e continuará atraindo muitos desenvolvedores por muito tempo.

Quando a tecnologia existe há anos, é provável que pareça irrelevante, não competitiva e até se torne obsoleta para algumas pessoas. Não é o caso de Java, que completa 26 anos este ano.

Java não é coisa do passado — ainda está muito na moda, algo que continua a surpreender aqueles que continuam apegados à ideia de que Java é antiquado. Mesmo estatísticas e estudos recentes mostram que Java ainda está entre as linguagens de programação mais exigidas, usadas e amadas. Mas o que ainda faz com que essa tecnologia um pouco antiga permaneça competitiva? Leia para saber mais.

Novos ciclos de lançamento o colocam em demanda por um longo tempo

Inicialmente, novas versões do Java eram lançadas uma vez por ano – algo que prejudicava alguns desenvolvedores. Isso mudou em 2018, quando foi decidido que as novas versões serão lançadas em pequenas iterações. O novo ciclo agora coloca a comunidade Java na vanguarda da inovação, pois permite que novos recursos sejam adicionados rapidamente, testados e relançados.

Desenvolvedores Java em todo o mundo continuam a crescer

Após 26 anos de existência – Java ainda está indo bem – os programadores que o conhecem ainda estão em alta demanda. Eles continuarão sendo procurados por muito tempo, já que mais de 90% das empresas da Fortune 500 ainda dependem do Java para seus projetos de desenvolvimento.

Globalmente, existem mais de 8 milhões de desenvolvedores Java. Isso significa que existe uma grande força de trabalho, tornando mais fácil para as empresas encontrar e contratar programadores Java qualificados. De acordo com o Indeed, o salário médio anual de um desenvolvedor java é de US$ 102.597 nos Estados Unidos, mais um bônus em dinheiro de US$ 5.000 por ano.

Java acompanha os tempos

Apesar de ser uma tecnologia madura, Java continua indo bem. Atualmente, é a segunda linguagem de programação mais popular de acordo com o índice do TIOBE. A tabela abaixo exibe as dez primeiras linguagens de programação populares de acordo com este índice.

Julho 2021	Julho 2020	Linguagem de Programação	Classificações
1	1	C	11.62%
2	2	Java	11.17%
3	3	Python	10.95%
4	4	C++	8.01%
5	5	C#	4.83%
6	6	Visual Basic	4.50%
7	7	JavaScript	2.71%
8	8	PHP	2.58%
9	9	Assembly Language	2.40%
10	10	SQL	1.53%

Além disso, o Java está acompanhando a inovação tecnológica e as tendências de software. Algo que aqueles que estão dizendo "Java está morrendo" e "programadores java não estão mais em demanda" estão ignorando ao defender uma mudança para outras linguagens. Felizmente, estatísticas e fatos continuam a provar a ampla aplicação do Java em diferentes projetos hoje.

O uso diário de Java em várias áreas de desenvolvimento de software, big data, inteligência artificial, blockchain, mobile, Internet das coisas e desenvolvimento web também é prova de que o Java veio para ficar. O IoT Developer Survey deixa claro que os programadores de produtos de software incorporados para dispositivos IoT optam pelo Java. A principal razão por trás disso é a independência da plataforma e a natureza de alta portabilidade da linguagem Java. Como o Java é executado na Java Virtual Machine (JVM), os desenvolvedores conseguem mover códigos Java para quaisquer dispositivos, pacotes de software ou chips com a JVM pré-instalada.

Você deve escolher Java para seu próximo projeto?

Se você ainda está cético em relação ao Java hoje, os exemplos a seguir demonstram as áreas críticas em que ele é usado.

Aplicativos Java baseados na Web

Java quando emparelhado com Servlets, Struts, JavaServer Page, Hibernate, Spring, JavaServer Face e servidores web como Resin, servidor web Apache HTTP e Apache Tomcat é usado no design de aplicativos web. Usando essas tecnologias, você pode criar qualquer aplicativo baseado na web.

Os aplicativos de comércio eletrônico também são desenvolvidos usando Java quando combinados com plataformas de comércio eletrônico de código aberto, como Broadleaf. E com o COVID-19 acelerando o comércio eletrônico e a transformação digital, a demanda por mais aplicativos de comércio eletrônico sem dúvida aumentará, criando espaço para mais desenvolvedores Java.

Uma das aplicações web significativas construídas em Java é o Gmail do Google.

Como criar aplicativos Android

Embora existam outras maneiras de desenvolver aplicativos Android, a maioria deles é escrita em Java usando a API Android do Google. Java Micro Edition é a estrutura usada para projetar aplicativos executados em smartphones e feature phones. Além disso, Java é compatível com Kotlin e Android Studio.

Os seguintes aplicativos populares de Java no Android mostram claramente que o desenvolvimento de aplicativos Android continuará sendo principalmente Java.

Twitter
Spotify
CashApp, anteriormente conhecido como Square Cash
Sinal

Sistemas Embarcados

Os sistemas embarcados estão em toda parte. De nossos smartphones e computadores a TVs e sistemas de motor, você os encontrará executando funções dedicadas para sistemas maiores. Esses sistemas usam Java para desenvolvimento. Na verdade, Java foi propositalmente projetado para desenvolver sistemas embarcados. Aplicações comuns incluem:

Cartões inteligentes
Cartões SIM em nossos telefones
Medidores de utilidade
Televisão
Discos Blu-ray.

Todos esses são dispositivos dos quais dependemos todos os dias de uma forma ou de outra. Isso significa que o mundo precisa de desenvolvedores Java para que esses e mais produtos sejam criados e mantidos.

Tecnologias de Big Data

As tecnologias de big data são um dos tópicos mais em voga no mundo atual. Todas essas tecnologias, incluindo Apache Hadoop, Apache Mahout e Apache, usam Java de uma forma ou de outra. Portanto, dominar Java é uma vantagem se estiver interessado em big data.

Aplicativo baseado em nuvem

Java também se encaixa perfeitamente na computação em nuvem. Ele ajuda a desenvolver aplicativos usados em infraestrutura como serviço, plataforma como serviço e software como serviço. A nuvem Oracle Java é um excelente exemplo de ferramenta de desenvolvimento em nuvem que ajuda a projetar e configurar servidores Oracle. Agora, considerando que a nuvem continua sendo um alvo crítico para empresas que buscam continuidade de negócios, maior escalabilidade e eficiência de custos, o mesmo acontecerá com a demanda por desenvolvedores Java para ajudar a realizar essa transição.

Aplicativos de jogos

Jogos Android não podem ser construídos sem Java. Eles são feitos com Java como linguagem principal porque suporta a Dalvik Virtual Machine que roda na plataforma Android. Java também suporta jMonkeyEngine, um motor 3D robusto com capacidade para criar jogos 3D.

Com a epidemia impulsionando o crescimento da indústria de jogos para dispositivos móveis em 2020, você pode esperar que a demanda seja muito maior, divertida e imersiva em 2021.

Ferramentas de software

As ferramentas de software ajudam os programadores a desenvolver, analisar, depurar, manter e dar suporte a outros programas. A maioria dos programadores confia em Java para escrever e construir ferramentas de software. Eclipse, NetBeans IDE e IntelliJ IDEA são algumas das ferramentas de software comumente usadas pelos desenvolvedores. O suporte dos desenvolvedores Java será fundamental para manter a funcionalidade dessas ferramentas este ano e além.

Referências

Artigo original em inglês.

Uma questão de interpretação: de bytecodes a código de máquina na JVM

2022-03-02T10:14:00.002-03:00

Uma questão de interpretação: de bytecodes a código de máquina na JVM

Esta é uma tradução/adaptação do artigo original em inglês.

No primeiro artigo desta série, vimos como os aplicativos baseados em JVM usam um conjunto de instruções virtuais na forma de bytecodes para criar um aplicativo de plataforma neutra. A JVM converte esses bytecodes no tempo de execução nas instruções para a plataforma na qual o aplicativo está sendo executado.

Antes de nos aprofundarmos na compilação just-in-time (JIT), vamos ver como a JVM começa a executar bytecodes usando um interpretador.

A ideia básica do interpretador é simples. Cada método, começando com public static void main(), possui um conjunto de bytecodes que definem o que ele fará. A JVM interpretará o primeiro bytecode (assumindo que a instrução não resulta em um salto para um endereço diferente ou chamará outro método) continuará com cada bytecode em sequência. Interpretar é o processo de converter um bytecode em qualquer chamada de sistema operacional ou instruções de código de máquina necessárias para executar a ação do bytecode.

Declarar assim parece simples, mas há uma quantidade considerável de trabalho envolvido.

Vamos voltar ao programa de exemplo do post anterior que soma os números de um a dez (vamos deixar de imprimir o resultado para manter o código o mais simples possível).

public class Sum {
public static void main(String[] args) {
int sum = 0;

for (int i = 1; i <= 10; i++) {
sum += i;
}

System.out.println(sum);
}
}

O arquivo de classe compilado contém os seguintes bytecodes (produzidos com javap -c).

Code:

0: iconst_0

1: istore_1

2: iconst_1

3: istore_2

4: iload_2

5: bipush 10

7: if_icmpgt 20

10: iload_1

11: iload_2

12: iadd

13: istore_1

14: iinc 2, 1

17: goto 4

20: return

Isso mostra que há 14 bytecodes a serem executados (A contagem de 20 inclui os operandos dos bytecodes). Como temos um loop, as nove instruções das posições 4 a 17 serão executadas dez vezes. Uma vez que incluímos as três instruções extras necessárias para sair do loop (posições 4 a 7), temos um total de 98 bytecodes para interpretar. Aqui, então, é uma questão interessante. Se executarmos este aplicativo, quantos bytecodes serão executados?

Para determinar isso, precisamos de uma compilação especial da JVM que forneça um nível de observabilidade maior do que o padrão. Não vou entrar em todos os detalhes de como fazer isso, mas você precisa configurar um ambiente de compilação OpenJDK usando os sinalizadores -with-debug-level=slowdebug e -with-native-debug-symbols=external. Isso fornece uma variedade de opções -XX adicionais que podem ser usadas ao iniciar a JVM. Também direi que usei o jlink para gerar um runtime que incluía apenas o módulo java.base, pois é tudo o que precisamos para executar a aplicação. Se executarmos nosso aplicativo com java -XX:+CountBytecodes Sum, obteremos o seguinte:

359058 bytecodes executed in 0.4s (0.904MHz)

A sério! Os 98 bytecodes esperados se transformaram em quase 360 mil! O que é ainda mais confuso é que você obtém três resultados diferentes se executar o aplicativo três vezes. Tanto para os autômatos finitos determinísticos que aprendi na universidade. O que está acontecendo? A primeira coisa a ser observada para descobrir isso é executar o aplicativo com a opção -verbose:class. Isso fornecerá informações sobre o carregamento de classe à medida que a JVM é executada. Uma simples contagem da saída revela que 412 classes estão sendo carregadas, 409 das quais são carregadas antes da nossa classe Sum. Embora não seja necessário que uma classe seja inicializada assim que for carregada (conforme definido na Especificação JVM), neste caso, todas são. Como você pode imaginar, muitas classes requerem inicialização complexa, instanciando objetos e chamando métodos. Tudo isso resulta (como podemos ver) na execução de muitos milhares de bytecodes. Demorei um pouco para descobrir por que o número de bytecodes executados varia para diferentes execuções. Embora o código que está sendo executado não esteja mudando (e, portanto, determinístico), o caminho percorrido pelo código pode ser diferente. Por exemplo, mesmo algo tão simples como o valor da hora atual pode resultar em uma ramificação diferente sendo obtida em uma instrução if.

Vamos voltar ao assunto real do post, que é como a JVM interpreta cada um desses muitos bytecodes. Como há muitas maneiras possíveis de fazer isso, discutiremos a implementação da Hotspot JVM no OpenJDK.

No JDK 1.0, o interpretador, como o restante da JVM, foi escrito em C e consistia em um loop while infinito. Dentro do loop havia uma instrução switch gigante, que incluía um case para cada instrução de bytecode. O loop while inicia a execução de bytecodes para um método e, quando o método retorna, sai do loop por meio de uma pausa.

O interpretador C++

O interpretador evoluiu no JDK 1.2 (suspeito, embora não possa confirmar isso) com a mudança para o Hotspot JVM. Às vezes chamado de C++Interpreter, ele ainda usa uma enorme instrução switch, mas faz alterações para melhorar a eficiência. Por exemplo, várias funções foram incorporadas para aproveitar os recursos específicos da plataforma.

Embora o C++Interpreter ainda esteja incluído no código-fonte do OpenJDK, ele não é construído e incluído na JVM por padrão. Nesse caso, o princípio Highlander é válido e pode haver apenas um (intérprete). A única compilação que faz uso disso é a de montagem zero.

O intérprete de modelos

O interpretador usado no OpenJDK por padrão é o interpretador de modelo (este tem sido o padrão desde, acredito, JDK 1.4, embora, novamente, eu não tenha confirmado isso). O uso de instruções case codificadas para implementar a funcionalidade de cada bytecode limita as otimizações que podem ser exploradas para uma determinada plataforma. Veremos isso mais quando analisarmos as vantagens e desvantagens da compilação AOT e JIT posteriormente nesta série.

O interpretador de modelo constrói o código do interpretador para cada bytecode quando a JVM é inicializada. Como o nome sugere, cada bytecode tem um template. A JVM pode determinar os detalhes precisos da microarquitetura em que está sendo executada e usar esse conhecimento para gerar código otimizado para cada bytecode. Esses pedaços de código são chamados de codelets. Em vez de usar uma instrução switch, o interpretador de modelo usa uma tabela de distribuição com pontos de entrada para cada codelet gerado.

Você pode obter mais informações sobre o que o interpretador de modelo faz usando as opções de linha de comando -XX:+UnlockDiagnosticVMOptions -XX:+PrintInterpreter. Executando isso na minha compilação do JDK 17 com nosso aplicativo simples mostrou:

Interpreter

code size = 66K bytes
total space = 66K bytes
wasted space = 0K bytes

# of codelets = 275
avg codelet size = 246 bytes

Como você pode ver, o interpretador de modelo gera 275 codelets, que é mais do que o número de bytecodes no conjunto de instruções da JVM. Um exame mais atento mostra que, além das instruções de bytecode, há um conjunto de codelets para otimizar determinadas operações. Por exemplo, existem codelets para lidar com coisas como funções matemáticas padrão (sin, cos, tan, etc.)

Há também uma série de codelets de atalho. Quando um campo do objeto atual é carregado por meio da referência this, sempre resulta em dois bytecodes, aload_0 seguido de getfield. Essa combinação de bytecodes resulta no valor de this sendo empurrado para a pilha e imediatamente retirado novamente. Neste caso, a JVM fornece uma pseudo-instrução, fast_agetfield, que elimina o push-pop redundante e reduz os dois bytecodes de uma operação muito comum para um. Outros codelets de atalho fazem coisas semelhantes para melhorar a eficiência de operações comuns de vários bytecodes. Há também, um tanto bizarramente, quatro codelets nofast que estão relacionados ao uso do recurso de compartilhamento de dados de classe (CDS). O tamanho médio dos codelets é de 246 bytes. Todos os codelets têm um tamanho múltiplo de 32 bytes, preenchendo com zeros quando necessário; muitos são apenas 96 bytes. Alguns, no entanto, são surpreendentemente grandes. Todo o branch se compara com zero bytecodes (ifeq, ifne, etc.), gera codelets (na minha máquina Windows com Core i7 de 9a geração) de 1376 bytes. (Eu não desmontei o código para tentar descobrir por que isso seria tão grande). Outra coisa curiosa é que o codelet para no-op é de 96 bytes! O impacto deste modelo, abordagem de geração de código em tempo real, é substancial. Volker Simonis fez uma comparação de referência de ambos, e seus resultados mostraram que o interpretador de modelo era (em termos gerais) duas vezes mais rápido que o interpretador C++ mais simples. Certamente, faria sentido armazenar em cache o código gerado pelo modelo para reduzir o tempo de inicialização da JVM? De maneira útil, podemos ver quanto tempo leva para gerar todos os codelets usando o sinalizador -Xlog:startuptime. Para nossa aplicação, os resultados na minha máquina são:

java -Xlog:startuptime Sum
[0.007s][info][startuptime] StubRoutines generation 1, 0.0002250 secs
[0.014s][info][startuptime] Genesis, 0.0069230 secs
[0.015s][info][startuptime] Interpreter generation, 0.0005353 secs
[0.015s][info][startuptime] StubRoutines generation 2, 0.0001260 secs
[0.015s][info][startuptime] MethodHandles adapters generation, 0.0000212 secs
[0.015s][info][startuptime] Start VMThread, 0.0002540 secs
[0.024s][info][startuptime] Initialize java.lang classes, 0.0082586 secs
[0.024s][info][startuptime] Initialize java.lang.invoke classes, 0.0001236 secs
[0.031s][info][startuptime] Initialize module system, 0.0069481 secs
[0.032s][info][startuptime] Create VM, 0.0282268 secs

A geração do interpretador levou apenas 0,5 ms, portanto, mesmo reduzindo isso para zero, não teria impacto perceptível no tempo de inicialização. Lembro-me de quando o Java foi lançado e começou a se tornar popular. Um dos argumentos que as pessoas tinham contra a plataforma era que ela era muito lenta em comparação com as linguagens tradicionais compiladas estaticamente como C e C++. O que, naquela época, era. Como vimos, o interpretador só se preocupa com um único bytecode (ou possivelmente dois usando codelets de caminho rápido) por vez. Mesmo o uso de modelos não mudará esse fato. Um compilador estático analisa blocos maiores de código, como loops e métodos. Ele pode então otimizar o código gerado usando técnicas como desdobramento de loop e métodos incorporados. O intérprete nunca será capaz de igualar este nível de desempenho. Para resolver isso sem sacrificar o “Write once, run anywhere”, Java adotou o uso de compilação adaptável just-in-time (JIT). No próximo post desta série, veremos as ideias básicas da compilação JIT e examinaremos como a JVM decide quais métodos compilar e quando fazê-lo.

Referências

Artigo original em inglês.

Java é a linguagem de programação mais requisitada em 2022

2022-02-22T20:35:00.008-03:00

Java é a linguagem de programação mais requisitada em 2022: Relatório

Os cargos mais procurados no ano de 2022 são desenvolvedores Java, JavaScript e SQL, de acordo com um relatório da Mercer|Mettl

Além de desenvolvedores Java, JavaScript e SQL, a demanda por desenvolvedores full-stack que podem trabalhar em front-end e back-end está crescendo rapidamente.

A Mercer|Mettl lançou recentemente seu “Relatório de Habilidades e Tendências Tecnológicas 2022”. Ele apresenta insights cruciais sobre habilidades e funções que devem estar em demanda do setor de tecnologia em breve. A base do relatório são os dados coletados de mais de 2 milhões de avaliações feitas em 2019-2021 pela Mercer|Mettl.

No cenário atual, o cenário de negócios está passando por uma transformação devido ao processo de digitalização. Consequentemente, as habilidades tecnológicas estão em constante evolução. O relatório mapeia essa mudança e apresenta descobertas críticas sobre os conjuntos de habilidades que são esperados de perfis específicos de trabalho de tecnologia nos próximos dias.

Função de trabalho mais requisitados em 2022

Os desenvolvedores de Java, JavaScript e SQL são as funções mais procuradas em 2022, graças à enorme adoção dessas linguagens em várias organizações, revela o relatório. Além disso, o DevOps se tornou uma das funções de destaque a serem contratadas em todos os setores devido à maior ênfase na segurança de rede, rápida adoção de sistemas em nuvem e metodologias ágeis.

Habilidades de front-end como JS, HTML e CSS continuam a liderar os gráficos. No entanto, Angular, jQuery, React e Bootstrap também ganharam importância. Habilidades de back-end, como estruturas Java, C# e .NET, continuam a ganhar destaque. No entanto, Python, APIs REST, Spring e Hibernate continuam sendo opções quentes.

No lançamento do relatório, Siddhartha Gupta, CEO da Mercer|Mettl, disse: “Nos últimos dois anos, organizações em todo o mundo perceberam a necessidade de adotar a tecnologia no centro de seus negócios. Empresas estabelecidas e startups estão usando extensivamente tecnologias como IA, ML, Blockchain e Ciências de Dados para se diferenciar. Essa revolta técnica levou a um crescimento exponencial na demanda por talentos tecnológicos de alta qualidade em várias habilidades. O relatório da MercerlMettl é um estudo das tecnologias que moldaram e moldarão o futuro de vários setores. Espero que o relatório guie os líderes do setor a definir abordagens inovadoras para contratação em 2022 e além.”

Além dos desenvolvedores Java, JavaScript e SQL, a demanda por desenvolvedores Full-Stack que podem trabalhar em front-end e back-end está crescendo rapidamente. Além disso, quando se trata de habilidades de ciência de dados – SQL, AWS e Azure ganharam importância devido à importância estratégica da análise de dados e ao aumento do uso de sistemas em nuvem. Python, que é amplamente utilizado em programação web, automação, visualização de dados e ciência de dados, tornou-se uma das linguagens mais populares.

Referências

Artigo original em inglês.

JDK 18: Os novos recursos do Java 18

2022-02-18T21:32:00.021-03:00

JDK 18: Os novos recursos do Java 18

Com o lançamento em março, o Java 18 incuba uma API vetorial, disponibiliza o “pattern matching for switch statements” como preview feature, adota UTF-8 como o conjunto de caracteres padrão e inclui um servidor web simples.

O Java Development Kit (JDK) 18 está programado para ser lançado em 22 de março de 2022. A nova versão do Java padrão terá nove novos recursos, com o conjunto de recursos congelado em 9 de dezembro.

O JDK 18 passou para um estágio de release candidate, após duas fases de rampdown realizadas entre dezembro e fevereiro. Um segundo release candidate está previsto para 24 de fevereiro. As atualizações do Java padrão são lançadas a cada seis meses, com a versão mais recente, JDK 17, chegando em setembro de 2021.

A página OpenJDK lista os seguintes recursos como direcionados oficialmente ao JDK 18: uma interface de provedor de serviços, um servidor web simples, uma terceira incubação da API vetorial, trechos de código, uma reimplementação do core reflexão, um conjunto de caracteres UTF-8, uma segunda versão preview de uma função estrangeira e API de memória, uma segunda preview de correspondência de padrões para instruções switch (pattern matching for switch statements) e a descontinuação do finalization, que foi a última adição.

Enquanto o JDK 17 foi uma versão de suporte de longo prazo (LTS) que recebeu pelo menos oito anos de suporte da Oracle, o JDK 18 será uma versão de recurso de curto prazo com suporte por seis meses. As compilações de acesso antecipado do JDK 18 podem ser encontradas para Linux, Windows e MacOS em java.net.

As especificidades das propostas do JDK 18 incluem: 1 - Deprecate finalization for removal para remoção em uma versão futura. O Finalizer tem falhas que causam problemas significativos do mundo real em segurança, desempenho, confiabilidade e capacidade de manutenção. Ele também tem um modelo de programação difícil. A finalização está habilitada por padrão por enquanto, mas pode ser desabilitada para facilitar os testes iniciais. Ele será desabilitado por padrão em uma versão de recurso e removido completamente em uma versão posterior. A proposta exige uma opção de linha de comando para desativar a finalização e a descontinuação de todos os finalizadores e métodos de finalização na API Java padrão. Os objetivos da proposta incluem ajudar os desenvolvedores a entender os perigos da finalização, preparar os desenvolvedores para sua eventual remoção e fornecer ferramentas simples para ajudar a detectar a dependência da finalização. Introduzida no Java 1.0, a finalização visava ajudar a evitar vazamentos de recursos. Uma classe pode declarar um finalizador — o método protected void finalize() — cujo corpo libera qualquer recurso subjacente. O coletor de lixo agendará o finalizador de um objeto inacessível para ser chamado antes de recuperar a memória do objeto; por sua vez, o método finalize pode executar ações como chamar o fechamento do objeto. Isso parece ser uma rede de segurança eficaz para evitar vazamentos de recursos, mas existem falhas, incluindo latência imprevisível, com um longo tempo decorrido entre quando um objeto se torna inacessível e quando seu finalizador é chamado; comportamento irrestrito, com código finalizador capaz de realizar qualquer ação, incluindo ressuscitar um objeto e torná-lo acessível novamente; o finalizador está sempre habilitado, sem mecanismo de registro explícito; e os finalizadores podem ser executados em threads não especificados em uma ordem arbitrária. Dados os problemas com a finalização, os desenvolvedores são aconselhados a usar técnicas alternativas para evitar vazamentos de recursos, ou seja, declarações try-with-resources e limpadores. (Consulte a Proposta de Aprimoramento do JDK 421 para obter detalhes.)

2 - Para o Internet-address resolution SPI, a proposta é definir um SPI para resolução de endereços de host e nome para que Inet.Address possa fazer uso de resolvedores diferentes do resolvedor interno da plataforma. As motivações para este esforço incluem uma melhor habilitação do Project Loom, para concorrência e novos modelos de programação em Java, juntamente com a integração de novos protocolos de rede, customização e habilitação de testes. A proposta não envolve o desenvolvimento de um resolvedor alternativo para o JDK.

3 - O segundo preview do (pattern matching for switch), na qual a linguagem Java seria aprimorada com correspondência de padrões para expressões e instruções switch, juntamente com extensões para a linguagem de padrões. Isso foi visualizado no JDK 17. Estendendo a correspondência de padrões para switch que permite que uma expressão seja testada em vários padrões, cada um com uma ação específica, de modo que consultas complexas orientadas a dados possam ser expressas de forma concisa e segura.

4 - A reimplementação do core de reflexão com identificadores de método reimplementaria lang.reflect.Method, Constructor e Field sobre os identificadores de método java.lang.invoke. Ter alças de método servindo como mecanismo subjacente para reflexão reduzirá os custos de manutenção e desenvolvimento das APIs java.lang.reflect e java.lang.invoke.

5 - Com a proposta de servidor web simples, uma ferramenta de linha de comando seria fornecida para iniciar um servidor web mínimo que serve apenas arquivos estáticos. Nenhuma funcionalidade semelhante a CGI ou servlet está disponível. A ferramenta será útil para prototipagem, codificação ad-hoc e testes, particularmente em contextos educacionais. Os objetivos do plano incluem oferecer um servidor de arquivos HTTP estático pronto para uso com configuração fácil e funcionalidade mínima, reduzindo a energia de ativação do desenvolvedor e tornando o JDK mais acessível e fornecendo uma implementação padrão por meio da linha de comando junto com uma pequena API para criação e personalização programática. Fornecer um servidor rico em recursos ou de nível comercial não é um objetivo da proposta.

6 - Uma segunda preview de uma API de função e memória externa (foreign function and memory API), na qual uma API é introduzida por meio da qual programas Java podem interoperar com código e dados fora do tempo de execução Java. Ao invocar funções externas – código fora da JVM – e ao acessar com segurança a memória externa – memória não gerenciada pela JVM – a API permite que programas Java chamem bibliotecas nativas e processem dados nativos sem a fragilidade e o perigo da JNI (Java Native Interface). A intenção é substituir o JNI por um modelo de desenvolvimento Java puro e superior. Essa API foi incubada no JDK 17. Para o JDK 18, refinamentos seriam incorporados, com base no feedback, como suporte para mais operadoras como Boolean e MemoryAddress em handles de var de acesso à memória e uma nova API para copiar arrays Java de e para a memória segmentos.

7 - A API vetorial (The vector API) seria incubada pela terceira vez no JDK 18, tendo sido incubada anteriormente no JDK 16 e JDK 17. Esta proposta expressaria computações vetoriais que compilam em tempo de execução instruções vetoriais ideais em arquiteturas de CPU suportadas, alcançando desempenho superior ao equivalente cálculos escalares. As operações vetoriais expressam um grau de paralelização, permitindo que mais trabalho seja feito em um único ciclo de CPU, produzindo melhorias significativas de desempenho. A API de vetor independente de plataforma visa fornecer uma maneira de escrever algoritmos complexos em Java, usando o auto vetorizador HotSpot existente, mas com um modelo de usuário que torna a vetorização mais previsível. O JDK 18 também adicionaria suporte para a plataforma ARM Scalar Vector Extension e melhoraria o desempenho de operações vetoriais que aceitam máscaras em arquiteturas que suportam mascaramento em hardware.

8 - Specifying UTF-8 as the default charset of the standard Java APIs. UTF-8 é uma codificação de caracteres de largura variável para comunicação eletrônica e é considerado o conjunto de caracteres padrão da web. Charset é a codificação de caracteres capaz de codificar todos os caracteres na web. Por meio dessa alteração, as APIs que dependem do conjunto de caracteres padrão se comportaram de forma consistente em todas as implementações, sistemas operacionais, localidades e configurações. A proposta não se destina a definir novas APIs padrão Java ou específicas de JDK. Os proponentes da proposta esperam que os aplicativos em muitos ambientes não vejam nenhum impacto da escolha do Java pelo UTF-8, já que o MacOS, muitas distribuições Linux e muitos aplicativos de servidor já suportam UTF-8. No entanto, há risco em outros ambientes, sendo o mais óbvio que os aplicativos que dependem do conjunto de caracteres padrão se comportem incorretamente ao processar dados produzidos quando o conjunto de caracteres padrão não foi especificado. A corrupção de dados pode ocorrer silenciosamente. Espera-se que o principal impacto recaia sobre os usuários de sistemas Windows em localidades asiáticas e possivelmente em alguns ambientes de servidor na Ásia e em outras localidades.

9 - Code snippets in Java API documentation, envolvendo a introdução de uma tag @snippet para o Doclet padrão do JavaDoc, para simplificar a inclusão de código-fonte de exemplo na documentação da API. Entre os objetivos do plano está facilitar a validação de fragmentos de código-fonte, fornecendo acesso à API a esses fragmentos. Embora a correção seja de responsabilidade do autor, o suporte aprimorado em JavaDoc e ferramentas relacionadas pode torná-lo mais fácil de alcançar. Outros objetivos incluem habilitar estilos modernos, como realce de sintaxe, bem como a vinculação automática de nomes a declarações e habilitar melhor suporte de IDE para criar e editar trechos. A proposta observa que os autores da documentação da API geralmente incluem fragmentos de código-fonte nos comentários da documentação.
Referências

Artigo original em inglês.