Alterações da release 8 do Java

Destaques da Release 8 do Java

Este artigo aplica-se a:

Plataforma(s): Nenhuma
Versão(ões) do Java: Nenhuma
Java version(s): 8.0

Esta página destaca alterações que impactam usuários finais para cada release do Java. Mais informações sobre alterações podem ser encontradas nas notas de cada release.
» Datas de release do Java

Java 8 Update 441 (8u441)

Destaques da Release

O JDK 8u441 contém dados de fuso horário da IANA 2024b.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
O JavaFX Não Será Mais Incluído no JDK/JRE 8
Esta release, JDK e JRE 8 Update 441, é a última release do pacote JavaFX. Conforme anunciado em 2020, o suporte para o JavaFX no JDK 8, a última versão com suporte comercial da Oracle para o JavaFX, se encerrará em março de 2025. Sendo assim, o JDK 8 Update 441 é o último upgrade do JDK/JRE 8 com JavaFX. A Oracle continua a desenvolver e lançar o JavaFX na forma de módulos stand-alone por meio do projeto OpenJFX para as versões mais recentes apenas do Java. Para ver mais detalhes, consulte o Java SE Spring 2024 Roadmap Update.
Outras Observações: O suporte para o Banco de Dados de Fuso Horário 2024b
Foi feito o upgrade do Banco de Dados de Fuso Horário IANA para a versão 2024b. Essa versão inclui, principalmente, alterações para aprimorar dados históricos de México, Mongólia e Portugal. Ela também altera uma abreviação de timestamp, pra o fuso horário 'MET'. Além disso, Ásia/Choibalsan agora é um alias para Ásia/Ulan Bator.
Consulte JDK-8339637

Mantendo o JDK atualizado

A Oracle recomenda que o JDK seja atualizado com cada Atualização Crítica de Patch. Para determinar se uma release é a mais recente, a página Linha de Base de Segurança pode ser usada para determinar qual é a versão mais recente de cada família de releases.

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendável que esse JDK (versão 8u441) seja usado após a próxima atualização crítica de patch programada para 15 de abril de 2025.

O Java Management Service, disponível para todos os usuários, pode ajudar a encontrar versões do Java vulneráveis em seus sistemas. Assinantes do Java SE e clientes executados no Oracle Cloud podem usar o Java Management Service para atualizar Java Runtimes e fazer análises de segurança mais detalhadas, como identificar bibliotecas de terceiros potencialmente vulneráveis usadas pelos seus programas Java. Usuário do Java Management Service existente, clique aqui para fazer log-in no seu painel de controle. A Documentação do Java Management Service fornece uma lista de recursos disponíveis a todos e de recursos exclusivos de apenas alguns clientes. Saiba mais sobre o uso do Java Management Service para monitorar e proteger suas Instalações do Java.

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u441) em 15-05-2025. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Esta release contém também correções para vulnerabilidades de segurança descritas no Oracle Critical Patch Update. Para obter uma lista mais completa das correções de bug incluídas nesta release, consulte Notas da release 8u441.

Java 8 Update 431 (8u431)

Destaques da Release

O JDK 8u431 contém dados de fuso horário da IANA 2024a.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Problemas Notáveis Resolvidos: Upgrade do JDK RPM Deixa Entrada de Alternativas para Órfãos
Corrigido o problema com entradas nos grupos "java" e "javac" que não eram gerenciadas adequadamente durante um upgrade do RPM.
O upgrade de um Java RPM mais antigo instalado em um diretório compartilhado (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) para um Java RPM instalando-o em um diretório específico da versão (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}), resulta no fato de as entradas Java mais antigas nos grupos "java" e "javac" não serem excluídas.
JDK-8336107 (não público)
Outras Observações: Novos Limites Padrão nas Implementações do cliente HTTP do JDK
Novos limites padrão foram adicionados ao HTTP no JDK.
A implementação incorporada no JDK do handler de protocolo URL para o HTTP (HttpURLConnection) agora tem um limite padrão sobre o tamanho máximo de cabeçalhos de resposta que serão aceitos de uma parte remota. O limite é definido por padrão em 384 kB (393.216 bytes) e é calculado como o tamanho cumulativo de todos os nomes de cabeçalho e valores de cabeçalho mais um overhead de 32 bytes por par nome/valor do cabeçalho.
JDK-8328286 (não público)
Outras Observações: Foram Adicionados Certificados Raiz da CA SSL.com TLS Emitidos em 2022
Os seguintes certificados raiz foram adicionados ao armazenamento confiável cacerts:
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
See JDK-8341057
Outras Observações: Certificados de Servidor TLS Suspeitos Ancorados por Certificados Raiz Entrust e Emitidos após 11 de novembro de 2024
O JDK interromperá o endosso de certificados de servidor TLS emitidos após 11 de novembro de 2024 e ancorados por certificados raiz Entrust, de forma alinhada com planos similares recém-anunciados pelo Google e pelo Mozilla. A lista de certificados afetados inclui certificados com a marca AffirmTrust, que são gerenciados pela Entrust.
Consulte JDK-8337664

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendável que este JDK (versão 8u431) seja usado após a próxima atualização de patch crítico programada para 21 de janeiro de 2025.

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u431) em 21-02-2025. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Java 8 Update 421 (8u421)

Destaques da Release

O JDK 8u421 contém dados de fuso horário da IANA 2024a.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Problema Conhecido: Uso de Armazenamento de Chaves do Browser no Windows
No Windows, quando o recurso "Usar certificados e chaves do armazenamento de chaves do browser" está ativado (o que é o padrão), o Java WebStart e o Plugin Java podem acessar os certificados que no momento são confiáveis na máquina local. Não há garantia de que a lista completa de certificados confiáveis esteja disponível, pois os certificados são carregados dinamicamente. Como resultado, os applets Java e aplicativos Java WebStart podem passar por problemas de validação de assinatura e conexão segura causados por uma falta de certificados relevantes, pois a estrutura de Implantação só pode acessar os certificados que estejam 'ativos' no momento da inicialização do aplicativo.
JDK-8330728 (não público)
Outras Observações: Adicionando o Argumento STATIC=1 ao Instalador do JRE
Essa correção adiciona o argumento do instalador STATIC=1 e descontinua o argumento do instalador RETAIN_ALL_VERSIONS=1. A especificação de STATIC=1 protege versões do JRE 8 mais antigas de serem desinstaladas durante um upgrade manual ou uma atualização automática.
JDK-8313223 (não público)
Outras Observações: Certificados de CA Raiz GlobalSign R46 e E46 Adicionados
Os seguintes certificados raiz foram adicionados ao armazenamento confiável cacerts:
+ GlobalSign + globalsignr46 DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE + GlobalSign + globalsigne46 DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
Consulte JDK-8316138
Outras Observações: O Instalador Criará um Diretório de Junção em um Novo Local
O JRE será instalado no local a seguir: C:\Program Files\Java\latest\jre-$fullversion, em que $fullversion é a versão técnica do JRE. Por exemplo, a versão 8u421 será instalada em C:\Program Files\Java\latest\jre-1.8.0_421.

"C:\Program Files" será ajustado para "C:\Program Files (x86)" para Java de 32 bits.

Uma junção será criada em C:\Program Files\Java\latest\jre-1.8. Ela apontará para o JRE mais recente da família 8.
JDK-8329700 (não público)

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u421) seja usado após a próxima atualização crítica de patch programada para 15 de outubro de 2024.

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u421) em 15-11-2024. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Java 8 Update 411 (8u411)

Destaques da Release

O JDK 8u411 contém dados de fuso horário da IANA 2024a.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Novo Recurso: Foram adicionados os Certificados Raiz Certainly R1 e E1
Os seguintes certificados raiz foram adicionados ao armazenamento confiável cacerts:+ Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US + Certainly + certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US
Consulte JDK-8321408
Novo Recurso: Ativar Modo de Validação Segura de Assinatura XML por Padrão
O modo de validação segura de Assinatura XML foi ativado por padrão (anteriormente, ele não era ativado por padrão a menos que estivesse em execução com um gerenciador de segurança). Quando ativada, a validação de assinaturas XML está sujeita a uma verificação mais rígida de algoritmos e outras restrições, conforme especificado pela propriedade de segurança jdk.xml.dsig.secureValidationPolicy.
Se necessário, e por sua própria conta e risco, os aplicativos podem desativar o modo definindo a propriedade org.jcp.xml.dsig.secureValidation como Boolean.FALSE com a API DOMValidateContext.setProperty().
Consulte JDK-8259801

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u411) seja usado após a próxima atualização de patch crítico programada para 16 de julho de 2024.

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u411) em 16-08-2024. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Java 8 Update 401 (8u401)

Destaques da Release

O JDK 8u401 contém dados de fuso horário da IANA 2023c.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Nova Propriedade do Sistema para Alternar o Modo de Validação Segura de Assinatura XML
Uma nova propriedade do sistema chamada org.jcp.xml.dsig.secureValidation foi adicionada. Ela pode ser usada para ativar ou desativar o modo de validação segura de Assinatura XML. A propriedade do sistema deve ser definida como "true" para ativar ou "false" para desativar. Qualquer outro valor para a propriedade do sistema é tratado como "false". Se a propriedade do sistema for definida, ela substituirá o valor da propriedade XMLCryptoContext. O modo de validação segura será ativado por padrão se você estiver executando o código com um SecurityManager; caso contrário, será desativado por padrão.
Consulte JDK-8301260
Nova Funcionalidade: Evento do JDK Flight Recorder para Desserialização
Um novo evento do JDK Flight Recorder (JFR) foi adicionado para monitorar a desserialização de objetos. Quando o JFR for ativado e a configuração dele incluir eventos de desserialização, ele emitirá um evento sempre que o programa em execução tentar desserializar um objeto. O evento de desserialização é chamado java/deserialization e é desativado por padrão. O evento de desserialização contém informações que são criadas pelo mecanismo de filtro de serialização. Além disso, se um filtro for ativado, o evento do JFR indicará se o filtro aceitou ou rejeitou a desserialização do objeto.
Consulte JDK-8261160

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendável que esse JDK (versão 8u401) seja usado após a próxima atualização crítica de patch programada para 16 de abril de 2024.

Os clientes dos produtos de Assinatura do Java SE que gerenciam atualizações/instalações do JRE para muitos desktops devem considerar o uso do Java Management Service (JMS).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u401) em 16-05-2024. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Java 8 Update 391 (8u391)

Destaques da Release

O JDK 8u391 contém dados de fuso horário da IANA 2023c.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Novo Evento do JFR: jdk.SecurityProviderService
Um novo evento do JFR (Java Flight Recorder) foi adicionado para registrar detalhes de chamadas java.security.Provider.getService(String type, String algorithm).
ConsulteJDK-8254711
Funcionalidade Removida: Foi Removido o Certificado Raiz RootCA1 do SECOM Trust System
O seguinte certificado raiz do SECOM Trust System foi removido do armazenamento de chaves cacerts:
+ alias name "secomscrootca1 [jdk]" Distinguished Name: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
Consulte JDK-8295894
Funcionalidade Removida: Remoção do Suporte ao Linux ARM32 para JDK 8
O suporte à plataforma para o Linux ARM32 no JDK 8 foi removido. Como resultado, o download do ARM32 Hard Float ABI não estará disponível. Os Sistemas Operacionais com suporte à arquitetura ARM32 chegaram ao fim de sua vida útil. Portanto, não há suporte conhecido disponível para o SO.
JDK-8305927 (não público)
Outras Observações: Foi Adicionado o Certificado da Autoridade de Certificação Raiz Certigna
O seguinte certificado raiz foi adicionado ao armazenamento confiável cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR
Consulte JDK-8314960

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendável que este JDK (versão 8u391) seja usado após a próxima atualização de patch crítico programada para 16 de janeiro de 2024.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u391) em 16-02-2024. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte a Data de Vencimento do JRE 23.1.2 no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Esta release contém também correções para vulnerabilidades de segurança descritas no Oracle Critical Patch Update. Para obter uma lista completa das correções de bug incluídas nesta release, consulte Notas da release do 8u391.

Java 8 Update 381 (8u381)

Destaques da Release

O JDK 8u381 contém dados de fuso horário da IANA 2023c.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Permitir Caracteres Adicionais para Suporte a GB18030-2022
O órgão regulador de padrões China National Standard (CESI) publicou recentemente o Padrão GB18030-2022, que é uma versão atualizada do padrão GB18030 e coloca este último em sintonia com o Unicode versão 11.0. A implementação do Conjunto de caracteres deste novo padrão agora substitui o padrão de 2000 anterior. Porém, esse novo padrão tem algumas alterações incompatíveis em relação à implementação anterior. Para quem precisa usar os mapeamentos antigos, uma nova propriedade do sistema, jdk.charset.GB18030, foi introduzida. Definindo seu valor para 2000, são usados os mapeamentos para o Conjunto de caracteres GB18030 das releases anteriores do JDK, os quais se baseiam no padrão de 2000.
ConsulteJDK-8307229
JDK Agora Aceita Chaves RSA no Formato PKCS n.º 1
As chaves RSA privadas e públicas no formato PKCS n.º 1 agora podem ser aceitas por provedores de JDK, como a RSA KeyFactory.impl do provedor SunRsaSign. O objeto de chave RSA privada ou pública deve ter o formato PKCS n.º 1 e uma codificação correspondente à sintaxe ASN.1 para uma chave privada e uma chave pública RSA PKCS n.º 1.
ConsulteJDK-8023980
Outras Observações: Suporte a Cgroup v2 e Aperfeiçoamentos no 8u381
O JDK 8u381 inclui vários aperfeiçoamentos e correções para melhorar o suporte a cgroup v1 e v2 para contêineres. Os aperfeiçoamentos incluem a detecção precisa dos limites de contêineres do recurso, o relatório correto das métricas do contêiner coletadas, a impressão de informações adicionais sobre o contêiner e a melhoria da estabilidade do aplicativo em ambientes conteinerizados.
ConsulteJDK-8307634
Outras Observações: Certificado-Raiz de CA TWCA Adicionado
O seguinte certificado-raiz foi adicionado ao armazenamento confiável cacerts:
+ TWCA + twcaglobalrootca DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW
ConsulteJDK-8305975
Outras Observações: 4 Certificados-Raiz de CA GTS Adicionados
Os seguintes certificados-raiz foram adicionados ao armazenamento confiável cacerts:
+ Google Trust Services LLC + gtsrootcar1 DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootcar2 DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar3 DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar4 DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US
ConsulteJDK-8307134
Outras Observações: 2 Certificados-Raiz de CA TLS da Microsoft Corporation Adicionados
Os seguintes certificados-raiz foram adicionados ao armazenamento confiável cacerts:
+ Microsoft Corporation + microsoftecc2017 DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US + Microsoft Corporation + microsoftrsa2017 DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US
ConsulteJDK-8304760

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u381) seja usado após a próxima atualização crítica de patch programada para 17 de outubro de 2023.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u381) em 17 de novembro de 2023. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Java 8 Update 371 (8u371)

Destaques da Release

O JDK 8u371 contém dados de fuso horário da IANA 2022g.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Foi adicionada uma Biblioteca GSS-API Nativa Padrão no Windows
Uma biblioteca GSS-API nativa foi adicionada ao JDK na plataforma Windows. A biblioteca se destina apenas ao cliente e usa as credenciais padrão. Ela será carregada quando a propriedade do sistema sun.security.jgss.native estiver definida como "true". Um usuário ainda pode carregar uma biblioteca GSS-API nativa de terceiros definindo a propriedade do sistema sun.security.jgss.lib para seu caminho.
Consulte JDK-6722928
Funcionalidades e Opções Removidas:Implementação do Mecanismo javax.script e com.apple.concurrent.Dispatch Foram Removidos para o macOS AArch64
O mecanismo AppleScript que implementa a API do mecanismo javax.script foi removido sem substituição. O mecanismo AppleScript tem funcionado de modo inconsistente. O arquivo de configuração dos serviços (META-INF/services) estava ausente e só funcionava por acidente ao instalar o JDK 7 ou o JDK 8 em sistemas que já tinham a versão para Apple do arquivo AppleScriptEngine.jar no sistema.
A API com.apple.concurrent.Dispatch era uma API somente para Mac. Ele foi transferido para o JDK 7u4 com a porta do código JDK 6 da Apple. Incentivamos os desenvolvedores a usar em seu lugar as APIs padrão java.util.concurrent.Executor e java.util.concurrent.ExecutorService.
Consulte JDK-8297475
Outras Observações: Foi Adicionado o Certificado da Autoridade de Certificação Raiz Certigna(Dhimyotis)
O seguinte certificado raiz foi adicionado ao armazenamento confiável cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna, O=Dhimyotis, C=FR
Consulte JDK-8245654
Outras Observações: SSLv2Hello e SSLv3 Removidos dos Protocolos TLS Ativados Padrão
SSLv2Hello e SSLv3 foram removidos dos protocolos TLS ativados padrão.

Após essa atualização, se SSLv3 for removido da propriedade de segurança jdk.tls.disabledAlgorithms, as APIs SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() e SSLParameters.getProtocols() retornarão "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" não será retornado nessa lista.
Se um cliente ou servidor ainda precisar usar o protocolo SSLv3, eles poderão fazer isso ativando-o por meio das propriedades do sistema jdk.tls.client.protocols ou jdk.tls.server.protocols ou com as APIs SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() e SSLEngine.setEnabledProtocols().
Consulte JDK-8190492

Mantendo o JDK atualizado

A Oracle recomenda que o JDK seja atualizado com cada Atualização Crítica de Patch. Use a página Linha de Base de Segurança para determinar a versão mais recente para cada família de release.

Atualizações de patch crítico, que contêm correções de vulnerabilidade na segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado usar este JDK (versão 8u371) após a próxima atualização de patch crítico, programada para 18 de julho de 2023.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Servidores Oracle, um mecanismo secundário vai expirar este JRE (versão 8u371) em 18 de agosto de 2023. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Java 8 Update 361 (8u361)

Destaques da Release

O JDK 8u361 contém dados de fuso horário da IANA 2022d, 2022e e 2022f.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Suporte para RSASSA-PSS na Resposta do OCSP
Agora há suporte para uma resposta do OCSP assinada com o algoritmo RSASSA-PSS.
Consulte JDK-8274471
Outras Observações: Mecanismo JavaScript FXML Desativado por Padrão
O “mecanismo de script JavaScript” para FXML agora é desativado por padrão. Nenhum arquivo .fxml que tiver uma Instrução de Processamento (PI) "javascript" será mais carregado por padrão e uma exceção será emitida.
Para ativá-lo, defina a propriedade de sistema: -Djavafx.allowjs=true
JDK-8294779 (não público)
Outras Observações: Tratamento Incorreto de Argumentos entre aspas no ProcessBuilder
O ProcessBuilder no Windows é restaurado para tratar uma regressão causada pelo JDK-8250568. Anteriormente, um argumento para o ProcessBuilder que começasse com aspas duplas e terminasse com uma barra invertida seguida por aspas duplas era informado para um comando incorretamente e podia causar falha no comando. Por exemplo, o argumento "C:\\Program Files\" seria visto pelo comando com aspas duplas a mais. Esta atualização restaura o antigo comportamento que não trata a barra invertida antes da aspa dupla final especialmente.
Consulte JDK-8282008
Outras Observações: Tornar Configurável o Timeout de Keep Alive Padrão do HttpURLConnection
Foram adicionadas duas propriedades de sistema que controlam o comportamento de keep alive do HttpURLConnection caso o servidor não especifique um tempo de keep alive. Duas propriedades são definidas para controlar conexões com servidores e proxies separadamente. São elas http.keepAlive.time.server e http.keepAlive.time.proxy respectivamente. Mais informações sobre elas poderão ser encontradas em Propriedades de Rede.
Consulte JDK-8278067
Outras Observações:A ferramenta VisualVM não faz mais parte do pacote
Essa versão do JDK não inclui mais uma cópia do Java VisualVM. O VisualVM agora está disponível como outro download em https://visualvm.github.io.
Consulte JDK-8294184

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendável que este JDK (versão 8u361) seja usado após a próxima atualização crítica de patch programada para 18 de abril de 2023.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Servidores Oracle, um mecanismo secundário vai expirar este JRE (versão 8u361) em 18 de maio de 2023. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Java 8 Update 351 (8u351)

Destaques da Release

Dados de Fuso Horário da IANA 2022b, 2022c.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Outras Observações: Foi feito upgrade do algoritmo PKCS12 do MAC
O algoritmo de criptografia MAC usado em um armazenamento de chaves PKCS #12 foi atualizado. O novo algoritmo se baseia no SHA-256 e é mais forte do que o antigo, baseado no SHA-1. Para obter informações detalhadas, consulte as propriedades de segurança, começando com keystore.pkcs12, no arquivo java.security
ConsulteJDK-8267880
Outras Observações: JARs Assinados Usando SHA-1 Desativados
JARs assinados com algoritmos SHA-1 agora são restritos por padrão e tratados como se não fossem assinados. Essa regra se aplica aos algoritmos usados para digestão, assinatura e, opcionalmente, timestamp do JAR. Ela também se aplica aos algoritmos de assinatura e resumo dos certificados na cadeia de certificados do assinador de código e da Autoridade de Timestamp, e a quaisquer respostas de CRLs ou do OCSP que sejam usadas para verificar se esses certificados foram revogados. Essas restrições também se aplicam a provedores de JCE assinados.
Consulte JDK-8269039
Outras Observações: Descontinuação do 3DES e do RC4 no Kerberos
Os tipos de criptografia (etypes) des3-hmac-sha1 e rc4-hmac do Kerberos agora estão obsoletos e desativados por padrão. Os usuários podem definir allow_weak_crypto = true no arquivo de configuração krb5.conf para reativá-los (juntamente com outros etypes fracos, incluindo des-cbc-crc e des-cbc-md5), por sua própria conta e risco. Para desativar um subconjunto dos etypes fracos, os usuários podem listar etypes preferenciais explicitamente em qualquer uma das definições default_tkt_enctypes, default_tgs_enctypes ou permitted_enctypes.
Consulte JDK-8139348

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendável que este JDK (versão 8u351) seja usado após a próxima atualização de patch crítico programada para 17 de janeiro de 2023.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u351) em 17 de fevereiro de 2023. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

» Notas da release 8u351

