Java.com

Fazer Download Ajuda

Versão para Impressão

Destaques da Release do Java 8


Este artigo aplica-se a:
  • 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 144 (8u144)

Release Highlights
  • IANA Data 2017b
    JDK 8u144 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.
  • Bug Fix: java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a / ended entry name for directory entry
    java.util.zip.ZipEntry API doc specifies 'A directory entry is defined to be one whose name ends with a /'. However, in previous JDK releases, java.util.zip.ZipFile.getEntry(String entryName) may return a ZipEntry instance with an entry name that does not end with / for an existing zip directory entry when the passed in argument entryName does not end with a / and there is a matching zip directory entry with name entryName + / in the zip file. With this release, the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with / for any zip directory entry.
    To revert to the previous behavior, set the system property jdk.util.zip.ensureTrailingSlash to 'false'.

    This change was made in order to fix a regression introduced in JDK 8u141 when verifying signed JARs and has caused some WebStart applications to fail to load.
    See JDK-8184993
Java Expiration Date

The expiration date for 8u144 is October 17, 2017. Java expires whenever a new release with security vulnerability fixes becomes available. For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 8u144) on November 17, 2017. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version.

Bug Fixes

This release contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see the JDK 8u144 Bug Fixes page.

» 8u144 Release notes


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 do 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'. Haverá falha nos aplicativos existentes que não fornecerem um nome de arquivo terminado com a extensão '.hprof', com 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)
  • 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 assegura que o Nome do Servidor seja agora enviado no corpo de ClientHello.
    Consulte JDK-8144566
  • 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)
  • 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 de uso pode ser especificado com um delimitador de espaços em branco.
      Por exemplo, 'SHA1 usage TLSServer TLSClient' não permitiria 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. Todavia, 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

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 8u141.

» 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 do 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 tiver sido assinado com um algoritmo de assinatura fraco, como MD5withRSA, este resultado seria obtido:

    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

    O seguinte resultado seria exibido:

    - 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 algumas aplicações, 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 algumas aplicações, 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 em 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 do 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
  • Improve the default strength of EC in 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 esta 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 distinta é 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
IllegalArgumentException no handshake TLS

Um problema recente da correção JDK-8173783 pode causar problemas em alguns servidores TLS. O problema vem de uma exceção IllegalArgumentException lançada pelo código de handshaker TLS.

java.lang.IllegalArgumentException: 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 presente). É recomendável que os usuários façam upgrade para esta release. Por padrão, Atualizações do JDK 7 e famílias JDK mais recentes são enviadas com o provedor de segurança SunEC que fornece suporte a 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

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<número>.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 do padrão de propriedade "sun.rmi.registry.registryFilter" e "sun.rmi.transport.dgcFilter" é descritya 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

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 de JDK 8u121.

» 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 do 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 jarsigner atualizado será encerrado com esta advertência impressa na saída padrão:
    "Signature not parsable or verifiable. 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:
  1. hotspot/jvm/os/processor/cpu_load
  2. 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

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 8u111.

» 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 do 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 certifiados-raiz foram adicionados:
    • Alias D-TRUST Raiz Classe 3 CA 2 2009
      : dtrustclass3ca2
      DN: CN=D-TRUST Raiz Classe 3 CA 2 2009, O=D-Trust GmbH, C=DE
    • Alias D-TRUST Raiz Classe 3 CA 2 EV 2009
      : dtrustclass3ca2ev
      DN: CN=D-TRUST Raiz Classe 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:
    • Alias de Autoridade de Certificação 1-Raiz de Setor Público IdenTrust
      : identrustpublicca
      DN: CN=Autoridade de Certificação 1-Raiz de Setor Público IdenTrust, O=IdenTrust, C=US
    • Alias de Autoridade de Certificação-Raiz 1 Comercial IdenTrust
      : identrustcommercial
      DN: CN=Alias de Autoridade de Certificação-Raiz 1 Comercial IdenTrust, O=IdenTrust, C=US
    • Alias de Autoridade de Certificação-Raiz X3 IdenTrust DST
      : identrustdstx3
      DN: CN=Autoridade de Certificação-Raiz X3 DST, 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)

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.

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 8u101.

