🔄 Atualização e Perguntas Frequentes sobre o Ritmo de Lançamento do Java SE
No início de 2017, conforme o trabalho no Java SE 9 se aproximava do fim, alguns colaboradores da Comunidade OpenJDK começaram a se perguntar se haveria uma maneira de evoluir a Plataforma Java SE e o JDK em um ritmo mais acelerado, para que novos recursos pudessem ser entregues de maneira mais oportuna. Um grupo de trabalho do JCP foi estabelecido para considerar como o Java Community Process poderia acomodar tal mudança. Após mais discussões entre os principais colaboradores, um plano foi proposto e, em paralelo, foram anunciados planos para seus produtos comerciais Java SE.
Nos poucos meses desde então, a Comunidade OpenJDK, com a liderança da Oracle, entregou o Java SE 9, o Java SE 10, versões de Acesso Antecipado do Java SE 11, bem como múltiplas atualizações de segurança programadas e coordenadas. O OpenJDK Vulnerability Group foi formado. Um novo e pequeno recurso de linguagem foi adicionado no Java SE 10, o que mostra que o novo ritmo funciona não apenas para a implementação, mas também para o trabalho de especificação no JCP.
Dito isto, o novo ritmo introduz novos idiomas e semântica a termos e processos aos quais estamos acostumados há muitos anos. Claramente, os benefícios de um cronograma de lançamento previsível de novos recursos facilmente assimiláveis valem o esforço para alguns dos maiores projetos do ecossistema. Essa tendência também foi observada em outras partes do Ecossistema Java SE. Por exemplo, o Eclipse há muito tem um "trem de lançamento" anual, e o Wildfly está migrando para um modelo de lançamento trimestral.
❓ Pergunta 1: Certamente não se espera que todos adotem releases principais a cada seis meses?!
Não existem mais "releases principais" propriamente ditos; esse agora é um termo legado. Em vez disso, há um fluxo constante de "releases de recursos". Isso é consistente com a forma como muitos lançamentos foram feitos no passado, exceto com uma nova abordagem sobre o versionamento. Por exemplo, o Java 8 foi lançado em março de 2014. O 8u20, um release de recurso, foi lançado quase seis meses depois, em agosto. O 8u40, o próximo release de recurso, foi lançado quase seis meses depois disso.
Então sim, espera-se a adoção de "releases de recursos" a cada seis meses, assim como antes.
Passar do Java 9 para o 10 e para o 11 é mais parecido com passar de 8 para 8u20 e para 8u40 do que de 7 para 8 e para 9. É assustador ver isso a princípio quando se está acostumado a releases principais a cada três anos e se tem um modelo mental do grande impacto dessas grandes mudanças. O ritmo de seis meses não é isso. Mais adiante no FAQ, será fornecida uma prova mais específica disso.
❓ Pergunta 2: Se os novos lançamentos são basicamente o antigo ritmo de seis meses, por que atualizar o número da release principal cada vez? Por que não chamá-lo simplesmente de 9u20, 9u40, etc.?
Por ter simplificado alguns processos do JCP, agora é possível introduzir novos recursos de biblioteca de classes, JVM e linguagem, como a Inferência de Tipo de Variável Local, em apenas seis meses, em vez de ter que esperar anos por uma "release principal". Em vez de lançar dezenas de grandes mudanças nas especificações a cada dois anos, elas podem ser introduzidas de forma mais pragmática em um fluxo constante assim que estiverem prontas para adoção.
❓ Pergunta 3: Mudanças na especificação parecem perigosas e vão inibir o ecossistema de ferramentas de se atualizar, certo?
Embora algumas ferramentas tenham tido dificuldade para migrar de 8 para 9, foi fantástico ver aqueles que fizeram essa transição serem capazes de ir de 9 para 10 quase que da noite para o dia.
Quando o Java 10 foi lançado, todas as principais IDEs tinham suporte ao Java 10, incluindo o novo recurso de inferência de tipo de variável local em questão de dias. Projetos populares como Gradle e Lucene adicionaram rapidamente suporte oficial. Algumas distribuições populares do Linux, como Ubuntu e SUSE Linux Enterprise Server, ajustaram-se proativamente para tornar as últimas releases do OpenJDK o JRE/JDK padrão em suas plataformas. O Elasticsearch planeja ser compatível com releases LTS e não LTS o mais rápido possível para se beneficiar dos novos recursos. Estes são apenas alguns exemplos de outros projetos e produtos mantendo-se no ritmo de seis meses.
O novo ritmo torna mais gerenciável e previsível para os fornecedores de ferramentas, que agora terão um fluxo constante de atualizações menores. Além disso, desenvolvedores com visão de futuro podem explorar novos recursos em desenvolvimento, como tipos de valor mínimo do OpenJDK Project Valhalla ou o Z Garbage Collector do OpenJDK Project ZGC, usando versões de acesso antecipado disponíveis sob uma licença de código aberto familiar.
❓ Pergunta 4: Por que alguém atualizaria para a versão X quando uma nova release X+1 está a apenas seis meses de distância?
Os builds mais recentes do Oracle JDK e os builds do OpenJDK da Oracle são baixados milhões de vezes por mês por desenvolvedores. Foi observado um crescimento consistente nos downloads do JDK com cada release de recurso, incluindo o 9 e o 10. As releases mais recentes do Java 10 estão sendo baixadas a uma taxa muito maior do que as do Java 7 e Java 8 eram. Por exemplo, os downloads do JDK 10, no momento desta escrita, excedem os das atualizações do JDK 8 por um fator de cinco.
A forte adoção do novo ritmo de lançamento é impressionante. É muito encorajador ver IDEs populares e outros fornecedores de ferramentas adotarem e disponibilizarem suporte ao Java 10 rapidamente.
❓ Pergunta 5: Ainda não estou convencido. O Java 9 foi um desafio para adotar, então isso significa que o 10 e o 11 também serão.
Muitos desenvolvedores e usuários de Java SE historicamente esperaram por algumas atualizações antes de adotar uma nova "versão principal". Isso era esperado quando havia dezenas de novos recursos principais que alteravam a especificação em uma release "principal", mas não será o caso daqui para frente com os lançamentos de seis meses. Este não tem sido o caso desde o Java SE 9.
Por exemplo, a release do Java SE 9 incorporou aproximadamente 19.000 mudanças no código-fonte em relação ao Java SE 8. Houve apenas 2.700 dessas mudanças entre o Java 9 e o Java 10 – aproximadamente a mesma quantidade entre o Java 8 e o Java 8u40. Então, enquanto o Java SE 9 foi uma atualização "principal" comparado ao Java SE 8, já vimos que o Java SE 10 é uma simples atualização de recurso para o Java SE 9.
❓ Pergunta 6: Como posso ter confiança de que a transição para a release X+1 será tranquila? Quanto tempo há para a transição?
Os Builds de Acesso Antecipado (EA) estão ainda mais fáceis do que antes para baixar e testar, incluindo os próprios builds do OpenJDK da Oracle. A recomendação é que os desenvolvedores usem os builds de EA do OpenJDK da Oracle em seus sistemas de teste de construção para que quaisquer problemas possam ser detectados antecipadamente.
Há três meses entre a atualização final de uma release de recurso e a atualização de segurança da próxima release de recurso. A recomendação é fazer a transição durante esse período. Há aproximadamente um mês entre uma nova release de recurso e a próxima atualização de segurança programada. Por exemplo, o Java 9.0.4 foi lançado em janeiro de 2018, o Java 10.0.0 em março de 2018 e o 10.0.1 em abril de 2018. Após o lançamento do Java 10.0.1, não é recomendável usar o Java 9.0.4 ou o Java 10.0.0. No entanto, não é necessário esperar um mês, ou mesmo três meses, para começar a testar – os builds de Acesso Antecipado do JDK 10 foram publicados regularmente a partir de novembro de 2017, mais de seis meses antes da release de atualização 10.0.1.
Isso é consistente com os lançamentos históricos de recursos, onde houve 4-6 semanas entre os lançamentos de recursos e uma atualização de segurança subsequente. Por exemplo, o 8u40 foi lançado no início de março de 2015 e a subsequente atualização de segurança programada 8u45 foi lançada em 14 de abril de 2015.
❓ Pergunta 7: Ok, mas não quero novos recursos. Tenho um sistema em produção e só quero atualizações de estabilidade, desempenho e segurança. O que devo fazer?
A intenção é designar releases a cada três anos como releases de "Suporte de Longo Prazo" (LTS), começando com o Java SE 11 em setembro de 2018. Então, enquanto o Java SE 9 atingiu seu Fim de Vida com o lançamento do Java 10, e o Java 10 fará o mesmo com o lançamento do Java 11, o Java 11 terá suporte comercial da Oracle disponível por pelo menos oito anos adicionais.
Como aconteceu por quase uma década com o Java 6 e Java 7 (e provavelmente com o Java 8 em 2019), uma vez que a Oracle parar de contribuir com nossas alterações de código-fonte para uma série de releases específica no OpenJDK, para que possa focar nas necessidades de seus clientes, outros colaboradores qualificados na Comunidade OpenJDK podem intervir para continuar mantendo a série de releases. Eles fazem isso de acordo com os padrões da Comunidade OpenJDK pelo tempo que escolherem, fazendo o backport das mudanças relevantes de releases posteriores ainda mantidas pela Oracle e por outros. Por exemplo, para o JDK 6, a Sun estabeleceu o projeto em 2008, e a Oracle continuou a mantê-lo até 2013. Outros mantenedores então continuaram trabalhando no projeto fazendo backport de atualizações de releases posteriores.
A Oracle apoia essas transições na Comunidade OpenJDK fornecendo um processo estabelecido para que elas ocorram dentro do JDK Updates Project, bem como assistência a novos mantenedores para se estabelecerem em seus novos papéis, e, por último, mas não menos importante, o Vulnerability Group.
❓ Pergunta 8: O que está acontecendo com o Java SE 8?
O Java SE 8 é o fim do legado do modelo de versionamento e ritmo de lançamento; o Java 9 foi o novo começo.
Para o Oracle JDK, o Java 8 está passando exatamente pelos mesmos processos de transição do Java 7 e Java 6, com algumas exceções. Primeiro, para dar tempo adicional para se acostumar ao novo modelo de lançamento, a Oracle estendeu as atualizações públicas de seu Oracle JDK para janeiro de 2019 para uso comercial em produção, e pelo menos até o final de 2020 para uso individual em desktop. Segundo, foram anunciados esforços para tornar o Oracle JDK intercambiável com os builds do OpenJDK da Oracle para aqueles que desejam migrar para as próximas releases, como fizeram para Java 6->7 e Java 7->8. Se ainda não o fez, a sugestão é migrar para o 10 e embarcar no novo trem de lançamentos. Finalmente, a Oracle postou mais informações sobre o roteiro para o Java Client (incluindo Applets e Web Start).
No front do OpenJDK, a Oracle planeja continuar liderando e contribuindo para o projeto JDK 8 Updates até janeiro de 2019, antes do qual será feita uma chamada para novos mantenedores (como tem sido prática por mais de uma década, consulte a pergunta anterior para mais detalhes).
❓ Pergunta 9: Sou um Cliente Oracle, como sou afetado?
Você está coberto pelo seu uso do Java SE dentro de um produto Oracle que tenha uma dependência do Java SE. Encontre mais detalhes via esta nota do My Oracle Support.
Nota de rodapé:
[1] – ;tldr para o plano que a Oracle anunciou para seus binários e builds – (a) mover todos os bits anteriormente de código fechado do Oracle JDK para o OpenJDK (b) publicar binários do OpenJDK sob a licença GPLv2+CPE e (c) garantir uma transição suave de modo que os binários do Oracle JDK e do OpenJDK sejam intercambiáveis.