Java 8 Update 341 (8u341)

Destaques da Release

Dados de Fuso Horário da IANA 2022a.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Suporte a Binding de Canal HTTPS para Java GSS/Kerberos
Foi adicionado o suporte para tokens de binding de canal TLS para autenticação Negotiate/Kerberos por HTTPS por meio de javax.net.HttpsURLConnection.

Os tokens de binding do canal são cada vez mais exigidos como uma forma avançada de segurança. Eles funcionam por meio da comunicação de um cliente a um servidor do entendimento do cliente quanto ao binding entre a segurança da conexão (conforme representado por um certificado de servidor TLS) e credenciais de comunicação de nível mais alto (como um nome de usuário e uma senha). O servidor pode então detectar se o cliente foi enganado por um MITM (ataque 'man-in-the-middle') e fazer shutdown da sessão/conexão.
Consulte JDK-8279842
Nova Funcionalidade: Ativar TLSv1.3 por Padrão no JDK 8u para Atribuições de Cliente
A implementação do TLSv1.3 está disponível no JDK 8u a partir de 8u261 e é ativada por padrão para atribuições de servidor, mas desativada por padrão para atribuições de cliente. Dessa release em diante, o TLSv1.3 agora também é ativado por padrão para atribuições de cliente. Você pode encontrar mais detalhes na seção Additional Information do Oracle JRE and JDK Cryptographic Roadmap.
Consulte JDK-8245263
Outras Observações:Atualizar java.net.InetAddress para Detectar Literais de Endereço IPv4 Ambíguos
A classe java.net.InetAddress foi atualizada para aceitar estritamente literais de endereço IPv4 em notação decimal com precisão quádrupla. Os métodos da classe InetAddress são atualizados para gerar uma java.net.UnknownHostException para literais de endereço IPv4 inválidos. Para desativar essa verificação, a nova propriedade "jdk.net.allowAmbiguousIPAddressLiterals" do sistema pode ser definida como "true".
Consulte JDK-8277608 (não público)
Outras Observações:Extensões do Pacote JDK Truncadas Durante o Download Usando o Firefox 102
No oracle.com e no java.com, certas extensões do pacote JDK estão ficando truncadas durante o download quando se usa o Firefox versão 102. Os pacotes baixados não têm extensão de arquivo como ".exe", ".rpm" ou ".deb". Se você não conseguir fazer o upgrade para o Firefox ESR 102.0.1 ou o Firefox 103 quando ele for lançado, como solução alternativa você poderá:
‐adicionar manualmente uma extensão de arquivo ao nome do arquivo, após o download.
‐usar outro browser
Consulte JDK-8277093

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u341) seja usado após a próxima atualização crítica de patch programada para 18 de outubro de 2022.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u341) em 18 de novembro de 2022. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Esta release contém também correções para vulnerabilidades de segurança descritas no Oracle Critical Patch Update. Para obter uma lista mais completa das correções de bug nesta release, consulte a página Correções de Bug do JDK 8u341.

» Notas da release 8u341

Java 8 Update 333 (8u333)

Destaques da Release

Dados de Fuso Horário da IANA 2021a.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Alteração: Ativar o Windows Alternate Data Streams por padrão
A implementação Windows de java.io.File foi alterada, de modo que verificações de validade estritas não sejam executadas por padrão em caminhos de arquivo. Isso inclui permitir dois-pontos (‘:’) no caminho em vez de apenas imediatamente após uma letra de unidade única. Ele também permite caminhos que representem ADS (Alternate Data Streams) do NTFS, como “filename:streamname”. Essa operação restaura o comportamento padrão do java.io.File ao que ele era antes do CPU (Critical Patch Update) de abril de 2022, no qual as verificações de disponibilidade não eram executadas por padrão em caminhos de arquivo no Windows. Para reativar a verificação de caminho estrita no java.io.File, a propriedade de sistema jdk.io.File.enableADS deve ser definida como false (sem distinção de maiúsculas/minúsculas). Essa opção pode ser preferível, por exemplo, se os caminhos de dispositivo especial do Windows como NUL: não forem usados.
Consulte JDK-8285445

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u333) seja usado após a próxima atualização de patch crítico programada para 19 de julho de 2022.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u333) em 19 de agosto de 2022. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Esta release se baseia no CPU anteror e não contém nenhuma correção de segurança adicional. Para obter uma lista mais completa das correções de bug incluídas nesta release, consulte a página Notas da release do JDK 8u333.

» Notas da release 8u333

Java 8 Update 331 (8u331)

Destaques da Release

Dados de Fuso Horário da IANA 2021e.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Novos Limites de Processamento
Três limites de processamento foram adicionados. São eles:
- jdk.xml.xpathExprGrpLimit
  Descrição: Limita o número de grupos que uma expressão XPath pode conter.
  Tipo: inteiro
  Valor: Um número inteiro positivo. Um valor menor ou igual a 0 indica que não há limite. Se o valor não for um número inteiro, uma NumberFormatException será gerada. O padrão é 10.
- jdk.xml.xpathExprOpLimit
  Descrição: Limita o número de operadores que uma expressão XPath pode conter.
  Tipo: inteiro
  Valor: Um número inteiro positivo. Um valor menor ou igual a 0 indica que não há limite. Se o valor não for um número inteiro, uma NumberFormatException será gerada. O padrão é 100.
- jdk.xml.xpathTotalOpLimit
  Descrição: Limita o número total de operadores XPath em uma Folha de Estilo XSL.
  Tipo: inteiro
  Valor: Um número inteiro positivo. Um valor menor ou igual a 0 indica que não há limite. Se o valor não for um número inteiro, uma NumberFormatException será gerada. O padrão é 10.000.
Processadores suportados
- O processador XPath suporta jdk.xml.xpathExprGrpLimit e jdk.xml.xpathExprOpLimit.
- O processador XSLT suporta todos os três limites.
Definindo propriedades
Para o processador XSLT, as propriedades podem ser alteradas por meio de TransformerFactory. Por exemplo,
```
<code>        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
```
Para os processadores XPath e XSLT, as propriedades podem ser definidas por meio da propriedade de sistema e do arquivo de configuração jaxp.properties localizados no diretório conf da instalação do Java. Por exemplo,
```
<code>        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
```
ou no arquivo jaxp.properties,
```
<code>        jdk.xml.xpathExprGrpLimit=20
```
JDK-8270504 (não público)
Outras observações: Somente Expor Certificados com Definições de Confiabilidade Apropriadas como Entradas de Certificado Confiáveis no KeychainStore do macOS
No macOS, apenas certificados com definições de confiabilidade apropriadas no keychaing do usuário serão expostos como entradas de certificado confiáveis no tipo de armazenamento de chaves KeychainStore. Além disso, a chamada do método KeyStore::setCertificateEntry ou do comando keytool -importcert em um armazenamento de chaves do tipo Armazenamento de Cadeia de Chaves agora falha com uma KeyStoreException. Em vez disso, chame o comando do macOS "security add-trusted-cert" para adicionar um certificado confiável ao keychain do usuário.
JDK-8278449 (não público)
Outras observações: O parsing de URLs nos provedores de JNDI incorporados em LDAP, DNS, RMI e ficou mais restrito. A intensidade do parsing pode ser controlada pelas propriedades do sistema:
O parsing de URLs nos provedores de JNDI incorporados em LDAP, DNS e RMI ficou mais restrito. A intensidade do parsing pode ser controlada pelas propriedades do sistema:
```
<code>  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)


  -Dcom.sun.jndi.dnsURLParsing="legacy" | "compat" | "strict" (to control "dns:" URLs)

  -Dcom.sun.jndi.rmiURLParsing="legacy" | "compat" | "strict" (to control "rmi:" URLs)

  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict" (to control "iiop:" and "iiopname:" URLs)
```
O valor padrão é "compat" em todos os casos.
- O modo "legacy" desativa a nova validação.
- O modo "compat" limita incompatibilidades.
- O modo "strict" é mais restrito e pode causar regressão pela rejeição de URLs que um aplicativo pode considerar válido.
Se for encontrada uma string de URL inválida, uma exceção javax.naming.NamingException (ou uma subclasse dela) será emitida.
JDK-8278972 (não público)

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u331) seja usado após a próxima atualização de patch crítico programada para 19 de julho de 2022.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u331) em 19 de agosto de 2022. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

» Notas da release 8u331

Java 8 Update 321 (8u321)

Destaques da Release

Dados de IANA TZ 2021b, 2021c, 2021d e 2021e.
O JDK 8u321 contém dados de fuso horário IANA 2021b, 2021c, 2021d e 2021e. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Novas Propriedades de Configuração do SunPKCS11
O provedor SunPKCS11 adiciona novos atributos de configuração do provedor para melhor controlar o uso de recursos nativos. O provedor SunPKCS11 consome recursos nativos para funcionar com bibliotecas nativas do PKCS11. ara gerenciar e controlar melhor os recursos nativos, atributos de configuração adicionais estão incluídos para controlar a frequência de remoção de referências nativas, e também para decidir se o Token do PKCS11 subjacente deverá ser destruído após o log-out.
Consulte JDK-8240256
Funcionalidades e Opções Removidas: Foi removido o Certificado Raiz GlobalSign do Google
O seguinte certificado raiz do Google foi removido do armazenamento de chaves cacerts:
+ alias name "globalsignr2ca [jdk]" Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Consulte JDK-8225083
Outras observações: Atualizar Dados de Fuso Horário para 2021c
O Banco de Dados de Fuso Horário IANA, no qual se baseiam as bibliotecas de Data/Hora do JDK, fez um ajuste para algumas regras de fuso horário desde a versão 2021c. Observe que, desde essa atualização, algumas das regras de fuso horário anteriores ao ano de 1970 foram modificadas de acordo com as alterações que foram introduzidas com a versão 2021b. Para obter mais detalhes, consulte o anúncio da versão 2021b
Consulte JDK-8274407

Mantendo o JDK atualizado

A Oracle recomenda que o JDK seja atualizado com cada CPU (Critical Patch Update). Para determinar se uma release é a mais recente, a página Linha de Base de Segurança pode ser usada para determinar qual é a versão mais recente de cada família de releases.

Atualizações de patch crítico, que contêm correções de vulnerabilidade na segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u291) seja usado após a próxima atualização de patch crítico programada para 20 de julho de 2021.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u291) em 20 de agosto de 2021. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

» Notas da release 8u321

Java 8 Update 311 (8u311)

Destaques da Release

Dados de IANA TZ 2021a.
Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Marlin Renderer no JDK 8u
A partir da versão 8u311, o renderizador de gráficos Marlin e seus artefatos serão criados e distribuídos como parte dos pacotes JDK/JRE. Ele não é o mecanismo de renderização padrão, mas há uma opção para ativá-lo definindo esta propriedade do sistema:
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Consulte JDK-8143849
Nova Funcionalidade: Subconjunto de Filtros de Desserialização Específicos do Contexto
Permite que os aplicativos configurem filtros de desserialização específicos do contexto e selecionados dinamicamente por meio de um factory de filtros da JVM que é chamado para selecionar um filtro para cada fluxo de desserialização. O comportamento é um subconjunto estrito de JEP 415: Context-Specific Deserialization Filters para permitir que uma factory de filtro seja configurada usando uma propriedade configurada na linha de comando ou no arquivo de propriedades de segurança.
Consulte Context-Specific Deserialization Filter and Serialization Filtering Guide para obter detalhes.
JDK-8268680 (não público)
Funcionalidades e Opções Removidas: Foi Removido o Certificado Raiz IdenTrust
O certificado raiz a seguir do IdenTrust foi removido do armazenamento de chaves cacerts:
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
Consulte JDK-8225082
Outras observações: A Release Não Reconhece Corretamente o Windows 11
Esta release não identifica corretamente o Windows 11. A propriedade os.name está definida como Windows 10 no Windows 11. Nos logs de erros do HotSpot, o sistema operacional é identificado como Windows 10; no entanto, o log de erros do HotSpot mostra o número do Build. O Windows 11 tem o Build 22000.194 ou posterior.
Consulte JDK-8274840
Outras observações: Foi Atualizada a Preferência Padrão de Suítes de Cifragem Ativadas
A ordem de prioridade padrão das suítes de cifragem do TLS 1.0 ao TLS 1.3 foi ajustada.
Para TLS 1.3, TLS_AES_256_GCM_SHA384 agora é preferida em relação a TLS_AES_128_GCM_SHA256.
Para TLS 1.0 a TLS 1.2, algumas das suítes intermediárias tiveram sua prioridade reduzida, como se segue:
- As suítes de cifragem que não preservam a confidencialidade antecipada foram movidas para baixo na prioridade em relação àquelas que suportam.
- As suítes de cifragem que usam SHA-1 foram movidas para baixo na prioridade.
Consulte JDK-8163326
Outras observações: Foi Modificado o Comportamento de HttpURLConnection Quando um Proxy Adequado Não é Encontrado
O comportamento de HttpURLConnection ao usar ProxySelector foi modificado nesta release do JDK. HttpURLConnection usado para fallback em uma tentativa de conexão direta em caso de falha dos proxy(s) configurado(s) ao estabelecer uma conexão. A partir desta release, o comportamento padrão foi alterado para não usar mais uma conexão direta quando a primeira tentativa de conexão do proxy falhar.
Consulte JDK-8161016

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade de segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendável que este JDK (versão 8u311) seja usado após a próxima atualização de patch crítico programada para 18 de janeiro de 2022.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário vai expirar esse JRE (versão 8u311) em 18 de fevereiro de 2022. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Esta release contém também correções para vulnerabilidades de segurança descritas no Oracle Critical Patch Update. Para obter uma lista mais completa das correções de bug desta release, consulte a página Correções de Bug do JDK 8u311.

» Notas da Release 8u311

Java 8 Update 301 (8u301)

Destaques da Release

Dados de IANA TZ 2021a.
O JDK 8u301 contém dados do fuso horário do IANA 2021a. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Personalizando a Geração de armazenamento de chaves PKCS12
Novas propriedades do sistema e de segurança foram adicionadas para permitir que os usuários personalizem a geração de armazenamentos de chaves PKCS #12. Isso inclui algoritmos e parâmetros para proteção de chave, proteção de certificado e MacData. A explicação detalhada e os valores possíveis para essas propriedades podem ser encontradas na seção "PKCS12 KeyStore properties" do arquivo java.security file.
Consulte JDK-8076190
Funcionalidades e Opções Removidas: Foram Removidos Certificados-Raiz com Chaves de 1.024 bits
Certificados-raiz com chaves públicas RSA de 1.024 bits fracas foram removidas do armazenamento de chaves cacerts.
Consulte JDK-8243559
Funcionalidades e Opções Removidas: Foi removido o certificado Sonera Class2 CA da Telia Company
O certificado-raiz a seguir foi removido do armazenamento confiável cacerts:
+ Telia Company + soneraclass2ca DN: CN=Sonera Class2 CA, O=Sonera, C=FI
Consulte JDK-8225081
Outras observações: Foi feito upgrade dos Algoritmos de Criptografia PKCS12 Padrão
Os algoritmos de criptografia padrão usados em um armazenamento de chaves PKCS #12 foram atualizados. Os novos algoritmos se baseiam em AES-256 e SHA-256 e são mais fortes do que os algoritmos antigos, que se baseavam em RC2, DESede e SHA-1. Para obter informações detalhadas, consulte as propriedades de segurança, começando com keystore.pkcs12, no arquivo java.security.
Por questões de compatibilidade, uma nova propriedade de sistema chamada keystore.pkcs12.legacy foi definida, a qual reverterá os algoritmos para usar os algoritmos mais antigos e mais fracos. Não há valor definido para essa propriedade.
Consulte JDK-8153005

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade na segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u301) seja usado após a próxima atualização crítica de patch programada para 19 de outubro de 2021.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para grandes números de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u301) em 19 de novembro de 2021. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

» Notas da release 8u301

Java 8 Update 291 (8u291)

Destaques da Release

Dados de IANA TZ 2020e, 2020f e 2021a.
O JDK 8u291 contém dados de fuso horário IANA 2020e, 2020f e 2021a. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Outras observações: Novas Propriedades de Sistema e Segurança para Controlar a Reconstrução de Objetos Remotos por Implementações JNDI RMI e LDAP Incorporadas do JDK
jdk.jndi.object.factoriesFilter: Esta propriedade de sistema e segurança permite a especificação de um filtro serial que controla o conjunto de classes de gerador de objetos permitidas para instanciar objetos com base em referências de objeto retornadas por sistemas de nomenclatura/diretório. A classe de factory nomeada pela instância de referência é correlacionada a este filtro durante a reconstrução da referência remota. A propriedade de filtro suporta a sintaxe de filtro baseada em padrão com o formato especificado pela funcionalidade JEP 290. Essa propriedade se aplica às implementações de provedor incorporadas JNDI/RMI e JNDI/LDAP. O valor padrão permite que qualquer classe de gerador de objetos especificada na referência recrie o objeto referenciado.
JDK-8244473 (não público)
Outras observações: A Versão Padrão do java Não É Atualizada para Execução de jar com Clique Duplo
Se a variável de ambiente PATH contiver um registro configurado por instaladores do Oracle JDK de releases mais recentes, o instalador do Oracle JRE inserirá o caminho para o diretório que contém os comandos Java (java.exe, javaw.exe e javaws.exe) na variável de ambiente PATH após esse registro. Anteriormente, o instalador do Oracle JRE ignorava alterações feitas na variável de ambiente PATH por instaladores do Oracle JDK de releases mais recentes e atualizava incorretamente o valor da variável de ambiente PATH. Consulte o seguinte CSR para obter mais informações técnicas: https://bugs.openjdk.java.net/browse/JDK-8259858
Consulte JDK-8259215
Outras observações: Desativar TLS 1.0 e 1.1
TLS 1.0 e 1.1 são versões do protocolo TLS que não são mais consideradas seguras e foram suplantadas por versões mais seguras e modernas (TLS 1.2 e 1.3).
Essas versões agora foram desativadas por padrão. Caso encontre problemas, você poderá, por sua própria conta e risco, reativar as versões removendo "TLSv1" e/ou "TLSv1.1" da propriedade de segurança jdk.tls.disabledAlgorithms no arquivo de configuração java.security.
Consulte JDK-8202343
Outras observações: Desativar TLS 1.0 e 1.1 para Applets Java Plugin e Aplicativos Java Web Start
TLS 1.0 e 1.1 foram desativados. Por padrão, esses protocolos NÃO são usados por applets Java Plugin e aplicativos Java Web Start. Caso haja problemas, há uma opção de reativar os protocolos via Painel de Controle do Java.
JDK-8255892 (não público)

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade na segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u291) seja usado após a próxima atualização de patch crítico programada para 20 de julho de 2021.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

Correções de Bug

» Notas da release 8u291

Java 8 Update 281 (8u281)

Destaques da Release

Dados da IANA 2020d
O JDK 8u281 contém a versão 2020d dos dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Novo Recurso: Opção groupname Adicionada à Geração do Par de Chaves da Ferramenta de Chave
Uma nova opção -groupname foi adicionada a keytool -genkeypair para que o usuário possa especificar um grupo com nome ao gerar um par de chaves. Por exemplo, keytool -genkeypair -keyalg EC -groupname secp384r1 gerará um par de chaves EC usando a curva secp384r1. Como pode haver diversas curvas com o mesmo tamanho, o uso da opção -groupname é preferível à opção -keysize.
Consulte JDK-8213400
Novo Recurso: Biblioteca do Apache Santuario Atualizada para a Versão 2.1.4
Foi feito upgrade da biblioteca do Apache Santuario para a versão 2.1.4. Como resultado, uma nova propriedade de sistema com.sun.org.apache.xml.internal.security.parser.pool-size foi introduzida.
Essa nova propriedade de sistema define o tamanho do pool do cache DocumentBuilder interno usado no processamento de Assinaturas XML. A função é equivalente à propriedade de sistema org.apache.xml.security.parser.pool-size usada no Apache Santuario e tem o mesmo valor padrão 20.
Consulte JDK-8231507
Novo Recurso: Suporte para Extensão certificate_authorities
A extensão "certificate_authorities" é opcional e foi introduzida no TLS 1.3. Ela é usada para indicar as autoridades de certificação (CAs) que um ponto final suporta e deve ser usada pelo ponto final de recebimento para orientar na seleção do certificado.
Consulte JDK-8206925
Outras observações: Alterado Properties.loadFromXML para Conformidade com Especificação
A implementação do método java.util.Properties loadFromXML foi alterada para conformidade com a especificação. Especificamente, a implementação do parser XML subjacente agora rejeita os documentos que não estão em conformidade, lançando uma exceção InvalidPropertiesFormatException, conforme especificado pelo método loadFromXML.
Consulte JDK-8213325
Outras observações: Nome da Zona US/Pacific-New Removido como Parte de tzdata2020b
Após a atualização do JDK para tzdata2020b, os nomes há muito obsoletos pacificnew e systemv foram removidos. Como resultado, o nome da Zona "US/Pacific-New" declarado no arquivo de dados pacificnew não está mais disponível para uso.
Consulte JDK-8254177

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade na segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u281) seja usado após a próxima atualização de patch crítico programada para 20 de abril de 2021.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u281) em 15 de maio de 2021. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

Esta release contém também correções para vulnerabilidades de segurança descritas no Oracle Critical Patch Update. Para obter uma lista de correções de bug mais completa incluída nesta release, consulte a página Correções de Bug do JDK 8u281.

» Notas da release 8u281

Java 8 Update 271 (8u271)

Destaques da Release

