Java.com

Download Guida in linea

Versione stampabile

Caratteristiche più importanti della release di Java 8


Questo articolo è relativo a:
  • Versioni Java: 8.0

In questa pagina vengono evidenziate le modifiche che riguardano gli utenti finali per ciascuna release Java. Ulteriori informazioni sulle modifiche sono contenute nelle note di rilascio per ogni release.
» Date di release 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)

Caratteristiche più importanti della release
  • Dati IANA 2017b
    JDK 8u141 contiene i dati del fuso orario IANA versione 2017b. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Modifiche dei certificati: aggiunta di nuovi certificati Let's Encrypt alle CA root
    È stato aggiunto un nuovo certificato root:
    ISRG Root X1
    alias: letsencryptisrgx1
    DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US

    JDK-8177539 (non pubblico)
  • Miglioramenti della diagnostica JMX
    com.sun.management.HotSpotDiagnostic::dumpHeap L'API viene modificata in modo da restituire IllegalArgumentException, se il nome file fornito non termina con il suffisso '.hprof'. L'esecuzione delle applicazioni esistenti che non forniscono un nome file che termina con l'estensione '.hprof' non riuscirà a causa dell'eccezione IllegalArgumentException. In tal caso, le applicazioni possono scegliere di gestire l'eccezione o ripristinare il funzionamento precedente impostando la proprietà di sistema 'jdk.management.heapdump.allowAnyFileSuffix' su true.
    JDK-8176055 (non pubblico)
  • La classe HostnameVerifier personalizzata abilita l'estensione SNI
    Le release precedenti di JDK 8 Update non inviavano sempre l'estensione SNI (Server Name Indication) nella fase TLS ClientHello, se si utilizzava un verificatore di nomi host personalizzato. Questo verificatore viene impostato tramite il metodo setHostnameVerifier(HostnameVerifier v) in HttpsURLConnection. La correzione garantisce che il nome server venga ora inviato nel corpo ClientHello.
    Vedere JDK-8144566
  • Controlli di sicurezza più rigorosi durante l'elaborazione dei file WSDL tramite lo strumento wsimport
    Lo strumento wsimport è stato modificato per non consentire le DTD nelle descrizioni dei Web Service, in particolare:
    • La dichiarazione DOCTYPE non è consentita nei documenti
    • Le entità esterne generali non sono incluse per impostazione predefinita
    • Le entità parametriche esterne non sono incluse per impostazione predefinita
    • Le DTD esterne vengono completamente ignorate
    Per ripristinare il funzionamento precedente, effettuare le operazioni riportate di seguito.
    • Impostare la proprietà di sistema com.sun.xml.internal.ws.disableXmlSecurity su true
    • Utilizzare l'opzione della riga di comando dello strumento wsimport – disableXmlSecurity
      NOTA: il supporto di JDK 7 e JDK 6 per questa opzione in wsimport verrà fornito tramite la release di una patch successiva all'aggiornamento di patch critiche del mese di luglio

    JDK-8182054 (non pubblico)
  • Migliore controllo dei vincoli degli algoritmi
    L'esigenza di limitare l'uso di algoritmi minimi nelle situazioni in cui sono più vulnerabili ha determinato l'aggiunta di ulteriori funzioni durante la configurazione delle proprietà di sicurezza jdk.certpath.disabledAlgorithms e jdk.jar.disabledAlgorithms nel file java.security.

    jdk.certpath.disabledAlgorithms: alla proprietà certpath sono state apportate le modifiche più consistenti. In precedenza, la proprietà doveva utilizzare solo due tipi di vincoli: disabilitazione completa di un algoritmo per nome o disabilitazione completa di un algoritmo in base alla dimensione della chiave durante il controllo dei certificati, delle catene e delle firme dei certificati. Questa limitazione crea configurazioni assolute e ne impedisce l'uso flessibile. Per garantire maggiore flessibilità nell'accettazione e nel rifiuto dei certificati, sono stati aggiunti nuovi vincoli.

    'jdkCA' esamina l'interruzione della catena di certificati rispetto al file cacerts. Nel caso di 'SHA1 jdkCA'. L'uso dell'algoritmo SHA1 viene controllato tramite la catena di certificati, ma la catena deve terminare in corrispondenza di una trust anchor contrassegnata nel keystore cacerts per poter essere rifiutata. Questa funzione è utile per le organizzazioni con un proprio CA privato che accettano come sicuro utilizzando l'algoritmo SHA1 insieme alla corrispettiva trust anchor, ma che desiderano bloccare le catene di certificati ancorate da un CA pubblico proveniente dall'uso di SHA1.

    'denyAfter' controlla se la data specificata è antecedente alla data corrente o alla data di PKIXParameter. Nel caso di 'SHA1 denyAfter 2018-01-01', è possibile utilizzare un certificato con algoritmo SHA1 prima del 2018 ma, una volta trascorsa tale data, il certificato viene rifiutato. Questa funzione può essere utilizzata per un criterio all'interno di un'organizzazione che intende eliminare gradualmente un algoritmo con una data improrogabile. Per i file JAR con firma, la data viene confrontata con l'indicatore orario TSA. Il fuso orario è GMT.

    'usage' esamina l'algoritmo specificato per un determinato uso. Questa funzione può essere utilizzata quando non conviene disabilitare un algoritmo destinato a tutti gli usi. È possibile specificare tre usi:

    • 'TLSServer' limita l'algoritmo nella catena di certificati del server TLS quando l'autenticazione del server viene eseguita come client.
    • 'TLSClient' limita l'algoritmo nella catena di certificati del server TLS quando l'autenticazione del server viene eseguita come server.
    • 'SignedJAR' limita gli algoritmi nei certificati nei file JAR con firma. Il tipo d'uso segue la parola chiave ed è possibile specificare più tipi con un delimitatore di spazi vuoti.
      Ad esempio, 'SHA1 usage TLSServer TLSClient' non consente i certificati SHA1 per le operazioni TLSServer e TLSClient, mentre SignedJars ne permette l'uso

    Tutti questi vincoli possono essere associati per vincolare un algoritmo quando è delimitato da '&'. Ad esempio, per disabilitare le catene di certificati SHA1 che terminano in corrispondenza di trust anchor contrassegnate solo per le operazioni TLSServer, il vincolo sarà 'SHA1 jdkCA & usage TLSServer'.

    jdk.jar.disabledAlgorithms: a questa proprietà .jar è stato aggiunto un ulteriore vincolo per limitare gli algoritmi del file manifest JAR.

    'denyAfter' controlla i vincoli degli algoritmi imposti agli algoritmi digest dei file manifest all'interno di un file JAR con firma. La data specificata nel vincolo viene confrontata con l'indicatore orario TSA del file JAR con firma. Se non è presente alcun indicatore orario o l'indicatore orario corrisponde alla data specificata o a quella successiva, il file JAR viene gestito come senza firma. Se l'indicatore orario è antecedente alla data specificata, il . jar funzionerà come file JAR con firma. La sintassi per limitare l'algoritmo SHA1 nei file JAR con firma successivi al 1° gennaio 2018 è la seguente: 'SHA1 denyAfter 2018-01-01'. La sintassi è identica a quella della proprietà certpath, ma il controllo dei certificati non verrà eseguito da questa proprietà.
    Vedere JDK-8176536

Data di scadenza di Java

La data di scadenza di 8u141 è il 17 ottobre 2017. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 17 novembre 2017 come data di scadenza di questo JRE (versione 8u141). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), JRE fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per le vulnerabilità della sicurezza descritte nell'advisory di aggiornamento delle patch critiche di Oracle Java SE. Per una lista più completa delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u141.

» Note di rilascio di 8u141

Java 8 Update 131 (8u131)

Caratteristiche più importanti della release
  • Dati IANA 2016j
    JDK 8u131 contiene i dati del fuso orario IANA versione 2016j. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: introduzione di un nuovo modello di ordinamento delle finestre
    Nella piattaforma OS X la struttura AWT utilizzava i servizi nativi per implementare la relazione padre-figlio per le finestre. Questa situazione ha causato alcuni problemi di visualizzazione, in particolare negli ambienti con più monitor. Per far fronte agli svantaggi derivanti da un approccio di questo tipo, è stato introdotto il nuovo modello di ordinamento delle finestre, completamente implementato nel layer JDK. Di seguito sono elencate le regole principali.
    • Una finestra deve essere posizionata sopra la finestra padre più vicina.
    • Se una finestra dispone di più finestre figlio, tutte le finestre figlio devono essere posizionate sullo stesso layer e la finestra appartenente alla catena di finestre attive deve essere ordinata sopra gli elementi di pari livello.
    • L'ordinamento non deve essere eseguito per una finestra ridotta a icona o se è in corso il passaggio allo stato di icona.
    Queste regole vengono applicate a ogni frame o finestra di dialogo della gerarchia di finestre contenente la finestra attualmente attiva. Vedere JDK-8169589
  • Correzione di bug: correzione dell'eccezione IllegalArgumentException restituita dall'handshake TLS
    Un problema recente introdotto dalla correzione JDK-8173783 può provocare errori in alcuni server TLS. Il problema ha origine da un'eccezione IllegalArgumentException restituita dal codice handshaker TLS:

    java.lang.IllegalArgumentException: la proprietà di sistema
    jdk.tls.namedGroups(null) contiene curve ellittiche non supportate


    Il problema può verificarsi quando il server non dispone del supporto per la crittografia delle curve ellittiche per gestire un campo di estensione di nome di curva ellittica (se presente). Agli utenti viene consigliato di effettuare l'aggiornamento a questa release. Per impostazione predefinita, gli aggiornamenti di JDK 7 e le famiglie JDK più recenti vengono forniti con il provider di sicurezza SunEC che offre il supporto per la crittografia delle curve ellittiche. Queste release non dovrebbero essere interessate dal problema a meno che i provider di sicurezza non subiscano modifiche. Vedere JDK-8173783
  • MD5 aggiunto alla proprietà di scurezza jdk.jar.disabledAlgorithms
    In questa release di JDK viene introdotta una nuova limitazione sulla modalità di verifica dei file JAR firmati MD5. Se il file JAR firmato utilizza MD5, le operazioni di verifica della firma ignoreranno la firma e considereranno il file JAR come non firmato. Questo scenario si potrebbe verificare nei seguenti tipi di applicazioni che utilizzano file JAR firmati:
    • Applet o applicazioni Web Start
    • Applicazioni standalone o applicazioni server eseguite con un SecurityManager abilitato e configurate con un file dei criteri che concede le autorizzazioni in base ai firmatari del codice del file JAR.

    La lista degli algoritmi disabilitati viene controllata mediante la proprietà di sicurezza, jdk.jar.disabledAlgorithms, inserita nel file java.security. Questa proprietà contiene una lista di algoritmi disabilitati e dimensioni di chiave per i file JAR firmati crittograficamente.

    Per determinare se è stato utilizzato un algoritmo o una chiave debole per firmare un file JAR, è possibile utilizzare il comando jarsigner fornito con questo JDK. L'esecuzione di "jarsigner -verify" su un file JAR firmato con un algoritmo o una chiave debole comporta la visualizzazione di ulteriori informazioni sull'algoritmo o sulla chiave disabilitata.

    Ad esempio, per controllare un file JAR denominato test.jar, usate questo comando:

    jarsigner -verify test.jar

    Se il file di questo esempio è stato firmato con un algoritmo di firma debole quale MD5withRSA, verrà restituito questo output:

    Il file jar verrà considerato come non firmato perché è firmato con un algoritmo debole che è attualmente disabilitato. Rieseguire jarsigner con l'opzione -verbose per ulteriori dettagli.

    È possibile visualizzare più dettagli con l'opzione verbose:

    jarsigner -verify -verbose test.jar

    Verrà restituito questo output:

    - 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
    
    Per risolvere il problema, sarà necessario firmare di nuovo il file JAR con un algoritmo o una dimensione di chiave più potente. In alternativa, è possibile annullare le limitazioni rimuovendo gli algoritmi o le dimensioni di chiave deboli applicabili dalla proprietà di sicurezza jdk.jar.disabledAlgorithms; questa opzione è tuttavia sconsigliata. Prima di firmare di nuovo i file JAR interessati, è consigliabile rimuovere le firme esistenti dal file JAR. A tale scopo, è possibile utilizzare la utility zip come indicato di seguito:

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

    Controllate periodicamente Oracle JRE and JDK Cryptographic Roadmap all'indirizzo http://java.com/cryptoroadmap per informazioni sulle limitazioni pianificate per i file JAR firmati e per altri componenti di sicurezza. JDK-8171121 (non pubblico)
  • Nuova proprietà di sistema per controllare l'inserimento dei dati nella cache per la connessione SPNEGO HTTP.
    È stata introdotta una nuova proprietà di sistema specifica dell'implementazione JDK per controllare l'inserimento dei dati nella cache per le connessioni SPNEGO (Negotiate/Kerberos) HTTP. L'inserimento dei dati nella cache per le connessioni SPNEGO HTTP rimane abilitato per impostazione predefinita, pertanto se la proprietà non viene specificata in modo esplicito, il funzionamento rimarrà invariato. Se si esegue la connessione a un server HTTP che utilizza SPNEGO per negoziare l'autenticazione e se la connessione e l'autenticazione con il server riescono, le informazioni sull'autenticazione verranno inserite nella cache e riutilizzate per le ulteriori connessioni allo stesso server. Inoltre, la connessione a un server HTTP mediante SPNEGO in genere implica che la connessione sottostante sia attiva e venga riutilizzata per le ulteriori richieste inviate allo stesso server. In alcune applicazioni può essere opportuno disabilitare l'inserimento di tutti i dati nella cache per il protocollo SPNEGO (Negotiate/Kerberos) HTTP in modo da forzare una nuova autenticazione per ogni nuova richiesta inviata al server.

    Grazie a questa modifica, viene ora fornita una nuova proprietà di sistema che consente di controllare i criteri di inserimento nella cache per le connessioni SPNEGO HTTP. Se la proprietà jdk.spnego.cache è definita e restituisce false, tutti i criteri di inserimento nella cache vengono disabilitati per le connessioni SPNEGO HTTP. L'impostazione di questa proprietà di sistema su false, può comunque causare effetti collaterali indesiderati.
    • Si può verificare una riduzione significativa delle prestazioni delle connessioni SPNEGO HTTP poiché sarà necessario eseguire di nuovo l'autenticazione di ogni nuova richiesta di connessione, con il conseguente aumento della quantità di scambi di comunicazioni con il server.
    • Sarà necessario ottenere di nuovo le credenziali per ogni nuova richiesta e ciò può determinare la visualizzazione di una finestra popup in cui viene richiesto all'utente di specificare le credenziali per ogni nuova richiesta, a seconda della disponibilità dell'autenticazione trasparente e dell'implementazione dell'autenticatore a livello globale.
    JDK-8170814 (non pubblico)
  • Nuova proprietà di sistema per controllare l'inserimento dei dati nella cache per la connessione NTLM HTTP.
    È stata introdotta una nuova proprietà di sistema specifica dell'implementazione JDK per controllare l'inserimento dei dati nella cache per le connessioni NTLM HTTP. L'inserimento dei dati nella cache per la connessione NTLM HTTP rimane abilitato per impostazione predefinita, pertanto se la proprietà non viene specificata in modo esplicito, il funzionamento rimarrà invariato. Su alcune piattaforme l'implementazione NTLM HTTP nel JDK può supportare l'autenticazione trasparente che prevede l'utilizzo delle credenziali dell'utente di sistema a livello di sistema. Se l'autenticazione trasparente non è disponibile o non riesce, il JDK supporta il recupero delle credenziali solo da un autenticatore globale. Se la connessione al server riesce, le informazioni sull'autenticazione verranno inserite nella cache e riutilizzate per le ulteriori connessioni allo stesso server. Inoltre, la connessione a un server NTLM HTTP in genere implica che la connessione sottostante sia attiva e venga riutilizzata per le ulteriori richieste inviate allo stesso server. In alcune applicazioni può essere opportuno disabilitare l'inserimento di tutti i dati nella cache per il protocollo NTLM HTTP in modo da forzare una nuova autenticazione per ogni nuova richiesta inviata al server.

    Grazie a questa modifica, viene ora fornita una nuova proprietà di sistema che consente di controllare i criteri di inserimento nella cache per le connessioni NTLM HTTP. Se la proprietà jdk.ntlm.cache è definita e restituisce false, tutti i criteri di inserimento nella cache vengono disabilitati per le connessioni NTLM HTTP. L'impostazione di questa proprietà di sistema su false, può comunque causare effetti collaterali indesiderati.
    • Si può verificare una riduzione significativa delle prestazioni delle connessioni NTLM HTTP poiché sarà necessario eseguire di nuovo l'autenticazione di ogni nuova richiesta di connessione, con il conseguente aumento della quantità di scambi di comunicazioni con il server.
    • Sarà necessario ottenere di nuovo le credenziali per ogni nuova richiesta e ciò può determinare la visualizzazione di una finestra popup in cui viene richiesto all'utente di specificare le credenziali per ogni nuova richiesta, a seconda della disponibilità dell'autenticazione trasparente e dell'implementazione dell'autenticatore a livello globale.
    JDK-8163520 (non pubblico)
  • Nuova versione di VisualVM
    VisualVM 1.3.9 è stato rilasciato il 4 ottobre 2016 http://visualvm.github.io/relnotes.html ed è stato integrato nella release 8u131. Vedere JDK-8167485