» 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 do 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 será 2), não executaremos o método Java real e só retornaremos o status 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 principal thread do browser deverá ser bloqueado, o que poderá fazer com que o browser trave e o plug-in seja encerrado.

    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 classes 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 classes. 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)

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..

» 8u77 Notas da release


Java 8 Update 73 (8u73)

Destaques da Release
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 do 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 do 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 do 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 aplicações 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.

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 do 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 falsa. Consulte 8080637.
  • Correção de Bug: Desativar suítes de cifras RC4
    As suítes de cifras 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 comandos, os conjuntos de codificação baseados em RC4 precisam ser readicionados à lista de conjuntos de codificação 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 da Área de Armazenamento de Chaves: para auxiliar na interoperabilidade, o tipo de área de armazenamento de chaves Java JKS agora suporta o modo de compatibilidade da área de 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:
    • Anexar DumpJFR a um processo ativo:

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <pid>

    • Anexar DumpJFR a um arquivo básico:

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>
    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. No entanto:
      • 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 citadas anteriormente, o DTD para DRS 1.2 ficará assim:
<!ELEMENT ruleset (rule*)>
<!ATTRIBUTE ruleset href CDATA #IMPLIED>
<!ATTRIBUTE ruleset version CDATA #REQUIRED>

<!ELEMENT rule (id, action)>

<!ELEMENT id (certificate?) (checksum?) >
<!ATTRIBUTE id title CDATA #IMPLIED>
<!ATTRIBUTE id location CDATA #IMPLIED>

<!ELEMENT certificate EMPTY>
<!ATTLIST certificate algorithm CDATA #IMPLIED>
<!ATTLIST certificate hash CDATA #REQUIRED>

<!ELEMENT checksum EMPTY>
<!ATTLIST checksum algorithm CDATA #IMPLIED>
<!ATTLIST checksum hash CDATA #REQUIRED>
 
<!ELEMENT action (message?)>
<!ATTRIBUTE permission (run | block | default) #REQUIRED>
<!ATTRIBUTE version CDATA #IMPLIED>
<!ATTRIBUTE force (true|false) "false">

<!ELEMENT message (#PCDATA)>
<!ATTLIST message locale CDATA #IMPLIED>

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 do Fuso Horário no Software JRE.
  • Correção de Bug: Adiciona novas raízes de Commodo às Autoridades de Certificação (CAs)
    Quatro novos certificados-raiz foram adicionados a Commodo:
    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
      apelido: globalsigneccrootcar4
      DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
    2. GlobalSign ECC Root CA - R5
      apelido: 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:
    Autoridade de Certificação Raiz Actalis
    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:
    Autoridade de Certificação Raiz de Entrust - EC1
    alias: entrustrootcaec1
    DN: CN=Autoridade de Certificação Raiz de Entrust - EC1, OU="(c) 2012 Entrust, Inc. - somente para uso autorizado", OU=Consulte 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 1024 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 1024 bytes:
    1. Thawte Server CA
      apelido: 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
      apelido: 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 1024 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
      apelido: 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
      apelido: equifaxsecureebusinessca1
      DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
    5. Equifax Secure Global eBusiness CA-1,
      apelido: 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
      apelido: 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 cifra 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 cifra 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 do 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 apenas 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 do 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 32 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:
  • 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 G1HeapWastePercent e G1MixedGCLiveThresholdPercent
    O valor padrão 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, conforme documentado, 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, 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.
  • Documentação do MSI Installer incluída
    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 do 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 do 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 gravados 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. Permite que você especifique um argumento (no elemento ) para o bundler que é usado para criar aplicativos autossuficientes.
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 do Java 8

» JDK e JRE 8 - Notas de release


Talvez você também esteja interessado em:




Selecionar Idioma | Sobre o Java | Suporte | Desenvolvedores
Privacidade  | Termos de Uso | Marcas Comerciais | Isenção de Responsabilidade

Oracle