Versão 2020a para Dados da IANA
O JDK 8u271 contém a versão 2020a de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Por padrão, Curvas com Nomes Fracos em TLS, CertPath e JAR Assinado São Desativadas
Por padrão, curvas com nomes fracos são desativadas quando adicionamos a elas as seguintes propriedades de segurança disabledAlgorithms: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms e jdk.jar.disabledAlgorithms. Havendo 47 curvas com nomes fracos a serem desativadas, seria complicado adicionar curvas com nomes individuais a cada propriedade disabledAlgorithms. Para atenuar esse problema, uma nova propriedade de segurança, jdk.disabled.namedCurves, foi implementada para listar as curvas com nomes comuns a todas as propriedades disabledAlgorithms. Para usar a nova propriedade nas propriedades disabledAlgorithms, preceda o nome da propriedade todo com a palavra-chave include. Os usuários ainda podem adicionar curvas com nomes individuais a propriedades disabledAlgorithms separadas dessa nova propriedade. Nenhuma outra propriedade pode ser incluída nas propriedades disabledAlgorithms.
Consulte JDK-8233228
Nova Funcionalidade: Suporte para Kerberos com Referências Cross-Realm (RFC 6806)
O cliente Kerberos foi aprimorado com o suporte a referências cross-realm e a canonicalização de nomes principais, conforme definido pela extensão de protocolo RFC 6806.
Como resultado dessa nova funcionalidade, o cliente Kerberos pode se beneficiar de configurações de ambiente mais dinâmicas e não necessariamente precisa saber (antecipadamente) como acessar o realm de um alvo principal (usuário ou serviço).
Consulte JDK-8223172
Funcionalidade Removida: O Java Plugin foi Removido do JDK 8u para as Plataformas Linux, Solaris e MacOS
A NPAPI é considerada um plug-in vulnerável e foi desativada em muitos browsers. Atualmente, nenhum browser suporta o Java Plugin, que se baseia na NPAPI e nas plataformas Linux, Solaris e MacOS.
A partir da atualização 8u271, a parte do Java Plugin responsável pela integração e pela integração com um browser (especificamente com a biblioteca libnpjp2) e um artefato associado não será desenvolvida e não constará na distribuição do JRE para as plataformas Linux, Solaris e MacOS.
JDK-8240210 (não público)
Outras observações: Foi Adicionada uma Propriedade para Controlar os Mecanismos de Autenticação LDAP Permitidos para Autenticar Conexões Clear
Uma nova propriedade de ambiente, jdk.jndi.ldap.mechsAllowedToSendCredentials, foi adicionada para controlar quais mecanismos de autenticação LDAP têm permissão para enviar credenciais por meio de conexões LDAP clear - conexões não protegidas por TLS. Uma conexão LDAP encrypted é uma conexão aberta por meio da utilização de um esquema ldaps ou ldap com upgrade para TLS e uma operação estendida STARTTLS.
JDK-8237990 (não público)

Mantendo o JDK atualizado

A Oracle recomenda que o JDK seja atualizado com cada CPU (Critical Patch Update). Para determinar se uma release é a mais recente, a página Linha de Base de Segurança a seguir pode ser usada para determinar qual é a versão mais recente para cada família de releases.

Atualizações de patch crítico, que contêm correções de vulnerabilidade na segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u271) seja usado após a próxima atualização de patch crítico programada para 19 de janeiro de 2021.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não podem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u271) em 20 de fevereiro de 2021. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

» Notas da release 8u271

Java 8 Update 261 (8u261)

Destaques da Release

Dados de IANA 2020a
O JDK 8u261 contém a versão 2020a de dados do fuso horário do IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Alterações de Dependência da Biblioteca (DLL) do Windows Visual Studio no Runtime do JDK/JRE
Como parte da manutenção contínua, a cadeia de ferramentas do Microsoft Visual Studio 2017 será usada para criar o JDK 7 e o JDK 8 para Windows. O JDK 8u261, na CPU de julho de 2020, foi criada com o Visual Studio 2017. Com o lançamento da CPU em outubro de 2020, o JDK 7u281 será transferido para o Visual Studio 2017.
JDK-8246783 (não público)
Nova Funcionalidade: JEP 332: Transport Layer Security (TLS) 1.3
O JDK 8u261 inclui uma implementação da especificação Transport Layer Security (TLS) 1.3 (RFC 8446). Para obter mais detalhes, incluindo uma lista das funcionalidades suportadas, consulte a documentação Java Secure Socket Extension (JSSE) Reference Guide e a JEP 332.
Consulte JDK-814252
Nova Funcionalidade: Novas Propriedades do Sistema para Configurar os Esquemas de Assinatura TLS
Duas novas Propriedades do Sistema são adicionadas para personalizar os esquemas de assinatura TLS no JDK.
jdk.tls.client.SignatureSchemes é adicionada para o cliente TLS e jdk.tls.server.SignatureSchemes é adicionada para o servidor.
Consulte JDK-8242141
Nova Funcionalidade: Parâmetros Finite Field Diffie-Hellman Ephemeral Negociados para TLS
A implementação do JDK SunJSSE agora suporta os mecanismos TLS FFDHE definidos na RFC 7919. Se um servidor não puder processar a extensão TLS supported_groups ou os grupos com nome na extensão, os aplicativos poderão personalizar os nomes dos grupos suportados com jdk.tls.namedGroups ou desativar os mecanismos FFDHE, definindo a Propriedade do Sistema jsse.enableFFDHEExtension com o valor falso.
Consulte JDK-8140436

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade na segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u261) seja usado após a próxima atualização de patch crítico programada para 13 de outubro de 2020.

Os clientes da Assinatura do Java SE que gerenciam atualizações/instalações do JRE para um grande número de desktops devem considerar o uso do Java Advanced Management Console (AMC).

No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u261) em 13 de novembro de 2020. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

» Notas da release 8u261

Java 8 Update 251 (8u251)

Destaques da Release

Dados da IANA 2019c
O JDK 8u251 contém a versão 2019c de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Adicionado o Suporte para Algoritmos PKCS#1 v2.2 que incluem Assinatura RSASSA-PSS
Os provedores SunRsaSign e SunJCE foram aprimorados com suporte para mais algoritmos definidos em PKCS#1 v2.2, como assinatura RSASSA-PSS e OAEP usando algoritmos digest FIPS 180-4. Novos construtores e métodos foram adicionados a classes JCA/JCE relevantes nos pacotes java.security.spec e javax.crypto.spec para suportar parâmetros RSASSA-PSS adicionais.
Consulte JDK-8146293
Outras observações: O WebEngine Limita Chamadas do Método JavaScript para Determinadas Classes
Os programas JavaScript executados no contexto de uma página web carregada pelo WebEngine pode se comunicar com objetos Java especificados pelo aplicativo para o programa JavaScript. Os programas JavaScript que fazem referência a objetos java.lang.Class agora estão limitados aos seguintes métodos:
getCanonicalName getEnumConstants getFields getMethods getName getPackageName getSimpleName getSuperclass getTypeName getTypeParameters isAssignableFrom isArray isEnum isInstance isInterface isLocalClass isMemberClass isPrimitive isSynthetic toGenericString toString

Nenhum método pode ser chamado nas seguintes classes:
java.lang.ClassLoader java.lang.Module java.lang.Runtime java.lang.System java.lang.invoke.* java.lang.module.* java.lang.reflect.* java.security.* sun.misc.*

JDK-8236798 (não público)
Outras observações: Nova Propriedade de Sistema de Atualizações do JDK 8 Específicas da Oracle para Fallback para o Formato de Codificação Base64 Legado
O JDK 8u231 da Oracle fez upgrade das bibliotecas do Apache Santuario para a v2.1.3. Esse upgrade introduziu um problema, em que a assinatura XML que usa codificação Base64 resultou na anexação de &#xd ou &#13 à saída codificada. Essa mudança de comportamento foi feita na base de código do Apache Santuario para cumprir o RFC 2045. A equipe do Santuario adotou uma posição de manter suas bibliotecas em conformidade com o RFC 2045.
Consulte JDK-8236645

Mantendo o JDK atualizado

Atualizações de patch crítico, que contêm correções de vulnerabilidade na segurança, são anunciadas com um ano de antecedência nas Atualizações de Patch Crítico, Alertas de Segurança e Boletins. Não é recomendado que este JDK (versão 8u251) seja usado após a próxima atualização de patch crítico programada para 14 de julho de 2020.

No caso de sistemas que não conseguem acessar Oracle Servers, um mecanismo secundário expirará esta versão do JRE (versão 8u251) em 14 de agosto de 2020. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova. Para obter mais informações, consulte 23.1.2 JRE Expiration Date no Java Platform, Standard Edition Deployment Guide.

Correções de Bug

» Notas da release 8u251

Java 8 Update 241 (8u241)

Destaques da Release

Dados da IANA 2019c
O JDK 8u241 contém a versão 2019c de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Permitir que Mecanismos SASL Sejam Restringidos
Foi adicionada uma propriedade de segurança chamada jdk.sasl.disabledMechanisms que pode ser usada para desativar mecanismos SASL. Qualquer mecanismo desativado será ignorado se for especificado no argumento mechanisms de Sasl.createSaslClient ou no argumento mechanism de Sasl.createSaslServer. O valor padrão dessa propriedade de segurança está vazio, o que significa que nenhum mecanismo é desativado por padrão.
Consulte JDK-8200400
Nova Funcionalidade: Provedor SunPKCS11 Atualizado com Suporte para PKCS#11 v2.40
O provedor SunPKCS11 foi atualizado com suporte para PKCS#11 v2.40. Essa versão adiciona suporte para mais algoritmos, como a cifra AES/GCM/NoPadding, assinaturas DSA que usam a família SHA-2 de compilações de mensagens, bem como assinaturas RSASSA-PSS quando os mecanismos PKCS11 correspondentes são suportados pela biblioteca PKCS11 subjacente.
Consulte JDK-8080462
Outras observações: Novas Verificações em Certificados de Âncora Confiável
Novas verificações foram adicionadas para assegurar que âncoras confiáveis sejam certificadas CA e contenham extensões apropriadas. São utilizadas âncoras confiáveis para validar cadeias de certificado usadas em código assinado e TLS. Os certificados de âncora confiável devem incluir uma extensão de Restrições Básicas com o campo cA definido como verdadeiro. Além disso, se incluírem uma extensão de Uso de Chave, o bit keyCertSign deverá ser definido.
JDK-8230318 (não público)
Outras observações: Correspondência Exata Obrigatória para Certificado de Servidor TLS Confiável
Um certificado de servidor TLS deve ser a correspondência exata de um certificado confiável no cliente para que seja confiável ao estabelecer uma conexão TLS.
JDK-8227758 (não público)
Outras observações: Adicionado o Certificado Raiz 2 Global LuxTrust
O certificado raiz LuxTrust foi adicionado ao armazenamento confiável de cacerts
Consulte JDK-8232019
Outras observações: Adicionados Certificados CA Raiz 4 da Amazon
O certificado raiz da Amazon foi adicionado ao armazenamento confiável de cacerts
Consulte JDK-8233223
Correções de Bug: Suporte para Fontes OpenType CFF
Anteriormente, o Oracle JDK 8 não incluía fontes OpenType CFF (fontes .otf) nas fontes lógicas padrão (como "Dialog" e "SansSerif"). Isso resultava na ausência de glifos ao renderizar texto. Nos casos mais extremos, em que apenas as fontes CFF foram instaladas no sistema, uma exceção Java poderia ser gerada.
Várias distribuições do Linux foram afetadas por esse problema, porque elas contam com fontes CFF para suporte a alguns idiomas; ela é comum para os idiomas CJK (chinês, japonês e coreano).
O Oracle JDK 8 agora usa essas fontes CFF, e esse problema foi resolvido.
Consulte JDK-8209672
Correções de Bug: Melhor Tratamento de Filtro Serial
A propriedade de sistema jdk.serialFilter só pode ser definida na linha de comando. Se o filtro não tiver sido definido na linha de comandos, poderá ser definido com java.io.ObjectInputFilter.Config.setSerialFilter. A definição de jdk.serialFilter com java.lang.System.setProperty não tem efeito.
JDK-8231422 (não público)

Data de Expiração do Java

A data de expiração do 8u241 é 14 de abril de 2020. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u241) em 14 de maio de 2020. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u241

Java 8 Update 231 (8u231)

Destaques da Release

Dados de IANA 2019b
O JDK 8u231 contém a versão 2019b de dados do fuso horário do IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Nova Propriedade de Sistema jdk.jceks.iterationCount
Uma nova propriedade de sistema foi introduzida para controlar o valor da contagem de iterações usado para o armazenamento de chaves jceks. O valor padrão permanece em 200.000, mas valores entre 10.000 e 5.000.000 podem ser especificados. O nome da nova propriedade de sistema é jdk.jceks.iterationCount e o valor fornecido deve ser um número inteiro dentro da faixa aceita. O valor padrão será usado se um erro de parsing for encontrado.
JDK-8223269 (não público)
Nova Funcionalidade: Novos Eventos de Segurança do JFR (Java Flight Recorder)
Quatro novos eventos do JFR foram adicionados à área da biblioteca de segurança. Esses eventos são desativados por padrão e podem ser ativados por meio dos arquivos de configuração do JFR ou via opções do JFR.
Consulte JDK-8148188
Funcionalidades e Opções Removidas: Remoção do Rasterizador T2K e Mecanismo de Layout do ICU do JavaFX
O rasterizador T2K e o mecanismo de layout do ICU foram removidos do JavaFX.
Consulte JDK-8187147
Outras observações: [client-libs e javaFX] GTK3 É Agora o Padrão no Linux/Unix
Versões mais novas do Linux, Solaris e outros ambientes de desktop compatíveis com Unix usam GTK3, embora ainda suportem GTK2.
Anteriormente, o JDK adotaria como padrão a carga das bibliotecas GTK2 mais antigas. Porém, nesta release, ele adota como padrão a carga de bibliotecas GTK3. A carga em geral é acionada usando o Recurso Look and Feel do Swing/GTK.
O comportamento antigo pode ser restaurado usando a propriedade de sistema: -Djdk.gtk.version=2.2
Consulte JDK-8222496
Outras observações: Remover Curvas Elípticas no Padrão NIST Obsoletas dos Algoritmos de TLS Padrão
Esta alteração remove curvas elípticas de padrão NIST dos Grupos Nomeados padrão usados durante a negociação com o protocolo TLS. As curvas removidas são sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 e secp256k1.
Para reativar essas curvas, use a propriedade de sistema jdk.tls.namedGroups. A propriedade contém uma lista de grupos nomeados ativados entre aspas e separados por vírgulas na ordem de preferência. Por exemplo:
java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
JDK-8228825 (não público)

Data de Expiração do Java

A data de expiração para 8u231 é 14 de janeiro de 2020. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u231) em 14 de fevereiro de 2020. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u231

Java 8 Update 221 (8u221)

Destaques da Release

Dados de IANA 2018i
O JDK 8u221 contém a versão 2018i dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: a Detecção do Windows OS do HotSpot Identifica Corretamente o Windows Server 2019
Antes desta correção, o Windows Server 2019 era reconhecido como "Windows Server 2016", o que gerava valores incorretos na propriedade do sistema os.name e no arquivo hs_err_pid.
Consulte JDK-8211106
Funcionalidades e Opções Removidas: Remoção de Dois Certificados CA Raiz DocuSign
Dois certificados CA raiz DocuSign expiraram e foram removidos do armazenamento de chaves cacerts:
- nome do alias "certplusclass2primaryca [jdk]"
  Nome Distinto: CN=CA Principal Classe 2, O=Certplus, C=FR
- nome do alias "certplusclass3pprimaryca [jdk]"
  Nome Distinto: CN=CA Principal Classe 3P, O=Certplus, C=FR
Consulte JDK-8223499
Funcionalidades e Opções Removidas: Remoção de Dois Certificados CA Raiz Comodo
Dois certificados CA raiz Comodo expiraram e foram removidos do armazenamento de chaves cacerts:
- nome do alias "utnuserfirstclientauthemailca [jdk]"
  Nome Distinto: CN=UTN-USERFirst-Autenticação do Cliente e E-mail, OU=http://www.usertrust.com, O=A Rede USERTRUST, L=Salt Lake City, ST=UT, C=US
- nome do alias "utnuserfirsthardwareca [jdk]"
  Nome Distinto: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=A Rede USERTRUST, L=Salt Lake City, ST=UT, C=US
Consulte JDK-8222136
Funcionalidades e Opções Removidas: Remoção do Certificado CA 2 Raiz T-Systems Deutsche Telekom
O certificado CA 2 Raiz T-Systems Deutsche Telekom expirou e foi removido do armazenamento de chaves cacerts:
- nome do alias "deutschetelekomrootca2 [jdk]"
  Nome Distinto: CN=CA 2 Raiz Deutsche Telekom, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
Consulte JDK-8222137
Outras observações: Solução Alternativa da Instalação do Java Access Bridge
Há risco de ruptura da funcionalidade Java Access Bridge ao instalar o Java em um sistema Windows com uma versão instalada anteriormente do Java e uma instância do JAWS em execução. Após a reinicialização, o sistema pode ser deixado sem o WindowsAccessBridge-64.dll no diretório do sistema (C:\Windows\System32) para produtos Java de 64 bits ou no diretório do sistema usado pelo WOW64 (C:\Windows\SysWoW64) para produtos Java de 32 bits.
Para impedir a interrupção da funcionalidade Java Access Bridge, use uma das seguintes soluções alternativas:
- Interrompa o JAWS antes de executar o instalador do Java.
- Desinstale o(s) JRE(s) existente(s) antes de instalar a nova versão do Java.
- Desinstale o(s) JRE(s) existente(s) depois que a nova versão do Java for instalada e a máquina for reinicializada.
O objetivo das soluções alternativas é evitar o cenário de desinstalação do(s) JRE(s) existente(s) do instalador Java quando o JAWS está em execução.
JDK-8223293 (não público)

Data de Expiração do Java

A data de expiração da versão 8u221 é 15 de outubro de 2019. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u221) em 15 de novembro de 2019. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u221

Java 8 Update 211 (8u211)

Destaques da Release

Dados da IANA 2018g
O JDK 8u211 contém a versão 2018g de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Suporte a Caractere Quadrado para a Nova Era do Japão
O ponto de código, U+32FF, foi reservado pela Unicode Consortium para representar o caractere quadrado japonês para a nova era que começou a partir de maio de 2019. Métodos relevantes na classe Caractere retornam as mesmas propriedades dos caracteres de era japoneses existentes (por exemplo, U+337E para "Meizi"). Para saber detalhes sobre o ponto de código, consulte http://blog.unicode.org/2018/09/new-japanese-era.html.
Consulte JDK-8211398
Alteração: Adicionado o Certificado Raiz GlobalSign R6
O seguinte certificado raiz foi adicionado ao armazenamento confiável de cacerts do OpenJDK:
- GlobalSign
  - globalsignrootcar6
    DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6
JDK-8216577 (não público)
Alteração: Suspeita de Certificados do Servidor do TLS Ancorados pelo Certificado-Raiz da Symantec
O JDK não confiará mais nos certificados do Servidor do TLS emitidos pela Symantec, de forma alinhada com planos semelhantes recém-anunciados pelo Google, Mozilla, Apple e Microsoft. A lista de certificados afetados inclui certificados com as marcas GeoTrust, Thawte e VeriSign, que eram gerenciados pela Symantec.
Os certificados de Servidor TLS emitidos até 16 de abril de 2019 continuarão a ser confiáveis até que expirem. Os certificados emitidos após essa data serão rejeitados. Consulte a página de suporte da DigiCert para obter informações sobre como substituir seus certificados Symantec por um certificado DigiCert (A DigiCert assumiu a validação e a emissão de todos os certificados Symantec Website Security SSL/TLS em 1º de dezembro de 2017).
Uma exceção a essa política é que os certificados de Servidor TLS emitidos por meio de duas Autoridades de Certificação subordinadas gerenciadas pela Apple, e identificadas abaixo, continuarão a ser confiáveis desde que tenham sido emitidos até 31 de dezembro de 2019.
Consulte JDK-8207258
Alteração: Nome da Nova Era no Japão
O nome placeholder "NewEra" para a era japonesa iniciada a partir de 1 de maio de 2019 foi substituído pelo nome divulgado pelo governo do Japão: "Reiwa". Aplicativos que contam com o nome placeholder para obter o singleton da nova era (JapaneseEra.valueOf("NewEra")) não vão funcionar mais.
Consulte JDK-8205432
Alteração: Suporte à Nova Era do Japão em java.time.chrono.JapaneseEra
A classe JapaneseEra e os respectivos métodos of(int), valueOf(String) e values() são esclarecidos de modo a acomodar futuras inclusões da era japonesa, como a forma de definição das instâncias singleton, quais são os valores inteiros associados da era etc.
Consulte JDK-8212941

Data de Expiração do Java

A data de expiração para a release 8u211 é 16 de julho de 2019. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar Oracle Servers, um mecanismo secundário expirará esta versão do JRE (versão 8u211) em 16 de agosto de 2019. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança descritas no Oracle Java SE Critical Patch Update Advisory. Para obter uma lista de correções de bug mais completa incluída nesta release, consulte a página Correções de Bug JDK 8u211.

» Notas da release 8u211

Java 8 Update 201 (8u201)

Destaques da Release

Dados da IANA 2018e
O JDK 8u201 contém a versão 2018e de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Alteração: As Suítes de Cifragem TLS anon e NULL estão Desativadas
As suítes de cifragem TLS anon (anônima) e NULL foram adicionadas à propriedade de segurança jdk.tls.disabledAlgorithms e agora, por padrão, estão desativadas.
Consulte JDK-8211883
Alteração: jarsigner É Impresso Quando um Timestamp Vai Expirar
A ferramenta jarsigner agora mostra mais informações sobre o tempo de vida de um JAR com timestamp. Novas mensagens de advertência e erro são exibidas quando um timestamp expirou ou vai expirar dentro de um ano.
Consulte JDK-8191438

Data de Expiração do Java

A data de expiração do 8u201 é 16 de abril de 2019. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u201) em 16 de maio de 2019. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u201

Java 8 Update 191 (8u191)

Destaques da Release