Data di scadenza di Java

La data di scadenza di Java 8u131 è il 18 luglio 2017. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 18 agosto 2017 come data di scadenza di questo JRE (versione 8u131). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE. Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u131.

» Note di rilascio di Java 8u131


Java 8 Update 121 (8u121)

Caratteristiche più importanti della release
  • Dati IANA 2016i
    JDK 8u121 contiene i dati del fuso orario IANA versione 2016i. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: lo scorrimento del testo tramite trackpad in OS X 10.12 Sierra è molto rapido
    Il metodo MouseWheelEvent.getWheelRotation() ha restituito in Mac OS X eventi NSEvent deltaX/Y nativi arrotondati. Il nuovo macOS Sierra 10.12 produce valori NSEvent deltaX/Y molto piccoli, pertanto il relativo arrotondamento e la relativa somma comportano la restituzione di un valore enorme da parte di MouseWheelEvent.getWheelRotation(). La correzione JDK-8166591 accumula i valori NSEvent deltaX/Y e il metodo MouseWheelEvent.getWheelRotation() restituirà valori diversi da zero solo quando il valore accumulato supera una soglia e il valore zero. Ciò è conforme alla specifica MouseWheelEvent.getWheelRotation(): "Restituisce il numero di 'clic' in cui la rotellina del mouse è stata ruotata come numero intero. Può verificarsi una rotazione parziale se il mouse supporta una rotellina ad alta risoluzione. In questo caso, il metodo restituisce zero fino a quando non viene accumulato un 'clic' completo." Per ottenere valori precisi di rotazione della rotellina, utilizzare il metodo MouseWheelEvent.getPreciseWheelRotation(). Vedere JDK-8166591
  • Miglioramento dell'efficacia predefinita di EC in JDK
    Per migliorare l'efficacia predefinita della crittografia EC, le chiavi EC di lunghezza inferiore a 224 bit sono state disattivate nell'elaborazione del percorso di certificazione (mediante la proprietà di sicurezza jdk.certpath.disabledAlgorithms) e nelle connessioni SSL/TLS (mediante la proprietà di sicurezza jdk.tls.disabledAlgorithms) in JDK. Per le applicazioni è possibile aggiornare questa limitazione nelle proprietà di sicurezza e consentire dimensioni di chiave inferiori se realmente necessario, ad esempio "EC keySize < 192". Le curve EC di lunghezza inferiore a 256 bit vengono rimosse dall'implementazione SSL/TLS in JDK. La nuova proprietà di sistema jdk.tls.namedGroups definisce una lista di curve con nome abilitate per le suite di cifratura EC in ordine di preferenza. Se in un'applicazione è necessario personalizzare le curve EC abilitate predefinite o la preferenza delle curve, aggiornare la proprietà di sistema di conseguenza. Ad esempio:
        jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1"
    

    Tenere presente che le curve EC abilitate predefinite o personalizzate seguono i vincoli degli algoritmi. Ad esempio, le curve EC personalizzate non possono riattivare le chiavi EC disabilitate definite dalle proprietà di sicurezza Java. Vedere JDK-8148516
  • Novità: opzione --allow-script-in-comments per javadoc
    Lo strumento javadoc ora rifiuterà qualsiasi ricorrenza di codice JavaScript nei commenti della documentazione javadoc e nelle opzioni della riga di comando, a meno che non sia specificata l'opzione della riga di comando --allow-script-in-comments. Con l'opzione --allow-script-in-comments, lo strumento javadoc manterrà il codice JavaScript nei commenti della documentazione e nelle opzioni della riga di comando. Lo strumento javadoc restituirà un errore se viene rilevato codice JavaScript e l'opzione della riga di comando non è stata specificata.
    JDK-8138725 (non pubblico)
  • Aumento della lunghezza chiave minima a 1024 per le firme XML
    La modalità di convalida sicura dell'implementazione della firma XML è stata migliorata introducendo la limitazione a livello di impostazione predefinita per le chiavi RSA e DSA di lunghezza inferiore a 1024 bit poiché non sono più sufficientemente sicure per le firme digitali. Inoltre, una nuova proprietà di sicurezza denominata jdk.xml.dsig.SecureValidationPolicy è stata aggiunta al file java.security e può essere usata per controllare le diversi limitazioni applicate quando la modalità di convalida sicura è abilitata. La modalità di convalida sicura viene abilitata impostando la proprietà della firma XML org.jcp.xml.dsig.secureValidation su true con il metodo javax.xml.crypto.XMLCryptoContext.setProperty oppure eseguendo il codice con un SecurityManager. Se una firma XML viene generata o convalidata con una chiave RSA o DSA debole, viene restituita un'eccezione XMLSignatureException con il messaggio indicante che le chiavi RSA o DSA di lunghezza inferiore a 1024 bit non sono consentite quando la convalida sicura è abilitata.
    JDK-8140353 (non pubblico)
  • Limitazione dei certificati con chiavi DSA di lunghezza inferiore a 1024 bit
    Le chiavi DSA di lunghezza inferiore a 1024 bit non sono sufficientemente forti ed è necessario limitarle nella creazione e nella convalida del percorso di certificazione. Di conseguenza, le chiavi DSA di lunghezza inferiore a 1024 bit sono state disattivate per impostazione predefinita aggiungendo "DSA keySize < 1024" alla proprietà di sicurezza "jdk.certpath.disabledAlgorithms". Le applicazioni possono aggiornare questa limitazione nella proprietà di sicurezza ("jdk.certpath.disabledAlgorithms") e consentire dimensioni di chiave inferiori se effettivamente necessario (ad esempio, "DSA keySize < 768"). JDK-8139565 (non pubblico)
  • Ulteriori controlli aggiunti al codice di analisi della codifica DER
    Ulteriori controlli sono stati aggiunti al codice di analisi della codifica DER per rilevare vari errori di codifica. Inoltre, le firme che contengono codifica di lunghezza indefinita composta causeranno ora l'eccezione IOException durante l'analisi. Le firme generate utilizzando i provider predefiniti JDK non sono interessate da questa modifica. JDK-8168714 (non pubblico)
  • Ulteriori limitazioni di accesso per URLClassLoader.newInstance
    I loader di classe creati dai metodi java.net.URLClassLoader.newInstance possono essere usati per caricare le classi da una lista di determinati URL. Se il codice di chiamata non ha accesso a uno o più URL e gli artifact URL accessibili non contengono la classe richiesta, viene restituita un'eccezione ClassNotFoundException o simile. In precedenza, sarebbe stata restituita un'eccezione SecurityException in caso di accesso negato a un URL. Se è necessario ripristinare il funzionamento precedente, è possibile disabilitare questa modifica impostando la proprietà di sistema jdk.net.URLClassPath.disableRestrictedPermissions. JDK-8151934 (non pubblico)
  • Nuova proprietà configurabile in logging.properties java.util.logging.FileHandler.maxLocks
    Una nuova proprietà configurabile "java.util.logging.FileHandler.maxLocks" è stata aggiunta a java.util.logging.FileHandler. Questa nuova proprietà di log può essere definita nel file di configurazione del log e consente di configurare il numero massimo di lock di file di log contemporanei che un FileHandler può gestire. Il valore predefinito è 100. In un ambiente caratterizzato da elevata contemporaneità in cui più applicazioni client standalone (più di 101) utilizzano contemporaneamente l'interfaccia API di log JDK con FileHandler, può verificarsi il raggiungimento del limite predefinito di 100. Ciò provoca un errore nell'acquisizione dei lock di file FileHandler e la restituzione di un'eccezione di I/O. In tal caso, la nuova proprietà di log può essere usata per aumentare il numero massimo di lock prima della distribuzione dell'applicazione. Se non viene sostituito, il valore predefinito di maxLocks (100) rimane invariato. Per ulteriori informazioni, vedere la documentazione dell'interfaccia API java.util.logging.LogManager e java.util.logging.FileHandler. Vedere JDK-8153955
Note
Protezione migliorata per caricamento classe remota JNDI

