Guia do 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

    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

  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 chamad