Dados da IANA 2018e
O JDK 8u191 contém a versão 2018e de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Alteração: Alterado o Local do Sistema de Arquivos Central para o Arquivo usagetracker.properties
O local do sistema de arquivos no Windows para o arquivo usagetracker.properties foi movido de %ProgramData%\Oracle\Java\ para %ProgramFiles%\Java\conf
Não há alteração no caminho do arquivo para Linux, Solaris ou macOS. JDK-8204901 (não público)
Alteração: Desativadas todas as Suítes de Cifragem TLS do DES
As suítes de cifragem TLS baseadas no DES são consideradas obsoletas e não devem mais ser usadas. As suítes de cifragem baseadas no DES foram desativadas por padrão na implementação do SunJSSE adicionando o identificador "DES" à propriedade de segurança jdk.tls.disabledAlgorithms. Essas suítes de cifragem podem ser reativadas removendo "DES" da propriedade de segurança jdk.tls.disabledAlgorithms no arquivo java.security ou chamando dinamicamente o método Security.setProperty(). Em ambos os casos, a reativação do DES deve ser seguida da adição de suítes de cifragem baseadas no DES à lista de suítes de cifragem ativada, usando os métodos SSLSocket.setEnabledCipherSuites() ou SSLEngine.setEnabledCipherSuites().
Observe que, antes dessa alteração, as suítes DES40_CBC (mas não todas as suítes DES) eram desativadas por meio da propriedade de segurança jdk.tls.disabledAlgorithms.
Consulte JDK-8208350
Alteração: Remoção de Diversas CAs Raiz da Symantec
Os seguintes certificados raiz da Symantec não estão mais em uso e foram removidos:
- Symantec
  - equifaxsecureca
    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
  - equifaxsecureglobalebusinessca1
    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
  - equifaxsecureebusinessca1
    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
  - verisignclass1g3ca
    DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass2g3ca
    DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
  - verisignclass1g2ca
    DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
  - verisignclass1ca
    DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US
Consulte JDK-8191031
Alteração: Remoção da CA de Assinatura de Código Baltimore Cybertrust
O seguinte certificado raiz de Assinatura de Código Baltimore CyberTrust não está mais em uso e foi removido:
- baltimorecodesigningca
  DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE
Consulte JDK-8189949
Correção de Bug: Falha na Comunicação LDAPS
O código de aplicativo que usa LDAPS com um timeout de conexão de soquete que é <= 0 (o valor padrão), executado na CPU de julho de 2018 (8u181, 7u191 E 6u201 ), pode encontrar uma exceção ao estabelecer a conexão.
A maioria dos principais frames de rastreamentos de pilha de Exceção de aplicativos que encontram esses problemas podem se parecer com o seguinte:
javax.naming.ServiceUnavailableException: ; soquete fechado
at com.sun.jndi.ldap.Connection.readReply (Unknown Source)
at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
O problema foi resolvido e a correção está disponível nas seguintes releases:
- 8u181
- 7u191
Consulte JDK-8211107

Data de Expiração do Java

A data de expiração para 8u191 é 15 de janeiro de 2019. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u191) em 15 de fevereiro de 2019. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança descritas no Oracle Java SE Critical Patch Update Advisory. Para obter uma lista mais completa das correções de bug nesta release, consulte a página Correções de Bug do JDK 8u191.

» Notas da release 8u191

Java 8 Update 181 (8u181)

Destaques da Release

Dados da IANA 2018e
O JDK 8u181 contém a versão 2018e de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Funcionalidade Removida: Remoção do Java DB
O Java DB, também conhecido como Apache Derby, foi removido nesta release.
Recomendamos que você obtenha o Apache Derby mais recente diretamente no projeto Apache, no endereço:
https://db.apache.org/derby
JDK-8197871 (não público)
Alteração: Melhorar o suporte a LDAP
A identificação de ponto final foi ativada em conexões LDAPS.
Para melhorar a robustez de conexões LDAPS (LDAP seguro em TLS), algoritmos de identificação de ponto final foram ativados por padrão.
Observe que pode haver situações nas quais alguns aplicativos que antes podiam estabelecer conexões com sucesso a um servidor LDAPS talvez não possam mais fazer isso. Tais aplicativos podem, se for apropriado, desativar a identificação de ponto final usando uma nova propriedade do sistema: com.sun.jndi.ldap.object.disableEndpointIdentification.
Defina essa propriedade do sistema (ou defina-a como true) para desativar algoritmos de identificação de ponto final.
JDK-8200666 (não público)
Alteração: Melhor processo de "stack walking"
Novas verificações de acesso foram adicionadas durante a fase de desserialização da criação de objetos. Isso não deverá afetar os usos comuns da desserialização. Porém, estruturas reflexivas que fazem uso de APIs internas do JDK poderão ser impactadas. As novas verificações poderão ser desativadas, se necessário, definindo a propriedade do sistema jdk.disableSerialConstructorChecks para o valor "verdadeiro". Isso deve ser feito adicionando o argumento -Djdk.disableSerialConstructorChecks=true à linha de comando do Java.
JDK-8197925 (não público)
Correção de Bug: Pane na JVM durante G1 GC
Um parâmetro klass que foi considerado inacessível pela marcação simultânea de G1 pode ser pesquisado em ClassLoaderData/SystemDictionary e seus respectivos campos _java_mirror ou _class_loader podem ser armazenados em uma raiz ou qualquer outro objeto acessível, tornando-o ativo novamente. Sempre que um parâmetro klass ressurge desta maneira, a parte SATB do G1 precisa ser notificada sobre o fato. Caso contrário, a fase de remarcação da marcação simultânea descarregará de forma errada esse parâmetro klass.
Consulte JDK-8187577
Correção de Bug: Maior estabilidade com bibliotecas NUMA mais antigas (-XX+UseNuma)
Uma correção incluída no JDK 8 Update 152 introduziu uma regressão que pode causar pane no HotSpot JVM durante a inicialização, quando o flag UseNUMA é usado em sistemas Linux com versões de libnuma anteriores à 2.0.9. Esse problema foi resolvido.
Consulte JDK-8198794

Data de Expiração do Java

A data de expiração para 8u181 é 16 de outubro de 2018. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u181) em 16 de novembro de 2018. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u181

Java 8 Update 171 (8u171)

Destaques da Release

Dados da IANA 2018c
O JDK 8u171 contém a versão 2018c de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Mecanismos Aprimorados de Armazenamento de Chaves
Uma nova propriedade de segurança chamada jceks.key.serialFilter foi apresentada. Se esse filtro for configurado, o Armazenamento de Chaves JCEKS o usará durante a desserialização do objeto de Chave criptografado armazenado dentro de uma SecretKeyEntry. Se ele não for configurado ou se o resultado do filtro for UNDECIDED (por exemplo, nenhum dos padrões corresponde), o filtro configurado por jdk.serialFilter será consultado.
Se a propriedade de sistema jceks.key.serialFilter também for especificada, ela se sobreporá ao valor da propriedade de segurança definido aqui.
O padrão de filtro usa o mesmo formato que jdk.serialFilter. O padrão predeterminado permite java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type e javax.crypto.spec.SecretKeySpec, mas rejeita todos os outros.
Os clientes que armazenam uma SecretKey que não é serializada para os tipos acima devem modificar o filtro para tornar a chave extraível.
JDK-8189997 (não público)
Nova Funcionalidade: Propriedade de Sistema para Desativar o Rastreamento da Última Utilização do JRE
Uma nova propriedade de sistema jdk.disableLastUsageTracking foi introduzida para desativar o rastreamento da última utilização do JRE numa VM em execução. Esta propriedade pode ser definida na linha de comando usando -Djdk.disableLastUsageTracking=true ou -Djdk.disableLastUsageTracking. Com esta propriedade de sistema definida, o rastreamento da última utilização do JRE será desativado, não importa qual seja o valor da propriedade com.oracle.usagetracker.track.last.usage definido em usagetracker.properties.
JDK-8192039 (não público)
Observação: Uso de CipherOutputStream
A especificação de javax.crypto.CipherOutputStream foi esclarecida de modo a indicar que essa classe captura BadPaddingException e outras exceções causadas por falhas nas verificações de integridade durante a decriptografia. Essas exceções não são geradas novamente. Portanto, o cliente não é informado de que as verificações de integridade falharam. Em decorrência desse comportamento, esta classe talvez não seja adequada para uso com a decriptografia em um modo de operação autenticado (por exemplo, GCM) se o aplicativo exigir notificação explícita quando houver falha na autenticação. Esses aplicativos podem usar a API Cipher diretamente como alternativa ao uso desta classe.
JDK-8182362 (não público)
Alteração: Certificado-Raiz TeliaSonera Adicional
"TeliaSonera Root CA v1" foi adicionado ao armazenamento de chaves cacerts.
JDK-8190851 (não público)
Alteração: Assinaturas XML Feitas com Chaves EC com Menos de 224 Bits Desativadas
Para aumentar a força das conexões SSL/TLS, as suítes de cifragem 3DES foram desativadas nas conexões SSL/TLS do JDK por meio da Propriedade de Segurança jdk.tls.disabledAlgorithms.
JDK-8175075 (não público)
Correção de Bug: Conexões RMI de Servidor com canal de transporte via túnel HTTP Desativadas
Por padrão, as conexões RMI de servidor com canal de transporte via túnel HTTP foram desativadas nesta release. Este comportamento pode ser revertido definindo-se a propriedade de runtime sun.rmi.server.disableIncomingHttp como falso. Observação: essa propriedade não deve ser confundida com a propriedade sun.rmi.server.disableHttp, que desativa o túnel HTTP-no cliente e tem o valor falso por padrão.
JDK-8193833 (não público)

Data de Expiração do Java

A data de expiração para a release 8u171 é 17 de julho de 2018. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar Oracle Servers, um mecanismo secundário expirará esta versão do JRE (versão 8u171) em 17 de agosto de 2018. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da Release 8u171

Java 8 Update 161 (8u161)

Destaques da Release

Dados da IANA 2017c
O JDK 8u161 contém a versão 2017c de dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Nova Funcionalidade: Suporte para DHE de até 8192 bits e para DSA de até 3072 bits
Aprimoramento dos provedores de segurança de JDK para suportar a geração de parâmetros DiffieHellman e DSA de 8192 bits e parâmetros DiffieHellman pré-computados de até 3072 bits.
Consulte JDK-8072452
Nova Funcionalidade: Parâmetros Finite Field Diffie-Hellman Ephemeral Negociados para TLS
A implementação do JDK SunJSSE agora suporta os mecanismos TLS FFDHE definidos na RFC 7919. Se um servidor não puder processar a extensão TLS supported_groups ou os grupos com nome na extensão, os aplicativos poderão personalizar os nomes dos grupos suportados com jdk.tls.namedGroups ou desativar os mecanismos FFDHE, definindo a Propriedade do Sistema jsse.enableFFDHEExtension como false.
Consulte JDK-8140436
Nova Funcionalidade: Adição de verificações do tipo de stub IDL ao método org.omg.CORBA.ORBstring_to_object
Os aplicativos que chamam org.omg.CORBA.ORB.string_to_object de forma explícita ou implícita, e desejam assegurar a integridade do tipo de stub IDL envolvido no fluxo de chamadas ORB::string_to_object, devem especificar a verificação adicional do tipo de stub IDL. Esta é uma funcionalidade "opt in" e não ativada por padrão.
Para aproveitar a vantagem da verificação adicional de tipo, a lista de nomes de classe válidos de interface IDL das classes de stub IDL é configurada por uma das seguintes formas:
- Especificando a propriedade de segurança com.sun.CORBA.ORBIorTypeCheckRegistryFilter localizada no arquivo conf/security/java.security no Java SE 9 ou no arquivo jre/lib/security/java.security no Java SE 8 e anterior.
- Especificando a propriedade de sistema com.sun.CORBA.ORBIorTypeCheckRegistryFilter com a lista de classes. Se a propriedade de sistema estiver definida, seu valor substituirá a propriedade correspondente definida na configuração java.security.
Se a propriedade com.sun.CORBA.ORBIorTypeCheckRegistryFilter não estiver definida, a verificação de tipo só será executada de acordo com um conjunto de nomes de classe dos tipos de interface IDL correspondentes às classes de stub IDL incorporadas.
JDK-8160104 (não público)
Alteração: validação de chave pública RSA
Na 8u161, a implementação de RSA no provedor SunRsaSign rejeitará qualquer chave pública RSA cujo expoente não esteja na faixa válida definida pelo PKCS#1 versão 2.2. Essa alteração afetará as conexões JSSE e também os aplicativos criados no JCE.
JDK-8174756 (não público)
Alteração: restrição de chaves Diffie-Hellman com menos de 1.024 bits
As chaves Diffie-Hellman com menos de 1.024 bits são consideradas muito fracas para uso na prática e devem ser restringidas por padrão nas conexões SSL/TLS/DTLS. Sendo assim, as chaves Diffie-Hellman com menos de 1.024 bits foram desativadas por padrão, adicionando "DH keySize < 1.024" à propriedade de segurança "jdk.tls.disabledAlgorithms" no arquivo java.security. Embora não seja recomendável, os administradores podem atualizar a propriedade de segurança ("jdk.tls.disabledAlgorithms") e permitir chaves menores (por exemplo, definindo "DH keySize < 768").
JDK-8148108 (não público)
Alteração: o tamanho de chave padrão do provedor foi atualizado
Essa alteração atualiza os provedores de JDK para usar 2048 bits como tamanho de chave padrão para DSA em vez de 1.024 bits, quando os aplicativos não inicializaram explicitamente os objetos java.security.KeyPairGenerator e java.security.AlgorithmParameterGenerator com um tamanho de chave.
Se problemas de compatibilidade surgirem, os aplicativos existentes poderão definir a propriedade de sistema jdk.security.defaultKeySize introduzida no JDK-8181048 com o algoritmo e seu tamanho de chave padrão desejado.
JDK-8178466 (não público)

Data de Expiração do Java

A data de expiração da 8u161 é 17 de abril de 2018. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u161) em 17 de maio de 2018. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u161

Java 8 Update 151 (8u151)

Destaques da Release

Dados de IANA 2017b
O JDK 8u151 contém a versão 2017b de dados do fuso horário do IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Alterações de Certificado: Remova o certificado-raiz Swisscom "swisscomrootevca2" revogado
Um certificado-raiz Swisscom foi revogado pela Swisscom e foi removido: Swisscom Root EV CA 2 alias: "swisscomrootevca2 [jdk]" DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
JDK-8186330 (não público)
Novas Funcionalidades Nova propriedade de Segurança para controlar a política de criptografia
Esta release apresenta uma nova funcionalidade pela qual os arquivos de política de jurisdição JCE usados pelo JDK podem ser controlados por meio de uma nova propriedade de Segurança. Nas releases mais antigas, era preciso fazer download dos arquivos de jurisdição JCE e instalá-los separadamente para permitir o uso de criptografia ilimitada pelo JDK. As etapas de download e instalação não são mais necessárias. Para ativar a criptografia ilimitada, é possível usar a nova propriedade de Segurança crypto.policy. Se a nova propriedade de Segurança (crypto.policy) for definida no arquivo java.security ou tiver sido definida dinamicamente com o uso da chamada Security.setProperty() antes da inicialização do framework JCE, essa definição será respeitada. Por padrão, a propriedade não será definida. Se a propriedade for deixada indefinida e os arquivos de jurisdição JCE legados não existirem no diretório lib/security legado, o nível criptográfico padrão permanecerá 'limitado'. Para configurar o JDK para utilizar criptografia ilimitada, defina crypto.policy com um valor 'ilimitado'. Consulte as observações no arquivo java.security que acompanha esta release para obter mais informações.
Observação: no Solaris, é recomendável que você remova os pacotes SVR4 antigos antes de instalar as novas atualizações do JDK. Se um upgrade baseado em SVR4 (sem a instalação dos pacotes antigos) estiver sendo feito sobre uma release do JDK anterior à 6u131, 7u121, 8u111, defina a nova propriedade de Segurança crypto.policy no arquivo java.security.

Como os arquivos de jurisdição JCE antigos são deixados em <java-home>/lib/security pode ser que não atendam aos padrões mais recentes de assinatura do JAR de segurança, que foram atualizados nas versões 6u131, 7u121, 8u111 e atualizações posteriores. Uma exceção semelhante à seguinte poderá ser vista se os arquivos antigos forem utilizados:

Causada por: java.lang.SecurityException: os arquivos de política de jurisdição não estão assinados por assinantes confiáveis! em javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) em javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)
Consulte JDK-8157561
Alterações Refatore os provedores existentes para consultar as mesmas constantes em busca dos valores padrão para tamanho de chave
Duas alterações importantes foram feitas para esse problema:
1. Uma nova propriedade do sistema foi introduzida para permitir que os usuários configurem o tamanho de chave padrão usado pelas implementações KeyPairGenerator e AlgorithmParameterGenerator do provedor do JDK. O nome dessa propriedade é "jdk.security.defaultKeySize" e o valor dela é uma lista de entradas separadas por vírgulas. Cada entrada consiste em um nome de algoritmo que não distingue maiúsculas de minúsculas e o correspondente tamanho de chave padrão (em decimal) separado por ':'. Além disso, espaço em branco é ignorado.
Por padrão, essa propriedade não terá um valor e os provedores de JDK usarão seus próprios valores padrão. As entradas que contiverem um nome de algoritmo não reconhecido serão ignoradas. Se o tamanho de chave padrão especificado não for um inteiro decimal analisável, essa entrada será ignorada também.
1. A implementação do DSA KeyPairGenerator do provedor SUN não implementa mais java.security.interfaces.DSAKeyPairGenerator. Os aplicativos que lançam o objeto DSA KeyPairGenerator do provedor SUN em um java.security.interfaces.DSAKeyPairGenerator podem definir a propriedade "jdk.security.legacyDSAKeyPairGenerator" do sistema. Se o valor dessa propriedade for 'verdadeiro', O provedor SUN retornará um objeto DSA KeyPairGenerator que implementa a interface java.security.interfaces.DSAKeyPairGenerator. Essa implementação legada utilizará o mesmo valor padrão especificado pelo javadoc na interface.
Por padrão, essa propriedade não terá um valor e o provedor SUN retornará um objeto DSA KeyPairGenerator, que não implementa a interface anteriormente mencionada; com isso, pode determinar seu próprio valor padrão específico do provedor, conforme indicado na classe java.security.KeyPairGenerator ou pela propriedade 'jdk.security.defaultKeySize' do sistema se definida.
JDK-8181048 (não público)

Data de Expiração do Java

A data de expiração da 8u151 é 16 de janeiro de 2018. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u151) em 16 de fevereiro de 2018. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u151

Java 8 Update 144 (8u144)

Destaques da Release

Dados de IANA 2017b
O JDK 8u144 contém a versão 2017b de dados do fuso horário do IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: java.util.zip.ZipFile.getEntry() agora sempre retorna a instância ZipEntry com o nome de uma entrada que termina com / para a entrada de diretório
java.util.zip.ZipEntry O doc da API especifica 'É definida uma entrada de diretório cujo nome termina com /'. No entanto, nas releases anteriores do JDK, java.util.zip.ZipFile.getEntry(String entryName) pode retornar uma instância ZipEntry com um nome de entrada que não termina com / para uma entrada de diretório quando o argumento transmitido entryName não termina com / e há uma entrada de diretório zip correspondente com o nome entryName + / no arquivo zip. Com essa release, o nome da instância ZipEntry retornada de java.util.zip.ZipFile.getEntry() sempre termina com / para qualquer entrada de diretório zip.
Para reverter ao comportamento anterior, defina a propriedade jdk.util.zip.ensureTrailingSlash do sistema como 'false'.

Essa alteração foi feita para corrigir uma regressão introduzida no JDK 8u141 ao verificar JARs assinados e fez com que houvesse falha no carregamento de alguns aplicativos WebStart.
Consulte JDK-8184993

Data de Expiração do Java

A data de expiração para 8u144 é 17 de outubro de 2017. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u144) em 17 de novembro de 2017. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u144

Java 8 Update 141 (8u141)

Destaques da Release

Dados de IANA 2017b
O JDK 8u141 contém a versão 2017b de dados do fuso horário do IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Alterações de Certificado: Novos certificados Let's Encrypt adicionados às autoridades de certificação-raiz
Um novo certificado-raiz foi adicionado:
ISRG Root X1 alias: letsencryptisrgx1 DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US
JDK-8177539 (não público)
Melhorias no Diagnóstico JMX
com.sun.management.HotSpotDiagnostic::dumpHeap A API foi modificada para gerar IllegalArgumentException se o nome de arquivo fornecido não terminar com o sufixo “.hprof”. Os aplicativos existentes que não fornecerem um nome de arquivo que termine com a extensão “.hprof” falharão com a exceção IllegalArgumentException. Nesse caso, os aplicativos podem optar por tratar da exceção ou restaurar o comportamento antigo, definindo a propriedade do sistema 'jdk.management.heapdump.allowAnyFileSuffix' como verdadeira.
JDK-8176055 (não público)
Verificações de segurança mais restritas no processamento de arquivos WSDL pela ferramenta wsimport
A ferramenta wsimport foi alterada para não permitir DTDs em descrições de Web Service, especificamente:
- A declaração DOCTYPE não é permitida em documentos
- Por padrão, entidades gerais externas não estão incluídas
- Por padrão, entidades de parâmetro externas não estão incluídas
- DTDs externas são completamente ignoradas
Para restaurar o comportamento anterior:
- Defina a propriedade do Sistema com.sun.xml.internal.ws.disableXmlSecurity como verdadeira
- Use a opção de linha de comando da ferramenta wsimport –disableXmlSecurity
  OBSERVAÇÃO: O suporte do JDK 7 e JDK 6 para essa opção no wsimport será fornecido via release de Patch após CPU (Critical Patch Update) de julho
JDK-8182054 (não público)
O HostnameVerifier personalizado ativa a extensão SNI
As releases anteriores de Atualizações do JDK 8 nem sempre enviavam a extensão SNI (Server Name IndicationI) na fase TLS ClientHello se um verificador de nome de host personalizado fosse usado. Esse verificador é definido via método setHostnameVerifier(HostnameVerifier v) em HttpsURLConnection. A correção garante que o Nome do Servidor agora seja enviado no corpo ClientHello.
Consulte JDK-8144566
Verificação aperfeiçoada de restrições de algoritmo
Com a necessidade de restringir o uso de algoritmos fracos em situações nas quais eles são mais vulneráveis, funcionalidades adicionais foram adicionadas ao configurar as propriedades de segurança jdk.certpath.disabledAlgorithms e jdk.jar.disabledAlgorithms no arquivo java.security.
jdk.certpath.disabledAlgorithms: A propriedade certpath foi a que teve a alteração mais significativa. Anteriormente, ela era limitada a dois tipos de Restrição; ou a desativação total de um algoritmo por nome ou uma desativação total de um algoritmo pelo tamanho da chave, ao verificar certificados, cadeias de certificados e assinaturas de certificado. Isso cria configurações que são absolutas e não têm flexibilidade de uso. Três novas Restrições foram adicionadas para conferir mais flexibilidade ao aceitar e rejeitar certificados.