Il caricamento classe remota tramite object factory JNDI memorizzati nei servizi di denominazione e di directory è disabilitato per impostazione predefinita. Per abilitare il caricamento classe remota da parte del registro RMI o del provider del servizio di denominazione COS, impostare la seguente proprietà di sistema sulla stringa "true", in modo appropriato:

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

JDK-8158997 (non pubblico)

jarsigner -verbose -verify dovrebbe visualizzare gli algoritmi usati per firmare il file JAR

Lo strumento jarsigner è stato migliorato per visualizzare i dettagli delle chiavi e degli algoritmi usati per generare un file JAR firmato e fornirà anche un'indicazione nel caso in cui uno di questi elementi sia considerato debole.

In particolare, quando viene chiamato "jarsigner -verify -verbose filename.jar", in una sezione distinta vengono visualizzate le informazioni della firma e dell'indicatore orario, se presente, all'interno del file JAR firmato, anche se viene considerato non firmato per vari motivi. Se una delle chiavi usate o uno degli algoritmi usati è considerato debole, come specificato nella proprietà di sicurezza jdk.jar.disabledAlgorithms, verrà etichettato con "(weak)".

Ad esempio:

- 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 

Vedere JDK-8163304

Problemi noti
Eccezione IllegalArgumentException da handshake TLS

Un problema recente introdotto dalla correzione JDK-8173783 può provocare errori in alcuni server TLS. Il problema ha origine da un'eccezione IllegalArgumentException restituita dal codice handshaker TLS.

Eccezione java.lang.IllegalArgumentException: la proprietà di sistema
jdk.tls.namedGroups(null) contiene curve ellittiche non supportate

Il problema può verificarsi quando il server non dispone del supporto per la crittografia delle curve ellittiche per gestire un campo di estensione di nome di curva ellittica (se presente). Agli utenti viene consigliato di effettuare l'aggiornamento a questa release. Per impostazione predefinita, gli aggiornamenti di JDK 7 e le famiglie JDK più recenti vengono forniti con il provider di sicurezza SunEC che offre il supporto per la crittografia delle curve ellittiche. Queste release non dovrebbero essere interessate dal problema a meno che i provider di sicurezza non subiscano modifiche. Vedere JDK-8173783

javapackager e fx:deploy forniscono l'intero JDK invece di JRE

In Java Packager per Mac è presente un bug noto a causa del quale l'intero JDK può essere fornito insieme al bundle applicazione dando luogo a un bundle di dimensioni insolitamente grandi. La soluzione alternativa prevede l'utilizzo dell'opzione bundler -Bruntime. Ad esempio: -Bruntime=JavaAppletPlugin.plugin dove JavaAppletPlugin.plugin per il JRE desiderato da raggruppare si trova nella directory corrente. Vedere JDK-8166835

L'installazione di Java non riuscirà per gli utenti non amministratori con UAC disattivato

L'installazione di Java in Windows non riuscirà per gli utenti non amministratori con UAC (User Access Control) disabilitato e non verranno visualizzate avvertenze o richieste. L'Installer creerà una directory, jds<number>.tmp, nella directory %TEMP%.
JDK-8161460 (non pubblico)

Nuove funzioni
Aggiunta proprietà di sicurezza per configurare la modalità di convalida sicura della firma XML

Una nuova proprietà di sicurezza denominata jdk.xml.dsig.secureValidationPolicy è stata aggiunta per consentire di configurare le singole limitazioni che vengono applicate quando la modalità di convalida sicura della firma XML è abilitata. Il valore predefinito per questa proprietà nel file di configurazione java.security è il seguente:

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

Per ulteriori informazioni, fare riferimento alla definizione della proprietà nel file java.security. Vedere JDK-8151893

Configurazione filtro di serializzazione

Il filtro di serializzazione introduce un nuovo meccanismo che consente ai flussi di dati di serializzazione oggetti in arrivo di essere filtrati in modo da migliorare la sicurezza e l'affidabilità. Ogni ObjectInputStream applica un filtro, se configurato, al contenuto del flusso durante la deserializzazione. I filtri vengono impostati utilizzando una proprietà di sistema o una proprietà di sicurezza configurata. Il valore dei pattern "jdk.serialFilter" è descritto in Filtro di serializzazione JEP 290 e in <JRE>/lib/security/java.security. Le azioni di filtro vengono registrate nel logger 'java.io.serialization', se abilitato. Vedere JDK-8155760

Controllo vincoli migliorato in RMI

RMI Registry e Distributed Garbage Collection usano i meccanismi del filtro di serializzazione JEP 290 per migliorare l'affidabilità del servizio. RMI Registry e DGC implementano i filtri integrati inseriti nella lista di inclusione per le classi tipiche di cui si prevede l'uso con ogni servizio. È possibile configurare ulteriori pattern utilizzando una proprietà di sistema o una proprietà di sicurezza. La sintassi dei pattern delle proprietà "sun.rmi.registry.registryFilter" e "sun.rmi.transport.dgcFilter" è descritta in JEP 290 e in <JRE>/lib/security/java.security. JDK-8156802 (non pubblico)

Aggiunta di un meccanismo per fare in modo che le CA radice non predefinite non siano soggette alle limitazioni previste per gli algoritmi.

Nel file java.security viene aggiunto un ulteriore vincolo denominato "jdkCA" alla proprietà jdk.certpath.disabledAlgorithms. Questo vincolo impedisce l'uso dell'algoritmo specificato solo se viene utilizzato in una catena di certificati che termina in corrispondenza di una trust anchor contrassegnata nel keystore lib/security/cacerts. Se il vincolo jdkCA non viene impostato, a tutte le catene che utilizzano l'algoritmo specificato vengono applicate limitazioni. Il vincolo jdkCA può essere utilizzato una sola volta in un'espressione DisabledAlgorithm. Esempio: per applicare questo vincolo ai certificati SHA-1, includere: SHA1 jdkCA
Vedere JDK-8140422.

Data di scadenza di Java

La data di scadenza di Java 8u121 è il 18 aprile 2017. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 18 maggio 2017 come data di scadenza di questo JRE (versione 8u121). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE. Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u121.

» Note di rilascio di Java 8u121


Java 8 Update 111 (8u111)

Caratteristiche più importanti della release
  • IANA Data 2016f
    JDK 8u111 contiene i dati del fuso orario IANA versione 2016f. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE. Vedere JDK-8159684.
  • Modifiche dei certificati: nuova CA root di firma del codice JCE
    Al fine di supportare lunghezze di chiave maggiori e algoritmi di firma più potenti, è stata creata una nuova autorità di certificazione con firma del codice per i provider JCE e il relativo certificato è stato aggiunto a Oracle JDK. D'ora in poi i nuovi certificati di firma del codice per i provider JCE emessi da questa autorità di certificazione verranno utilizzati per la firma dei provider JCE. Per impostazione predefinita, le nuove richieste per i certificati di firma del codice dei provider JCE verranno emesse da questa autorità di certificazione.

    I certificati esistenti emessi dalla CA root di firma del codice per i provider JCE corrente conserveranno la propria validità. Questa CA root potrebbe tuttavia essere disabilitata in futuro. Si consiglia pertanto di richiedere nuovi certificati e di firmare di nuovo i file JAR di provider esistenti. Per informazioni dettagliate sul processo di firma dei provider JCE, vedere il documento Come implementare un provider nell'architettura di crittografia Java. JDK-8141340 (non pubblico)
  • Servizi del menu Servizio
    Per la gestione del ciclo di vita dei componenti del menu AWT si sono verificati problemi su determinate piattaforme. Questa correzione migliora la sincronizzazione dello stato tra i menu e i relativi contenitori. JDK-8158993 (non pubblico)
  • Disabilitazione dell'autenticazione Basic per il tunneling HTTPS
    In alcuni ambienti certi schemi di autenticazione possono rivelarsi inadeguati quando si usa la funzione proxy per il protocollo HTTPS. Lo schema di autenticazione Basic è stato pertanto disattivato, per impostazione predefinita, nel runtime di Oracle Java, mediante l'aggiunta dello schema Basic alla proprietà di rete jdk.http.auth.tunneling.disabledSchemes. Ora le richieste di autenticazione Basic emesse dai proxy durante l'impostazione di un tunnel per il protocollo HTTPS non riusciranno più per impostazione predefinita. Se necessario, questo schema di autenticazione può essere riattivato rimuovendo Basic dalla proprietà di rete jdk.http.auth.tunneling.disabledSchemes oppure impostando una proprietà di sistema con lo stesso nome su "" (vuoto) nella riga di comando. Inoltre, le proprietà di rete jdk.http.auth.tunneling.disabledSchemes e jdk.http.auth.proxying.disabledSchemes, nonché le proprietà di sistema con lo stesso nome, possono essere utilizzate per disabilitare gli altri schemi di autenticazione che potrebbero essere attivi durante, rispettivamente, l'impostazione del tunnel per il protocollo HTTPS o l'uso della funzione proxy per il protocollo HTTP semplice. JDK-8160838 (non pubblico)
  • Limitazioni per i file JAR firmati con algoritmi e chiavi deboli
    In questa release di JDK sono state introdotte nuove limitazioni relative alla modalità di verifica dei file JAR firmati. Se il file JAR firmato utilizza un algoritmo disabilitato oppure una dimensione di chiave minore della lunghezza minima, le operazioni di verifica della firma ignoreranno la firma e considereranno il file JAR come non firmato. Questo scenario si potrebbe verificare nei seguenti tipi di applicazioni che utilizzano file JAR firmati:
    1. Applet o applicazioni Web Start
    2. Applicazioni standalone o applicazioni server eseguite con un SecurityManager abilitato e configurate con un file dei criteri che concede le autorizzazioni in base ai firmatari del codice del file JAR.

    La lista degli algoritmi disabilitati viene controllata mediante una nuova proprietà di sicurezza, jdk.jar.disabledAlgorithms, inserita nel file java.security. Questa proprietà contiene la lista degli algoritmi disabilitati e delle dimensioni di chiave per i file JAR firmati mediante crittografia.

    In questa release sono previste limitazioni per i seguenti algoritmi e dimensioni di chiavi:
    1. MD2 (negli algoritmi digest o di firma)
    2. Chiavi RSA inferiori a 1024 bit
    NOTA: nella release CPU di aprile 2017 è prevista l'introduzione di limitazioni per le firme basate su MD5 nei file JAR firmati.

    Per determinare se è stato utilizzato un algoritmo o una chiave debole per firmare un file JAR, è possibile utilizzare il comando jarsigner fornito con questo JDK. L'esecuzione di jarsigner -verify -J-Djava.security.debug=jar su un file JAR firmato con un algoritmo o una chiave debole comporta la visualizzazione di ulteriori informazioni sull'algoritmo o sulla chiave disabilitata.

    Ad esempio, per controllare il file JAR denominato test.jar, utilizzate il seguente comando:
    jarsigner -verify -J-Djava.security.debug=jar test.jar

    Se il file di questo esempio è stato firmato con un algoritmo di firma debole quale MD2withRSA, verrà restituito questo output:
    jar: beginEntry META-INF/my_sig.RSA
    jar: processEntry: elaborazione del blocco
    jar: processEntry caught: java.security.SignatureException: controllo della firma non riuscito. Algoritmo disabilitato usato: MD2withRSA
    jar: operazione metadati completata

    Il comando jarsigner aggiornato terminerà con l'avvertenza seguente visualizzata nell'output standard:
    "Firma non analizzabile o non verificabile. Il file JAR verrà considerato come non firmato. Il file JAR potrebbe essere stato firmato con un algoritmo debole ora disabilitato. Per ulteriori informazioni, rieseguite il comando jarsigner con la funzione di debug abilitata (-J-Djava.security.debug=jar)"

    Per risolvere il problema, sarà necessario firmare di nuovo il file JAR con un algoritmo o una dimensione di chiave più potente. In alternativa, è possibile annullare le limitazioni rimuovendo gli algoritmi o le dimensioni di chiave deboli applicabili dalla proprietà di sicurezza jdk.jar.disabledAlgorithms; questa opzione è tuttavia sconsigliata. Prima di firmare di nuovo i file JAR interessati, è consigliabile rimuovere le firme esistenti dal file JAR. A tale scopo, è possibile utilizzare la utility zip come indicato di seguito:

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

    Controllate periodicamente Oracle JRE and JDK Cryptographic Roadmap alla pagina http://java.com/cryptoroadmap per informazioni sulle limitazioni pianificate per i file JAR firmati e per altri componenti di sicurezza. In particolare, tenete presente che nella release CPU di aprile 2017 è pianificata l'introduzione di limitazioni per le firme basate su MD5 nei file JAR firmati.

    Per verificare se i file JAR sono stati firmati con MD5, aggiungete MD5 alla proprietà di sicurezza jdk.jar.disabledAlgorithms, ad esempio:

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

    , quindi eseguite jarsigner -verify -J-Djava.security.debug=jar sui file JAR come descritto in precedenza.
    JDK-8155973 (non pubblico)
  • Messaggio di avvertenza aggiunto alla finestra di dialogo dell'autenticatore di distribuzione
    È stata aggiunta un'avvertenza alla finestra di dialogo di autenticazione del plugin per i casi in cui si utilizza l'autenticazione Basic HTTP (invio delle credenziali non cifrate) quando si usa un proxy oppure quando non si usano i protocolli SSL/TLS.
    "AVVERTENZA: lo schema di autenticazione Basic trasmetterà le credenziali dell'utente con testo in chiaro. Si è certi di volerlo?"
    JDK-8161647 (non pubblico)
