Lançado em 14 de setembro de 2021, o Java 17 é uma versão LTS e extremamente importante.
Sealed Classes (Final)
Pattern Matching aprimorado
Melhorias significativas na JVM
Remoção definitiva de APIs antigas
O Java 17 se tornou a base moderna para aplicações corporativas.
Nos últimos 22 anos, o Java cresceu até se tornar uma comunidade vibrante que atingiu uma escala sem igual. O Java continua a trazer valor para desenvolvedores e empresas em todo o mundo. Um planejamento cuidadoso e o envolvimento do ecossistema ajudaram o Java a se tornar uma das linguagens de programação mais usadas do planeta. Com mais de 12 milhões de desenvolvedores em todo o mundo executando Java, ele continua sendo a linguagem de programação número 1 escolhida por programadores de software. Daqui para frente, o objetivo é garantir que o Java esteja bem posicionado para o desenvolvimento moderno e o crescimento na nuvem.
Em 2017, foi anunciada a intenção de mudar para um novo ciclo de lançamentos de seis meses para o Java, com o objetivo de reduzir a latência entre os lançamentos principais. Ao mesmo tempo, foram anunciados os planos para construir e distribuir binários do OpenJDK. Este modelo de lançamento é inspirado nos modelos de lançamento usados por outras plataformas e por várias distribuições de sistemas operacionais, atendendo ao cenário moderno de desenvolvimento de aplicativos. O ritmo da inovação está acontecendo em uma taxa cada vez maior, e este novo modelo de lançamento permitirá que os desenvolvedores aproveitem novos recursos em produção o mais rápido possível. O desenvolvimento moderno de aplicativos espera um licenciamento aberto simples e um ritmo previsível baseado no tempo, e o novo modelo de lançamento atende a ambos.
Com isso, temos o prazer de anunciar a disponibilidade geral do Java 10, o primeiro lançamento com prazo definido como parte do novo ciclo de lançamentos de seis meses. Esta versão é mais do que uma simples correção de estabilidade e desempenho em relação ao Java SE 9; na verdade, ela introduz doze novos aprimoramentos definidos através das JDK Enhancement Proposals (JEPs) que os desenvolvedores podem começar a usar imediatamente:
varjavahjavacjava.util.LocaleO ecossistema Java continua a ser uma coleção diversificada de desenvolvedores e sua participação contínua é bem-vinda para ajudar a moldar o futuro do Java.
Ao construir aplicações interconectadas, desenvolvedores frequentemente interagem com protocolos habilitados para TLS, como HTTPS. Com a recente ênfase em comunicações criptografadas, este conteúdo aborda a forma como o JDK evolui em relação a protocolos, algoritmos e alterações, bem como alguns diagnósticos avançados para entender melhor conexões TLS como HTTPS.
A maioria dos desenvolvedores não precisará fazer esse nível de diagnóstico no processo de escrita ou execução de aplicações. No entanto, se necessário, as informações a seguir devem fornecer base suficiente para entender o que está acontecendo dentro de conexões seguras.
Nos últimos 15 anos, a plataforma Java evoluiu por meio do Java Community Process, onde empresas, organizações e indivíduos dedicados desenvolvem e votam em especificações para determinar o que compõe a Plataforma Java. Grande parte dos esforços está centrada na compatibilidade, como o TCK, garantindo que diferentes implementações sejam compatíveis entre si e que os desenvolvedores possam prever como suas aplicações serão executadas. Opções padrão críticas (como o protocolo TLS) não são alteradas dentro de versões menores.
A tabela a seguir descreve os protocolos e algoritmos suportados em cada versão do JDK:
| JDK 8 (Março 2014 - presente) | JDK 7 (Julho 2011 - presente) | JDK 6 (2006 até fim das atualizações públicas 2013) |
|---|---|---|
| Protocolos TLS: TLSv1.2 (padrão) TLSv1.1 TLSv1 SSLv3 |
Protocolos TLS: TLSv1.2 TLSv1.1 TLSv1 (padrão) SSLv3 |
Protocolos TLS: TLSv1.2 (atualização 111+) TLSv1.1 (atualização 111+) TLSv1 (padrão) SSLv3 |
| Cifras JSSE: Cifras no JDK 8 | Cifras JSSE: Cifras no JDK 7 | Cifras JSSE: Cifras no JDK 6 |
Fazer uma conexão HTTPS em Java é relativamente simples. O código é apresentado com foco no ajuste e na compreensão das capacidades subjacentes.
Código de back-end de exemplo para fazer uma conexão SSL:
final URL url = new URL("https://example.com");
try(final InputStream in = url.openStream()){
//…
}A conexão também pode ser ajustada através de um cast:
final HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
//opera em conn
conn.connect();
try(final InputStream in = conn.getInputStream()){
//…
}O Qualys SSL Labs mantém uma coleção de ferramentas úteis para entender conexões SSL/TLS. Uma em particular é a página "View My Client", que exibe informações sobre a conexão do cliente. Ao integrar com essa página, é possível controlar a implementação enquanto se usam diferentes parâmetros de ajuste do Java.
Para testar o ajuste de parâmetros, foi implementada uma pequena aplicação JavaFX em JavaScript. Ela exibe essa página em um WebView, mostrando informações sobre a conexão cliente SSL/TLS subjacente do Java. O código pode ser encontrado no apêndice.
Ao diagnosticar problemas relacionados a TLS, há várias propriedades do sistema úteis. Elas geralmente são abordadas em suas seções relevantes do JSSE, mas esta coleção única pode ajudar quem busca entender a flexibilidade da implementação do Java ou diagnosticar detalhes de conexão.
| Parâmetro | Descrição |
|---|---|
javax.net.debug |
Imprime detalhes de depuração para conexões feitas. Exemplo: -Djavax.net.debug=all ou -Djavax.net.debug=ssl:handshake:verbose |
https.protocols |
Controla a versão do protocolo usada por clientes Java que obtêm conexões https através do uso da classe HttpsURLConnection ou via operações URL.openStream(). Para versões mais antigas, isso pode atualizar o padrão, caso seu cliente Java 7 queira usar TLS 1.2 como padrão.Exemplo: -Dhttps.protocols=TLSv1,TLSv1.1,TLSv1.2Para protocolos não HTTP, isso pode ser controlado através do SSLContext do SocketFactory. |
jdk.tls.client.protocols |
Controla a implementação TLS subjacente da plataforma. Mais informações estão disponíveis no Guia de Referência do JSSE. Exemplo: -Djdk.tls.client.protocols=TLSv1.1,TLSv1.2Disponível em todas as versões do JDK 8, ou após Java 7 update 95 (Janeiro 2016) e Java 6 update 121 (Julho 2016). |
http.agent |
Ao iniciar conexões, o Java aplica isso como sua string de agente do usuário. Modificar isso resolve casos onde a parte receptora responde de forma diferente com base no agente do usuário. Exemplo: -Dhttp.agent=“agente conhecido” |
java.net.useSystemProxies |
Usa detalhes de proxy do próprio sistema operacional. Exemplo: -Djava.net.useSystemProxies=true |
http.proxyHosthttp.proxyPort |
A conexão de proxy a ser usada para conexões HTTP. Exemplo: -Dhttp.proxyHost=proxy.exemplo.com -Dhttp.proxyPort=8080 |
https.proxyHosthttps.proxyPort |
O mesmo que acima, exceto que a configuração é separada entre HTTP e HTTPS. |
http.proxyUserhttp.proxyPasswordhttps.proxyUserhttps.proxyPassword |
Credenciais baseadas em senha para os proxies acima. |
Ao fazer uma conexão HTTPS, suponha que o cliente lançou a seguinte exceção devido a um handshake falho com o servidor:
javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failureSSLHandshakeException é uma subclasse de IOException, então não é necessário capturá-la explicitamente. A maioria dos desenvolvedores não precisará de uma captura explícita, mas isso pode ajudar a diagnosticar mais facilmente a causa de qualquer IOException.
Ao aplicar a propriedade -Djavax.net.debug=all, a falha associada a esta SSLHandshakeException apareceria logo após a negociação de algoritmo nos logs.
| JDK 7 (falha em algoritmo não suportado) | JDK 8 (funciona bem) |
|---|---|
Cipher Suites: […Lista longa de cifras…]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {…}
Extension ec_point_formats, formats: [uncompressed]
Extension server_name, server_name: [host_name: HOST]
main, WRITE: TLSv1 Handshake, length = 168
main, READ: TLSv1 Alert, length = 2
main, RECV TLSv1 ALERT: fatal, handshake_failure
main, called closeSocket()
main, handling exception: javax.net.ssl.SSLHandshakeException: Received fatal alert: handshake_failure |
Cipher Suites: […Lista longa de cifras…]
Compression Methods: { 0 }
Extension elliptic_curves, curve names: {…}
Extension ec_point_formats, formats: [uncompressed]
Extension signature_algorithms, signature_algorithms: …
Extension server_name, server_name: [type=host_name (0), value=HOST]
main, WRITE: TLSv1.2 Handshake, length = 226
main, READ: TLSv1.2 Handshake, length = 89
*** ServerHello, TLSv1.2
RandomCookie: GMT: -1809079139 bytes = { …}
Session ID: {…}
Cipher Suite: TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
Compression Method: 0
Extension renegotiation_info, renegotiated_connection: <empty>
Extension ec_point_formats, formats: [uncompressed, ansiX962_compressed_prime, ansiX962_compressed_char2]
%% Initialized: [Session-1, TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256]
** TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
main, READ: TLSv1.2 Handshake, length = 2308 |
No caso acima, a falha ocorreu durante o handshake. A causa mais provável para isso é o suporte de algoritmo. O JDK fornece um pacote separado chamado JCE Força Ilimitada, projetado para adicionar suporte a algoritmos mais fortes do que o disponível por padrão. O Qualys SSL Labs fornece um teste de servidor SSL diferente que enumerará quais algoritmos um servidor suporta.
Em um ambiente de alta segurança, uma forma de fortalecer os algoritmos no JDK é através dos arquivos de política JCE Força Ilimitada. Neste caso específico, substituir esses arquivos de política dentro do JDK 7 permite que ele use as variantes mais fortes dos algoritmos existentes e se conecte com sucesso.
O código a seguir abrirá a página "View My Client" do Qualys SSL Labs dentro de um cliente Java. Para testar configurações, execute assim:
jjs -fx viewmyclient.js
jjs -fx -Dhttps.protocols=TLSv1 viewmyclient.jsvar Scene = javafx.scene.Scene;
var WebView = javafx.scene.web.WebView;
var browser = new WebView();
browser.getEngine().load("https://ssllabs.com/ssltest/viewMyClient.html");
$STAGE.scene = new Scene(browser);
$STAGE.show();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.
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.
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.
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.
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.
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.
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.
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.
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).
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.
Recentemente, foram anunciadas mudanças significativas no modelo de suporte e distribuição do Java SE. Este artigo apresenta um resumo dessas mudanças para ajudar desenvolvedores e empresas a entenderem o novo cenário.
O modelo de suporte do Java SE passou por uma evolução. Tradicionalmente, as atualizações públicas eram fornecidas gratuitamente para versões específicas. No novo modelo, para continuar recebendo atualizações de segurança e correções de bugs após um determinado período, é necessário uma assinatura.
Isso garante que as organizações que exigem suporte de longo prazo para ambientes de produção estáveis possam obtê-lo de maneira estruturada.
A assinatura oferece benefícios essenciais para ambientes corporativos:
A assinatura é voltada principalmente para empresas que utilizam o Java SE em ambientes de missão crítica e produção, especialmente aquelas que:
É importante destacar que existem opções gratuitas robustas disponíveis no ecossistema Java:
Essas alternativas são excelentes para desenvolvimento, teste e para muitas cargas de trabalho em produção.
A escolha depende das necessidades específicas da sua organização. Recomenda-se considerar as seguintes perguntas:
Se a resposta for "sim" para essas questões, avaliar uma assinatura comercial é um passo prudente.
Para tomar uma decisão informada, consulte a documentação oficial e os detalhes dos termos de licenciamento. Recomenda-se também avaliar as necessidades de suporte de todos os times dentro da organização que utilizam Java.
O ecossistema Java continua vibrante, com múltiplas opções para atender a diferentes perfis de uso, desde desenvolvedores individuais até grandes corporações.
Existem planos para disponibilizar a tecnologia de código aberto JDK Mission Control (JMC) como um download separado para atender usuários tanto do OpenJDK quanto do Oracle JDK.
O Java Flight Recorder (JFR) agora é de código aberto. O JFR será incluído nos binários do OpenJDK e do Oracle JDK a partir do Java SE 11. Ter um único download separado do JMC para Oracle JDK e OpenJDK mantém a simplicidade.
Como um download separado, o JMC pode ser atualizado independentemente dos lançamentos do Java SE. Isso permite oferecer novas capacidades de monitoramento e diagnóstico em várias versões do Java SE simultaneamente. Recursos podem ser adicionados ao JMC no meio de um ciclo de lançamento do Java SE.
Aproveitando os recursos de modularidade introduzidos com o JDK 9, é possível criar um runtime otimizado e personalizado para o JMC. Ele pode incluir tudo o que é necessário para essa versão do JMC, como componentes JavaFX, enquanto remove tudo o que não é exigido pelo JMC, tornando o tamanho do runtime do aplicativo consideravelmente menor.
Versões mais recentes do JMC podem interagir com versões mais antigas do JDK (do JDK 7u40 acima). É comum usar uma única versão do JMC para interagir com lançamentos atuais e antigos do JDK. Isso fica mais claro se o JMC for um download separado.
É um cenário comum um único desenvolvedor precisar de múltiplas instâncias do JDK no mesmo sistema. Ter cada um desses JDKs incluindo sua própria cópia duplicada do JMC, quando uma única versão pode lidar com todos, desperdiça espaço. Também pode levar a confusão, pois diferentes versões do JDK podem incluir diferentes versões do JMC, todas com (às vezes sutis) diferenças na funcionalidade.
Com o Java 11 prestes a ser lançado, é momento de analisar o efeito que o novo ritmo de lançamentos teve na adoção das novas versões.
As novas versões do Java costumavam levar um bom tempo para serem adotadas pelos desenvolvedores. Por exemplo, o Java SE 5.0 introduziu mudanças importantes, como anotações e genéricos, em 2004. Levou dois anos, até 2006, para que uma versão da IDE Eclipse que fosse testada e validada no Java SE 5.0 fosse lançada. Somente então os desenvolvedores que usavam o Eclipse puderam começar a adotar o Java SE 5.0 de forma plena como sua plataforma principal.
Muito mudou no ecossistema Java na década desde 2004. O Java SE 8 foi lançado em 2014, introduzindo outra grande mudança na linguagem: as lambda expressions. No entanto, em poucos dias, novas versões das IDEs Eclipse, IntelliJ IDEA e NetBeans, testadas e validadas no JDK 8, já estavam disponíveis. Isso permitiu que os desenvolvedores começassem a adotar o Java SE 8 quase imediatamente após seu lançamento.
E muitos o fizeram, tornando o Java SE 8 a versão mais rapidamente adotada até então. O número de downloads do JDK 8 aumentou mais de 30% em comparação com o JDK 7 no mesmo período inicial de lançamento.
Com o novo ritmo semestral de lançamentos do Java SE a partir do Java SE 9, vimos o mesmo padrão de suporte rápido às novas versões da plataforma pelas principais IDEs. Engenheiros continuam a trabalhar em conjunto com desenvolvedores de mais de 100 bibliotecas e ferramentas Java de código aberto populares em todo o ecossistema para remover possíveis barreiras à adoção de novas versões.
Consequentemente, muitas bibliotecas e ferramentas populares estavam prontas para o Java 9 no momento de seu lançamento, ou logo em seguida. Isso incluiu ferramentas como Apache Ant, Apache Maven, Gradle, bibliotecas como ByteBuddy, JUnit, JaCoCo, Apache Lucene e frameworks como Akka, Spring Framework e WildFly.
Como resultado, o número de downloads do JDK 9 no lançamento do Java SE 9 foi mais de 10% maior do que o do lançamento do JDK 8.
Vimos um padrão semelhante entre os desenvolvedores com o JDK 10. O Java SE 10 registrou 20% mais downloads de JDK do que o JDK 8 no mesmo período durante o lançamento do Java SE 8. Assim como com o JDK 9, IDEs, ferramentas, bibliotecas e frameworks populares rapidamente anunciaram seu suporte para a nova versão do Java.
Isso mostra como um aspecto importante do novo ritmo de lançamentos está funcionando incrivelmente bem — ele realmente está colocando novos recursos do Java, como a inferência de tipo de variável local no Java SE 10, nas mãos de mais desenvolvedores muito mais rápido do que antes.
No passado, cada nova versão da plataforma Java levava vários anos para ser desenvolvida e, no processo, acumulava milhares de melhorias grandes e pequenas, mudanças e correções de bugs. Levava muito tempo para ser construída e depois levava muito tempo para se familiarizar com ela, devido ao escopo muito amplo de cada versão.
Sob o novo ritmo de lançamentos, cada versão de recurso do Java é entregue em uma fração do tempo que levava no passado e, consequentemente, cada versão tem um escopo muito menor. Como consequência, o tempo necessário para se familiarizar com ela é muito mais curto, pois há muito menos mudanças para assimilar. Na prática, isso significa que muitas das ferramentas, bibliotecas e frameworks populares que estavam prontos para o Java SE 9 e Java SE 10 já conseguiram se preparar para o Java SE 11.
Em outras palavras, desde o Spring Boot e Spring Framework, passando por Mockito e ByteBuddy, até Apache Cassandra, IntelliJ IDEA, Jenkins, Eclipse IDE e Atlassian, grandes partes do ecossistema Java anunciaram que estão prontas para o Java SE 11 ou que já estão trabalhando para suportá-lo.
Dado que esse é o caso, não deve ser surpresa que uma pesquisa recente tenha constatado que mais da metade dos entrevistados está considerando usar o Java SE 11 para implantação em um futuro próximo.
Para usuários que precisam adotar novas versões de forma mais conservadora, foi introduzida recentemente a Java SE Subscription: uma assinatura mensal simples e de baixo custo que inclui licenciamento e suporte do Java SE para uso em desktops, servidores ou implantações na nuvem. A assinatura fornece acesso a atualizações de desempenho, estabilidade e segurança testadas e certificadas para o Java SE, diretamente da fonte. Ela também inclui acesso ao suporte 24×7, suporte em 27 idiomas, recursos de gerenciamento, monitoramento e implantação de desktop do Java SE 8, entre outros benefícios.
O produto Java SE 11 é uma versão de suporte de longo prazo (LTS). A Java SE Subscription permite que esses usuários recebam atualizações nas versões LTS e permaneçam em uma determinada versão de lançamento LTS por pelo menos oito anos. As organizações podem facilmente adicionar às suas assinaturas a qualquer momento, conforme movem cargas de trabalho do desenvolvimento para a produção.
Usuários que não precisam adotar novas versões da plataforma de forma conservadora, por outro lado, podem continuar a aproveitar os benefícios de um rápido ritmo de lançamentos do Java, como foi o caso do JDK 9 e JDK 10, usando os builds do OpenJDK de código aberto e totalmente testados, conforme a plataforma Java continua a avançar mais rápido com a comunidade OpenJDK.
A partir do Java 11, a Oracle fornecerá lançamentos do JDK sob a licença de código aberto GNU General Public License v2, com a Exceção de Classpath (GPLv2+CPE), e sob uma licença comercial para aqueles que usam o Oracle JDK como parte de um produto ou serviço Oracle, ou que não desejam usar software de código aberto. Essa combinação de uso de uma licença de código aberto e uma licença comercial substitui a licença histórica "BCL", que tinha uma combinação de termos comerciais gratuitos e pagos.
Serão fornecidas compilações diferentes para cada licença, mas essas compilações são funcionalmente idênticas, exceto por algumas diferenças cosméticas e de empacotamento, descritas em detalhes abaixo.
A Binary Code License para tecnologias Oracle Java SE ("BCL") tem sido a licença principal para tecnologias Oracle Java SE por mais de uma década. A BCL permite o uso sem taxas de licença sob certas condições. Para simplificar as coisas no futuro, a Oracle começou a fornecer compilações do OpenJDK com licença de código aberto a partir do Java 9, usando o mesmo modelo de licença da plataforma Linux. Se você está acostumado a obter binários Oracle Java SE gratuitamente, pode simplesmente continuar fazendo isso com as compilações OpenJDK da Oracle disponíveis em jdk.java.net. Se você está acostumado a obter binários Oracle Java SE como parte de um produto ou serviço comercial da Oracle, pode continuar a obter lançamentos do Oracle JDK por meio do My Oracle Support (MOS) e outros locais.
Historicamente, o JDK licenciado pela BCL da Oracle continha "recursos comerciais" que não estavam disponíveis nas compilações do OpenJDK. Conforme prometido, no entanto, no ano passado a Oracle contribuiu com esses recursos para a Comunidade OpenJDK, incluindo:
A partir do Java 11 em diante, portanto, as compilações do Oracle JDK e do OpenJDK serão essencialmente idênticas.
Ainda restam um pequeno número de diferenças, algumas intencionais e cosméticas, e outras simplesmente porque é necessário mais tempo para discussão com os contribuidores do OpenJDK.
O Oracle JDK 11 emite um aviso ao usar a opção
-XX:+UnlockCommercialFeaturesO Oracle JDK 11 pode ser configurado para fornecer dados de log de uso para a ferramenta "Advanced Management Console", que é um produto comercial separado da Oracle. Trabalhar-se-á com outros contribuidores do OpenJDK para discutir como esses dados de uso podem ser úteis no OpenJDK em versões futuras, se é que serão. Essa diferença permanece principalmente para fornecer uma experiência consistente aos clientes da Oracle até que tais decisões sejam tomadas.
O comando
javac –releasejavafx.base
javafx.controls
javafx.fxml
javafx.graphics
javafx.media
javafx.web
java.jnlp
jdk.jfr
jdk.management.cmm
jdk.management.jfr
jdk.management.resource
jdk.packager.services
jdk.snmpEssa diferença permanece para fornecer uma experiência consistente para tipos específicos de uso legado. Esses módulos agora estão disponíveis separadamente como parte do OpenJFX, agora estão tanto no OpenJDK quanto no Oracle JDK porque eram recursos comerciais que a Oracle contribuiu para o OpenJDK (por exemplo, Flight Recorder) ou foram removidos do Oracle JDK 11 (por exemplo, JNLP).
A saída dos comandos
java –versionjava -fullversionjava –versionjava 11 2018-09-25
Java(TM) SE Runtime Environment 18.9 (build 11+28)
Java HotSpot(TM) 64-Bit Server VM 18.9 (build 11+28, mixed mode)E para uma compilação do OpenJDK 11:
openjdk version "11" 2018-09-25
OpenJDK Runtime Environment 18.9 (build 11+28)
OpenJDK 64-Bit Server VM 18.9 (build 11+28, mixed mode)O Oracle JDK sempre exigiu que os provedores criptográficos de terceiros fossem assinados por um certificado conhecido. A estrutura de criptografia no OpenJDK tem uma interface criptográfica aberta, o que significa que não restringe quais provedores podem ser usados. O Oracle JDK 11 continuará a exigir uma assinatura válida, e as compilações do Oracle OpenJDK continuarão a permitir o uso de um provedor de criptografia de terceiros com assinatura válida ou não assinado.
O Oracle JDK 11 continuará a incluir instaladores, marcação e empacotamento JRE para uma experiência consistente com usos legados de desktop. As compilações do Oracle OpenJDK estão atualmente disponíveis como arquivos zip e tar.gz, enquanto formatos de distribuição alternativos estão sendo considerados.
Idealmente, simplesmente nos referiríamos a todas as compilações do Oracle JDK como "Oracle JDK", seja sob a GPL ou a licença comercial, dependendo da sua situação. No entanto, por razões históricas, enquanto as pequenas diferenças remanescentes existirem, nos referiremos a elas separadamente como compilações OpenJDK da Oracle e Oracle JDK.
Plataformas de software bem-sucedidas e seus ecossistemas têm um relacionamento simbiótico, com ciclos de feedback positivos e negativos. À medida que os desenvolvedores usam uma plataforma para criar produtos de sucesso que resolvem problemas, a plataforma evolui para oferecer novos recursos. Ao mesmo tempo, plataformas de sucesso se adaptam às mudanças no ambiente tecnológico, depreciando e removendo funcionalidades legadas menos utilizadas.
Este processo está sempre em movimento. À medida que novas versões de uma plataforma são lançadas, as mais antigas são gradualmente reduzidas para que os provedores possam focar seus esforços no futuro, em vez de no passado.
O ecossistema Java passa por esse processo com sucesso há décadas, através de dez revisões principais da plataforma. Uma forte compatibilidade com versões anteriores protege os investimentos feitos em todo o ecossistema. Ao mesmo tempo, alguma adaptação é inevitável ao longo do tempo. O sucesso contínuo da plataforma, portanto, requer que a maior parte do ecossistema avance para o lançamento mais recente, protegendo os investimentos existentes.
Uma estratégia para equilibrar esses dois objetivos é, por um lado, fornecer atualizações públicas gratuitas por um período de tempo e, por outro, oferecer suporte de longo prazo comercial para usuários com necessidades diferentes. Essa estratégia permite que a maior parte do ecossistema acompanhe o ritmo de lançamento gratuitamente, fornecendo atualizações adicionais de segurança, desempenho e outras sob termos comerciais para usuários que desejam migrar de uma versão da plataforma para outra em seu próprio cronograma, ou não migrar.
O Java SE 8 foi lançado em 18 de março de 2014. No momento em que o Oracle Java SE 8 atinge o fim das atualizações públicas para usuários comerciais em janeiro de 2019, terão sido fornecidos quase cinco anos de atualizações públicas gratuitas e contínuas.
Com uma Assinatura Oracle Java SE, os usuários comerciais podem continuar a se beneficiar do suporte e das atualizações regulares do Oracle Java SE 8, incluindo melhorias e correções críticas, por um período ainda maior. Por exemplo, a tecnologia Java Web Start continuará sendo suportada comercialmente no Oracle Java SE 8 até pelo menos março de 2025.
Nem todos os usuários do Oracle Java SE 8 o usam comercialmente. Alguns o usam para jogar ou executar aplicativos de produtividade pessoal. As atualizações públicas gratuitas do Oracle Java SE 8 para usuários pessoais continuarão sendo fornecidas até pelo menos dezembro de 2020. Durante esse tempo, os usuários pessoais devem entrar em contato com seus provedores de aplicativos e incentivá-los a migrar seus aplicativos para a versão mais recente do Java ou mudar para aplicativos alternativos.
O caminho de atualização mais curto do Oracle Java SE 8 leva ao JDK 10. As instruções para desenvolvedores de aplicativos estão disponíveis no Oracle JDK 10 Migration Guide. Instruções para usuários que migram do Oracle JRockit também estão disponíveis.
A versão mais recente do Java disponível para download no momento da redação é o JDK 10.0.2. Esta é a linha de base de segurança, ou seja, contém correções para vulnerabilidades de segurança descritas no último Oracle Critical Patch Update.
O JDK 10 chegará ao fim de sua vida útil no final de setembro de 2018. O próximo caminho de atualização do Oracle Java SE 8 leva ao JDK 11. O Oracle Java SE 11 é a próxima versão planejada de Suporte de Longo Prazo (LTS) e a primeira versão desse tipo que faz parte do ciclo de seis meses. Os clientes da Oracle receberão, portanto, o Oracle Premier Support e lançamentos de atualizações periódicas mesmo após o lançamento do Java SE 12. Isso torna o Oracle Java SE 11 um alvo de migração atraente para ISVs e outros usuários comerciais.
Como o JDK 11 ainda não foi lançado, o curso de ação recomendado para desenvolvedores que pretendem usar o JDK 11 é começar a trabalhar na migração do Java SE 8 fazendo com que seus aplicativos sejam executados com sucesso no JDK 10. Devido ao ciclo de lançamento semestral mais rápido, o número de alterações entre o JDK 10 e o JDK 11 é muito menor do que entre o JDK 8 e o JDK 10.
Assim que um aplicativo funcionar bem no JDK 10, os desenvolvedores devem testá-lo com as versões de candidata a lançamento (Release Candidate) do JDK 11 para estarem prontos para migrar para o JDK 11 quando for lançado ainda neste mês.
Os desenvolvedores que desejam migrar um aplicativo diretamente do Oracle Java SE 8 para o JDK 12 devem seguir o mesmo modelo de migração — começando com um esforço de migração maior para a versão mais recente na linha de base de segurança, ou seja, o JDK 10.0.2 no momento e, em seguida, assim que o aplicativo funcionar bem, continuar com uma migração incremental para a versão mais recente disponível do JDK 11.
Assim que o aplicativo funcionar bem no JDK 11, os desenvolvedores devem começar a testá-lo com as versões de acesso antecipado (Early Access) do JDK 12. As versões de acesso antecipado do JDK 12 são publicadas regularmente sob a GNU General Public License, versão 2, com a Classpath Exception. Essas versões permitem que os desenvolvedores avaliem os novos recursos do JDK 12 e testem o impacto das alterações nos recursos existentes em seus próprios aplicativos.
Neste ponto, os engenheiros da Oracle lideram e realizam a maior parte do trabalho de manutenção nas atualizações do OpenJDK 8 na Comunidade OpenJDK há mais de quatro anos e meio. Isso continuará até pelo menos janeiro de 2019. Após janeiro de 2019, os contribuidores da Oracle provavelmente redirecionarão seus esforços na Comunidade OpenJDK das atualizações do OpenJDK 8 para outras versões atuais do JDK, como foi feito no passado com as atualizações do OpenJDK 6 e do OpenJDK 7.
Como no passado, quando uma parte adequada se apresentar para continuar a manter as atualizações do OpenJDK 8 após janeiro de 2019, será discutido na Comunidade OpenJDK como melhor possibilitar essa transição.
Os usuários interessados em continuar usando o OpenJDK 8 após os engenheiros da Oracle mudarem de foco devem, portanto, se inscrever na lista de e-mails do projeto até janeiro de 2019 e discutir suas expectativas e planos com os contribuidores restantes para entender melhor o escopo do suporte disponível para o OpenJDK 8 naquele momento.
O tempo voa! Nos últimos meses, foram anunciadas mudanças para evoluir a plataforma Java, garantindo que ela continue avançando com um futuro promissor para os usuários. Esses avanços incluíram:
Desde o lançamento do Java 9, a plataforma Java mudou para um ciclo de lançamento de seis meses, permitindo que os desenvolvedores tenham acesso mais rápido a melhorias contínuas. Os lançamentos agora ocorrem em março e setembro de cada ano, o que significa que não é mais necessário tentar absorver centenas de mudanças a cada dois anos de uma só vez – em vez disso, as mudanças são entregues em um ritmo mais mensurado e previsível.
Para melhorar a produtividade dos desenvolvedores, recursos comerciais anteriormente acessíveis apenas com uma licença paga foram disponibilizados como código aberto. Isso cria maior alinhamento e intercambialidade entre as versões do Oracle JDK e do Oracle OpenJDK. Recursos comerciais anteriores agora disponíveis no OpenJDK incluem Application Class Data Sharing, o Project ZGC, o Java Flight Recorder (JFR) e o Java Mission Control (JMC). Mais recentemente, foram anunciados planos para disponibilizar a tecnologia JMC como um download separado para atender tanto aos usuários do OpenJDK quanto do Oracle JDK.
Foi anunciada a Java SE Subscription, um novo modelo que cobre todas as necessidades de licenciamento e suporte do Java SE para dar ainda mais suporte aos milhões de empresas em todo o mundo que executam Java em produção. A assinatura complementa a oferta gratuita de longa data do Oracle OpenJDK, que atende desenvolvedores e organizações que não precisam de suporte comercial.
Com seis meses desde o Java 10 (o primeiro lançamento de recursos como parte do ciclo de seis meses), o Java 11 já está disponível.
O Oracle fornece o JDK não apenas sob a versão Oracle OpenJDK usando a licença de código aberto GNU General Public License v2, com a Classpath Exception (GPLv2+CPE), mas também sob uma licença comercial para quem usa o Oracle JDK como parte de um produto ou serviço Oracle, ou que não deseja usar software de código aberto. Estas substituem a histórica licença "BCL", que tinha uma combinação de termos comerciais gratuitos e pagos.
Isso significa que os usuários podem obter o Java 11 de acordo com suas necessidades:
Dezessete aprimoramentos foram entregues no Java 11, incluindo mais notavelmente:
Este JEP padroniza a API de Cliente HTTP incubada introduzida no JDK 9, via JEP 110, e atualizada no JDK 10.
O TLS 1.3 é uma grande reformulação do protocolo TLS e fornece melhorias significativas de segurança e desempenho em relação às versões anteriores.
O JFR fornece um mecanismo de gravação de alto desempenho e uma estrutura de coleta de dados de baixa sobrecarga para solução de problemas de aplicativos Java críticos.
// Exemplo de código com o JFR (conceitual)
// O JFR permite iniciar gravações para diagnóstico
try (Recording recording = new Recording()) {
recording.start();
// Seu código da aplicação aqui
recording.stop();
recording.dump(Paths.get("my-recording.jfr"));
}O ZGC é um coletor de lixo (GC) experimental, mas previsível e de baixa latência, que pode lidar com heaps que variam de relativamente pequenos (algumas centenas de megabytes) a muito grandes (muitos terabytes) de tamanho.
Este aprimoramento simplifica a "entrada" para novos usuários Java, melhorando o launcher java para executar um programa fornecido como um único arquivo de código-fonte Java, incluindo o uso dentro de um script e/ou técnicas relacionadas. Por exemplo, um arquivo chamado HelloWorld.java contendo:
public class HelloWorld {
public static void main(String[] args) {
System.out.println("Olá, mundo!");
}
}Agora pode ser executado diretamente com:
java HelloWorld.javaAgora que o Java 11 está geralmente disponível, o desenvolvimento mudou para o próximo lançamento de recursos de seis meses, na forma do Java 12, atualmente com duas melhorias direcionadas e mais a serem adicionadas à medida que o trabalho for concluído.
Com 12 milhões de desenvolvedores em todo o mundo usando Java, o Java continua sendo a linguagem de programação número 1 escolhida pelos programadores de software. E como o Java 11 demonstra, por meio de um planejamento contínuo e cuidadoso e do envolvimento do ecossistema, a plataforma Java está bem posicionada para o desenvolvimento moderno e o crescimento na nuvem.
Existe um trabalho ativo em segurança do Java, com o objetivo importante de encontrar maneiras de remover versões antigas e inseguras de circulação. A recomendação é que os usuários de Java mantenham suas instalações JRE atualizadas com a linha de base de segurança mais recente por meio do recurso Java Auto Update.
Há muito tempo, os usuários do Microsoft Windows têm conseguido melhorar a segurança de seu computador verificando versões antigas do Java e removendo-as usando a Java Uninstall Tool.
Recentemente, foi anunciado que o Internet Explorer em breve bloqueará controles ActiveX desatualizados. Esse recurso fornecerá aos usuários do Internet Explorer notificações quando as páginas da web tentarem carregar controles ActiveX desatualizados, como os controles Java ActiveX fornecidos por uma JRE abaixo da linha de base de segurança. Documentação e informações adicionais sobre como configurar e gerenciar esse novo recurso são fornecidas pela Microsoft.
Manter a segurança do Java é uma prioridade, e existe uma cooperação contínua com os parceiros para manter os usuários de Java atualizados e seguros em diferentes navegadores e sistemas operacionais.
As empresas que precisam manter uma JRE mais antiga para aplicativos legados ainda devem usar uma JRE atualizada instalada junto com a versão mais antiga e aproveitar a Funcionalidade Deployment Rule Set para limitar o acesso à JRE mais antiga apenas para aplicativos bem conhecidos.
Nota: Este conteúdo foi adaptado e traduzido para desenvolvedores brasileiros, com foco nas informações técnicas e de segurança.
Com o lançamento recente do Java 11, é hora de olhar para trás, para o desenvolvimento da segunda versão de recursos no novo ritmo de lançamentos semestrais. Vamos celebrar as muitas contribuições da Comunidade OpenJDK vindas de vários indivíduos e organizações — todos nós construímos o JDK 11, juntos!
A taxa geral de mudança no JDK ao longo do tempo permaneceu essencialmente constante por muitos anos, mas, sob o novo ritmo, a taxa na qual as mudanças são disponibilizadas aumentou drasticamente. Em vez de dezenas de milhares de correções e cerca de uma centena de JEPs serem disponibilizados em um lançamento enorme a cada poucos anos, as mudanças são disponibilizadas em lançamentos menores em uma programação mais gerenciável e previsível. Essas mudanças podem variar de grandes recursos a pequenas melhorias, manutenção de rotina, correções de bugs e melhorias na documentação. Cada uma dessas mudanças é representada em um único commit para um único problema no JDK Bug System.
Dos 2.468 problemas do JIRA marcados como corrigidos no JDK 11, 1.963 foram concluídos por pessoas que trabalham na Oracle, enquanto 505 foram contribuídos por desenvolvedores individuais e desenvolvedores que trabalham para outras organizações. Ao percorrer os problemas e compilar os dados organizacionais dos responsáveis, obtém-se o seguinte gráfico das organizações que patrocinam o desenvolvimento de correções no JDK 11:
Embora os desenvolvedores empregados pela Oracle tenham resolvido 80% dos problemas do JIRA durante o desenvolvimento do JDK 11, 20% foram corrigidos por desenvolvedores que trabalham para outras organizações. Os desenvolvedores que trabalham para as cinco próximas maiores organizações contribuintes, SAP (7%), Red Hat (5%), Google (3%), BellSoft (1%) e IBM (1%), corrigiram coletivamente 17% desses problemas. Desenvolvedores independentes contribuíram com 2% das correções no JDK 11.
Por último, mas não menos importante, o um por cento restante das correções foi contribuído coletivamente por desenvolvedores de uma ampla gama de organizações, incluindo Alibaba, Amazon, ARM, Azul, Intel, JetBrains, Linaro e Qualcomm Datacenter Technologies.
Muito mais trabalho vai para um lançamento do JDK, além dos commits individuais. Existem JEPs, revisões de código, relatórios de bugs e discussões em listas de e-mail, tanto no Projeto JDK quanto nos vários Projetos OpenJDK onde se originaram recursos e correções destinados ao JDK 11. Estes incluem o Projeto Valhalla e o Projeto Amber, ambos liderados por Brian Goetz da Oracle, a Porta AArch64, liderada por Andrew Haley da Red Hat, e o Projeto ZGC, liderado por Per Lidén da Oracle.
Com o JDK 11 lançado, o trabalho na primeira atualização do JDK 11 liderada pela Oracle no repositório do Projeto JDK Updates também começou.
Finalmente, é hora de agradecer a todos os desenvolvedores que contribuíram com código para o JDK 11 e às suas organizações patrocinadoras. Um agradecimento especial também aos muitos desenvolvedores experientes que revisaram as mudanças propostas, aos primeiros usuários que testaram as versões de acesso antecipado e relataram problemas, e aos profissionais pacientes que forneceram feedback nas listas de e-mail do OpenJDK.
Uma mudança significativa foi proposta para o JDK 9: um novo formato de string de versão. Este novo esquema foi projetado para ser facilmente compreensível por humanos e máquinas, atender aos requisitos atuais e futuros de versionamento e seguir as práticas recomendadas da indústria de software.
O formato de versão atual do JDK (JDK 8 e anteriores) tem várias limitações que se tornaram aparentes ao longo dos anos. A versão $MAJOR.$MINOR.$SECURITY não é flexível o suficiente para os novos ciclos de lançamento mais rápidos. Além disso, a string de versão 1.8.0_92 é semanticamente incorreta, pois o 1.8 não é mais um 'major version' no sentido convencional.
O novo esquema visa resolver essas questões, oferecendo uma estrutura clara para os próximos anos.
O novo formato de string de versão segue a seguinte estrutura geral:
$MAJOR.$MINOR.$SECURITY.$PATCHOnde:
Suponha que a primeira versão do JDK 9 seja lançada. Suas strings de versão poderiam evoluir da seguinte forma:
9.0.1.0 // Versão inicial
9.0.1.1 // Corrigido um bug de inicialização (patch)
9.0.2.0 // Aplicado um patch de segurança crítico
9.1.0.0 // Adicionado um novo recurso compatível (minor release)Para o JDK 10, a sequência recomeçaria:
10.0.0.0 // Versão principal inicialA API java.lang.Runtime.Version foi estendida para analisar e representar este novo formato. Desenvolvedores que analisam programaticamente a string de versão devem migrar para esta API.
Exemplo de uso:
Runtime.Version ver = Runtime.version();
System.out.println("Major: " + ver.major());
System.out.println("Minor: " + ver.minor());
System.out.println("Security: " + ver.security());
System.out.println("Patch: " + ver.patch());Essa mudança também afeta propriedades do sistema como java.version, java.runtime.version e java.vm.version, que agora refletirão o novo esquema.
A adoção deste novo esquema de versionamento é um passo importante para modernizar o ciclo de vida de lançamento do JDK. Ele proporciona a clareza e a flexibilidade necessárias para os futuros lançamentos mais ágeis e previsíveis, beneficiando tanto os mantenedores quanto os usuários finais da plataforma Java.
Esta mudança estabelece uma base sólida para o versionamento do JDK nos próximos anos, alinhando-o com as melhores práticas da indústria.
Depois de lançar a Comunidade OpenJDK como o lugar para colaborar em implementações de código aberto da Plataforma Java SE em 2006, o próximo passo lógico foi disponibilizar o Java SE TCK (JCK) para aqueles que trabalham e contribuem para o OpenJDK. A Sun Microsystems fez isso através do "OpenJDK Community TCK License Agreement" (OCTLA), disponibilizado em 2007 com versões certificadas aparecendo em 2008. A Oracle deu continuidade e expandiu esse programa, lançando um OCTLA para o Java SE 7, outro para o Java SE 8 e, considerando o novo ritmo de lançamentos, um único acordo para o Java SE 9 e versões posteriores. Houve dezenas de signatários nessas versões do Java SE.
O FAQ inicial do OCTLA ainda está disponível aqui. A Oracle continuou a aplicar as tradições e a intenção do programa OCTLA como ele foi originalmente concebido. Ou seja, o OCTLA é para indivíduos e organizações que trabalham e contribuem para a Comunidade OpenJDK, com implementações testadas pelo OCTLA de tais indivíduos e organizações distribuídas apenas sob a licença GPL do código do OpenJDK. Como observado no FAQ, o OCTLA não é para "implementações independentes de padrões de tecnologia Java". Para implementações independentes, a Oracle oferece opções comerciais de JCK, o que ajuda a financiar o desenvolvimento geral do Java. De fato, muitos dos signatários do OCTLA que participam da Comunidade OpenJDK também têm acordos comerciais de JCK para seus produtos e serviços baseados em implementação independente (não-OpenJDK). Alguns exemplos de implementações independentes de padrões de tecnologia Java ao longo do tempo incluem o BEA JRockit e o IBM J9.
A Oracle aplicou consistentemente o espírito e a intenção deste programa de longa data para o benefício da Comunidade OpenJDK, e planeja continuar o programa como vem fazendo desde a aquisição da Sun.
Durante a conferência JavaOne de 2010, foi anunciado que as JVMs Oracle JRockit e HotSpot seriam fundidas, incorporando ao HotSpot as funcionalidades que eram exclusivas do JRockit.
Com o JDK 7, esse trabalho começou a ser entregue, sendo concluído com o JDK 8. Enquanto isso, os clientes que usavam o Oracle JRockit JVM continuaram a receber atualizações de segurança periódicas e correções de bugs.
As versões de CPU (atualizações críticas de patch) e correções de bugs para o Java SE 6 JRockit (apenas R28) continuarão a ser fornecidas até o final da fase de suporte estendido, atualmente programada para dezembro de 2018.
Foi publicado um Guia de Migração para clientes que estão migrando do Oracle JRockit JVM para o HotSpot JVM. Ele fornece informações sobre muitas ferramentas e opções comuns disponíveis para o JRockit e suas equivalentes no HotSpot.
Para os desenvolvedores que ainda utilizam o JRockit em ambientes de produção, este guia é um recurso essencial para planejar a transição para o HotSpot, garantindo continuidade e aproveitando o roadmap unificado do Java na Oracle.
No final de 2015, muitos fornecedores de navegadores removeram ou anunciaram cronogramas para a remoção do suporte a plugins baseados em padrões, eliminando a capacidade de incorporar Flash, Silverlight, Java e outras tecnologias baseadas em plugins.
Com os fornecedores de navegadores modernos trabalhando para restringir e reduzir o suporte a plugins em seus produtos, os desenvolvedores de aplicativos que dependem do plugin Java para navegadores precisam considerar opções alternativas, como migrar de Java Applets (que dependem de um plugin de navegador) para a tecnologia Java Web Start livre de plugins.
Há planos de depreciar o plugin Java do navegador no JDK 9. Essa tecnologia será removida do Oracle JDK e JRE em uma versão futura do Java SE.
As versões de acesso antecipado do JDK 9 estão disponíveis para download e teste. Mais informações e opções de migração podem ser encontradas no artigo técnico da Oracle.
Informações técnicas sobre a etapa de depreciação planejada no JDK 9 podem ser encontradas na JEP 289.
A confiança em certificados emitidos por duas subautoridades de certificação gerenciadas pela Apple será mantida por um período mais longo. As instruções sobre como reativar a confiança nas autoridades de certificação raiz afetadas foram atualizadas.
O JDK da Oracle deixará de confiar em certificados TLS emitidos pela Symantec, alinhando-se a planos semelhantes anunciados recentemente por Google, Mozilla, Apple e Microsoft. A lista de certificados afetados inclui certificados das marcas GeoTrust, Thawte e VeriSign, que eram gerenciados pela Symantec.
A partir das versões de patch crítico planejadas para 16 de abril de 2019, todas as versões suportadas do JDK (12, 11, 8 e 7) começarão a remover a confiança em novos certificados de servidor TLS emitidos pelas autoridades de certificação afetadas.
Informações sobre como substituir certificados Symantec por um certificado DigiCert estão disponíveis na página de suporte da DigiCert.
As novas restrições serão aplicadas na implementação do JDK (o Provedor SunJSSE) da API Java Secure Socket Extension (JSSE). Uma sessão TLS não será negociada se a cadeia de certificados do servidor estiver ancorada por qualquer uma das Autoridades de Certificação listadas na tabela abaixo.
Uma aplicação receberá uma exceção com uma mensagem indicando que a âncora de confiança não é confiável, por exemplo:
TLS Server certificate issued after 2019-04-16 and anchored by a distrusted legacy Symantec root CA: CN=GeoTrust Global CA, O=GeoTrust Inc., C=USSe necessário, é possível contornar as restrições comentando ou removendo "SYMANTEC_TLS" da propriedade de segurança jdk.security.caDistrustPolicies no arquivo de configuração java.security.
# Exemplo: Para desativar a política de desconfiança SYMANTEC_TLS
# jdk.security.caDistrustPolicies=SYMANTEC_TLSAtenção: Esta é uma solução temporária. A ação correta é substituir o certificado.
A restrição será imposta aos seguintes certificados raiz da Symantec incluídos no JDK:
| Nome Distinto (Distinguished Name) | Imprensa Digital (Fingerprint) SHA-256 |
|---|---|
| CN=GeoTrust Global CA, O=GeoTrust Inc., C=US | FF:85:6A:2D:25:1D:CD:88:D3:66:56:F4:50:12:67:98:CF:AB:AA:DE:40:79:9C:72:2D:E4:D2:B5:DB:36:A7:3A |
| CN=GeoTrust Primary Certification Authority, O=GeoTrust Inc., C=US | 37:D5:10:06:C5:12:EA:AB:62:64:21:F1:EC:8C:92:01:3F:C5:F8:2A:E9:8E:E5:33:EB:46:19:B8:DE:B4:D0:6C |
| CN=GeoTrust Primary Certification Authority – G2, OU=(c) 2007 GeoTrust Inc. – For authorized use only, O=GeoTrust Inc., C=US | 5E:DB:7A:C4:3B:82:A0:6A:87:61:E8:D7:BE:49:79:EB:F2:61:1F:7D:D7:9B:F9:1C:1C:6B:56:6A:21:9E:D7:66 |
| CN=GeoTrust Primary Certification Authority – G3, OU=(c) 2008 GeoTrust Inc. – For authorized use only, O=GeoTrust Inc., C=US | B4:78:B8:12:25:0D:F8:78:63:5C:2A:A7:EC:7D:15:5E:AA:62:5E:E8:29:16:E2:CD:29:43:61:88:6C:D1:FB:D4 |
| CN=GeoTrust Universal CA, O=GeoTrust Inc., C=US | A0:45:9B:9F:63:B2:25:59:F5:FA:5D:4C:6D:B3:F9:F7:2F:F1:93:42:03:35:78:F0:73:BF:1D:1B:46:CB:B9:12 |
| CN=thawte Primary Root CA, OU=”(c) 2006 thawte, Inc. – For authorized use only”, OU=Certification Services Division, O=”thawte, Inc.”, C=US | 8D:72:2F:81:A9:C1:13:C0:79:1D:F1:36:A2:96:6D:B2:6C:95:0A:97:1D:B4:6B:41:99:F4:EA:54:B7:8B:FB:9F |
| CN=thawte Primary Root CA – G2, OU=”(c) 2007 thawte, Inc. – For authorized use only”, O=”thawte, Inc.”, C=US | A4:31:0D:50:AF:18:A6:44:71:90:37:2A:86:AF:AF:8B:95:1F:FB:43:1D:83:7F:1E:56:88:B4:59:71:ED:15:57 |
| CN=thawte Primary Root CA – G3, OU=”(c) 2008 thawte, Inc. – For authorized use only”, OU=Certification Services Division, O=”thawte, Inc.”, C=US | 4B:03:F4:58:07:AD:70:F2:1B:FC:2C:AE:71:C9:FD:E4:60:4C:06:4C:F5:FF:B6:86:BA:E5:DB:AA:D7:FD:D3:4C |
| EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA | 3F:9F:27:D5:83:20:4B:9E:09:C8:A3:D2:06:6C:4B:57:D3:A2:47:9C:36:93:65:08:80:50:56:98:10:5D:BC:E9 |
| OU=VeriSign Trust Network, OU=”(c) 1998 VeriSign, Inc. – For authorized use only”, OU=Class 2 Public Primary Certification Authority – G2, O=”VeriSign, Inc.”, C=US | 3A:43:E2:20:FE:7F:3E:A9:65:3D:1E:21:74:2E:AC:2B:75:C2:0F:D8:98:03:05:BC:50:2C:AF:8C:2D:9B:41:A1 |
| OU=Class 3 Public Primary Certification Authority, O=”VeriSign, Inc.”, C=US | A4:B6:B3:99:6F:C2:F3:06:B3:FD:86:81:BD:63:41:3D:8C:50:09:CC:4F:A3:29:C2:CC:F0:E2:FA:1B:14:03:05 |
| OU=VeriSign Trust Network, OU=”(c) 1998 VeriSign, Inc. – For authorized use only”, OU=Class 3 Public Primary Certification Authority – G2, O=”VeriSign, Inc.”, C=US | 83:CE:3C:12:29:68:8A:59:3D:48:5F:81:97:3C:0F:91:95:43:1E:DA:37:CC:5E:36:43:0E:79:C7:A8:88:63:8B |
| CN=VeriSign Class 3 Public Primary Certification Authority – G3, OU=”(c) 1999 VeriSign, Inc. – For authorized use only”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US | EB:04:CF:5E:B1:F3:9A:FA:76:2F:2B:B1:20:F2:96:CB:A5:20:C1:B9:7D:B1:58:95:65:B8:1C:B9:A1:7B:72:44 |
| CN=VeriSign Class 3 Public Primary Certification Authority – G4, OU=”(c) 2007 VeriSign, Inc. – For authorized use only”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US | 69:DD:D7:EA:90:BB:57:C9:3E:13:5D:C8:5E:A6:FC:D5:48:0B:60:32:39:BD:C4:54:FC:75:8B:2A:26:CF:7F:79 |
| CN=VeriSign Class 3 Public Primary Certification Authority – G5, OU=”(c) 2006 VeriSign, Inc. – For authorized use only”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US | 9A:CF:AB:7E:43:C8:D8:80:D0:6B:26:2A:94:DE:EE:E4:B4:65:99:89:C3:D0:CA:F1:9B:AF:64:05:E4:1A:B7:DF |
| CN=VeriSign Universal Root Certification Authority, OU=”(c) 2008 VeriSign, Inc. – For authorized use only”, OU=VeriSign Trust Network, O=”VeriSign, Inc.”, C=US | 23:99:56:11:27:A5:71:25:DE:8C:EF:EA:61:0D:DF:2F:A0:78:B5:C8:06:7F:4E:82:82:90:BF:B8:60:E8:4B:3C |
Se você possui um certificado de servidor TLS emitido por uma das ACs acima, deve ter recebido uma mensagem da DigiCert com informações sobre a substituição desse certificado, sem custo.
Certificados emitidos por duas autoridades de certificação subordinadas gerenciadas pela Apple, identificadas abaixo, continuarão a ser confiáveis desde que emitidos em ou antes de 31 de dezembro de 2019.
| Nome Distinto (Distinguished Name) | Imprensa Digital (Fingerprint) SHA-256 | Data de Desconfiança |
|---|---|---|
| CN=Apple IST CA 2 – G1, OU=Certification Authority, O=Apple Inc., C=US | AC:2B:92:2E:CF:D5:E0:17:11:77:2F:EA:8E:D3:72:DE:9D:1E:22:45:FC:E3:F5:7A:9C:DB:EC:77:29:6A:42:4B | 2019-12-31 |
| CN=Apple IST CA 8 – G1, OU=Certification Authority, O=Apple Inc., C=US | A4:FE:7C:7F:15:15:5F:3F:0A:EF:7A:AA:83:CF:6E:06:DE:B9:7C:A3:F9:09:DF:92:0A:C1:49:08:82:D4:88:ED | 2019-12-31 |
É possível usar a utilitário keytool do JDK para imprimir detalhes da cadeia de certificados, da seguinte forma:
keytool -v -list -alias <seu_alias_de_servidor> -keystore <seu_arquivo_de_keystore>Se algum dos certificados na cadeia for emitido por uma das autoridades de certificação raiz na tabela acima e aparecer na saída, será necessário atualizar o certificado ou entrar em contato com a organização que gerencia o servidor, se não for o seu.
Manter a segurança da infraestrutura de certificados é essencial para a confiança na internet e a proteção de dados.
Com certeza. Conforme acontece há mais de duas décadas, a Oracle mantém o Java gratuito e aberto, fornecendo atualizações de estabilidade, desempenho e segurança para a versão atual, sem custo. A Oracle também continua a fornecer gratuitamente atualizações críticas de patch, agendadas com mais de um ano de antecedência, atualizações adicionais quando necessário e duas atualizações de recursos (que também incluem atualizações críticas de patch) por ano sob o novo ritmo de lançamento.
Todo esse desenvolvimento é feito no OpenJDK, comunidade de código aberto, disponibilizando as contribuições para que qualquer pessoa as porte, analise e use como código aberto. É possível baixar as atualizações mais recentes do Java da Oracle, gratuitamente, sob uma licença de código aberto em jdk.java.net, e para fins de desenvolvimento e teste como o Oracle JDK no OTN.
Após cinco anos de disponibilidade pública, o Java 8 passou pelo "Fim das Atualizações Públicas" no início de 2019 – assim como o Java 5 em 2009, o Java 6 em 2013 e o Java 7 em 2015. A Oracle fornece atualizações gratuitas, previsíveis e agendadas com antecedência, incluindo atualizações de estabilidade, desempenho e segurança das versões atuais em jdk.java.net e OTN. Versões legadas continuam disponíveis e com suporte para clientes Oracle via My Oracle Support, conforme os prazos publicados.
Transições anteriores de "Fim das Atualizações Públicas" (Java 5 em 2009, Java 6 em 2013 e Java 7 em 2015) ocorreram em uma data fixa, para todos os tipos de usuários, ao mesmo tempo.
Conforme anunciado no ano passado, a Oracle estendeu as atualizações públicas para o Java 8 de setembro de 2018 para janeiro de 2019. A Oracle também estendeu ainda mais as atualizações públicas gratuitas do Java 8 para uso pessoal, individual em desktop ou laptop até pelo menos o final de 2020 [Nota: esta data foi estendida indefinidamente; consulte este post para mais informações]. Isso fornece atualizações gratuitas para indivíduos que usam aplicativos do tipo "B2C" que ainda podem usar recursos legados do Java 8 como Applets, Java Web Start e JavaFX (que foram removidos no Java 9 ou versões posteriores). Mais informações sobre este tópico foram publicadas no ano passado. Isso significa que indivíduos que dependem do Java 8 para jogos, bancos pessoais ou outras atividades do tipo consumidor individual em seus computadores desktop ou laptop continuarão recebendo atualizações gratuitas pelo menos até 2020.
Usuários comerciais podem atualizar para uma versão mais recente do Java, disponível gratuitamente pela Oracle, ou considerar uma Java SE Subscription se for importante permanecer em versões mais antigas, como o Java 8.
A Atualização Crítica de Patch do Java 8 (8u201 e a 8u202 Patch Set Update relacionada) agendada para 15 de janeiro de 2019 foi a última atualização disponível sob a licença BCL, que é geralmente gratuita para uso geral em desktop e servidor, e tem sido a licença do Oracle JDK por vários anos. A seguinte atualização do Java 8, agendada para 16 de abril de 2019 (8u211 e a 8u212 Patch Set Update relacionada), foi disponibilizada sob uma nova licença que será gratuita para uso pessoal individual em desktop e gratuita para fins de desenvolvimento, teste, prototipagem e demonstração.
Os lançamentos mais recentes do Java permanecem gratuitos e sob uma licença de código aberto em jdk.java.net, ou gratuitos para licença de desenvolvimento, teste, prototipagem e demonstração no OTN. Java SE Subscriptions estão disponíveis para quem deseja continuar a usar as atualizações do Java 8 disponibilizadas a partir de 16 de abril de 2019 para fins comerciais ou de produção. O Java SE Subscription FAQ tem informações adicionais, incluindo preços.
Sim. Você pode continuar usando qualquer versão do Java sob os termos da licença sob a qual ela foi fornecida. O novo licenciamento para atualizações do Java 8 aplica-se apenas a atualizações lançadas sob a nova licença após janeiro de 2019, começando com a atualização trimestral agendada para 16 de abril de 2019.
Atualizações públicas mais antigas do Java, desde o Java 1.1, estão disponíveis nos Java Archives. Essas versões mais antigas são fornecidas para ajudar os desenvolvedores a depurar problemas em sistemas antigos. Elas não são atualizadas com os patches de segurança mais recentes e não são recomendadas para uso em produção.
Sim. Se você é um Cliente Oracle com um produto Oracle suportado que requer Java SE, você continua a ter acesso às atualizações do Oracle Java, conforme exigido pelo seu produto Oracle, para o uso de produtos Oracle suportados, sem custo adicional. Consulte esta nota do My Oracle Support (MOS) para obter mais informações (requer login).
O mecanismo de atualização do Java rotineiramente recomenda a remoção de versões mais antigas após concluir uma atualização, para manter seu sistema limpo.
A partir de janeiro de 2019, o mecanismo de atualização automática também pode detectar se você não usou o Java em seu computador por seis meses ou mais e, nesse caso, pode oferecer a remoção em vez da atualização do Java. Clientes que instalaram o Java a partir do Oracle eDelivery ou My Oracle Support não devem ver essas mensagens. Se você desinstalar o Java acidentalmente e decidir mais tarde que precisava dele, sempre poderá reinstalá-lo visitando java.com/download ou através de seus canais de suporte e distribuição ao cliente Oracle.
As respostas às perguntas frequentes acima se aplicam a ISVs e àqueles que usam Java para uso interno. ISVs que precisam permitir que seus usuários escolham qual versão do Java usar para executar seu software podem seguir a abordagem de suportar tanto a versão mais recente do Java fornecida gratuitamente pela Oracle quanto as versões mais antigas do Oracle Java disponíveis por meio do Java SE Subscription. ISVs que incorporam o Java em seus aplicativos podem escolher os lançamentos gratuitos de código aberto em jdk.java.net ou entrar em contato com a Oracle para distribuir atualizações do Oracle JDK.
Informações adicionais e as últimas atualizações estão disponíveis nos canais oficiais do Java.
Está previsto para 14 de outubro o lançamento da atualização de patch crítico (CPU), conforme o cronograma regular para o Oracle Java SE.
Para o Oracle Java SE 8, a versão será a 8u25. Agora, há um incentivo para que todos os usuários de Java façam o download e utilizem a versão de atualização mais recente do Java SE 8. Com este lançamento, o Java SE 8 está pronto para se tornar a versão padrão no Java.com, e, como mencionado anteriormente, o processo de atualização automática dos usuários para o Java SE 8 terá início no começo de 2015.
Para o Oracle Java SE 7, haverá dois lançamentos voltados para públicos diferentes:
Para obter informações mais detalhadas sobre a diferença entre CPU e PSU, consulte o artigo "Java CPU and PSU Releases Explained" disponível na OTN.
Após o lançamento do Java 9 em 2017, o ritmo de lançamentos da plataforma Java mudou de uma versão principal a cada 3+ anos para uma versão com novos recursos a cada seis meses. Isso fornece aos desenvolvedores um acesso mais previsível a melhorias contínuas. As versões com novos recursos agora ocorrem de forma confiável em março e setembro de cada ano. Chega de tentar gerenciar centenas de mudanças a cada dois anos de uma só vez – em vez disso, a mudança é entregue em um ritmo mais granular, rápido e gerenciável.
A Oracle agora oferece o Java 12 para empresas e desenvolvedores. O JDK 12 receberá, no mínimo, duas atualizações, de acordo com o cronograma de CPU da Oracle, antes de ser seguido pelo Oracle JDK 13, previsto para setembro de 2019.
A Oracle fornece o Java 12 como a versão Oracle OpenJDK usando a licença de código aberto GNU General Public License v2, com a Classpath Exception (GPLv2+CPE), e também sob uma licença comercial para quem usa a versão Oracle JDK como parte de um produto ou serviço Oracle, ou que não deseja usar software de código aberto.
Semelhante ao Java 11, vale a pena celebrar as contribuições feitas para o Java 12 por muitos indivíduos e organizações na Comunidade OpenJDK — todos nós construímos o Java, juntos!
A taxa geral de mudança no JDK ao longo do tempo permaneceu essencialmente constante por muitos anos, mas, sob o ritmo de seis meses, a velocidade na qual as inovações são entregues aos desenvolvedores melhorou muito. Em vez de disponibilizar dezenas de milhares de correções e cerca de cem JEPs em uma grande versão principal a cada poucos anos, os aprimoramentos são disponibilizados em versões de recursos menores em um cronograma previsível e mais gerenciável de seis meses. Essas mudanças podem variar de um recurso significativo a pequenas melhorias, manutenção de rotina, correções de bugs e melhorias na documentação. Cada uma dessas alterações é representada em um único commit para um único problema no JDK Bug System.
Dos 1.919 problemas do JIRA marcados como corrigidos no JDK 12, 1.433 foram concluídos por pessoas que trabalham para a Oracle, enquanto 486 foram contribuições de desenvolvedores individuais e desenvolvedores que trabalham para outras organizações. Analisar os problemas e compilar os dados da organização dos responsáveis resulta no seguinte gráfico de organizações que patrocinam o desenvolvimento de correções no JDK 12:
Embora os desenvolvedores empregados pela Oracle tenham resolvido 75% dos problemas do JIRA durante o desenvolvimento do JDK 12, 25% foram corrigidos por desenvolvedores que trabalham para outras organizações. Desenvolvedores que trabalham para as cinco próximas maiores organizações contribuintes, Red Hat (8%), Google (6%), SAP (4%), BellSoft (1%) e IBM (1%), corrigiram coletivamente 20% desses problemas. Desenvolvedores independentes contribuíram com 3% das correções no JDK 12.
Por último, mas não menos importante, os dois por cento restantes das correções foram contribuídos coletivamente por desenvolvedores de uma ampla gama de organizações, incluindo Alibaba, Amazon, ARM, Azul, Huawei, Intel, JetBrains, Linaro e Twitter.
Agradecimentos especiais também aos muitos desenvolvedores experientes que revisaram as mudanças propostas, aos primeiros usuários que testaram as compilações de acesso antecipado e relataram problemas, e aos profissionais dedicados que forneceram feedback nas listas de e-mail do OpenJDK.
Oito melhorias são entregues com o Java 12:
Estende a instrução switch para que possa ser usada como uma instrução ou uma expressão, e que ambas as formas possam usar um comportamento de escopo e fluxo de controle "tradicional" ou "simplificado". Essas mudanças simplificarão a codificação do dia a dia e também prepararão o caminho para o uso de correspondência de padrões (JEP 305) no switch. Para o JDK 12, esse recurso está disponível como um recurso de linguagem de visualização (JEP 12).
Torna as coletas mistas do G1 abortáveis se elas excederem o alvo de pausa.
Aprimora o coletor de lixo G1 para retornar automaticamente a memória do heap Java para o sistema operacional quando ociosa.
Adiciona um novo algoritmo de coleta de lixo (GC) que reduz os tempos de pausa do GC fazendo o trabalho de evacuação simultaneamente com os threads Java em execução.
Adiciona um conjunto básico de microbenchmarks ao código-fonte do JDK e facilita para os desenvolvedores executar microbenchmarks existentes e criar novos.
Introduz uma API para modelar descrições nominais de artefatos principais de arquivo de classe e tempo de execução, em particular constantes que podem ser carregadas do pool de constantes.
Remove todas as fontes relacionadas à porta arm64, mantendo a porta ARM de 32 bits e a porta aarch64 de 64 bits.
Aprimora o processo de construção do JDK para gerar um arquivo de compartilhamento de dados de classe (CDS), usando a lista de classes padrão, em plataformas de 64 bits.
Com 12 milhões de desenvolvedores em todo o mundo, o Java continua sendo a linguagem de programação nº 1 de escolha dos programadores de software. E como a entrega pontual de melhorias com o Java 12 demonstra, por meio de um planejamento contínuo e cuidadoso e envolvimento do ecossistema, a plataforma Java está bem posicionada para o desenvolvimento moderno e crescimento na nuvem.
No dia a dia, o Japão usa o mesmo calendário que a maior parte do mundo, no qual estamos atualmente no ano de 2019 (da era comum). Para documentos oficiais e formais, o calendário japonês usa o mesmo dia e mês, mas um nome de era e anos dentro dessa era, em vez do ano da era comum. A era japonesa atual é Heisei (平成) e o ano de 2019 corresponde a Heisei 31.
No Japão moderno, uma era começa com a ascensão de um novo imperador e dura até a ascensão do próximo imperador. Por exemplo, a era 明治 Meiji durou até 30 de julho de 1912 (30 de julho Meiji 45). A era seguinte, 大正 Taishō, começou em 31 de julho de 1912 com a ascensão do Imperador Taishō. A primeira data seria 31 de julho Taishō 1, exceto que o primeiro ano de novas eras é sempre referido como 元年 (Gan-nen). Seria escrito como “31 de julho 大正元年” (Taishō Gan-nen).
Em 2016, o Imperador Akihito anunciou planos de abdicar do trono em favor de seu filho, o Príncipe Herdeiro Naruhito. O plano era abdicar em 30 de abril de 2019 (30 de abril Heisei 31). O nome da nova era, que começaria em 1º de maio de 2019, seria anunciado pelo gabinete japonês em 1º de abril de 2019.
Foram necessários alguns preparativos para a nova era, mas atualizações finais só poderiam ser concluídas após o anúncio oficial do nome da nova era. No JDK, especificamente, algumas mudanças foram planejadas:
A partir do JDK 8, as APIs Java possuem uma nova Data Time API (consulte o JSR 310), além da classe mais antiga java.util.Calendar, com métodos para manipular datas. Todas as APIs relevantes seriam atualizadas para lidar corretamente com a nova era.
Em preparação para as mudanças, o JDK 12 usaria um nome provisório para a nova era: 元号 (“NewEra”). Usando o JDK 12, seria possível ter uma ideia de como o nome da nova era seria tratado nas atualizações lançadas após o anúncio do nome.
Após o lançamento do nome da nova era, com a próxima atualização (planejada para 16 de abril de 2019), todas as versões suportadas do JDK: 7, 8, 11 LTS e 12 seriam atualizadas para lidar com a nova era.
Em todas as versões suportadas, a classe java.util.Calendar seria atualizada para entender e retornar os valores corretos.
import java.util.*;
import java.text.*;
new SimpleDateFormat("GGGGyyyy年M月d日", Locale.forLanguageTag("ja-JP-u-ca-japanese")).
format(new Calendar.Builder().
setDate(2019, Calendar.MAY, 1).build().getTime());
// Antes da atualização: 平成31年5⽉1⽇
// Depois da atualização: 元号元年5⽉1⽇
// Nas versões lançadas após o novo anúncio, 元号 será substituído pelo novo nome da era.A análise de uma data usando java.text.SimpleDateFormat funcionaria corretamente:
import java.text.*;
var sdf = new SimpleDateFormat("GGGGyyyy年M⽉d⽇",
Locale.forLanguageTag("ja-JP-u-ca-japanese"));
sdf.setLenient(false);
new SimpleDateFormat("Y-M-d", Locale.US).format(sdf.parse("元号2年2⽉1⽇"));
// Resultado: “2020-2-1”
// Com 元号 substituído pelo novo nome da eraPara JDK 8 e posteriores, as novas APIs de data e hora JSR 310 também seriam atualizadas (JDK 7 não possui essas novas APIs).
import java.time.chrono.*;
import java.time.format.*;
import java.time.temporal.*;
DateTimeFormatter.ofPattern("GGGGy年M⽉d⽇").
withChronology(JapaneseChronology.INSTANCE).
withLocale(Locale.JAPAN).
format(JapaneseDate.of(2020, 2, 1));
// Resultado: “元号2年2⽉1⽇”DateTimeFormatter.ofPattern("u-M-d").format(
DateTimeFormatter.ofPattern("GGGGy年M⽉d⽇").
withChronology(JapaneseChronology.INSTANCE).
withLocale(Locale.JAPAN).
withResolverStyle(ResolverStyle.STRICT).
parse("元号2年2⽉1⽇"));
// Resultado: “2020-2-1”JapaneseEra.of(3).getDisplayName(TextStyle.FULL,
Locale.forLanguageTag("ja-JP-u-ca-japanese"));
// Resultado: “元号”
// Com 元号 substituído pelo novo nome da eraNo JDK 8 e posterior, o ponto de código Unicode U+32FF também seria incluído na classe java.lang.Character. O ponto de código U+32FF é reservado para o caractere quadrado da nova era japonesa.
Em resumo:
(*) Devido a um problema na análise de uma data em formato de string, seria necessário aguardar as atualizações do JDK de abril de 2019 para que a análise funcionasse corretamente.