"jdkCA" examina a terminação da cadeia de certificados com relação ao arquivo cacerts. No caso de "SHA1 jdkCA". O uso de SHA1 é verificado por meio da cadeia de certificados, mas a cadeia deve terminar em uma âncora confiável marcada no armazenamento de chaves cacerts para ser rejeitada. Isso é útil para organizações que têm sua própria autoridade de certificação privada que confia no uso de SHA1 com sua âncora confiável, mas deseja bloquear o uso de SHA1 por cadeias de certificados ancorados por uma autoridade de certificação pública.

"denyAfter" verifica se a data fornecida é anterior à data atual ou à data de PKIXParameter. No caso de "SHA1 denyAfter 2018-01-01", antes de 2018, um certificado com SHA1 poderá ser usado, mas após essa data, o certificado será rejeitado. Isso pode ser usado para uma política em toda uma organização que está excluindo gradativamente um algoritmo com uma data limite. Para arquivos JAR assinados, a data é comparada com o timestamp da TSA. A data é especificada em GMT.

"usage" examina o algoritmo especificado quanto a um uso especificado. Isso pode ser usado quando não for prático desativar um algoritmo para todos os usos. Há três usos que podem ser especificados:
- 'TLSServer' restringe o algoritmo em cadeias de certificados de servidor TLS quando a autenticação do servidor é efetuada como um cliente.
- 'TLSServer' restringe o algoritmo em cadeias de certificados de cliente TLS quando a autenticação do cliente é efetuada como um servidor.
- 'SignedJAR' restringe os algoritmos em certificados de arquivos JAR assinados. O tipo de uso segue a palavra-chave e mais de um tipo pode ser especificado com um delimitador de espaço em branco.
  Por exemplo, "SHA1 usage TLSServer TLSClient" proibiria certificados SHA1 para operações TLSServer e TLSClient, mas SignedJars seria permitido
Todas essas restrições podem ser combinadas para restringir um algoritmo quando delimitado por '&'. Por exemplo, para desativar cadeias de certificados SHA1 que terminam em âncoras confiáveis marcadas somente para operações TLSServer, a restrição seria "SHA1 jdkCA & usage TLSServer".

jdk.jar.disabledAlgorithms: Uma restrição adicional foi adicionada a esta propriedade .jar para restringir algorimtos de manifesto JAR.

"denyAfter" verifica restrições de algoritmo em algoritmos de compilação de manifesto dentro de um arquivo JAR assinado. A data fornecida na restrição é comparada com o timestamp da TSA no arquivo JAR assinado. Se não houver um timestamp ou ele coincidir com a data especificada ou se situar depois dela, o arquivo JAR assinado será tratado como não assinado. Se o timestamp for anterior à data especificada, o .jar operará como um arquivo JAR assinado. A sintaxe para restringir SHA1 em arquivos JAR assinados após 1º de janeiro de 2018 é: "SHA1 denyAfter 2018-01-01". A sintaxe é a mesma que a da propriedade certpath; porém, a verificação do certificado não será feita por essa propriedade.
Consulte JDK-8176536

Data de Expiração do Java

A data de expiração para 8u141 é 17 de outubro de 2017. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u141) em 17 de novembro de 2017. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o JRE fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u141

Java 8 Update 131 (8u131)

Destaques da Release

Dados de IANA 2016j
O JDK 8u131 contém a versão 2016j dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: Introdução do novo modelo de classificação da janela
Na plataforma OS X, a estrutura AWT usou serviços nativos para implementar relacionamento pai-filho para janelas. Isso causou alguns efeitos visuais negativos, principalmente em ambientes com vários monitores. Para evitar as desvantagens de tal abordagem, foi introduzido o novo modelo de classificação da janela, que é totalmente implementado na camada JDK. Seus principais princípios são listados abaixo:
- Uma janela deve ser colocada acima de sua janela mãe mais próxima.
- Se uma janela tiver várias janelas filhas, todas as janelas filhas deverão ser colocadas na mesma camada e a janela da cadeia de janelas ativas deverá ser ordenada acima de suas irmãs.
- A classificação não deve ser executada para uma janela que está em um estado iconificado ou quando uma transição para um estado iconificado estiver em andamento.
Estas regras são aplicadas a cada quadro ou caixa de diálogo da hierarquia de janelas que contém a janela focada atualmente. Consulte JDK-8169589
Correção de Bug: Correção de IllegalArgumentException do handshake TLS
Um problema recente da correção JDK-8173783 pode causar problemas em alguns servidores TLS. O problema vem de uma IllegalArgumentException emitida pelo código de handshaker TLS:

java.lang.IllegalArgumentException: A propriedade do sistema jdk.tls.namedGroups(null) não contém curvas elípticas suportadas

O problema pode surgir quando o servidor não tem suporte a criptografia de curva elíptica para identificar um campo de extensão de nome de curva elíptica (se houver). É recomendável que os usuários façam upgrade para esta release. Por padrão, as Atualizações de JDK 7 e das famílias JDK veem com um provedor de segurança SunEC que fornece suporte à criptografia de curva elíptica. Essas releases não deverão ser impactadas, a menos que os provedores de segurança sejam modificados. Consulte JDK-8173783
MD5 adicionado à propriedade de Segurança jdk.jar.disabledAlgorithms
Esta release do JDK apresenta uma nova restrição sobre como é feita a verificação de arquivos JAR com assinatura MD5. Se o arquivo JAR assinado usar MD5, as operações de verificação de assinatura vão ignorar a assinatura e tratar o JAR como se ele fosse não assinado. Isso pode acontecer nos seguintes tipos de aplicativos que usam arquivos JAR assinados:
- Applets ou Aplicativos Web Start
- Aplicativos Standalone ou de Servidor executados com um SecurityManager ativado e que são configurados com um arquivo de política que concede permissões com base no(s) assinante(s) de código do JAR.
A lista de algoritmos desativados é controlada por meio da propriedade de segurança, jdk.jar.disabledAlgorithms, no arquivo java.security. Essa propriedade contém uma lista de algoritmos e tamanhos de chave desativados para arquivos JAR assinados criptograficamente.

Para verificar se uma chave ou um algoritmo fraco foi utilizado para assinar um arquivo JAR, você pode usar o binário jarsigner que acompanha este JDK. A execução de "jarsigner -verify" em um arquivo JAR assinado com uma chave ou um algoritmo fraco imprimirá mais informações sobre a chave ou o algoritmo desativado.

Por exemplo, para verificar um arquivo JAR chamado test.jar, use este comando:

jarsigner -verify test.jar

Se o arquivo desse exemplo tivesse sido assinado com um algoritmo de assinatura fraco, como MD5withRSA, este resultado seria exibido:

O jar será tratado como não assinado, porque foi assinado com um algoritmo fraco que agora está desativado. Reexecute o jarsigner com a opção -verbose para ver mais detalhes.

Mais detalhes podem ser exibidos usando a opção detalhada:

jarsigner -verify -verbose test.jar

A seguinte saída seria exibida:
```
 - Signed by "CN=weak_signer" Digest algorithm: MD5 (weak) Signature algorithm: MD5withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key 
```
Para resolver o problema, será necessário assinar novamente o arquivo JAR com um tamanho de chave ou de algoritmo mais forte. Como alternativa, as restrições podem ser revertidas removendo da propriedade de segurança jdk.jar.disabledAlgorithms os algoritmos fracos ou tamanhos de chave menores aplicáveis; no entanto, essa opção não é recomendada. Antes de assinar novamente os JARs afetados, remova do JAR a(s) assinatura(s) existente(s). Isso pode ser feito com o utilitário zip, desta forma:

zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA'

Verifique periodicamente o Oracle JRE and JDK Cryptographic Roadmap em http://java.com/cryptoroadmap para obter as restrições planejadas aos JARs assinados e a outros componentes de segurança. JDK-8171121 (não público)
Nova propriedade do sistema para controlar armazenamento no cache para conexão HTTP SPNEGO.
Foi introduzida uma nova propriedade do sistema específica da implementação JDK para controlar armazenamento no cache para conexões HTTP SPNEGO (Negotiate/Kerberos). O armazenamento no cache para conexões HTTP SPNEGO permanece ativado por padrão; dessa forma, se a propriedade não for explicitamente especificada, não haverá alteração de comportamento. Ao conectar-se a um servidor HTTP que usa SPNEGO para negociar autenticação e quando a conexão e autenticação dentro do servidor for bem-sucedida, as informações de autenticação serão armazenadas no cache e reutilizadas para conexões adicionais para o mesmo servidor. Além disso, a conexão a um servidor HTTP que usa SPNEGO geralmente envolve manter a conexão subjacente ativa e reutilizá-la para solicitações adicionais para o mesmo servidor. Em alguns aplicativos, pode ser aconselhável desativar todo o armazenamento no cache do protocolo HTTP SPNEGO (Negotiate/Kerberos) para forçar a solicitação de nova autenticação com cada uma das novas solicitações ao servidor.

Com esta alteração, agora fornecemos uma nova propriedade do sistema que permite controle da política de armazenamento no cache para conexões HTTP SPNEGO. Se jdk.spnego.cache for definida e avaliada como falso, então todo o armazenamento no cache será desativado das conexões HTTP SPNEGO. A definição desta propriedade do sistema como falsa pode, no entanto, resultar em efeitos colaterais não desejados:
- O desempenho das conexões HTTP SPNEGO pode ser muito afetado, pois a conexão precisará ser reautenticada com cada nova solicitação, exigindo várias trocas de comunicação com o servidor.
- Será necessário obter as credenciais novamente para cada nova solicitação, o que, dependendo de se a autenticação transparente está disponível ou não, e dependendo da implementação do Autenticador global, pode resultar em uma janela pop-up solicitando credenciais ao usuário para cada nova solicitação.
JDK-8170814 (não público)
Nova propriedade do sistema para controlar armazenamento no cache para conexão HTTP NTLM.
Foi introduzida uma nova propriedade do sistema específica da implementação JDK para controlar armazenamento no cache para conexão HTTP NTLM. O armazenamento no cache para a conexão HTTP NTLM permanece ativado por padrão; dessa forma, se a propriedade não for explicitamente especificada, não haverá alteração de comportamento. Em algumas plataformas, a implementação HTTP NTLM no JDK pode suportar autenticação transparente, na qual as credenciais do usuário do sistema são usadas em nível de sistema. Quando a autenticação transparente não estiver disponível ou for malsucedida, o JDK só suportará a obtenção de credenciais de um autenticador global. Se a conexão ao servidor for bem-sucedida, as informações de autenticação serão armazenadas no cache e reutilizadas para conexões adicionais para o mesmo servidor. Além disso, a conexão a um servidor NTLM geralmente envolve manter a conexão subjacente ativa e reutilizá-la em solicitações adicionais para o mesmo servidor. Em alguns aplicativos, pode ser aconselhável desativar todo o armazenamento no cache do protocolo HTTP NTLM para forçar a solicitação de nova autenticação com cada uma das novas solicitações ao servidor.

Com esta alteração, agora fornecemos uma nova propriedade do sistema que permite controle da política de armazenamento no cache para conexões HTTP NTLM. Se jdk.ntlm.cache for definida e avaliada como falso, então todo o armazenamento no cache será desativado das conexões HTTP NTLM. A definição desta propriedade do sistema como falsa pode, no entanto, resultar em efeitos colaterais não desejados:
- O desempenho das conexões HTTP NTLM pode ser muito afetado, pois a conexão precisará ser reautenticada com cada nova solicitação, exigindo várias trocas de comunicação com o servidor.
- Será necessário obter as credenciais novamente para cada nova solicitação, o que, dependendo de se a autenticação transparente está disponível ou não, e dependendo da implementação do Autenticador global, pode resultar em uma janela pop-up solicitando credenciais ao usuário para cada nova solicitação.
JDK-8163520 (não público)
Nova versão de VisualVM
A VisualVM 1.3.9 foi lançada em 4 de outubro de 2016 http://visualvm.github.io/relnotes.html e foi integrada na versão 8u131. Consulte JDK-8167485

Data de Expiração do Java

A data de expiração para a release 8u131 é 18 de julho de 2017. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u131) em 18 de agosto de 2017. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory.. Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug 8u131 de JDK.

» Notas da release 8u131

Java 8 Update 121 (8u121)

Destaques da Release

Dados de IANA 2016i
O JDK 8u121 contém a versão 2016i dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: A rolagem de texto no trackpad no OS X 10.12 Sierra é rápida demais
O método MouseWheelEvent.getWheelRotation() retornou eventos nativos arredondados NSEvent deltaX/Y no Mac OS X. O macOS Sierra 10.12 mais recente produz valores deltaX/Y de NSEvent muito pequenos. Portanto, o arredondamento e a soma deles leva ao valor enorme retornado pelo MouseWheelEvent.getWheelRotation(). A correção JDK-8166591 acumula deltax/Y de NSEvent deltaX/Y e o método MouseWheelEvent.getWheelRotation() retorna valores diferentes de zero somente quando o valor acumulado excede um valor limite e um valor zero. Isso é compatível com a especificação MouseWheelEvent.getWheelRotation() : "Retorna o número de 'cliques' que o botão de rolagem do mouse girou, na forma de número inteiro. Uma rotação parcial poderá ocorrer se o mouse suportar um botão de rolagem de alta resolução. Nesse caso, o método retornará zero até que um 'clique' completo tenha sido acumulado". Para saber os valores de rotação precisos do botão de rolagem, use o método MouseWheelEvent.getPreciseWheelRotation(). Consulte JDK-8166591
Aumentar a força padrão de EC no JDK
Para aumentar o poder nativo da criptografia EC, as chaves de EC inferiores a 224 bits foram desativadas no processamento do caminho de certificação (via Propriedade de Segurança jdk.certpath.disabledAlgorithms) e conexões SSL/TLS (via Propriedade de Segurança jdk.tls.disabledAlgorithms) no JDK. Os aplicativos podem atualizar essa restrição nas Propriedades de Segurança e permitir tamanhos de chave menores se for realmente necessário (por exemplo, "EC keySize < 192"). As curvas da EC inferiores a 256 bits são removidas da implementação de SSL/TLS no JDK. A nova Propriedade de Sistema, jdk.tls.namedGroups, define uma lista de curvas nomeadas ativadas para suítes de cifragem EC por ordem de preferência. Se um aplicativo precisar personalizar as curvas EC ativadas padrão ou a preferência de curvas, atualize a Propriedade de Sistema de acordo. Por exemplo:
```
 jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1" 
```
Observe que as curvas EC padrão ativadas ou personalizadas seguem as restrições do algoritmo. Por exemplo, as curvas EC personalizadas não podem reativar as chaves EC desativadas definidas pelas Propriedades de Segurança do Java. Consulte JDK-8148516
Novo -- opção allow-script-in-comments para javadoc
A ferramenta javadoc agora rejeitará qualquer ocorrência de código JavaScript nos comentários da documentação do javadoc e nas opções de linha de comando, a menos que a opção de linha de comando, --allow-script-in-comments, seja especificada. Com a opção --allow-script-in-comments, a ferramenta javadoc preservará o código JavaScript nos comentários da documentação e nas opções de linha de comando. Um erro será gerado pela ferramenta javadoc se o código JavaScript for encontrado e a opção de linha de comando não estiver definida.
JDK-8138725 (não público)
Aumente o tamanho mínimo da chave para 1.024 para Assinaturas XML
O modo de validação seguro da implementação da Assinatura de XML foi aprimorado para restringir chaves RSA e DSA inferiores a 1.024 bits por padrão, pois elas não são seguras o suficiente para assinaturas digitais. Além disso, uma nova propriedade de segurança chamada jdk.xml.dsig.SecureValidationPolicy foi adicionada ao arquivo java.security e poderá ser usada para controlar as diferentes restrições postas em vigor quando o modelo de validação seguro for ativado. O modo de validação seguro é ativado pela definição da propriedade de assinatura de xml org.jcp.xml.dsig.secureValidation para 'true' com o método javax.xml.crypto.XMLCryptoContext.setProperty, ou executando o código com um SecurityManager. Se uma Assinatura XML for gerada ou validada com uma chave RSA ou DSA fraca, uma XMLSignatureException será gerada com a mensagem "Chaves RSA inferiores a 1.024 bits são proibidas quando a validação segura está ativada" ou "Chaves DSA inferiores a 1.024 bits são proibidas quando a validação segura está ativada".
JDK-8140353 (não público)
Certificados restritos com chaves DSA inferiores a 1.024 bits
Chaves DSA inferiores a 1.024 bits não são fortes o suficiente e devem ser restritas na criação e validação do caminho do certificado. De acordo com isso, chaves DSA inferiores a 1.024 bits foram desativadas por padrão adicionando "DSA keySize < 1024" à propriedade de segurança "jdk.certpath.disabledAlgorithms". Os aplicativos podem atualizar essa restrição na propriedade de segurança ("jdk.certpath.disabledAlgorithms") e permitir tamanhos de chave menores, se for realmente necessário (por exemplo, "DSA keySize < 768"). JDK-8139565 (não público)
Mais verificações adicionadas ao código de parsing de codificação DER
Mais verificações são adicionadas ao código de parsing de codificação DER para capturar vários erros de codificação. Além disso, assinaturas que contêm codificação construída com tamanho indefinido agora vão conduzir a uma IOException durante o parsing. Observe que as assinaturas geradas usando provedores padrão de JDK não são afetadas por essa alteração. JDK-8168714 (não público)
Restrições de acesso adicionais para URLClassLoader.newInstance
Carregadores de classe criados pelos métodos java.net.URLClassLoader.newInstance podem ser usados para carregar classes de uma lista de URLs fornecidos. Se o código de chamada não tiver acesso a um ou mais dos URLs, e os artefatos de URL que podem ser acessados não contiverem a classe exigida, uma exceção ClassNotFoundException, ou semelhante, será emitida. Anteriormente, uma SecurityException teria sido gerada quando o acesso a um URL fosse negado. Se for necessário reverter para o comportamento antigo, essa alteração poderá ser desativada definindo a propriedade de sistema jdk.net.URLClassPath.disableRestrictedPermissions. JDK-8151934 (não público)
Uma nova propriedade configurável em logging.properties java.util.logging.FileHandler.maxLocks
Uma nova propriedade configurável "java.util.logging.FileHandler.maxLocks" é adicionada a java.util.logging.FileHandler. Essa nova propriedade de logging pode ser definida no arquivo de configuração de logging e torna possível configurar o número máximo de bloqueios de arquivo de log simultâneos que um FileHandler pode manipular. O valor padrão é 100. Em um ambiente de alta simultaneidade, em que vários (mais de 101) aplicativos clientes standalone estão usando a API de Logging do JDK com o FileHandler simultaneamente, pode acontecer de o limite padrão de 100 ser atingido, resultando em uma falha em adquirir bloqueios de arquivo FileHandler e causando a geração de uma Exceção de E/S. Em um caso como esse, a nova propriedade de logging pode ser usada para aumentar o número máximo de bloqueios antes de implantar o aplicativo. Se não for substituído, o valor padrão de maxLocks (100) permanece inalterado. Consulte a documentação da API java.util.logging.LogManager e java.util.logging.FileHandler para ver mais detalhes. Consulte JDK-8153955

Observações

Proteção aperfeiçoada para carregamento remoto de classe JNDI

Por padrão, o carregamento remoto de classe via factories de objeto JNDI armazenadas em serviços de nomenclatura e diretório está desativado. Para ativar o carregamento remoto de classe pelo Registro RMI ou provedor de serviço de nomenclatura COS, definia a seguinte propriedade do sistema como a string "true", conforme apropriado:


 com.sun.jndi.rmi.object.trustURLCodebase com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (não público)

jarsigner -verbose -verify deve imprimir os algoritmos usados para assinar o arquivo jar

A ferramenta jarsigner foi aperfeiçoada de forma a mostrar detalhes dos algoritmos e chaves usados para gerar um arquivo JAR assinado e também fornecerá uma indicação se qualquer um deles for considerado fraco.

Especificamente, quando "jarsigner -verify -verbose filename.jar" é chamado, uma seção separada é impressa, mostrando informações da assinatura e timestamp (se houver) dentro do arquivo JAR assinado, mesmo que ele seja tratado como não assinado por vários motivos. Se algum algoritmo ou chave usado for considerado fraco, conforme especificado na propriedade de Segurança jdk.jar.disabledAlgorithms ele(a) será identificado(a) com "(weak)".

Por exemplo:


 - Signed by "CN=weak_signer" Digest algorithm: MD2 (weak) Signature algorithm: MD2withRSA (weak), 512-bit key (weak) Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 Timestamp digest algorithm: SHA-256 Timestamp signature algorithm: SHA256withRSA, 2048-bit key

Consulte JDK-8163304

Problemas Conhecidos

javapackager e fx:deploy empacotam todo o JDK em vez do JRE

Há um bug conhecido no Java Packager para Mac no qual todo o JDK pode ser empacotado com o pacote de aplicativos, resultando em um pacote anormalmente grande. A solução alternativa é usar a opção de empacotador -Bruntime. Por exemplo: -Bruntime=JavaAppletPlugin.plugin, em que o JavaAppletPlugin.plugin para que o JRE desejado seja empacotado se localiza no diretório atual. Consulte JDK-8166835

A instalação do Java vai falhar para usuários não admim com o UAC desligado

A instalação do Java no Windows falha sem advertência ou prompt, para usuários não admin com o UAC (User Access Control) desativado. O instalador deixará um diretório, jds<number>.tmp, no diretório %TEMP%.
JDK-8161460 (não público)

Novas Funcionalidades

Foi adicionada a propriedade de segurança para configurar o modo de validação segura de Assinatura XML

Foi adicionada uma nova propriedade de segurança chamada jdk.xml.dsig.secureValidationPolicy que permite configurar as restrições individuais que são impostas quando o modo de validação segura de Assinatura XML está ativado. O valor padrão dessa propriedade no arquivo de configuração java.security é:


 jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ noDuplicateIds,\ noRetrievalMethodLoops

Consulte a definição da propriedade no arquivo java.security para obter mais informações. Consulte JDK-8151893

Configuração do Filtro de Serialização