Problemi noti
Alcuni eventi non sono disponibili nelle registrazioni JFR su Windows
Per la release 8u111 non sono disponibili i seguenti eventi nelle registrazioni JFR su Windows:
  1. hotspot/jvm/os/processor/cpu_load
  2. os/processor/context_switch_rate

Ciò è dovuto al JDK-8063089 di regressione introdotto nella release 8u111 con le modifiche a JDK-8162419. Non è stato possibile includere la correzione per JDK-8063089 nella release 8u111. Sarà disponibile nella successiva build BPR di 8u111 e nella successiva release pubblica.
JDK-8063089 (non pubblico)

JVM restituisce le eccezioni NullPointerExceptions su macOS Sierra 10.12

Su macOS Sierra 10.12, se un utente preme i tasti modificatori (ad esempio, Comando, Maiuscole o Alt) mentre un'applet è in esecuzione in un browser, è possibile che venga visualizzato il messaggio di errore "Errore interno". Viene anche visualizzata l'icona "exec" nel Dock di macOS. L'utente può chiudere l'applet o provare a rieseguirla senza premere un tasto modificatore. Vedere JDK-8165867.

Data di scadenza di Java

La data di scadenza di Java 8u111 è il 17 gennaio 2017. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 17 febbraio 2017 come data di scadenza di questo JRE (versione 8u111). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE. Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u111.

» Note di rilascio di Java 8u111


Java 8 Update 101 (8u101)

Caratteristiche più importanti della release
  • Dati IANA 2016d
    JDK 8u101 contiene i dati del fuso orario IANA versione 2016d. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE. Vedere JDK-8151876.
  • Modifiche dei certificati
    Aggiunta di nuovi certificati DTrust alle CA root
    Sono stati aggiunti due nuovi certificati root:
    • D-TRUST Root Class 3 CA 2 2009
      alias: dtrustclass3ca2
      DN: CN=D-TRUST Root Class 3 CA 2 2009, O=D-Trust GmbH, C=DE
    • D-TRUST Root Class 3 CA 2 EV 2009
      alias: dtrustclass3ca2ev
      DN: CN=D-TRUST Root Class 3 CA 2 EV 2009, O=D-Trust GmbH, C=DE
    Vedere JDK-8153080

    Aggiunta di nuovi certificati Iden alle CA root
    Sono stati aggiunti tre nuovi certificati root:
    • IdenTrust Public Sector Root CA 1
      alias: identrustpublicca
      DN: CN=IdenTrust Public Sector Root CA 1, O=IdenTrust, C=US
    • IdenTrust Commercial Root CA 1
      alias: identrustcommercial
      DN: CN=IdenTrust Commercial Root CA 1, O=IdenTrust, C=US
    • IdenTrust DST Root CA X3
      alias: identrustdstx3
      DN: CN=DST Root CA X3, O=Digital Signature Trust Co.
    Vedere JDK-8154757

    CA radice Comodo rimosso
    Il certificato CA radice "UTN - DATACorp SGC" Comodo è stato rimosso dal file cacerts. Vedere JDK-8141540

    Sonera Class1 CA rimosso
    Il certificato CA root "Sonera Class1 CA" è stato rimosso dal file cacerts. Vedere JDK-8141276.
  • Miglioramento del controllo dell'accesso a javax.rmi.CORBA.ValueHandler
    La classe javax.rmi.CORBA.Util offre dei metodi che possono essere utilizzati da stub e vincoli per eseguire operazioni comuni. Funge anche da factory per i ValueHandler. L'interfaccia javax.rmi.CORBA.ValueHandler fornisce i servizi per supportare la lettura e la scrittura dei tipi di valori nei flussi GIOP. Il livello di sicurezza di queste utility è stato migliorato grazie all'introduzione dell'autorizzazione java.io.SerializablePermission("enableCustomValueHanlder"). Questa autorizzazione viene utilizzata per stabilire una relazione sicura tra gli utenti delle interfacce API javax.rmi.CORBA.Util e javax.rmi.CORBA.ValueHandler.

    L'autorizzazione richiesta è SerializablePermission "enableCustomValueHanlder". Durante il richiamo di Util.createValueHandler() l'esecuzione del codice di terze parti non riuscirà quando è installato un SecurityManager ma non è disponibile la nuova autorizzazione e verrà visualizzata l'eccezione AccessControlException.

    In JDK8u e nelle release precedenti è possibile ignorare questo metodo di controllo dell'autorizzazione definendo la proprietà di sistema "jdk.rmi.CORBA.allowCustomValueHandler".

    Per questo motivo, per consentire il funzionamento delle applicazioni esterne che richiamano javax.rmi.CORBA.Util.createValueHandler in modo esplicito è necessario apportare una modifica alla configurazione quando è installato un SecurityManager e non vengono soddisfatti i seguenti requisiti:
    1. L'autorizzazione java.io.SerializablePermission("enableCustomValueHanlder") non viene concessa da SecurityManager.
    2. Nel caso di applicazioni in esecuzione su JDK8u e versioni precedenti, la proprietà di sistema "jdk.rmi.CORBA.allowCustomValueHandler" non è definita o è definita come "false" (senza distinzione tra maiuscole e minuscole).

    Tenere presente che l'errore ortografico "enableCustomValueHanlder" verrà corretto nelle release disponibili a ottobre 2016. In quelle release e nelle release future di JDK, "enableCustomValueHandler" rappresenterà l'autorizzazione SerializationPermission corretta da utilizzare.
    JDK-8079718 (non pubblico)
  • È stato ora aggiunto il supporto a jarsigner per specificare l'algoritmo hash dell'indicatore orario
    È stata aggiunta una nuova opzione -tsadigestalg a jarsigner per specificare l'algoritmo digest di messaggio utilizzato per generare l'indicazione del messaggio da inviare al server TSA. Nelle precedenti release di JDK veniva utilizzato l'algoritmo digest di messaggio SHA-1. Se non si specifica questa nuova opzione, negli aggiornamenti di JDK 7 e nelle versioni successive della famiglia JDK verrà utilizzato SHA-256. Negli aggiornamenti di JDK 6, SHA-1 rimarrà l'opzione predefinita ma verrà visualizzata un'avvertenza nel flusso di output standard. Vedere JDK-8038837
  • Il keystore MSCAPI è in grado di gestire i certificati con lo stesso nome
    Il keystore Java SE non consente l'uso di certificati con lo stesso alias. Tuttavia, in Windows è consentito l'uso di nomi semplici non univoci per più certificati memorizzati in un singolo keystore. La correzione per JDK-6483657 consente di utilizzare questi tipi di certificati con nomi non univoci tramite l'API Java rendendo univoci, in modo virtuale, gli alias visibili. Tenere presente che questa correzione non consente la creazione di certificati con lo stesso nome mediante l'API Java. Consente solo di gestire i certificati con lo stesso nome aggiunti al keystore mediante strumenti di terze parti. Si consiglia di non utilizzare più certificati con lo stesso nome nella propria implementazione. In particolare, la seguente frase non verrà rimossa dalla documentazione di Java:
    "Per evitare problemi, si consiglia di non utilizzare in un keystore alias che differiscono solo nell'utilizzo delle maiuscole e minuscole".
    Vedere JDK-6483657.
  • I metodi dell'API del toolkit per la distribuzione non installano più l'ambiente JRE
    I metodi installLatestJRE() e installJRE(requestedVersion) di deployJava.js e il metodo install() di dtjava.js dell'API del toolkit per la distribuzione non installano più l'ambiente JRE. Se la versione di Java di un utente non raggiunge la baseline di sicurezza, l'utente viene reindirizzato alla pagina java.com per scaricare una versione aggiornata di JRE. JDK-8148310 (non pubblico)
  • DomainCombiner non prenderà più in considerazione il criterio di runtime per gli oggetti ProtectionDomain statici durante la combinazione di questo tipo di oggetti
    Le applicazioni, che utilizzano gli oggetti ProtectionDomain statici (creati mediante il costruttore con 2 argomenti) e dispongono di un set insufficiente di autorizzazioni, posso ora ricevere un'eccezione AccessControlException con questa correzione. Queste applicazioni devono sostituire gli oggetti ProtectionDomain statici con quelli dinamici (utilizzando il costruttore con 4 argomenti), il cui set di autorizzazioni verrà espanso dal criterio corrente oppure devono costruire l'oggetto ProtectionDomain statico con tutte le autorizzazioni necessarie. JDK-8147771 (non pubblico)
Problemi noti
JRE 8u101 non viene riconosciuto da Internet Explorer (IE) durante l'utilizzo dell'ID della classe statica

Quando una classe statica viene utilizzata per avviare un'applet o un'applicazione Web Start durante l'uso di JRE 8u101, viene visualizzata una finestra di dialogo non richiesta per indicare che è necessario utilizzare l'ambiente JRE più recente o annullare l'avvio anche se è installato o si sta utilizzando l'ambiente JRE più recente (JRE 8u101). Questo caso specifico è applicabile solo in Windows e IE.

Si consiglia di non utilizzare l'ID di classe statica per la selezione della versione di JRE (a partire dalla JDK 5u6 di dicembre 2005) come indicato alla pagina http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

Come soluzione alternativa per questo problema, gli utenti possono effettuare una delle due operazioni riportate di seguito.
  • Selezionare l'avvio con la versione più recente (8u101) e ignorare il messaggio di avvertenza.
  • Installare JRE 8u102 anziché JRE 8u101 per evitare questo problema.
Per risolvere questo problema, gli sviluppatori possono effettuare una delle due operazioni riportate di seguito.
  • Utilizzare un ID di classe dinamica anziché un ID di classe statica.
  • Utilizzare java_version quando si usa un'applet HTML oppure un descrittore JNLP quando si utilizza JNLP.
JDK-8147457 (non pubblico)

Data di scadenza di Java

La data di scadenza di 8u101 è il 19 ottobre 2016. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 19 novembre 2016 come data di scadenza di questo JRE (versione 8u101). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE. Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u101.

» Note di rilascio di Java 8u101


Java 8 Update 91 (8u91)

