Pular para o conteúdo principal

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

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.




Comentários

Postagens mais visitadas deste blog

Java Records

  Java Records Imutável, Simples e limpa Esta funcionalidade da linguagem apareceu pela primeira vez na versão 14 como experimental e assim continuou até a versão 15 . Agora liberada de forma definitiva no Java 16 . O objetivo é ser possível ter classes que atuam como portadores transparentes de dados imutáveis. Os registros podem ser considerados tuplas nominais. Ou seja, após criado, um record não pode mais ser alterado. Records oferece uma uma sintaxe compacta para declarar classes que são portadores transparentes para dados imutáveis superficiais visando reduzir significamente o detalhamento dessas classes e irá melhorar a capacidade de leitura e manutenção do código. Vamos seguir um exemplo de uma classe chamada Pessoa . O primeiro exemplo vamos utilizar o modo tradicional. public class Pessoa { private String nome; private int idade; public Pessoa (String nome, int idade) { super (); this .nome = nome; this .idade = idade; } public String getNo

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

    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 d

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

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