A Filtragem de Serialização apresenta um novo mecanismo que permite que fluxos de entrada de dados de serialização de objetos sejam filtrados para aumentar a segurança e a solidez. Cada ObjectInputStream se aplica a um filtro, se estiver configurado, ao conteúdo do fluxo durante a desserialização. Os filtros são definidos usando uma propriedade de sistema ou uma propriedade de segurança configurada. O valor dos padrões "jdk.serialFilter" são descritos em JEP 290 Serialization Filtering e em <JRE>/lib/security/java.security. As ações de filtro são registradas no logger 'java.io.serialization', se estiver ativado. Consulte JDK-8155760

Melhor verificação de restrição de RMI

O Registro RMI e e a Coleta de Lixo Distribuída usam os mecanismos de Filtragem de Serialização JEP 290 para aumentar a solidez do serviço. O Registro RMI e a DGC implementam filtros de lista branca incorporados para as classes típicas que se espera que sejam usadas com cada serviço. Padrões de filtro adicionais podem ser configurados usando uma propriedade de sistema ou de segurança. A sintaxe padrão da propriedade "sun.rmi.registry.registryFilter" e "sun.rmi.transport.dgcFilter" é descrita em JEP 290 e em <JRE>/lib/security/java.security. JDK-8156802 (não público)

Adicione o mecanismo para permitir que CAs raiz não padrão não estejam sujeitas a restrições de algoritmo

No arquivo java.security, uma restrição adicional chamada "jdkCA" é adicionada à propriedade jdk.certpath.disabledAlgorithms. Essa restrição só proibirá o algoritmo especificado se ele for usado em uma cadeia de certificados que termina com a marcação de uma âncora de confiança na área de armazenamento de chaves lib/security/cacerts. Se a restrição jdkCA não for definida, todas as cadeias que usarem o algoritmo especificado serão restritas. jdkCA só pode ser usado uma vez em uma expressão DisabledAlgorithm. Exemplo: para aplicar essa restrição aos certificados SHA-1, inclua SHA1 jdkCA
Consulte JDK-8140422

Data de Expiração do Java

A data de expiração do 8u121 é 18 de abril de 2017. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar Oracle Servers, um mecanismo secundário expira este JRE (versão 8u121) em 18 de maio de 2017. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u121

Java 8 Update 111 (8u111)

Destaques da Release

Dados da IANA 2016f
O JDK 8u111 contém a versão 2016f dos dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE. Consulte JDK-8159684.
Alterações de Certificado: Nova CA Raiz de Assinatura de Código JCE
Para suportar tamanhos de chave maiores e algoritmos de assinatura mais fortes, uma nova autoridade de certificação raiz de Assinatura de Código do Provedor JCE foi criada e seu certificado adicionado ao Oracle JDK. Os novos certificados de assinatura de código do provedor JCE emitidos por essa CA serão usados para assinar provedores JCE daqui em diante. Por padrão, as novas solicitações de certificados de assinatura de código do provedor JCE serão emitidas por essa CA.

Os certificados existentes da raiz de assinatura de código do provedor JCE atual continuarão válidos. No entanto, essa CA raiz poderá ser desativada futuramente. É recomendável que os novos certificados sejam solicitados e os JARs existentes do provedor sejam novamente assinados. Para obter detalhes sobre o processo de assinatura do provedor JCE, consulte a documentação How to Implement a Provider in the Java Cryptography Architecture. JDK-8141340 (não público)
Serviços do Menu de Serviços
O gerenciamento de ciclo de vida dos componentes de menu AWT apresentavam problemas em algumas plataformas. Esta correção melhora a sincronização de estado entre os menus e seus contêineres. JDK-8158993 (não público)
Desativar autenticação Básica para encapsulamento HTTPS
Em alguns ambientes, determinados esquemas de autenticação podem ser indesejáveis ao usar proxy HTTPS. Assim, o esquema de autenticação Básica foi desativado, por padrão, no Oracle Java Runtime, adicionando Basic à propriedade de rede jdk.http.auth.tunneling.disabledSchemes. Agora, os proxies que exigem autenticação Basic ao configurar um túnel para HTTPS não obterão mais êxito por padrão. Se necessário, esse esquema de autenticação poderá ser reativado, removendo Basic da propriedade de rede jdk.http.auth.tunneling.disabledSchemes ou definindo uma propriedade de sistema do mesmo nome como "" (vazio) na linha de comando. Além disso, as propriedades de rede jdk.http.auth.tunneling.disabledSchemes e jdk.http.auth.proxying.disabledSchemes e as propriedades de sistema do mesmo nome podem ser usadas para desativar outros esquemas de autenticação que podem estar ativos ao configurar um túnel para HTTPS, ou ao usar proxy de HTTP simples, respectivamente. JDK-8160838 (não público)
JARs restritos assinados com algoritmos e chaves fracos
Esta release do JDK apresenta novas restrições de como os arquivos JAR assinados são verificados. Se o arquivo JAR assinado usar um algoritmo desativado ou tamanho de chave menor que o mínimo, as operações de verificação de assinatura vão ignorar a assinatura e tratar o arquivo JAR como se ele fosse não assinado. Isso pode acontecer nos seguintes tipos de aplicativos que usam arquivos JAR assinados:
1. Applets ou Aplicativos Web Start
2. Aplicativos Standalone ou de Servidor executados com um SecurityManager ativado e que são configurados com um arquivo de política que concede permissões com base no(s) assinante(s) de código do JAR.

A lista de algoritmos desativados é controlada por meio de uma nova propriedade de segurança, jdk.jar.disabledAlgorithms, no arquivo java.security. Essa propriedade contém uma lista de algoritmos e tamanhos de chave desativados para arquivos JAR assinados criptograficamente.

Os seguintes algoritmos e tamanhos de chave são restritos nesta release:
1. MD2 (no algoritmo de compilação ou assinatura)
2. Chaves RSA menores que 1024 bits
OBSERVAÇÃO: Estamos planejando restringir assinaturas baseadas em MD5 em JARS assinados na CPU de abril de 2017.

Para verificar se uma chave ou um algoritmo fraco foi utilizado para assinar um arquivo JAR, você pode usar o binário jarsigner que acompanha este JDK. A execução de jarsigner -verify -J-Djava.security.debug=jar em um arquivo JAR assinado com uma chave ou um algoritmo fraco imprimirá mais informações sobre a chave ou o algoritmo desativado.

Por exemplo, para verificar um arquivo JAR chamado test.jar, use este comando:
jarsigner -verify -J-Djava.security.debug=jar test.jar

Se o arquivo neste exemplo fosse assinado com um algoritmo de assinatura fraco, como MD2withRSA, esta saída seria exibida:
jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!

O comando atualizado jarsigner sairá com a seguinte advertência impressa para a saída padrão:
"Assinatura não passível de parsing ou verificável. O jar será tratado como não assinado. O jar pode ter sido assinado com um algoritmo fraco que agora está desativado. Para obter mais informações, execute novamente jarsigner com a depuração ativada (-J-Djava.security.debug=jar)"

Para tratar o problema, o arquivo JAR precisará ser novamente assinado com um algoritmo mais forte ou tamanho de chave maior. Como alternativa, as restrições podem ser revertidas removendo da propriedade de segurança jdk.jar.disabledAlgorithms os algoritmos fracos ou tamanhos de chave menores aplicáveis; no entanto, essa opção não é recomendada. Antes de assinar novamente os arquivos JAR afetados, remova do JAR a(s) assinatura(s) existente(s). Isso pode ser feito com o utilitário zip, desta forma:

zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

Verifique periodicamente o Oracle JRE and JDK Cryptographic Roadmap em http://java.com/cryptoroadmap para obter as restrições planejadas aos arquivos JAR assinados e a outros componentes de segurança. Especificamente, lembre-se de que o plano atual é restringir assinaturas baseadas em MD5 em arquivos JAR assinados na CPU de abril de 2017.

Para saber se seus JARs foram assinados com MD5, adicione MD5 à propriedade de segurança jdk.jar.disabledAlgorithms; por exemplo:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

e, em seguida, execute jarsigner -verify -J-Djava.security.debug=jar em seus arquivos JAR conforme descrito acima.
JDK-8155973 (não público)
Mensagem de advertência adicionada à caixa de diálogo do autenticador de implantação
Uma advertência foi adicionada à caixa de diálogo de autenticação de plug-in nos casos de uso da autenticação Básica HTTP (credenciais são enviadas sem criptografia) ao utilizar um proxy ou quando não se utiliza protocolos SSL/TLS:
"ADVERTÊNCIA: O esquema de autenticação Básica transmitirá efetivamente suas credenciais em texto simples. Deseja realmente fazer isso?"
JDK-8161647 (não público)

Problemas Conhecidos

Alguns eventos não disponíveis nos registros JFR do Windows

Os seguintes eventos não estão disponíveis nos registros JFR do Windows para a release 8u111:

hotspot/jvm/os/processor/cpu_load
os/processor/context_switch_rate

O motivo disso é o JDK-8063089 de regressão que foi introduzido na 8u111 com as alterações do JDK-8162419. A correção do JDK-8063089 não pôde ser incluída na release 8u111. Ela estará disponível no próximo build do BPR 8u111 e no próximo lançamento público.
JDK-8063089 (não público)

A JVM gera NullPointerExceptions no macOS Sierra 10.12

No macOS Sierra 10.12, se um usuário pressionar teclas modificadoras (como Command, Shift ou Alt) enquanto um applet estiver em execução em um browser, uma caixa de erro chamada "Erro Interno" poderá ser exibida. Ela também mostrará o ícone "exec" no dock do macOS. O usuário pode descartar o applet ou tentar reexecutá-lo enquanto não estiver pressionando uma tecla modificadora. Consulte JDK-8165867.

Data de Expiração do Java

A data de expiração para 8u111 é 17 de janeiro de 2017. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário fará com que este JRE (versão 8u111) expire em 17 de fevereiro de 2017. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

» Notas da release 8u111

Java 8 Update 101 (8u101)

Destaques da Release

Dados de IANA 2016d
O JDK 8u101 contém a versão 2016d dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE. Consulte JDK-8151876.
Alterações no Certificado
Novos certificados DTrust adicionados às autoridades de certificação-raiz
Dois novos certificados-raiz foram adicionados:
- D-TRUST Root Class 3 CA 2 2009 alias: dtrustclass3ca2 DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
- D-TRUST Root Class 3 CA 2 EV 2009 alias: dtrustclass3ca2ev DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
Consulte JDK-8153080

Novos certificados Iden adicionados às autoridades de certificação-raiz
Três novos certificados-raiz foram adicionados:
- IdenTrust Public Sector Root CA 1 alias: identrustpublicca DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
- IdenTrust Commercial Root CA 1 alias: identrustcommercial DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
- IdenTrust DST Root CA X3 alias: identrustdstx3 DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
Consulte JDK-8154757

Autoridade de Certificação-Raiz Comodo removida
O certificado da Autoridade de Certificação-raiz Comodo "UTN - DATACorp SGC" foi removido do arquivo cacerts. Consulte JDK-8141540

Autoridade de Certificação Sonera Class1 removida
O certificado da Autoridade de Certificação-raiz "Sonera Class1 CA" foi removido do arquivo cacerts. Consulte JDK-8141276.
Melhorar o controle de acesso a javax.rmi.CORBA.ValueHandler
A classejavax.rmi.CORBA.Util fornece métodos que podem ser usados por stubs e ties para executar operações comuns. Ela também atua como factory para ValueHandlers. A interface javax.rmi.CORBA.ValueHandler fornece serviços para suportar a leitura e gravação de tipos de valor para fluxos GIOP. A metodologia de segurança desses utilitários foi aperfeiçoada com a introdução de uma permissão java.io.SerializablePermission("enableCustomValueHandler"). Ela é usada para estabelecer uma relação de confiança entre os usuários das APIs javax.rmi.CORBA.Util e javax.rmi.CORBA.ValueHandler.

A permissão exigida é "enableCustomValueHanlder" SerializablePermission. Um código de terceiros executado com um SecurityManager instalado, mas que não tenha a nova permissão ao chamar Util.createValueHandler() vai falhar com uma AccessControlException.

Esse comportamento de verificação de permissão pode ser substituído, no JDK8u e em versões anteriores, definindo uma propriedade do sistema, "jdk.rmi.CORBA.allowCustomValueHandler".

Como tal, aplicativos externos que chamam explicitamente javax.rmi.CORBA.Util.createValueHandler requerem uma alteração de configuração para funcionar quando um SecurityManager está instalado e nenhum dos dois seguintes requisitos é atendido:
1. A java.io.SerializablePermission("enableCustomValueHanlder") não é concedida pelo SecurityManager.
2. No caso de aplicativos executados no JDK8u e versões anteriores, a propriedade do sistema "jdk.rmi.CORBA.allowCustomValueHandler" não está definida ou então está definida como "false" (sem distinção entre maiúsculas e minúsculas).
Observe que o typo "enableCustomValueHanlder" será corrigido nas versões de outubro de 2016. Nessas e em futuras releases do JDK, "enableCustomValueHandler" será a SerializationPermission correta a ser usada.
JDK-8079718 (não público)
Suporte adicionado a jarsigner para especificar um algoritmo hash de timestamp
Uma nova opção -tsadigestalg é adicionada a jarsigner para especificar o algoritmo message digest que é usado para gerar a impressão da mensagem a ser enviada ao servidor TSA. Em releases mais antigas do JDK, o algoritmo message digest usado era SHA-1. Se essa nova opção não for especificada, o SHA-256 será usado nas Atualizações do JDK 7 e em versões mais recentes da família JDK. Em Atualizações do JDK 6, o SHA-1 continuará sendo o padrão, mas uma advertência será impressa no fluxo de saída padronizado. Consulte JDK-8038837
MSCAPI KeyStore pode manipular certificados com o mesmo nome
Java SE KeyStore não permite certificados que tenham os mesmos aliases. No entanto, no Windows, vários certificados armazenados em um armazenamento de chaves podem ter nomes simples não exclusivos. A correção para JDK-6483657 possibilita a operação em tais certificados com nomes não exclusivos por meio da API do Java, tornando os aliases visíveis exclusivos de forma artificial. Observe que essa correção não permite a criação de certificados com o mesmo nome com a API do Java. Ela só permite que você lide com certificados com o mesmo nome que tenham sido adicionados ao armazenamento de chaves por ferramentas de terceiros. Ainda é recomendável que o seu projeto de sistema não use vários certificados com o mesmo nome. Em particular, a seguinte sentença não será removida da documentação do Java:
"Para evitar problemas, recomenda-se não usar aliases em um Armazenamento de Chaves que só apresente diferença de letras maiúsculas ou minúsculas."
Consulte JDK-6483657.
Métodos da API do Kit de Ferramentas de Implantação não instalam mais o JRE
Os métodos da API do Kit de Ferramentas de Implantação installLatestJRE() e installJRE(requestedVersion) do deployJava.js e o método install() do dtjava.js não instalam mais o JRE. Caso a versão do Java de um usuário esteja abaixo da linha de base de segurança, ela redirecionará o usuário para o java.com para obter um JRE atualizado. JDK-8148310 (não público)
DomainCombiner não vai mais consultar a política de run-time para objetos ProtectionDomain estáticos ao combinar objetos ProtectionDomain
Os aplicativos que usam objetos ProtectionDomain estáticos (criados usando o construtor que contém 2 argumentos) com um conjunto de permissões insuficiente agora podem obter uma AccessControlException com essa correção. Eles devem substituir os objetos ProtectionDomain estáticos por outros dinâmicos (usando o construtor com 4 argumentos) cujo conjunto de permissões seja expandido pela Política atual ou construir o objeto ProtectionDomain estático com todas as permissões necessárias. JDK-8147771 (não público)

Problemas Conhecidos

O JRE 8u101 não é reconhecido pelo Internet Explorer (IE) ao usar o ID de classe estática

Quando um id de classe estática é usado para iniciar um applet ou aplicativo web start ao usar o JRE 8u101, os usuários veem uma caixa de diálogo indesejada declarando que ou eles devem usar o JRE mais recente ou cancelar a inicialização, mesmo que tenham instalado e estejam usando o JRE mais recente (JRE 8u101). Este caso específico só se aplica no Windows e no IE.

Não recomendamos o uso de id de classe estática para a seleção de versão do JRE (desde o JDK 5u6, dezembro de 2005) conforme a referência http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

Para contornar esse problema, os usuários podem tomar uma destas duas providências:

Iniciar com a versão mais recente (8u101) e ignore a advertência.
Instalar o JRE 8u102 em vez do JRE 8u101 para evitar esse problema.

Para resolver esse problema, os desenvolvedores podem tomar uma destas duas providências:

Usar um id de classe dinâmica em vez de um id de classe estática.
Usar java_version ao utilizar um applet HTML ou um descritor JNLP ao usar JNLP.

JDK-8147457 (não público)

Correções de Bug

Data de Expiração do Java

A data de expiração para 8u101 é 19 de outubro de 2016. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u101) em 19 de novembro de 2016. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

» Notas da release 8u101

Java 8 Update 91 (8u91)

Destaques da Release

Dados de IANA 2016a
O JDK 8u91 contém a versão 2016a dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: Regressão no horário de inicialização do Applet corrigida
O JDK-8080977 introduziu um retardo na inicialização do applet. O retardo só aparece no IE e dura cerca de 20 segundos. O JDK-8136759 removeu esse retardo. Consulte JDK-8136759
Correção de Bug: A geração de assinatura DSA agora está sujeita a uma verificação de força da chave
Para geração de assinatura, se o nível de segurança do algoritmo digest for mais fraco do que o nível de segurança da chave usada para fazer a assinatura (por exemplo, usar chaves DSA de 2048, 256 bits com assinatura SHA1withDSA), a operação falhará com a mensagem de erro: "O nível de segurança do algoritmo digest SHA1 não é suficiente para esse tamanho de chave." JDK-8138593 (não público)
Correção de Bug: Problema de liveconnect do Firefox 42
Como isso pode fazer com que o browser trave, não processamos as chamadas do JavaScript para Java quando o plug-in Java é iniciado com base no arquivo plugin-container.exe (o comportamento padrão para o Firefox 42) e o status do applet é Não Está Pronto(2). Se o applet não estiver pronto (o status não for 2), não executaremos o método Java real e só retornaremos o valor nulo.

Se o plug-in for iniciado com base no arquivo plugin-container.exe, não use chamadas JavaScript para Java, que podem precisar de mais do que 11 segundos (o valor padrão de dom.ipc.plugins.hangUITimeoutSecs) para serem concluídas nem mostre uma caixa de diálogo modal durante a chamada JavaScript-para-Java. Nesse caso, o thread principal do browser deverá ser bloqueado, o que pode causar suspensão do browser e o encerramento do plug-in.

Solução alternativa para o Firefox 42: Os usuários podem definir dom.ipc.plugins.enabled=false. O efeito colateral dessa solução alternativa é que ela altera a definição de todos os plug-ins. JDK-8144079 (não público)
Correção de Bug: Um novo atributo para servidores JMX RMI JRMP especifica uma lista de nomes de classe a serem usados ao desserializar credenciais do servidor
Um novo atributo java foi definido para o ambiente a fim de permitir que um servidor JMX RMI JRMP especifique uma lista de nomes de classe. Esses nomes correspondem ao fechamento de nomes de classes que são esperados pelo servidor ao desserializar credenciais. Por exemplo, se as credenciais esperadas fossem um(a)
```
 List<string>
```
o fechamento constituiria todas as classes concretas que deveriam ser esperadas na forma serial de uma lista de Strings.

Por padrão, esse atributo é usado só pelo agente padrão com o seguinte:
```
 { "[Ljava.lang.String;", "java.lang.String" } 
```
Só matrizes de Sequências de Caracteres e Sequências de Caracteres serão aceitas ao desserializar as credenciais. O nome do atributo é:
```
"jmx.remote.rmi.server.credential.types" 
```
Veja a seguir um exemplo de um usuário que está iniciando um servidor com os nomes de classes de credenciais especificadas:
```
 Map<string, object=""> env = new HashMap<>(1); env.put ( "jmx.remote.rmi.server.credential.types", new String[]{ String[].class.getName(), String.class.getName() } ); JMXConnectorServer server = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer); 
```
A nova funcionalidade deve ser usada especificando diretamente:
"jmx.remote.rmi.server.credential.types"

JDK-8144430 (não público)
Correção de Bug: Desativar o algoritmo de assinatura MD5withRSA no provedor JSSE
O algoritmo de assinatura MD5withRSA agora é considerado como não seguro e não deve mais ser usado. Assim, o MD5withRSA foi desativado por padrão na implementação do Oracle JSSE adicionando "MD5withRSA" à propriedade de segurança "jdk.tls.disabledAlgorithms". Agora, as mensagens de handshake TLS e os certificados X.509 assinados com o algoritmo MD5withRSA não são mais aceitos por padrão. Essa alteração se estende à restrição anterior do certificado baseado em MD5 ("jdk.certpath.disabledAlgorithms") para também incluir mensagens de handshake na versão TLS 1.2. Se necessário, esse algoritmo pode ser reativado removendo "MD5withRSA" da propriedade de segurança "jdk.tls.disabledAlgorithms". JDK-8144773 (não público)
Correção de Bug: Novos certificados adicionados às autoridades de certificação-raiz
Oito novos certificados-raiz foram adicionados:
- QuoVadis Root CA 1 G3 alias: quovadisrootca1g3 DN: CN=QuoVadis Root CA 1 G3, O=QuoVadis Limited, C=BM
- QuoVadis Root CA 2 G3 alias: quovadisrootca2g3 DN: CN=QuoVadis Root CA 2 G3
- QuoVadis Root CA 3 G3 alias: quovadisrootca3g3 DN: CN=QuoVadis Root CA 3 G3, O=QuoVadis Limited, C=BM
- DigiCert Assured ID Root G2 alias: digicertassuredidg2 DN: CN=DigiCert Assured ID Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Assured ID Root G3 alias: digicertassuredidg3 DN: CN=DigiCert Assured ID Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G2 alias: digicertglobalrootg2 DN: CN=DigiCert Global Root G2, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Global Root G3 alias: digicertglobalrootg3 DN: CN=DigiCert Global Root G3, OU=www.digicert.com, O=DigiCert Inc, C=US
- DigiCert Trusted Root G4 alias: digicerttrustedrootg4 DN: CN=DigiCert Trusted Root G4, OU=www.digicert.com, O=DigiCert Inc, C=US
Consulte JDK-8145954 e JDK-8145955.