Caratteristiche più importanti della release
  • Dati IANA 2016a
    JDK 8u91 contiene i dati del fuso orario IANA versione 2016a. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: è stata corretta la regressione nell'ora di avvio dell'applet
    In JDK-8080977 era presente un ritardo all'avvio dell'applet. Il ritardo viene visualizzato solo su IE e dura circa 20 secondi. Questo ritardo è stato rimosso in JDK-8136759. Vedere JDK-8136759
  • Correzione di bug: la generazione di firme DSA è ora soggetta al controllo di efficacia delle chiavi.
    Per la generazione delle firme, se l'efficacia di sicurezza dell'algoritmo digest è più debole di quella della chiave utilizzata per apporre la firma (ad esempio, se si usano le chiavi DSA a 2048 e 256 bit con la firma SHA1withDSA), l'operazione non riesce con il messaggio di errore: "L'efficacia di sicurezza dell'algoritmo digest SHA1 non è sufficiente per questa dimensione di chiave". JDK-8138593 (non pubblico)
  • Correzione di bug: problema di connessione attiva in Firefox 42
    Poiché potrebbe causare il blocco del browser, le chiamate da JavaScript a Java non vengono elaborate quando il plugin Java viene avviato da plugin-container.exe (il comportamento predefinito per Firefox 42) e lo stato dell'applet non è Pronto(2). Se l'applet non è pronta (lo stato è diverso da 2), non viene eseguito il metodo Java effettivo e viene restituito un valore nullo.

    Se il plugin viene avviato da plugin-container.exe, non utilizzare le chiamate da JavaScript a Java che possono richiedere più di 11 secondi (il valore predefinito di dom.ipc.plugins.hangUITimeoutSecs) per essere completate o non visualizzare una finestra di dialogo modale durante questo tipo di chiamate. In questo caso, è necessario bloccare il thread del browser principale, che potrebbe causare il blocco del browser e la chiusura del plugin.

    Soluzione alternativa per Firefox 42: gli utenti possono impostare dom.ipc.plugins.enabled=false. L'effetto collaterale di questa soluzione alternativa è che viene modificata l'impostazione di tutti i plugin. JDK-8144079 (non pubblico)
  • Correzione di bug: il nuovo attributo per i server JRMP RMI JMX indica una lista di nomi di classe da utilizzare durante la deserializzazione delle credenziali dei server
    Per l'ambiente è stato definito un nuovo attributo Java in modo da consentire a un server JRMP RMI JMX di specificare una lista di nomi di classi. Questi nomi corrispondono alla chiusura dei nomi di classe previsti dal server durante la deserializzazione delle credenziali. Ad esempio, se le credenziali previste sono
    List<string>
    , la chiusura comprende tutte le classi concrete previste nel formato seriale di una lista di stringhe.

    Per impostazione predefinita, questo attributo viene utilizzato solo dall'agente predefinito con gli elementi riportati di seguito:
     {   
       "[Ljava.lang.String;",   
       "java.lang.String" 
     } 
    
    Durante la deserializzazione delle credenziali, verranno accettati solo array di stringhe e stringhe. Il nome dell'attributo è:
    "jmx.remote.rmi.server.credential.types"
    
    Di seguito è riportato un esempio di un utente che avvia un server con i nomi di classe delle credenziali specificati:
    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);
    
    La nuova funzione deve essere utilizzata specificando direttamente:
    "jmx.remote.rmi.server.credential.types"

    JDK-8144430 (non pubblico)
  • Correzione di bug: disabilitare l'algoritmo di firma MD5withRSA nel provider JSSE
    Attualmente, l'algoritmo di firma MD5withRSA è considerato non sicuro e non deve essere più utilizzato. Pertanto, MD5withRSA è stato disattivato per impostazione predefinita nell'implementazione Oracle JSSE mediante l'aggiunta di "MD5withRSA" alla proprietà di sicurezza "jdk.tls.disabledAlgorithms". Attualmente, per impostazione predefinita non vengono più accettati sia i messaggi di handshake TLS che i certificati X.509 firmati con l'algoritmo MD5withRSA. Questa modifica estende la restrizione precedente dei certificati basati su MD5 ("jdk.certpath.disabledAlgorithms") anche ai messaggi di handshake in TLS versione 1.2. Se necessario, è possibile riattivare questo algoritmo mediante la rimozione di "MD5withRSA" dalla proprietà di sicurezza "jdk.tls.disabledAlgorithms". JDK-8144773 (non pubblico)
  • Correzione di bug: aggiunta di nuovi certificati alle CA root
    Sono stati aggiunti otto nuovi certificati root:
    • 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
    Vedere JDK-8145954 e JDK-8145955.
Note

Rimozione degli ambienti JRE statici
Per impostazione predefinita, gli Installer Java per Windows rilasciati prima della versione 8u91 non rimuovevano gli ambienti JRE installati in modo statico. Per rimuovere gli ambienti JRE installati in modo statico, era necessario selezionarli manualmente nell'interfaccia utente dell'Installer Java. Attualmente nelle release Java 8u91 e successive, gli ambienti JRE installati in modo statico vengono rimossi automaticamente se non raggiungono la baseline di sicurezza. Per ulteriori informazioni sull'installazione statica, vedere Configurazione di Java Runtime Environment.

Data di scadenza di Java

La data di scadenza di Java 8u91 è il 19 luglio 2016. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 19 agosto 2016 come data di scadenza di questo JRE (versione 8u91). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE. Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u91.

» Note di rilascio di Java 8u91


Java 8 Update 77 (8u77)

Data di scadenza di Java

La data di scadenza di Java 8u77 è il 19 aprile 2016. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 19 maggio 2016 come data di scadenza di questo JRE (versione 8u77). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Note

Questo avviso di sicurezza (8u77) si basa sulla precedente release 8u74 PSU. Tutti gli utenti delle precedenti release JDK 8 devono eseguire l'aggiornamento a questa release. Per ulteriori informazioni sulla differenza tra aggiornamenti di patch critiche e aggiornamenti del set di patch, fate riferimento alla sezione relativa alla spiegazione delle release Java CPU e PSU.

L'avviso di sicurezza per CVE-2016-0636 non influisce sulle demo, sugli esempi e sui bundle della documentazione relativi alla versione 8u77. Pertanto, la versione più aggiornata delle demo, degli esempi e dei bundle della documentazione rimane la 8u73 fino al rilascio dell'Aggiornamento delle patch critiche del mese di aprile.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE.

» Note di rilascio di Java 8u77


Java 8 Update 73 (8u73)

Caratteristiche più importanti della release
Data di scadenza di Java

La data di scadenza di Java 8u73 è il 19 aprile 2016. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 19 maggio 2016 come data di scadenza di questo JRE (versione 8u73). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Note

Oracle consiglia vivamente agli utenti Java che hanno scaricato le versioni interessate e prevedono installazioni future con le versioni scaricate di eliminare questi vecchi download. Gli utenti Java che hanno installato le versioni Aggiornamento patch critiche di Java SE 6, 7 o 8 del mese di gennaio 2016 non devono effettuare alcuna operazione. Gli utenti Java che non hanno installato le versioni Aggiornamento patch critiche di Java SE 6, 7 o 8 del mese di gennaio 2016 devono effettuare l'aggiornamento alla release Java SE 6, 7 o 8 dell'Avviso di sicurezza per CVE-2016-0603.

L'avviso di sicurezza per CVE-2016-0603 non influisce sulle demo, sugli esempi e sui bundle della documentazione relativi alla versione 8u73. Pertanto, la versione più aggiornata delle demo, degli esempi e dei bundle della documentazione rimane la 8u71 fino al rilascio dell'Aggiornamento delle patch critiche del mese di aprile.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE. Tenere presente che 8u73 non contiene le build PSU disponibili in 8u72. I clienti che necessitano delle correzioni bug aggiuntive contenute in 8u72 devono effettuare l'aggiornamento a 8u74 anziché a 8u73.

» Note di rilascio di Java 8u73


Java 8 Update 71 (8u71)

Caratteristiche più importanti della release
  • Dati IANA 2015g
    JDK 8u71 contiene i dati del fuso orario IANA versione 2015g. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: l'esecuzione di jps come root non mostra tutte le informazioni
    Dopo la correzione del kit JDK-8050807 (correzione eseguita in 8u31, 7u75 e 6u91), durante l'esecuzione di jps come root non venivano mostrate tutte le informazioni provenienti dai processi Java avviati da altri utenti su alcuni sistemi. Questo problema è stato ora risolto. Vedere JDK-8075773.
  • Correzione di bug: gli Installer appaiono bloccati nelle configurazioni ESC
    Gli utenti che eseguono la configurazione ESC (Enhance Security Configuration) di Internet Explorer in Windows Server 2008 R2 potrebbero aver riscontrato problemi durante l'installazione di Java in modalità interattiva. Questo problema è stato risolto nella release 8u71. Gli Installer eseguiti in modalità interattiva non appariranno più bloccati nelle configurazioni ESC. Vedere JDK-8140197.
  • Correzione di bug: il problema con gli algoritmi PBE che utilizzano la crittografia AES è stato corretto.
    Un errore relativo a PBE che utilizza cifre AES a 256 bit è stato corretto in modo che la chiave derivata possa essere diversa e non equivalente alle chiavi derivate in precedenza dalla stessa password. JDK-8138589 (non pubblico).
  • Correzione di bug: limite predefinito aggiunto per la dimensione entità massima XML.
    È stato aggiunto un limite predefinito per la dimensione entità massima. Per ulteriori informazioni sui limiti di elaborazione XML, vedere The Java Tutorials, Processing Limits. JDK-8133962 (non pubblico)
  • Correzione di bug: il problema nella documentazione di Enterprise MSI relativo allo switch 'REMOVEOLDERJRES' è stato corretto.
    Nella documentazione di Enterprise MSI sono elencate le opzioni di configurazione. L'opzione REMOVEOLDERJRES utilizzata per disinstallare i JRE obsoleti era mancante. L'opzione è stata aggiunta con la seguente descrizione:
    Se impostata su 1, rimuove le release precedenti del JRE installato nel sistema.
    Impostazione predefinita: 0 non rimuove alcun JRES obsoleto
    JDK-8081237 (non pubblico)
Data di scadenza di Java

La data di scadenza di Java 8u71 è il 19 aprile 2016. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 19 maggio 2016 come data di scadenza di questo JRE (versione 8u71). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u71.

» Note di rilascio di Java 8u71


Java 8 Update 66 (8u66)

Caratteristiche più importanti della release

Nella build 18 di 8u66 viene risolto un problema relativo a Firefox.

  • Correzione di bug: _releaseObject chiamato da thread errato
    A causa di una recente modifica di Firefox la chiamata _releaseObject viene effettuata da un thread diverso da quello principale. Ciò può generare una condizione di accesso che potrebbe inavvertitamente causare il crash del browser. Questo problema viene risolto nella build 18 di 8u66. Per ulteriori informazioni, vedere Bugs@Mozilla 1221448. Vedere JDK-8133523.
Il plugin Java non funziona in Firefox dopo l'installazione di Java

Può verificarsi il crash di Firefox 42 quando si tenta di eseguire il plugin Java. Le opzioni relative alle soluzioni alternative sono elencate nelle domande frequenti. Vedere JDK-8142908 (non pubblico).

Data di scadenza di Java

La data di scadenza di Java 8u66 è il 19 gennaio 2016. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 19 febbraio 2016 come data di scadenza di questo JRE (versione 8u66). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u66.

» Note di rilascio di Java 8u66


Java 8 Update 65 (8u65)

Caratteristiche più importanti della release
  • IANA Data 2015f
    JDK 8u65 contiene i dati del fuso orario IANA versione 2015f. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Supporto ISO 4217 'Codici fondi correnti' tabella (A.2)
    Questo miglioramento aggiunge supporto ai codici fondo ISO 4217 tabella A.2. In precedenza JDK supportava solo le valute elencate nella tabella A.1. Vedere JDK-8074350.
  • Correzione di bug: [mac osx] il client JRE AU installato non riesce ad aggiornare a NEXTVER su Mac 10.11
    È stato introdotto un nuovo Installer nella release 8u65 per aggiornare gli utenti OS X all'ultima versione. L'Installer si applicherà sia agli aggiornamenti pianificati che a quelli manuali e ai bundle resi disponibili su java.com e OTN. Gli utenti che riscontrano problemi di compatibilità con il nuovo Installer possono scaricare e installare manualmente l'Installer '.pkg' disponibile su My Oracle Support.
  • Correzione di bug: Hotspot deve usare l'interfaccia PICL per ottenere la dimensione della linea di cache su SPARC
    La libreria libpicl è ora richiesta su Solaris/SPARC per determinare la dimensione delle linee di cache. Se la libreria non è presente o il servizio PICL non è disponibile, JVM visualizzerà un'avvertenza e le ottimizzazioni del compiler che utilizzano l'istruzione BIS (Block Initializing Store) verranno disattivate. Vedere JDK-8056124.
  • Correzione di bug: dns_lookup_realm deve essere false per impostazione predefinita
    Il valore di dns_lookup_realm nel file krb5.conf Kerberos è false per impostazione predefinita. Vedere JDK-8080637.
  • Correzione di bug: Il precaricamento di libjsig.dylib causa deadlock quando viene chiamato signal()
    Le applicazioni devono precaricare la libreria libjsig per abilitare il concatenamento di segnali. In precedenza, su OS X, dopo il precaricamento di libjsig.dylib, qualunque chiamata dal codice nativo a signal() causava un deadlock. Questo problema è stato risolto. Vedere JDK-8072147.
  • Correzione di bug: migliore dinamica gruppi
    Nell'implementazione OpenJDK SSL/TLS/DTLS (provider SunJSSE), per impostazione predefinita vengono utilizzati i principali gruppi sicuri Diffie-Hellman. Gli utenti possono personalizzare i gruppi Diffie-Hellman tramite la proprietà di sicurezza jdk.tls.server.defaultDHEParameters.
  • Correzione di bug: VM subisce un crash quando la classe viene ridefinita con Instrumentation.redefineClasses
    JVM potrebbe subire un crash quando una classe è stata ridefinita con Instrumentation.redefineClasses(). Il crash potrebbe essere un errore di segmentazione in SystemDictionary::resolve_or_null o un errore interno con il messaggio 'mancata corrispondenza delle tag con tabelle errore di risoluzione'. Questo problema è stato ora risolto. Vedere JDK-8076110.
Note

Quando si esegue OSX 10.11 El Capitan, se SIP è abilitato, alcune variabili di ambiente per le applicazioni di debug, come DYLD_LIBRARY_PATH, potrebbero essere sottoposte a striping dall'ambiente quando si esegue Java dalla riga di comando o quando si fa doppio clic su un file JAR. Le applicazioni non devono basarsi su queste variabili in un ambiente di produzione; servono solo per il debugging durante lo sviluppo.