Observações

Remoção de JREs Estáticos
Os instaladores Java para Windows que foram lançados antes da versão 8u91 não removiam por padrão JREs instalados estaticamente. Para remover JREs que foram instaladas estaticamente, os usuários tinham que selecionar manualmente esses JREs na interface de usuário do instalador do Java. Agora, nas releases do Java 8u91 e mais recentes, os JREs que foram instalados estaticamente serão removidos de forma automática, se estiverem abaixo da linha de base de segurança. Para obter mais informações sobre a instalação estática, consulte Java Runtime Environment Configuration.

Data de Expiração do Java

A data de expiração para a release 8u91 é 19 de julho de 2016. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar Oracle Servers, um mecanismo secundário expirará esta versão do JRE (versão 8u91) em 19 de agosto de 2016. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory.. Para obter uma lista de correções de bug incluída nesta release, consulte a página Correções de Bug JDK 8u91.

» Notas da release 8u91

Java 8 Update 77 (8u77)

Destaques da Release

Dados de IANA 2016a
O JDK 8u77 contém a versão 2016a dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.

Data de Expiração do Java

A data de expiração do 8u77 é 19 de abril de 2016. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expira este JRE (versão 8u77) em 19 de maio de 2016. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Observações

Este Alerta de Segurança (8u77) se baseia na release anterior 8u74 PSU. Todos os usuários das releases anteriores do JDK 8 devem atualizar para essa release. Para obter mais informações sobre a diferença entre as Atualizações de Patch Crítico e as Atualizações de Conjunto de Patches, visite Java CPU and PSU Releases Explained.

As demonstrações, amostras e pacotes de Documentação da versão 8u77 não são impactados pelo Alerta de Segurança para CVE-2016-0636; portanto, as demonstrações, amostras e pacotes de Documentação da versão 8u73 permanecem sendo a versão mais atualizada até a versão de abril da Atualização de Patch Crítico.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory..

» Notas da release 8u77

Java 8 Update 73 (8u73)

Destaques da Release

Dados de IANA 2015g
O JDK 8u71 contém a versão 2015g dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.

Data de Expiração do Java

A data de expiração da versão 8u73 é 19 de abril de 2016. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u73) em 19 de maio de 2016. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Observações

A Oracle recomenda que os usuários do Java que fizeram download das versões afetadas e planejam instalações futuras dessas versões, descartem os downloads antigos. Nenhuma ação é necessária para os usuários do Java que instalaram as versões de Atualização de Patch Crítico de janeiro de 2016 do Java SE 6, 7 ou 8. Os usuários do Java que não instalaram as versões de Atualização de Patch Crítico de janeiro de 2016 do Java SE 6, 7 ou 8 devem fazer upgrade para as releases do Java SE 6, 7 ou 8 usando o Alerta de Segurança para CVE-2016-0603.

As demonstrações, amostras e pacotes de Documentação da versão 8u73 não são impactados pelo Alerta de Segurança para CVE-2016-0603; portanto, as demonstrações, amostras e pacotes de documentação da versão 8u71 permanecem sendo a versão mais atualizada até a versão de abril da Atualização de Patch Crítico.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory.. Observe que a versão 8u73 não contém os builds de PSU encontrados na versão 8u72. Os clientes que precisam de correções de bug adicionais contidas na versão 8u72 devem atualizar para a versão 8u74, em vez de para a versão 8u73.

» Notas da release 8u73

Java 8 Update 71 (8u71)

Destaques da Release

Dados de IANA 2015g
O JDK 8u71 contém a versão 2015g dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: A execução de jps como raiz não mostra todas as informações
Após a correção de JDK-8050807 (corrigida em 8u31, 7u75 e 6u91), a execução de jps como raiz não mostrou todas as informações dos processos Java iniciados por outros usuários em alguns sistemas. Esse problema foi corrigido. Consulte JDK-8075773.
Correção de Bug: Instaladores que parecem estar paralisados em configurações ESC
Os usuários que executam o ESC (Enhance Security Configuration) do Internet Explorer no Windows Server 2008 R2 podem ter tido problemas ao instalar o Java no modo interativo. Esse problema foi resolvido na release 8u71. Os instaladores executados no modo interativo não parecerão mais estar paralisados em configurações ESC. Consulte JDK-8140197.
Correção de Bug: Problema com algoritmos PBE que usam criptografia AES corrigido
Um erro foi corrigido para PBE usando cifragem AES de 256 bits de forma que a chave derivada possa ser diferente e não equivalente às chaves derivadas anteriormente da mesma senha. JDK-8138589 (não público).
Correção de Bug: Limite padrão adicionado para tamanho máximo de entidade XML
Um limite padrão para o tamanho máximo de entidade foi adicionado. Para saber mais sobre os limites de processamento de XML, consulte Os Tutoriais do Java, Limites de Processamento. JDK-8133962 (não público)
Correção de Bug: Problema com a documentação da chave MSI do Enterprise 'REMOVEOLDERJRES' corrigido
A documentação do MSI do Enterprise lista as opções de configuração. Falta a opção REMOVEOLDERJRES usada para desinstalar os JREs antigos. Essa opção foi adicionada com a descrição:
Se for definida como 1, removerá as releases mais antigas do JRE instaladas no sistema.
Padrão: 0 não remove JREs antigos
JDK-8081237 (não público)

Data de Expiração do Java

A data de expiração do 8u71 é 19 de abril de 2016. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u71) em 19 de maio de 2016. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory..

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug JDK 8u71.

» Notas da release 8u71

Java 8 Update 66 (8u66)

Destaques da Release

o build 8u66 18 trata de um problema no Firefox.

Correção de Bug: _releaseObject chamado pelo thread errado
Uma alteração recente no Firefox fez com que a chamada de _releaseObject fosse feita por um thread diferente do thread principal. Isso pode causar uma condição de corrida que pode inadvertidamente ocasionar uma pane no browser. Esse problema foi tratado no build 18 de 8u66. Para obter mais informações, consulte Bugs@Mozilla 1221448. Consulte JDK-8133523.

O plug-in do Java não funciona no Firefox após a instalação do Java

O Firefox 42 poderá sofre pane quando se tentar executar o plug-in Java Soluções alternativas opcionais estão listadas nas Perguntas Mais Frequentes. Consulte JDK-8142908 (não público).

Data de Expiração do Java

A data de expiração do 8u66 é 19 de janeiro de 2016. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u66) em 19 de fevereiro de 2016. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory..

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug do JDK 8u66.

» Notas da release 8u66

Java 8 Update 65 (8u65)

Destaques da Release

Dados de IANA 2015f
O JDK 8u65 contém a versão 2015f dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Suporte à tabela ISO 4217 'Current funds codes' (A.2)
Este aperfeiçoamento inclui suporte para códigos de valores monetários ISO 4217 tabela A.2. Anteriormente, o JDK só suportava as moedas listadas na tabela A.1. Consulte JDK-8074350.
Correção de Bug: [mac osx] Falha na atualização do cliente JRE AU instalado para NEXTVER no Mac 10.11
Um novo instalador é apresentado na release 8u65 para atualizar o OS X para a versão mais recente. O instalador se aplicará tanto a atualizações programadas quanto manuais, e os bundles ficarão disponíveis no java.com e na OTN. Os usuários que enfrentarem problemas de compatibilidade com o novo instalador poderão fazer download e instalar manualmente o instalador ".pkg" disponível no My Oracle Support.
Correção de Bug: O hotspot deve usar a interface PICL para obter o tamanho da linha de cache na SPARC
A biblioteca libpicl agora é necessária nas arquiteturas Solaris/SPARC para determinar o tamanho das linhas de cache. No caso de a biblioteca não estar presente ou o serviço PICL não estar disponível, a JVM exibirá uma advertência e as otimizações do compilador que utilizarem a instrução BIS (Block Initializing Store) serão desativadas. Consulte JDK-8056124.
Correção de Bug: dns_lookup_realm deve ser falso por padrão
A definição dns_lookup_realm no arquivo krb5.conf do Kerberos é por padrão falsa. Consulte JDK-8080637.
Correção de Bug: A pré-carga de libjsig.dylib causa deadlock quando signal() é chamado
Os aplicativos precisam pré-carregar a biblioteca libjsig para ativar o encadeamento de sinais. Anteriormente, no OS X, após a pré-carga de libjsig.dylib, qualquer chamada do código nativo para signal() causava um deadlock. Esse erro foi corrigido. Consulte JDK-8072147.
Correção de Bug: Melhor dinâmica de grupo
Na implementação OpenJDK SSL/TLS/DTLS (provedor de SunJSSE), grupos principais de criptografia Diffie-Hellman seguros são usados por padrão. Os usuários podem personalizar grupos Diffie-Hellman por meio da Propriedade de Segurança, jdk.tls.server.defaultDHEParameters.
Correção de Bug: Pane da VM quando a classe é redefinida com Instrumentation.redefineClasses
A JVM podia sofrer pane quando uma classe era redefinida com Instrumentation.redefineClasses(). A pane podia ser uma falha de segmentação em SystemDictionary::resolve_or_null ou um erro interno com a mensagem 'incompatibilidade da tag com a tabela de erros de resolução'. Esse problema foi corrigido. Consulte JDK-8076110.

Observações

Durante a execução no OSX 10.11 El Capitan, quando o protocolo SIP é ativado, determinadas variáveis de ambiente destinadas a aplicativos de depuração, como DYLD_LIBRARY_PATH podem ser separadas do ambiente durante a execução do Java pela linha de comando ou ao clicar duas vezes em um arquivo JAR. Os aplicativos não devem contar com essas variáveis em um ambiente de produção. Elas se destinam apenas à depuração durante o desenvolvimento.

O MD5 não deve ser usado para assinaturas digitais nas quais a resistência à colisão é necessária. Para impedir o uso do MD5 como algoritmo de assinatura digital durante operações de certificação X.509, MD5 é adicionado à propriedade de segurança jdk.certpath.disabledAlgorithms. Para os aplicativos que ainda estão usando o certificado com assinatura MD5, faça o upgrade do certificado com algoritmo de assinatura fraco logo que possível.

Problemas Conhecidos

[macosx] Problemas de acessibilidade (a11y) à tela de ofertas do patrocinador
Os usuários que utilizam o teclado para acessar interfaces de usuário no instalador do Java não poderão acessar hiperlinks e caixas de seleção nas telas de ofertas de add-on do software. Como solução alternativa para definir preferências relativas ao software de add-on na interface, os usuários podem desativar essas ofertas no painel de controle do Java ou especificar SPONSORS=0 na linha de comandos. Para obter mais informações, consulte as Perguntas Frequentes em Install Java without sponsor offers. Consulte JDK-8061886 (não público).

Data de Expiração do Java

A data de expiração da 8u65 é 19 de janeiro de 2016. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u65) em 19 de fevereiro de 2016. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory..

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug 8u65 de JDK.

» Notas da release 8u65

Java 8 Update 60 (8u60)

Destaques da Release

Dados da IANA 2015e
O JDK 8u60 contém a versão 2015e dos dados de fuso horário da IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: dns_lookup_realm deve ser falso por padrão
A definição dns_lookup_realm no arquivo Kerberos' krb5.conf é por padrão false. Consulte 8080637.
Correção de Bug: Desativar suítes de cifragem RC4
As suítes de cifragem TLS com base em RC4 (por exemplo, TLS_RSA_WITH_RC4_128_SHA) agora são consideradas comprometidas e não devem mais ser usadas (consulte RFC 7465). Assim, as suítes de cifras TLS com base em RC4 foram desativadas por padrão na implementação do Oracle JSSE, adicionando "RC4" à propriedade de segurança "jdk.tls.disabledAlgorithms" e removendo-as da lista de suítes de cifras ativadas padrão. É possível reativar essas suítes de cifras removendo "RC4" da propriedade de segurança "jdk.tls.disabledAlgorithms" no arquivo java.security ou chamando dinamicamente o método Security.setProperty() e também lendo-as na lista de suítes de cifras ativadas, usando os métodos SSLSocket/SSLEngine.setEnabledCipherSuites(). Você também pode usar a opção da linha de comandos -Djava.security.properties para substituir a propriedade de segurança jjdk.tls.disabledAlgorithms. Por exemplo:
java -Djava.security.properties=my.java.security ...
, em que my.java.security é um arquivo que contém a propriedade sem RC4:
jdk.tls.disabledAlgorithms=SSLv3
Mesmo com esta opção definida pela linha de comando, as suítes de cifragem baseadas em RC4 precisam ser readicionadas à lista de suítes de cifragem usando os métodos SSLSocket/SSLEngine.setEnabledCipherSuites(). Consulte 8076221.
Correção de Bug: Suportar detecção do tipo de área de armazenamento de chaves JKS e PKCS12
Modo de Compatibilidade do Armazenamento de Chaves: para auxiliar na interoperabilidade, o tipo de armazenamento de chaves Java JKS agora suporta o modo de compatibilidade do armazenamento de chaves por padrão. Esse modo permite que as áreas de armazenamento de chaves JKS acessem os formatos de arquivo JKS e PKCS12. Para desativar o modo de compatibilidade da área de armazenamento de chaves, defina a propriedade de Segurança keystore.type.compat com o valor de string falso. Consulte 8062552.
Correção de Bug: Tornar obsoletos métodos de monitoramento Não Seguros na release do JDK 8u
Os métodos monitorEnter, monitorExit e tryMonitorEnter em sun.misc.Unsafe estão marcados como obsoletos no JDK 8u60 e serão removidos em uma release futura. Esses métodos não são usados no próprio JDK e muito raramente são usados fora dele. Consulte 8069302.
Correção de Bug: Extrair gravação do JFR do arquivo básico usando o SA
DumpJFR é uma ferramenta com base no Serviceability Agent que pode ser usada para extrair dados do JFR (Java Flight Recorder) dos arquivos básicos e dos processos de Hotspot ativo. O DumpJFR pode ser usado em um dos seguintes métodos:
- Anexe DumpJFR a um processo ativo:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883097
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
- Anexe DumpJFR a um arquivo principal:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883117
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
A ferramenta DumpJFR faz dump dos dados do JFR para um arquivo chamado recording.jfr na pasta de trabalho atual. Consulte 8065301 (não público).
Correção de Bug: Variáveis locais chamadas 'enum' levam a falsos travamentos do compilador
O parser javac está fazendo parsing incorretamente das variáveis locais com o nome 'enum'; isso resulta em falhas falsas quando um programa que contém essas variáveis locais é compilado com um flag 'source' correspondente a uma release na qual a construção de enumeração não está disponível (como '-source 1.4'). Consulte 8069181.

Java Development Kit para ARM Release 8u60

Esta release inclui o Java Development Kit para ARM Release 8u60 (JDK 8u60 para ARM). Para obter informações de suporte ao dispositivo ARM, consulte a página Downloads de JDK para ARM. Para ver requisitos do sistema, instruções de instalação e dicas de diagnóstico e solução de problemas, consulte Instruções de Instalação.

Limitação: O suporte a Native Memory Tracking é limitado no JDK para ARM. A opção de linha de comandos do java XX:NativeMemoryTracking=detail não é suportada para alvos ARM (uma mensagem de erro é exibida para o usuário). Em vez disso, use a seguinte opção:
XX:NativeMemoryTracking=summary

Atualizações de Documentação devido a Aprimoramentos no Nashorn

O JDK 8u60 inclui novos aprimoramentos no Nashorn. Como resultado, as seguintes alterações na documentação devem ser lidas em conjunto com a documentação atual do Nashorn:

Além disso, na seção anterior, foi mencionado que cada objeto JavaScript, quando exposto a APIs Java, implementa a interface java.util.Map. Isso é válido até mesmo para arrays de JavaScript. Entretanto, esse comportamento muitas vezes não é desejado ou esperado quando o código Java espera objetos com parsing feito pelo JSON. As bibliotecas Java que manipulam objetos com parsing feito pelo JSON normalmente esperam arrays para exibir a interface java.util.List. Se você precisar exibir seus objetos JavaScript para que os arrays sejam exibidos como listas e não mapas, poderá usar a função Java.asJSONCompatible(obj), em que obj é a raiz da árvore de objetos JSON.
Correção: o cuidado mencionado no final da seção Mapeando Tipos de Dados não se aplica mais. O Nashorn assegura que as strings JavaScript internas sejam convertidas em java.lang.String quando exibidas externamente.
Correção: A instrução na seção Mapeando Tipos de Dados que menciona "Por exemplo, os arrays devem ser convertidos explicitamente..." não está correta. Os arrays são convertidos automaticamente em tipos de array Java, como java.util.List, java.util.Collection, java.util.Queue e java.util.Deque e assim por diante.

Alterações no Conjunto de Regras de Implantação v1.2

O JDK 8u60 implementa o DRS (Conjunto de Regras de Implantação) 1.2, que inclui as seguintes alterações:

Adicione o elemento "checksum" como subelemento de "id" que pode permitir que jars não assinados sejam identificados pela soma de verificação SHA-256 do formato descompactado de um jar:
- O elemento "checksum" corresponderá somente a jars não assinados; e o hash em questão só será comparado com o formato descompactado do jar.
- O elemento "checksum" (semelhante ao elemento "certificate") tem dois argumentos, "hash" e "algorithm"; no entanto, ao contrário do elemento "certificate", o único valor suportado para "algorithm" é "SHA-256". Qualquer outro valor fornecido será ignorado.
Permite que o elemento "message" se aplique a todos os tipos de regra, nos casos em que anteriormente só se aplicava a uma regra de bloqueio:
- Em uma regra de execução, um subelemento de mensagem fará com que uma caixa de diálogo de mensagem seja exibida, na qual, sem uma regra de execução, o comportamento padrão seria mostrar uma caixa de diálogo de certificado ou não assinado. A mensagem será exibida na caixa de diálogo de mensagem.
- Em uma regra padrão, a mensagem só será exibida se a ação padrão for bloquear. Nesse caso, a mensagem será incluída na caixa de diálogo de bloqueio.
Reflita os bloqueios do elemento "customer" na Console Java, em arquivos de rastreamento e nos registros do Java Usage Tracker.
- Antes do DRS 1.2, os elementos "customer" podiam ser incluídos (com qualquer subelemento) no arquivo ruleset.xml. Esse elemento e todos os seus subelementos são ignorados. No DRS 1.2, os elementos ainda são funcionalmente ignorados. Entretanto:
  - Ao fazer parsing do arquivo ruleset.xml, todos os bloqueios de elementos "customer" serão refletidos na Console Java e no arquivo de rastreamento de implantação (se a Console e o Rastreamento estiverem ativados).
  - Ao usar uma regra, todos os registros "customer" incluídos nela serão adicionados ao registro do JUT (Java Usage Tracker), se o JUT estiver ativado.

Como resultado das alterações acima, o DTD para DRS 1.2 é como se segue:
The embedded asset does not exist:
Asset Type: jWidget_C
Asset Id: 1385352043373
PAGENAME: JCOM/jWidget_C/Raw_HTML/Display

Data de Expiração do Java

A data de expiração do 8u60 é 20 de outubro de 2015. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário fará com que esse JRE (versão 8u60) expire em 20 de novembro de 2015. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug do JDK 8u60.

» Notas da release 8u60

Java 8 Update 51 (8u51)

Destaques da Release

Dados de IANA 2015d
O JDK 8u51 contém a versão 2015d dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: Adiciona novas raízes de Comodo às Autoridades de Certificação (CAs)
Quatro novos certificados-raiz foram adicionados a Comodo:
1. COMODO ECC Certification Authority alias: comodoeccca DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
2. COMODO RSA Certification Authority alias: comodorsaca DN: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
3. USERTrust ECC Certification Authority alias: usertrusteccca DN: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
4. USERTrust RSA Certification Authority alias: usertrustrsaca DN: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
Consulte JDK-8077997 (não público).
Correção de Bug: Adiciona novas raízes de GlobalSign às Autoridades de Certificação raiz
Dois certificados-raiz foram adicionados à GlobalSign:
1. GlobalSign ECC Root CA - R4 alias: globalsigneccrootcar4 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
2. GlobalSign ECC Root CA - R5 alias: globalsigneccrootcar5 DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
Consulte JDK-8077995 (não público).
Correção de Bug: Adicionar Actalis às Autoridades de Certificação raiz
Foi adicionado um novo certificado-raiz:
Actalis Authentication Root CA alias: actalisauthenticationrootca DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT
Consulte JDK-8077903 (não público).
Correção de Bug: Adicionar nova raiz de Entrust ECC
Foi adicionado um novo certificado-raiz:
Entrust Root Certification Authority - EC1 alias: entrustrootcaec1 DN: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US
Consulte JDK-8073286 (não público).
Correção de Bug: Remover raízes antigas da Política de Classe 1 e 2
Foram removidos dois certificados-raiz com chaves de 1.024 bits:
1. ValiCert Class 1 Policy Validation Authority alias: secomvalicertclass1ca DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
2. ValiCert Class 2 Policy Validation Authority alias: valicertclass2ca DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", L=ValiCert Validation Network
Consulte JDK-8043200 (não público).
Correção de Bug: Remover raízes antigas de Thawte
Foram removidos dois certificados-raiz com chaves de 1.024 bytes:
1. Thawte Server CA alias: thawteserverca DN: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
2. Thawte Personal Freemail CA alias: thawtepersonalfreemailca DN: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
Consulte JDK-8074423 (não público).
Correção de Bug: Remover raízes de Verisign, Equifax e Thawte mais antigas
Foram removidos cinco certificados-raiz com chaves de 1.024 bits:
1. Verisign Class 3 Public Primary Certification Authority - G2 alias: verisignclass3g2ca DN: 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
2. Thawte Premium Server CA alias: thawtepremiumserverca DN: 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
3. Equifax Secure Certificate Authority alias: equifaxsecureca DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
4. Equifax Secure eBusiness CA-1 alias: equifaxsecureebusinessca1 DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
5. Equifax Secure Global eBusiness CA-1, alias: equifaxsecureglobalebusinessca1 DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
Consulte JDK-8076202 (não público).
Correção de Bug: Remover raízes da Autoridade de Certificação de TrustCenter de cacerts
Foram removidos três certificados-raiz:
1. TC TrustCenter Universal CA I alias: trustcenteruniversalcai DN: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE
2. TC TrustCenter Class 2 CA II alias: trustcenterclass2caii DN: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
3. TC TrustCenter Class 4 CA II alias: trustcenterclass4caii DN: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE
Consulte JDK-8072958 (não público).
Correção de Bug: O RC4 ficou obsoleto no provedor SunJSSE
O RC4 agora é considerado uma cifragem fraca. Os servidores não devem selecionar RC4, a menos que não haja outro candidato mais forte nos conjuntos de cifras solicitados pelo cliente. Foi adicionada uma nova propriedade de segurança, jdk.tls.legacyAlgorithms, para definir os algoritmos de legado na implementação do Oracle JSSE. Algoritmos relacionados a RC4 foram adicionados à lista de algoritmos de legado. Consulte JDK-8074006 (não público).
Correção de Bug: Proibir conjuntos de cifra de RC4
O RC4 agora é considerado uma cifragem comprometida. Os conjuntos de cifras RC4 foram removidos da lista de conjuntos de cifras ativadas pelo cliente e pelo servidor padrão na implementação do Oracle JSSE Estes conjuntos de cifras ainda podem ser ativados pelos métodos SSLEngine.setEnabledCipherSuites() e SSLSocket.setEnabledCipherSuites(). Consulte JDK-8077109 (não público).
Correção de Bug: Verificação da certificação melhorada
Com essa correção, a identificação do ponto final de JSSE não executa pesquisa de nome inversa dos endereços IP, por padrão, no JDK. Se um aplicativo não precisar executar a pesquisa de nome inversa de endereços IP brutos nas conexões SSL/TLS e encontrar problema de compatibilidade de identificação do ponto final, a propriedade do Sistema "jdk.tls.trustNameService" pode ser usada para alternar pesquisa de nome inversa. Observe que se o serviço de nome não for confiável, a ativação da pesquisa de nome inversa talvez fique suscetível aos ataques de MITM. Consulte JDK-8067695 (não público).