MD5 non deve essere usato per le firme digitali dove è richiesta la resistenza al conflitto. Per impedire l'utilizzo di MD5 come algoritmo di firma digitale durante le operazioni di certificato X.509, MD5 viene aggiunto alla proprietà di sicurezza jdk.certpath.disabledAlgorithms. In caso di applicazioni che utilizzano ancora il certificato firmato MD5, aggiornare il certificato minimo il prima possibile.

Problemi noti

[macosx] Problemi con l'accesso facilitato allo schermo offerta dello sponsor (a11y)
Gli utenti che utilizzano la tastiera per accedere alle interfacce utente nell'Installer Java non saranno in grado di accedere ai collegamenti ipertestuali e alle caselle di controllo nelle schermate di offerta dei componenti aggiuntivi software. Come soluzione alternativa all'impostazione delle preferenze correlate al software del componente aggiuntivo nell'interfaccia utente, gli utenti possono disabilitare tali offerte disattivandole dal pannello di controllo Java o passando SPONSORS=0 tramite la riga di comando. Per ulteriori informazioni, fare riferimento alle Domande frequenti sull'installazione di Java senza le offerte dello sponsor.

Data di scadenza di Java

La data di scadenza di Java 8u65 è il 19 gennaio 2016. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 19 febbraio 2016 come data di scadenza di questo JRE (versione 8u65). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u65.

» Note di rilascio di Java 8u65


Java 8 Update 60 (8u60)

Caratteristiche più importanti della release
  • Dati IANA 2015e
    JDK 8u60 contiene i dati del fuso orario IANA versione 2015e. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: dns_lookup_realm deve essere false per impostazione predefinita
    Il valore di dns_lookup_realm nel file krb5.conf Kerberos è false per impostazione predefinita. Vedere 8080637.
  • Correzione di bug: disabilitare le suite di cifratura RC4
    Le suite di cifratura TLS basate su RC4 (ad esempio TLS_RSA_WITH_RC4_128_SHA) sono considerate compromesse e non devono più essere usate (vedere RFC 7465). Le suite di cifratura TLS basate su RC4 sono state pertanto disattivate per impostazione predefinita nell'implementazione Oracle JSSE mediante l'aggiunta di "RC4" alla proprietà di sicurezza "jdk.tls.disabledAlgorithms" e la rimozione dalla lista delle suite di cifratura abilitate predefinite. Queste suite di cifratura possono essere riattivate rimuovendo "RC4" dalla proprietà di sicurezza "jdk.tls.disabledAlgorithms" nel file java.security o mediante la chiamata dinamica del metodo Security.setProperty(), nonché aggiungendole di nuovo alla lista delle suite di cifratura abilitate utilizzando i metodi SSLSocket/SSLEngine.setEnabledCipherSuites(). È inoltre possibile usare l'opzione della riga di comando -Djava.security.properties per sostituire la proprietà di sicurezza jdk.tls.disabledAlgorithms. Ad esempio:
    java -Djava.security.properties=my.java.security ...
    dove my.java.security è un file contenente la proprietà senza RC4:
    jdk.tls.disabledAlgorithms=SSLv3
    Anche con questa opzione impostata dalla riga di comando, le suite di cifratura basate su RC4 devono essere aggiunte nuovamente alla lista delle suite di cifratura abilitate mediante i metodi SSLSocket/SSLEngine.setEnabledCipherSuites(). Vedere 8076221.
  • Correzione di bug: supporto per il rilevamento del tipo di keystore per i keystore JKS e PKCS12
    Modalità di compatibilità del keystore: per facilitare l'interoperabilità, ora il tipo di keystore Java JKS supporta la modalità di compatibilità del keystore per impostazione predefinita. Questa modalità consente ai keystore JKS di accedere ai formati file JKS e PKCS12. Per disabilitare la modalità di compatibilità del keystore, impostate la proprietà di sicurezza keystore.type.compat sul valore stringa false. Vedere 8062552.
  • Correzione di bug: metodi di monitoraggio Unsafe non più validi nella release JDK 8u
    I metodi monitorEnter, monitorExit e tryMonitorEnter in sun.misc.Unsafe sono contrassegnati come non più validi in JDK 8u60 e verranno rimossi in una release futura. Questi metodi non vengono utilizzati nel kit JDK e vengono utilizzati solo raramente al di fuori del kit JDK. Vedere 8069302.
  • Correzione di bug: estrazione delle registrazioni JFR dai file della memoria mediante SA
    DumpJFR è uno strumento basato su Serviceability Agent che può essere utilizzato per estrarre i dati JFR (Java Flight Recorder) dai file della memoria e dai processi Hotspot attivi. DumpJFR può essere utilizzato in uno dei metodi riportati di seguito.
    • Collegamento di DumpJFR a un processo attivo:

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

    • Collegamento di DumpJFR a un file della memoria:

      java -cp $JAVA_HOME/lib/sa-jdi.jar sun.jvm.hotspot.tools.DumpJFR <java> <core>
    Lo strumento DumpJFR esporta i dati JFR in un file di dump denominato recording.jfr nella cartella di lavoro corrente. Vedere 8065301 (non pubblico).
  • Correzione di bug: le variabili locali denominate 'enum' causano crash spuri del compilatore
    Il parser javac analizza in modo errato le variabili locali con nome 'enum'; ciò provoca errori spuri quando un programma che contiene tali variabili locali viene compilato con un flag 'source' corrispondente a una release in cui il costrutto enum non è disponibile (ad esempio '-source 1.4'). Vedere 8069181.
Java Development Kit per ARM Release 8u60

Questa release include Java Development Kit per ARM Release 8u60 (JDK 8u60 per ARM). Per informazioni sul supporto dei dispositivi ARM, vedere la pagina JDK for ARM Downloads. Per informazioni sui requisiti di sistema, istruzioni di installazione e suggerimenti di risoluzione dei problemi, vedere la pagina Installation Instructions.

Limitazione: il supporto di Native Memory Tracking è limitato in JDK per ARM. L'opzione della riga di comando Java XX:NativeMemoryTracking=detail non è supportata per le destinazioni ARM (all'utente viene visualizzato un messaggio di errore). Utilizzare invece la seguente opzione:
XX:NativeMemoryTracking=summary

Aggiornamenti alla documentazione dovuti ai miglioramenti Nashorn
JDK 8u60 include nuovi miglioramenti per Nashorn. Pertanto, le modifiche apportate alla documentazione riportata di seguito devono essere lette insieme alla documentazione Nashorn corrente.
  • Aggiunta: nella sezione precedente si affermava che ogni oggetto JavaScript esposto alle interfacce API Java implementa l'interfaccia java.util.Map. Ciò è vero anche per gli array JavaScript. Si tratta tuttavia di un funzionamento spesso non desiderato o previsto quando il codice Java prevede oggetti analizzati con JSON. In genere le librerie Java che manipolano gli oggetti analizzati con JSON prevedono piuttosto gli array per esporre l'interfaccia java.util.List. Se è necessario esporre gli oggetti JavaScript in modo che gli array vengano esposti come liste e non come mappe, potete usare la funzione Java.asJSONCompatible(obj), dove obj è la radice della struttura di oggetti JSON.
  • Correzione: il paragrafo Attenzione riportato alla fine della sezione Mapping dei tipi dati non è più applicabile. Nashorn garantisce che le stringhe JavaScript interne vengano convertite in java.lang.String quando esposte all'esterno.
  • Correzione: la frase "Ad esempio, gli array devono essere convertiti in modo esplicito..." della sezione Mapping dei tipi dati è errata. Gli array vengono infatti convertiti in modo automatico nei tipi di array Java java.util.List, java.util.Collection, java.util.Queue, java.util.Deque e così via.
Modifiche nella funzione Set di regole di distribuzione 1.2
JDK 8u60 implementa la funzione DRS (Set di regole di distribuzione) 1.2, che include le modifiche riportate di seguito.
  • Aggiunta dell'elemento "checksum" come elemento secondario di "id", che consente l'identificazione dei file JAR non firmati da parte del checksum SHA-256 della forma non compressa di un file JAR:
    • L'elemento "checksum" corrisponderà solo ai file JAR non firmati e l'hash specificato verrà confrontato solo con la forma non compressa del file JAR.
    • L'elemento "checksum" (simile all'elemento "certificate") dispone di due argomenti, "hash" e "algorithm"; tuttavia, a differenza dell'elemento "certificate", l'unico valore supportato per l'argomento "algorithm" è "SHA-256". Qualsiasi altro valore fornito verrà ignorato.
  • L'elemento "message" ora si applica a tutti i tipi di regola, mentre in precedenza si applicava solo a una regola di blocco:
    • In una regola di esecuzione, l'elemento secondario message causa la visualizzazione di una finestra di dialogo di messaggio, mentre senza una regola di esecuzione il funzionamento predefinito prevede la visualizzazione di una finestra di dialogo di certificato o non firmata. Il messaggio verrà visualizzato nella finestra di dialogo del messaggio.
    • In una regola predefinita il messaggio verrà visualizzato solo se l'azione predefinita è il blocco. In questo caso il messaggio verrà incluso nella finestra di dialogo di blocco.
  • Ripetizione dei blocchi "customer" nei record della console Java, dei file di trace e di Java Usage Tracker.
    • Nelle versioni DRS precedenti alla 1.2, gli elementi "customer" potevano essere inclusi, con qualsiasi elemento secondario, nel file ruleset.xml. Questo elemento e tutti i relativi elementi secondari vengono ignorati. In DRS 1.2 gli elementi continuano a essere ignorati funzionalmente. Tuttavia:
      • durante l'analisi del file ruleset.xml, tutti i blocchi "customer" verranno ripetuti nella console Java e nel file di trace di distribuzione (se la console e la funzione di trace sono state abilitate);
      • quando si usa una regola, tutti i record "customer" inclusi nella regola verranno aggiunti al record JUT (Java Usage Tracker) se JUT è stato abilitato.
In seguito alle modifiche descritte, la definizione DTD per DRS 1.2 è la seguente:
<!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 di scadenza di Java

La data di scadenza di 8u60 è il 20 ottobre 2015. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 20 novembre 2015 come data di scadenza di questo JRE (versione 8u60). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u60.

» Note di rilascio di Java 8u60


Java 8 Update 51 (8u51)

Caratteristiche più importanti della release
  • Dati IANA 2015d
    JDK 8u51 contiene i dati del fuso orario IANA versione 2015d. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: aggiunta di nuovi certificati root Comodo per le autorità di certificazione root
    Sono stati aggiunti quattro nuovi certificati root per Comodo:
    1. COMODO ECC Certification Authority
      alias: comodoeccca
      DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
    2. COMODO RSA Certification Authority
      alias: comodorsaca
      DN: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
    3. USERTrust ECC Certification Authority
      alias: usertrusteccca
      DN: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
    4. USERTrust RSA Certification Authority
      alias: usertrustrsaca
      DN: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
    Vedere JDK-8077997 (non pubblico).
  • Correzione di bug: aggiunta di nuovi certificati root GlobalSign per le autorità di certificazione root
    Sono stati aggiunti due certificati root per GlobalSign:
    1. CA root GlobalSign ECC - R4
      alias: globalsigneccrootcar4
      DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
    2. CA root GlobalSign ECC - R5
      alias: globalsigneccrootcar5
      DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
    Vedere JDK-8077995 (non pubblico).
  • Correzione di bug: aggiunta di Actalis alla CA root
    È stato aggiunto un nuovo certificato root:
    Actalis Authentication Root CA
    alias: actalisauthenticationrootca
    DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT

    Vedere JDK-8077903 (non pubblico).
  • Correzione di bug: aggiunta di un nuovo certificato root Entrust ECC
    È stato aggiunto un nuovo certificato root:
    Entrust Root Certification Authority - EC1
    alias: entrustrootcaec1
    DN: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=See www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

    Vedere JDK-8073286 (non pubblico).
  • Correzione di bug: rimozione dei vecchi certificati criteri root Classe 1 e 2 Valicert
    Sono stati rimossi due certificati root con chiavi da 1024 bit:
    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
    Vedere JDK-8077886 (non pubblico).
  • Correzione di bug: rimozione dei vecchi certificati root Thawte
    Sono stati rimossi due certificati root con chiavi da 1024 bit:
    1. Thawte Server CA
      alias: thawteserverca
      DN: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
    2. Thawte Personal Freemail CA
      alias: thawtepersonalfreemailca
      DN: EMAILADDRESS=personal-freemail@thawte.com, CN=Thawte Personal Freemail CA, OU=Certification Services Division, O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA
    Vedere JDK-8074423 (non pubblico).
  • Correzione di bug: rimozione di altri vecchi certificati root Verisign, Equifax e Thawte
    Sono stati rimossi cinque certificati root con chiavi da 1024 bit:
    1. Verisign Class 3 Public Primary Certification Authority - G2
      alias: verisignclass3g2ca DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 3 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
    2. Thawte Premium Server CA
      alias: thawtepremiumserverca
      DN: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, ST=Western Cape, C=ZA
    3. Equifax Secure Certificate Authority
      alias: equifaxsecureca
      DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
    4. Equifax Secure eBusiness CA-1
      alias: equifaxsecureebusinessca1
      DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
    5. Equifax Secure Global eBusiness CA-1,
      alias: equifaxsecureglobalebusinessca1
      DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
    Vedere JDK-8076202 (non pubblico).
  • Correzione di bug: rimozione dei certificati root TrustCenter CA da cacerts
    Sono stati rimossi tre certificati root:
    1. TC TrustCenter Universal CA I
      alias: trustcenteruniversalcai
      DN: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, O=TC TrustCenter GmbH, C=DE
    2. TC TrustCenter Class 2 CA II
      alias: trustcenterclass2caii
      DN: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, O=TC TrustCenter GmbH, C=DE
    3. TC TrustCenter Class 4 CA II
      alias: trustcenterclass4caii
      DN: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, O=TC TrustCenter GmbH, C=DE
    Vedere JDK-8072958 (non pubblico).
  • Correzione di bug: RC4 non più valido nel provider SunJSSE
    Ora RC4 è considerato un algoritmo di cifratura debole. I server non devono selezionare RC4 a meno che non via nessun altro candidato più forte nelle suite di cifratura richieste dal client. È stata aggiunta una nuova proprietà di sicurezza, jdk.tls.legacyAlgorithms, per definire gli algoritmi precedenti nell'implementazione Oracle JSSE. Gli algoritmi correlati a RC4 sono stati aggiunti alla lista degli algoritmi precedenti. Vedere JDK-8074006 (non pubblico).
  • Correzione di bug: suite di cifratura RC4 proibite
    Ora RC4 è considerato un algoritmo di cifratura compromesso. Le suite di cifratura RC4 sono state rimosse dalla lista delle suite di cifratura predefinite per client e server nell'implementazione Oracle JSSE. Queste suite di cifratura possono essere ancora abilitate mediante i metodi SSLEngine.setEnabledCipherSuites() e SSLSocket.setEnabledCipherSuites(). Vedere JDK-8077109 (non pubblico).
  • Correzione di bug: controllo delle certificazioni migliorato
    Con questa correzione, durante l'identificazione dell'endpoint JSSE non viene eseguita la ricerca inversa dei nomi per gli indirizzi IP per impostazione predefinita nel kit JDK. Se un'applicazione deve eseguire la ricerca inversa dei nomi per gli indirizzi IP raw nelle connessioni SSL/TLS e viene rilevato un problema di compatibilità di identificazione dell'endpoint, è possibile utilizzare la proprietà di sistema "jdk.tls.trustNameService" per attivare la ricerca inversa dei nomi. Tenere presente che se il servizio di nomi non è sicuro, l'abilitazione della ricerca inversa dei nomi può creare una vulnerabilità agli attacchi di tipo MITM. Vedere JDK-8067695 (non pubblico).
Data di scadenza di Java

La data di scadenza di 8u51 è il 20 ottobre 2015. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 20 novembre 2015 come data di scadenza di questo JRE (versione 8u51). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u51.

» Note di rilascio di Java 8u51


Java 8 Update 45 (8u45)

Caratteristiche più importanti della release
  • Dati IANA 2015a
    JDK 8u45 contiene i dati del fuso orario IANA versione 2015a. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: ottimizzazione della gestione dei file jar. A partire da JDK release 8u45, lo strumento jar non supporta più la barra iniziale "/" e ".." (punto-punto) come componenti di percorso in un nome di file zip durante la creazione di un nuovo file zip e jar e/o l'estrazione da un file zip e jar. Se necessario, è necessario utilizzare la nuova opzione della riga di comando "-P" per conservare il componente di percorso punto-punto e/o il componente di percorso assoluto. Vedere 8064601 (non pubblico).
  • Correzione di bug: esecuzione dell'applicazione jnlp con la sezione "resource" nidificata non riuscita con NPE in caricamento in jre8u40. Un'applicazione jnlp con tag nidificate in una tag <java> o può restituire un'eccezione NPE. Il problema è stato risolto. La tag deve essere utilizzata solo se viene effettivamente utilizzata la tag <java>. Vedere 8072631 (non pubblico).
Data di scadenza di Java

La data di scadenza di Java 8u45 è il 14 luglio 2015. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 14 agosto 2015 come data di scadenza di questo JRE (versione 8u45). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u45.

» Note di rilascio di Java 8u45


Java 8 Update 40 (8u40)