Data de Expiração do Java

A data de expiração para 8u51 é 20 de outubro de 2015. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u51) em 20 de novembro de 2015. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory..

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug 8u51 de JDK.

» Notas da release 8u51

Java 8 Update 45 (8u45)

Destaques da Release

Dados de IANA 2015a
O JDK 8u45 contém a versão 2015a dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: Melhorar o tratamento do arquivo jar. A partir da release JDK 8u45, a ferramenta jar não permite mais o componente de caminho barra "/" e ".." (ponto-ponto) no nome do arquivo zip de entrada ao criar um novo arquivo ou ao extrair um arquivo zip e jar. Se necessário, a nova opção de linha de comandos "-P" deve ser usada explicitamente para preservar o componente de caminho absoluto e/ou ponto-ponto. Consulte 8064601 (não público).
Correção de Bug: jnlp app com a seção "resource" aninhada falha com NPE no carregamento em jre8u40. Um aplicativo jnlp, com tags aninhadas dentro de uma tag <java> ou , pode gerar um NPE. O problema foi corrigido. A tag só deverá ser usada se <java> for realmente usado. Consulte 8072631 (não público).

Data de Expiração do Java

A data de expiração para a release 8u45 é 14 de julho de 2015. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u45) em 14 de agosto de 2015. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory..

Para obter uma lista de correções de bug incluídas nesta release, consulte a página Correções de Bug JDK 8u45.

» Notas da release 8u45

Java 8 Update 40 (8u40)

Destaques da Release

Dados de IANA 2014j
O JDK 8u40 contém a versão 2014j dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: métodos de interface padrão e estática em JDI, JDWP e JDB. A partir do JDK 8, é possível ter métodos estáticos e padrão diretamente executáveis em interfaces. Esses métodos não são executáveis via JDWP ou JDI e, portanto, não podem ser adequadamente depurados. Consulte o Guia de Compatibilidade do JDK 8 para obter mais detalhes. Consulte 8042123.
Correção de Bug: o Java Access Bridge pode ser ativado no Painel de controle para jres 32 bits. Anteriormente, a caixa de seleção "Ativar Java Access Bridge" havia sido removida do Painel de Controle do Java, com a desinstalação do jre 64 bits, mesmo quando o JRE 32 bits ainda estava presente no sistema. A partir da release JDK 8u40, a caixa de seleção "Ativar Java Access Bridge" foi mantida, em Painel de Controle -> Facilidade de Acesso -> Central de Facilidade de Acesso -> Usar o computador sem vídeo se um jre de 32s bit estiver presente. Portanto, um usuário pode ativar o Java Access Bridge por meio do painel de controle. Consulte 8030124.
Correção de Bug: modernizando a Pilha do JavaFX Media no Mac OS X. Uma plataforma de player baseada no AVFoundation foi adicionada ao JavaFX Media. A antiga plataforma baseada no QTKit agora é removível para compatibilidade com a Mac App Store. Consulte 8043697 (não público)
Correção de Bug: Faltam APIs de DOM. Na release JDK 8u40, as APIs de DOM do plug-in antigo foram removidas inadvertidamente. Se um applet requer o uso de com.sun.java.browser.dom.DOMServicepara se comunicar com o browser, então os usuários talvez precisem atualizar seus applets para usar netscape.javascript.JSObject ou continuar usando o JDK 8 Update 31. Este problema foi resolvido no build 26 e novos instaladores 8u40 foram postados. Se você estiver tendo este problema, faça download e execute os instaladores JDK 8u40 atualizados. Consulte 8074564.
Correção de Bug: Mac 10.10: O aplicativo executado com tela inicial tem problemas de foco. Aplicativos iniciados por meio de Webstart ou aplicativos stand-alone, que usam tela inicial, não conseguem obter foco do teclado. Solução: inicie javaws usando a opção -Xnosplash. Este problema foi resolvido no build 27 e um novo instalador 8u40 foi postado. Se você estiver tendo este problema, faça download e execute o instalador JDK 8u40 atualizado. Consulte 8074668.
Aprimoramentos na Ferramenta Java Packager
A release JDK 8u40 contém os seguintes aprimoramentos feitos no Java Packager:
- Os argumentos da linha de comando podem ser informados para aplicativos autossuficientes. Argumentos padrão são definidos quando o pacote é criado, os quais podem ser substituídos pelo usuário quando o aplicativo é iniciado.
- Associações de arquivos podem ser configuradas quando um aplicativo autossuficiente é instalado, para que o sistema operacional execute automaticamente o aplicativo para as extensões de arquivos registradas ou para os tipos MIME.
- A API UserJvmOptionsService está disponível para alterar as opções da JVM em aplicativos autossuficientes. As novas definições serão usadas na próxima vez que o aplicativo for iniciado.
- Múltiplos pontos de entrada são suportados para aplicativos autossuficientes, o que permite que uma suíte de produtos seja integrada ao mesmo pacote de aplicativos.
APIs Obsoletas
O mecanismo de substituição de padrões endossados e o mecanismo de extensão estão obsoletos e poderão ser removidos em uma futura release. Não há alterações de runtime. Recomenda-se que os aplicativos existentes que usam os mecanismos de "substituição de padrões endossados" ou de "extensão" migrem para outros mecanismos. Para ajudar a identificar quaisquer usos existentes desses mecanismos, a opção de linha de comando -XX:+CheckEndorsedAndExtDirs está disponível. Ela falhará se qualquer uma das seguintes condições for verdadeira:
- A propriedade do sistema -Djava.endorsed.dirs ou -Djava.ext.dirs for definida para alterar o padrão; ou
- o diretório ${java.home}/lib/endorsed já existir; ou
- ${java.home}/lib/ext contiver qualquer arquivo JAR, com exceção daqueles que o JDK utiliza ou
- qualquer diretório de extensão acessível por todos os usuários do sistema específico da plataforma contiver arquivos JAR.
A opção de linha de comando -XX:+CheckEndorsedAndExtDirs é suportada no JDK 8u40 e em releases posteriores.
Diferenças na Página da Ferramenta JJS
A versão em japonês da página de ajuda da ferramenta jjs é diferente da versão em inglês. Algumas das opções não suportadas foram removidas da versão em inglês da página da ferramenta jjs. A versão em japonês do documento será atualizada futuramente. Consulte 8062100 (não público). Para saber sobre outras mudanças na página da ferramenta jjs, consulte Tools Enhancements in JDK 8.
Mudança nos valores padrão de G1HeapWastePercent e G1MixedGCLiveThresholdPercent
O valor padrão de G1HeapWastePercent foi alterado de 10 para 5 para reduzir a necessidade de GCs totais. Pelo mesmo motivo, o valor padrão G1MixedGCLiveThresholdPercent foi alterado de 65 para 85.
Nova Interface de Filtragem de acesso a classes Java
A interface jdk.nashorn.api.scripting.ClassFilter permite restringir o acesso às classes Java especificadas na execução de scripts por um mecanismo de script Nashorn. Consulte Restricting Script Access to Specified Java Classes no Nashorn User's Guide e 8043717 (não público) para obter mais informações.
Problemas com provedores JCE de terceiros
A correção para o JDK-8023069 (no JDK 8u20) atualizou os provedores SunJSSE e SunJCE, incluindo algumas interfaces internas. Alguns provedores JCE de terceiros (como RSA JSAFE) estão usando algumas interfaces sun.* internal e, portanto, não funcionarão com o provedor SunJSSE atualizado. Esses provedores precisarão ser atualizados para que eles possam funcionar com o provedor SunJSSE atualizado. Se você estiver enfrentando esse problema, entre em contato com o seu fornecedor JCE para obter uma atualização. Consulte 8058731.
Criptografias reativadas na Estrutura de Criptografia do Solaris
Se você estiver usando o Solaris 10, uma mudança foi feita para reativar operações com o MD5, SHA1 e SHA2 por meio da Estrutura de Criptografia do Solaris. Se você receber uma mensagem CloneNotSupportedException ou de erro do PKCS11 CKR_SAVED_STATE_INVALID no JDK 8u40, verifique e aplique os patches a seguir ou a versão mais recente deles:
- 150531-02 no sparc
- 150636-01 no x86
Atualizações do Guia de Diagnóstico e Solução de Problemas para NMT
O NMT (Native Memory Tracking) é uma funcionalidade do Java Hotspot VM que rastreia o uso de memória interna de uma HotSpot JVM. O Native Memory Tracking pode ser usado para monitorar as alocações de memória interna de uma VM e diagnosticar perdas de memória de uma VM. A página de aprimoramentos de VM é atualizada com funcionalidades do NMT. Consulte Java Virtual Machine Enhancements in Java SE 8. O Guia de Diagnóstico e Solução de Problemas é atualizado com funcionalidades do NMT. ConsulteNative Memory Tracking.
Funcionalidade Multiple JRE Launcher obsoleta
A funcionalidade Seleção de Versão JRE de Tempo de Inicialização ou a funcionalidade Multiple JRE Launcher está obsoleta no JDK 8u40. Aplicativos que exigem versões específicas do Java implantadas usando esta funcionalidade devem alternar para soluções de implantação alternativas, como Java WebStart.
Aprimoramentos de JavaFX
A partir da release JDK 8u40, os controles JavaFX foram aprimorados para suportar tecnologias assistivas, significando que os controles de JavaFX agora são acessíveis. Além disso, uma API pública é fornecida para permitir que os desenvolvedores escrevam seus próprios controles acessíveis. Suporte a acessibilidade é fornecido nas plataformas Windows e Mac OS X e inclui:
- Suporte para ler controles JavaFX por um leitor de tela
- Os controles JavaFX podem ser passados usando o teclado
- Suporte para um modo especial de alto contraste que torna os controles mais visíveis para os usuários.
Consulte 8043344 (não público).

A release JDK 8u40 inclui novos controles JavaFX, um controle giratório, suporte a texto formatado e um conjunto padrão de diálogos de alerta.
- Controle Giratório: trata-se de um campo de texto de linha única que permite que o usuário selecione um número ou um valor de objeto em uma sequência ordenada. Consulte a classe javafx.scene.control.Spinner para obter mais informações.
- Texto Formatado: uma nova classe TextFormatter fornece uma capacidade de formatação de texto para subclasses de TextInputControl (por exemplo, TextField e TextArea). Consulte a classe javafx.scene.control.TextFormatter para obter mais informações.
- Diálogos: a classe Diálogo permite que os aplicativos criem suas próprias caixas de diálogo personalizadas. Além disso, uma classe Alerta também é fornecida, a qual estende o Diálogo, e fornece suporte para vários tipos de diálogo pré-construídos que podem ser facilmente mostradas aos usuários para pedir uma resposta. Consulte as classes javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog e javafx.scene.control.ChoiceDialog para obter mais informações.
Consulte 8043350 (não público).

Funcionalidades Comerciais

AppCDS (Application Class Data Sharing)
O AppCDS (Application Class Data Sharing) estende o CDS para permitir que você use classes dos diretórios de extensões padrão e o caminho da classe do aplicativo no arquivo compactado compartilhado. Esta é uma funcionalidade experimental e não licenciada para uso comercial. Consulte a opção -XX:+UseAppCDS na página da ferramenta Java Launcher.
Gerenciamento de Memória Cooperativa
A partir do JDK 8u40, a noção de "demanda de memória" foi incluída no JDK. A demanda de memória é uma propriedade que representa o uso total de memória (RAM) no sistema. Quanto maior a demanda de memória, mais próximo o sistema está de ficar sem memória. Esta é uma funcionalidade experimental e não licenciada para uso comercial. Para controlar o aumento de demanda de memória, o JDK tentará reduzir o uso da memória. Isso é feito principalmente reduzindo o tamanho de heap do Java. As ações que o JDK executará para reduzir o uso da memória poderão afetar o desempenho. Esta escolha é intencional. O nível de demanda é fornecido pelo aplicativo por meio de um JMX MXBean usando uma escala de 0 (nenhuma demanda) a 10 (quase sem memória). Para ativar essa funcionalidade, o jdk.management.cmm.SystemResourcePressureMXBean deve ser registrado. A demanda de memória é, então, definida usando o atributo "MemoryPressure".
Um novo flag da linha de comando -XX:MemoryRestriction que usa um dos argumentos "none", "low", "medium" ou "high" também está disponível. Esse flag definirá a demanda inicial no JDK e também funcionará em casos em que o MXBean não estiver registrado. O Gerenciamento de Memória Cooperativa requer o G1 GC (-XX:+UseG1GC). Essa funcionalidade não é compatível com o flag -XX:+ExplicitGCInvokesConcurrent.
Novos flags comerciais
Duas novas opções de VM agora estão disponíveis para portadores de licenças comerciais:
- -XX:+ResourceManagement
- -XX:ResourceManagementSampleInterval=value (milissegundos)
Para obter mais informações, consulte a documentação do Java Launcher.
Nova Documentação do MSI Installer:
O Microsoft Windows Installer (MSI) Enterprise JRE Installer Guide está disponível. O MSI Enterprise JRE Installer requer uma licença comercial para uso do produto. Saiba mais sobre as funcionalidades comerciais e como ativá-las.

Data de Expiração do Java

A data de expiração do 8u40 é 14 de abril de 2015. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u40) em 14 de maio de 2015. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Para obter uma lista de correções de bug incluídas nesta release, consulte a página Correções de Bug JDK 8u40.

» Notas da release 8u40

Java 8 Update 31 (8u31)

Destaques da Release

Dados de IANA 2014j
O JDK 8u31 contém a versão 2014j dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Por padrão, o Sslv3 está desativado
A partir da release JDK 8u31, o protocolo SSLv3 (Secure Socket Layer) foi desativado e normalmente não está disponível. Consulte a propriedade jdk.tls.disabledAlgorithms no arquivo \lib\security\java.security. Se o protocolo SSLv3 for estritamente necessário, ele poderá ser reativado removendo o 'SSLv3' da propriedade jdk.tls.disabledAlgorithms no arquivo java.security ou definindo dinamicamente esta propriedade de segurança antes de o JSSE ser inicializado.
Alterações no Painel de Controle Java
A partir da release JDK 8u31, o protocolo SSLv3 foi removido das opções Avançadas do Painel de Controle Java. Se o usuário precisar utilizar o SSLv3 para aplicativos, reative-o manualmente da seguinte forma:
- Ative o protocolo SSLv3 no nível do JRE: conforme descrito na seção anterior.
- Ative o protocolo SSLv3 no nível de implantação: edite o arquivo deployment.properties e adicione o seguinte:
  
  deployment.security.SSLv3=true

Data de Expiração do Java

A data de expiração do 8u31 é 14 de abril de 2015. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar os Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u31) em 14 de maio de 2015. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory..

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug 8u31 de JDK.

» Notas da release 8u31

Java 8 Update 25 (8u25)

Destaques da Release

Dados de IANA 2014c
O JDK 8u25 contém a versão 2014c dos dados de fuso horário de IANA. Para obter mais informações, consulte Versões de Dados de Fuso Horário no Software JRE.
Correção de Bug: Diminui o modo de preferência do RC4 na lista do conjunto de cifras ativado
Esta correção diminui a preferência de conjuntos de cifras com base em RC4 na lista de conjunto de cifras padrão ativado do provedor SunJSSE. Consulte 8043200 (não público).
Correção de Bug: O JRE 8u20 trava ao usar o IM japonês no Windows
A VM trava ao usar controles do Swing quando alguns caracteres japoneses ou chineses são inseridos na plataforma Windows. O problema foi corrigido. Consulte 8058858 (não público).

Instruções para desativar a SSL v3.0 no Oracle JDK e JRE

A Oracle recomenda que os usuários e desenvolvedores desativem o uso do protocolo SSLv3
» Como os usuários do Java podem confirmar se eles não são afetados pela vulnerabilidade 'Poodle' da SSL v3.0?

Data de Expiração do Java

A data de expiração para 8u25 é 20 de janeiro de 2015. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u25) em 20 de fevereiro de 2015. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory..

Para obter uma lista de correções de bug incluídas nesta release, consulte a página Correções de Bug JDK 8u25.

» Notas da release 8u25

Java 8 Update 20 (8u20)

Destaques da Release

Novos flags adicionados à API do Java Management
Os flags MinHeapFreeRatio e MaxHeapFreeRatio se tornaram gerenciáveis. Isso significa que eles podem ser alterados no runtime usando a API de gerenciamento no Java. O suporte a esses flags também foi adicionado a ParallelGC como parte da política de tamanho adaptável.
Alterações do Instalador do Java
- Está disponível um novo Instalador do Enterprise JRE do Microsoft Windows Installer (MSI) que permite que o usuário instale o JRE na empresa. Consulte a seção Fazendo Download do Instalador em Instalação do JRE para Microsoft Windows para obter mais informações. O Instalador do Enterprise JRE do MSI só fica disponível como parte do Java SE Advanced ou do Java SE Suite. Para obter informações sobre esses produtos comerciais, consulte Java SE Advanced e Java SE Suite.
- A Ferramenta de Desinstalação do Java está integrada ao instalador, a fim de fornecer uma opção para remover do sistema as versões mais antigas do Java. A alteração se aplica a plataformas Windows de 32 bits e de 64 bits. Consulte Desinstalando o JRE.
Alterações do Painel de Controle do Java
- A guia Atualizar no Painel de Controle do Java agora permite que os usuários atualizem automaticamente JREs de 64 bits (além das versões de 32 bits) que estão instalados no sistema.
- O nível de segurança Médio foi removido. Agora só estão disponíveis os níveis Alto e Muito Alto. Applets que não estão em conformidade com as práticas de segurança mais recentes podem ser autorizados para execução, inclusive os sites que os hospedam na Lista de Sites de Exceção. A lista de sites de exceção fornece aos usuários a opção de permitir os mesmos applets que seriam permitidos por meio da seleção da opção Médio, só que por site, o que reduz o risco de usar definições mais permissivas.
Compilador Java atualizado
O compilador javac foi atualizado para implementar a análise de atribuição definida para acesso de campo final em branco usando "este". Consulte o Guia de Compatibilidade do JDK 8 para obter mais detalhes.
Alteração na Versão Java mínima necessária para Java Plugin e Java Webstart
A versão mínima do Java necessária para Java Plugin e Java Webstart agora é Java 5. Os applets que não são executados no Java 5 ou posterior devem ser transportados para uma versão mais recente do Java para continuar funcionando. Os applets desenvolvidos em versões anteriores, mas capazes de serem executados, pelo menos no Java 5, continuarão funcionando.
Alteração na formatação de saída do UsageTracker
A formatação de saída de UsageTracker foi alterada para usar repetição, para evitar confusão no log. Isso pode exigir alterações na forma em que as informações são lidas. O recurso pode ser configurado para se comportar como em versões anteriores, embora o novo formato seja recomendado. Consulte a documentação Rastreador de Uso do Java.
Alterações nas Ferramentas de Empacotamento Java
- javafxpackager foi renomeado como javapackager
- A opção "-B" foi adicionada ao comando de implantação javapackager para permitir que você informe os argumentos aos bundlers que são usados para criar aplicativos autossuficientes. Consulte a documentação javapackager (Windows)/(Unix) para obter informações
- O argumento do parâmetro auxiliador foi adicionado à Referência da Tarefa Ant de JavaFX. Ele permite que você especifique um argumento (no elemento ) para o empacotador que é usado para criar aplicativos autocontidos.

Data de Expiração do Java

A data de expiração para 8u20 é 14 de outubro de 2014. O Java expira toda vez que uma nova release com correções de vulnerabilidades de segurança torna-se disponível. No caso de sistemas que não conseguem acessar o Oracle Servers, um mecanismo secundário expirará este JRE (versão 8u20) em 14 de novembro de 2014. Depois de uma das duas condições ser atendida (uma nova release estar disponível ou a data de expiração ser atingida), o Java fornecerá advertências e lembretes adicionais para os usuários, a fim de que eles façam a atualização para a versão mais nova.

Correções de Bug

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug JDK 8u20.

» Notas da release 8u20

Java 8 Update 11 (8u11)

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory.

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug JDK 8u11.

» Notas da release 8u11

Java 8 Update 5 (8u5)

Esta release contém correções para vulnerabilidades de segurança. Para obter mais informações, consulte Oracle Java SE Critical Patch Update Advisory.

Para obter uma lista das correções de bug incluídas nesta release, consulte a página Correções de Bug JDK 8u5.

» Notas da release 8u5

Release 8 do Java

» JDK e JRE 8 - Notas de release