Caratteristiche più importanti della release
  • Dati IANA 2014j
    JDK 8u40 contiene i dati del fuso orario IANA versione 2014j. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: metodi predefiniti e statici per le interfacce in JDI, JDWP e JDB. A partire da JDK 8 è possibile disporre direttamente di metodi eseguibili statici e predefiniti nelle interfacce. Tali metodi non sono possono essere eseguiti tramite JDWP o JDI e pertanto non è possibile eseguirne correttamente il debug. Per ulteriori dettagli, vedere JDK 8 Compatibility Guide. Vedere 8042123.
  • Correzione di bug: è possibile abilitare Java Access Bridge dal Pannello di controllo per i JRE a 32 bit. La casella di controllo "Abilita Java Access Bridge" è stata in precedenza rimossa dal Pannello di controllo Java con la disinstallazione di JRE a 64 bit anche se il JRE a 32 bit era ancora presente sul sistema. A partire dalla release JDK 8u40, la casella di controllo "Abilita Java Access Bridge" viene conservata (Pannello di controllo -> Accessibilità -> Centro accessibilità -> Utilizza il computer senza schermo, se è presente il JRE a 32 bit. Un utente può pertanto abilitare il bridge Java Access tramite il pannello di controllo. Vedere 8030124.
  • Correzione di bug: modernizzazione dello stack dei supporti JavaFX su Mac OS X. Una piattaforma per lettori basata su AVFoundation è stata aggiunta ai supporti JavaFX. È ora possibile rimuovere la piattaforma precedente basata su QTKit per la compatibilità con Mac App Store. Vedere 8043697 (non pubblico).
  • Correzione di bug: interfacce API DOM mancanti. Nella release JDK 8u40, le precedenti interfacce API DOM del plugin sono state rimosse inavvertitamente. Se un'applet richiede l'uso di com.sun.java.browser.dom.DOMService per comunicare con il browser, è possibile che sia necessario aggiornare l'applet per utilizzare netscape.javascript.JSObject o continuare a utilizzare JDK 8 Update 31. Questo problema è stato risolto nella build 26 e sono stati inviati nuovi Installer 8u40. Se si verifica questo problema, scaricate ed eseguite gli Installer JDK 8u40 aggiornati. Vedere 8074564.
  • Correzione di bug: (Mac 10.10) l'applicazione eseguita con la schermata iniziale ha problemi di attivazione. Le applicazioni avviate mediante Webstart o le applicazioni standalone, che utilizzano la schermata iniziale, non possono essere avviate tramite tastiera. Soluzione alternativa: avviare javaws utilizzando l'opzione -Xnosplash. Questo problema è stato risolto nella build 27 ed è stato inviato un nuovo Installer 8u40. Se si verifica questo problema, scaricate ed eseguite l'Installer JDK 8u40 aggiornato. Vedere 8074668.
  • Miglioramenti dello strumento Java Packager
    Nella release JDK 8u40 sono stati apportati i seguenti miglioramenti a Java Packager:
  • Interfacce API non valide
    I meccanismi Endorsed Standards Override ed Extension non sono validi e possono essere rimossi in una release futura. Non sono presenti modifiche in fase di esecuzione. Si consiglia di eseguire la migrazione delle applicazioni esistenti che utilizzano i meccanismi 'Endorsed Standards Override' o 'Extension' per evitare che utilizzino questi meccanismi. Per verificare se vengono utilizzati questi meccanismi, è disponibile l'opzione della riga di comando -XX:+CheckEndorsedAndExtDirs, L'esecuzione di questa opzione non riesce se una qualsiasi delle seguenti condizioni è vera:
    • La proprietà di sistema -Djava.endorsed.dirs o -Djava.ext.dirs è impostata per modificare la posizione predefinita; oppure
    • La directory ${java.home}/lib/endorsed esiste; oppure
    • ${java.home}/lib/ext contiene file JAR, tranne quelli forniti da JDK; oppure
    • Qualsiasi directory delle estensione a livello di sistema specifica della piattaforma contiene file JAR.
    L'opzione della riga di comando -XX:+CheckEndorsedAndExtDirs è supportata in JDK 8u40 e nelle release successive.
  • Differenze nella pagina dello strumento JJS
    La versione giapponese della pagina della Guida di jjs è diversa dalla versione inglese. Alcune delle opzioni non supportate sono state rimosse dalla versione inglese della pagina dello strumento jjs. La versione giapponese del documento verrà aggiornata in futuro. Vedere 8062100 (non pubblico). Per le altre modifiche apportate alla pagina dello strumento jjs, vedere Miglioramenti degli strumenti in JDK 8.
  • Modifica dei valori predefiniti di G1HeapWastePercent e G1MixedGCLiveThresholdPercent
    Il valore predefinito di G1HeapWastePercent è stato modificato da 10 a 5 per ridurre la necessità di GC complete. Per lo stesso motivo, il valore predefinito di G1MixedGCLiveThresholdPercent è stato modificato da 65 a 85.
  • Nuova interfaccia di filtro per l'accesso alle classi Java
    L'interfaccia jdk.nashorn.api.scripting.ClassFilter consente di limitare l'accesso alle classi Java specificate dagli script eseguiti da un motore di script Nashorn. Per ulteriori informazioni, consultare Limitazione dell'accesso di script alle classi Java specificate nella Guida per l'utente di Nashorn e 8043717 (non pubblico).
  • Problemi con i provider JCE di terze parti
    La correzione per JDK-8023069 (in JDK 8u20) ha aggiornato sia i provider SunJSSE che i provider SunJCE, incluse alcune interfacce interne. Alcuni provider JCE di terze parti (ad esempio, RSA JSAFE) utilizzano alcune interfacce interne sun.* e, pertanto, non funzioneranno con il provider SunJSSE aggiornato. Questi provider dovranno essere aggiornati per consentirne il funzionamento con il provider SunJSSE aggiornato. Se si è interessati da questo problema, contattare il fornitore JCE per un aggiornamento. Vedere 8058731.
  • Cifrature riabilitate in Solaris Crypto Framework
    Se si sta utilizzando Solaris 10, è stata apportata una modifica per riabilitare le operazioni con MD5, SHA1 e SHA2 mediante Solaris Crypto Framework. Se si è verificata un'eccezione CloneNotSupportedException o viene visualizzato il messaggio di errore PKCS11 CKR_SAVED_STATE_INVALID con JDK 8u40, è necessario verificare e applicare le patch o le versioni più recenti riportate di seguito.
    • 150531-02 su SPARC
    • 150636-01 su sistemi x86
  • Aggiornamenti alla guida per la risoluzione dei problemi per NMT
    NMT (Native Memory Tracking) è una funzione VM Hotspot Java che tiene traccia dell'utilizzo della memoria interna per una JVM HotSpot. È possibile utilizzare NMT (Native Memory Tracking) per monitorare le allocazioni di memoria interna della VM e diagnosticare le perdite di risorse di memoria nella VM. La pagina dei miglioramenti della VM è stata aggiornata con le funzioni NMT. Vedere Miglioramenti della Java Virtual Machine in Java SE 8. La guida per la risoluzione dei problemi è stata aggiornata con le funzioni NMT. Vedere NMT (Native Memory Tracking).
  • Funzione Più launcher JRE non valida
    La funzione di selezione della versione JRE in fase di avvio o Più launcher JRE, come indicato, non è valida in JDK 8u40. Le applicazioni che richiedono specifiche versioni di Java distribuite con questa funzione devono passare a soluzioni di distribuzione alternative, ad esempio Java WebStart.
  • Miglioramenti di JavaFX
    A partire dalla release JDK 8u40, i controlli di JavaFX sono stati migliorati per supportare le tecnologie assistive, pertanto tali controlli sono ora accessibili. È inoltre disponibile un'interfaccia API pubblica che consente agli sviluppatori di scrivere i propri controlli accessibili. Il supporto dell'accesso facilitato viene fornito sulle piattaforme Windows e Mac OS X e include quanto elencato di seguito.
    • Supporto per la lettura dei controlli di JavaFX tramite un lettore di schermo
    • Possibilità di utilizzare i controlli di JavaFX tramite tastiera
    • Supporto per una modalità speciale ad alto contrasto che rende i controlli più visibili agli utenti
    Vedere 8043344 (non pubblico).

    La release JDK 8u40 include nuovi controlli dell'interfaccia utente di JavaFX, un controllo della casella di selezione, supporto del testo formattato e un set standard di finestre di dialogo per avvisi.
    • Controllo della casella di selezione: una casella di selezione è un campo di testo a riga singola che consente di selezionare un numero o un valore dell'oggetto da una sequenza ordinata. Per ulteriori informazioni, consultare la classe javafx.scene.control.Spinner.
    • Testo formattato: una nuova classe TextFormatter offre funzionalità di formattazione del testo per classi secondarie di TextInputControl (ad esempio, TextField e TextArea). Per ulteriori informazioni, consultare la classe javafx.scene.control.TextFormatter.
    • Finestre di dialogo: la classe Dialog consente alle applicazioni di creare finestre di dialogo personalizzate. È inoltre disponibile una classe Alert, a estensione della classe Dialog, che offre supporto per diversi tipi di finestre di dialogo predefinite che possono essere facilmente visualizzate agli utenti per richiedere una risposta. Per ulteriori informazioni, consultare le classi javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog, javafx.scene.control.ChoiceDialog.
    Vedere 8043350 (non pubblico).
Funzioni commerciali
  • Application Class Data Sharing (AppCDS)
    Application Class Data Sharing (AppCDS) estende CDS per consentire di inserire le classi presenti nelle directory delle estensioni standard e il classpath dell'applicazione nell'archivio condiviso. Questa è una funzione sperimentale e non è autorizzata per uso commerciale. Vedere l'opzione -XX:+UseAppCDS nella pagina dello strumento Launcher Java.
  • Cooperative Memory Management
    A partire da JDK 8u40, il concetto "limite d'uso della memoria" è stato aggiunto al JDK. Il limite d'uso della memoria è una proprietà che rappresenta l'utilizzo totale della memoria (RAM) nel sistema. Più alto è il limite d'uso della memoria, più rapidamente verrà esaurita la memoria del sistema. Questa è una funzione sperimentale e non è autorizzata per uso commerciale. Come conseguenza dell'aumento del limite d'uso della memoria, il JDK tenterà di ridurre la quantità di memoria che utilizza. Questa operazione viene eseguita principalmente riducendo la dimensione heap Java. Le azioni che verranno intraprese dal JDK per ridurre l'utilizzo della memoria possono influire negativamente sulle prestazioni. Si tratta di una scelta intenzionale. Il livello del limite d'uso viene fornito dall'applicazione mediante un MXBean JMX che utilizza una scala di valori da 0 (nessun limite d'uso) a 10 (memoria quasi esaurita). Per abilitare questa funzione, è necessario registrare jdk.management.cmm.SystemResourcePressureMXBean. Il limite d'uso della memoria viene quindi impostato utilizzando l'attributo "MemoryPressure".
    È disponibile un nuovo flag della riga di comando -XX:MemoryRestriction che utilizza uno degli argomenti 'none', 'low', 'medium' o 'high'. Questo flag imposterà il limite d'uso iniziale nel JDK e funzionerà anche nei casi in cui l'MXBean non è registrato. Cooperative Memory Management richiede G1 GC (-XX:+UseG1GC). Questa funzione è compatibile con il flag -XX:+ExplicitGCInvokesConcurrent.
  • Nuovi flag commerciali
    Sono ora disponibili due nuove opzioni VM per i titolari di licenze commerciali:
    • -XX:+ResourceManagement
    • -XX:ResourceManagementSampleInterval=value (millisecondi)
    Per ulteriori informazioni, vedere la documentazione del Launcher Java.
  • È stata aggiunta la documentazione sull'Installer MSI
    È disponibile la Guida per l'Installer JRE Enterprise MSI (Microsoft Windows Installer). L'Installer JRE Enterprise MSI richiede una licenza commerciale per essere utilizzato in produzione. Ulteriori informazioni sulle funzioni commerciali e come abilitarle.
Data di scadenza di Java

La data di scadenza di Java 8u40 è il 14 aprile 2015. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 14 maggio 2015 come data di scadenza di questo JRE (versione 8u40). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u40.

» Note di rilascio di Java 8u40


Java 8 Update 31 (8u31)

Caratteristiche più importanti della release
  • Dati IANA 2014j
    JDK 8u31 contiene i dati del fuso orario IANA versione 2014j. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • SSLv3 è disabilitato per impostazione predefinita
    A partire dalla release JDK 8u31, il protocollo SSLv3 (Secure Socket Layer) è stato disattivato e non è disponibile normalmente. Vedere la proprietà jdk.tls.disabledAlgorithms nel file \lib\security\java.security. Se il protocollo SSLv3 è assolutamente necessario, è possibile riattivarlo rimuovendo la voce 'SSLv3' dalla proprietà jdk.tls.disabledAlgorithms nel file java.security oppure impostando dinamicamente questa proprietà di sicurezza prima dell'inizializzazione dell'estensione JSSE.
  • Modifiche al pannello di controllo Java
    A partire dalla release JDK 8u31, il protocollo SSLv3 è stato rimosso dalle opzioni avanzate del pannello di controllo Java. Se è necessario utilizzare SSLv3 per le applicazioni, è possibile riabilitarlo manualmente come indicato di seguito.
    • Abilitazione del protocollo SSLv3 nel livello JRE: vedere la descrizione nella sezione precedente.
    • Abilitazione del protocollo SSLv3 nel livello di distribuzione: modificare il file deployment.properties e aggiungere l'istruzione seguente:

      deployment.security.SSLv3=true
Data di scadenza di Java

La data di scadenza di Java 8u31 è il 14 aprile 2015. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 14 maggio 2015 come data di scadenza di questo JRE (versione 8u31). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u31.

» Note di rilascio di Java 8u31


Java 8 Update 25 (8u25)

Caratteristiche più importanti della release
  • Dati IANA 2014c
    JDK 8u25 contiene i dati del fuso orario IANA versione 2014c. Per ulteriori informazioni, fare riferimento a Versioni dei dati di fuso orario nel software JRE.
  • Correzione di bug: diminuzione della modalità di preferenza di RC4 nella lista delle suite di cifratura abilitate
    Questa correzione diminuisce la preferenza delle suite di cifratura basate su RC4 nella lista predefinita delle suite di cifratura abilitate del provider SunJSSE. Vedere 8043200 (non pubblico).
  • Correzione di bug: si verifica il crash di JRE 8u20 durante l'utilizzo del servizio Instant Messaging in giapponese su Windows
    Si verifica un arresto anomalo della virtual machine durante l'utilizzo dei controlli Swing quando alcuni caratteri giapponesi o cinesi vengono utilizzati come input in una piattaforma Windows. Il problema è stato risolto. Vedere 8058858 (non pubblico).
Istruzioni per disabilitare SSL v3.0 in Oracle JDK e JRE

Oracle consiglia a utenti e sviluppatori di disabilitare l'utilizzo del protocollo SSLv3.
» In che modo gli utenti Java possono verificare di non essere interessati dalla vulnerabilità 'Poodle' di SSL V3.0?

Data di scadenza di Java

La data di scadenza di Java 8u25 è il 20 gennaio 2015. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 20 febbraio 2015 come data di scadenza di questo JRE (versione 8u25). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle Java SE.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u25.

» Note di rilascio di Java 8u25


Java 8 Update 20 (8u20)

Caratteristiche più importanti della release
  • Nuovi flag aggiunti a Java Management API
    I flag MinHeapFreeRatio e MaxHeapFreeRatio sono stati resi gestibili. Ciò significa che possono essere modificati in fase di esecuzione tramite Management API in Java. Il supporto per questi flag è stato anche aggiunto a ParallelGC come parte del criterio per dimensione adattabile.
  • Modifiche dell'Installer Java
    • È disponibile un nuovo Installer JRE Enterprise MSI (Microsoft Windows Installer), che consente agli utenti di installare l'ambiente JRE in ambito aziendale. Per ulteriori informazioni, vedere la sezione Download dell'Installer in Installazione dell'ambiente JRE per Microsoft Windows. L'Installer JRE Enterprise MSI è disponibile solo come componente di Java SE Advanced o di Java SE Suite. Per informazioni su questi prodotti commerciali, vedere Java SE Advanced e Java SE Suite.
    • Lo strumento di disinstallazione di Java, integrato all'Installer, consente di rimuovere le versioni precedenti di Java dal sistema. Questa modifica si applica alle piattaforme Windows a 32 bit e a 64 bit. Vedere Disinstallazione dell'ambiente JRE.
  • Modifiche del Pannello di controllo Java
    • La scheda Aggiornamento nel Pannello di controllo Java ora consente agli utenti di aggiornare automaticamente gli ambienti JRE a 64 bit (oltre alle versioni a 32 bit) installati nei sistemi.
    • Il livello di sicurezza Media è stato rimosso. Ora sono disponibili solo i livelli Alta e Molto alta. Le applet non conformi ai criteri di sicurezza più recenti potranno continuare a essere eseguite se si includono i siti che le ospitano nella lista di eccezioni dei siti. Mediante la lista di eccezioni dei siti, gli utenti possono consentire l'esecuzione delle stesse applet che sarebbero consentite selezionando l'opzione Media, ma secondo un criterio sito per sito, in modo da ridurre al minimo il rischio di utilizzare impostazioni più permissive.
  • Compilatore Java aggiornato
    Il compilatore javac è stato aggiornato per implementare l'analisi delle assegnazioni definite per l'accesso al campo finale vuoto mediante la parola chiave "this". Per ulteriori dettagli, vedere JDK 8 Compatibility Guide.
  • Modifica della versione minima di Java richiesta per il plugin Java e per Java Webstart
    Ora la versione minima di Java richiesta per il plugin Java e per Java Webstart è Java 5. Le applet che non vengono eseguite in Java 5 o in una versione successiva deve essere aggiornate a una versione successiva di Java per continuare a funzionare. Le applet scritte per le versioni precedenti, ma in grado di essere eseguite almeno in Java 5, continueranno a funzionare.
  • Modifica nella formattazione dell'output di UsageTracker
    La formattazione dell'output di UsageTracker è stata modificata per consentire l'uso della delimitazione tra virgolette al fine di evitare confusione nel log. Potrebbero essere necessarie modifiche alla modalità di lettura di tali informazioni. La funzione può essere configurata con le modalità di esecuzione delle versioni precedenti, anche se si consiglia l'uso del nuovo formato. Vedere la documentazione di Java Usage Tracker.
  • Modifiche agli strumenti di creazione package Java
    • javafxpackager è stato rinominato in javapackager
    • L'opzione "-B" è stata aggiunta al comando di distribuzione di javapackager per consentire agli utenti di passare gli argomenti ai bundler utilizzati per creare applicazioni indipendenti. Per informazioni, vedere la documentazione javapackager (Windows)/(Unix).
    • L'argomento parametro di applicazione di supporto è stato aggiunto a JavaFX Ant Task Reference. Consente di specificare un argomento (nell'elemento ) per il bundler utilizzato per creare applicazioni indipendenti.
Data di scadenza di Java

La data di scadenza di Java 8u20 è il 14 ottobre 2014. Java scade ogni volta che diventa disponibile una nuova release con correzioni alla vulnerabilità della sicurezza. Per i sistemi che non sono in grado di raggiungere i server Oracle, un meccanismo secondario imposta il 14 novembre 2014 come data di scadenza di questo JRE (versione 8u20). Dopo che una delle seguenti condizioni viene soddisfatta (la nuova release diventa disponibile o viene raggiunta la data di scadenza), Java fornirà altre avvertenze e promemoria per l'aggiornamento alla versione più recente.

Correzioni dei bug

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u20.

» Note di rilascio di Java 8u20


Java 8 Update 11 (8u11)

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u11.

» Note di rilascio di Java 8u11


Java 8 Update 5 (8u5)

Questa release contiene correzioni per i problemi di sicurezza. Per ulteriori informazioni, vedere Advisory di aggiornamento delle patch critiche Oracle.

Per la lista delle correzioni dei bug incluse in questa release, vedere la pagina Correzioni dei bug in JDK 8u5.

» Note di rilascio di Java 8u5


Release di Java 8

» Note di rilascio di JDK e JRE 8


Si potrebbe essere interessati anche a:




Scegli una lingua | Informazioni su Java | Supporto | Sviluppatori
Privacy  | Termini e condizioni per l'utilizzo | Marchi | Dichiarazione di non responsabilità

Oracle