Java.com

Pobieranie Pomoc

Wersja do druku

Najważniejsze cechy wydania Java 8


Artykuł dotyczy:
  • Wersje oprogramowania Java: 8.0

Na tej stronie przedstawiono najważniejsze zmiany w poszczególnych wydaniach oprogramowania Java, mające wpływ na użytkowników końcowych. Więcej informacji o zmianach można znaleźć w uwagach do wydania dla poszczególnych wersji.
» Daty wydań Java


Java 8 Update 221 (8u221)

Najważniejsze cechy wydania
  • Dane IANA 2018i
    JDK 8u221 zawiera dane stref czasowych IANA w wersji 2018i. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Nowa funkcja: Funkcja HotSpot wykrywania systemu operacyjnego Windows poprawnie identyfikuje Windows Server 2019
    Przed tą poprawką Windows Server 2019 był rozpoznawany jako "Windows Server 2016", wskutek czego we właściwości systemowej os.name oraz w pliku hs_err_pid były wstawiane niepoprawne wartości.
    Zob. JDK-8211106
  • Usunięte funkcje i opcje: Usunięcie dwóch certyfikatów jednostek certyfikujących (CA) poziomu głównego firmy DocuSign
    Dwa certyfikaty CA poziomu głównego, wystawiane przez firmę DocuSign, zostały usunięte z magazynu kluczy cacerts:
    • Nazwa-alias "certplusclass2primaryca [jdk]"
      Nazwa rozróżniana: CN=Class 2 Primary CA, O=Certplus, C=FR
    • Nazwa-alias "certplusclass3pprimaryca [jdk]"
      Nazwa rozróżniana: CN=Class 3P Primary CA, O=Certplus, C=FR
    Zob. JDK-8223499
  • Usunięte funkcje i opcje: Usunięcie dwóch certyfikatów jednostek certyfikujących (CA) poziomu głównego firmy Comodo
    Dwa certyfikaty CA poziomu głównego, wystawiane przez firmę Comodo, zostały usunięte z magazynu kluczy cacerts:
    • Nazwa-alias "utnuserfirstclientauthemailca [jdk]"
      Nazwa rozróżniana: CN=UTN-USERFirst-Client Authentication and Email, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
    • Nazwa-alias "utnuserfirsthardwareca [jdk]"
      Nazwa rozróżniana: CN=UTN-USERFirst-Hardware, OU=http://www.usertrust.com, O=The USERTRUST Network, L=Salt Lake City, ST=UT, C=US
    Zob. JDK-8222136
  • Usunięte funkcje i opcje: Usunięcie dwóch certyfikatów jednostek certyfikujących (CA) poziomu głównego firmy T-Systems Deutsche Telekom
    Dwa certyfikaty CA poziomu głównego, wystawiane przez firmę T-Systems Deutsche Telekom, wygasły i zostały usunięte z magazynu kluczy cacerts:
    • Nazwa-alias "deutschetelekomrootca2 [jdk]"
      Nazwa rozróżniana: CN=Deutsche Telekom Root CA 2, OU=T-TeleSec Trust Center, O=Deutsche Telekom AG, C=DE
    Zob. JDK-8222137
  • Inne uwagi: Instalacja Java Access Bridge — rozwiązanie tymczasowe
    Istnieje ryzyko uszkodzenia funkcjonalności modułu Java Access Bridge podczas instalowania oprogramowania Java w systemie Windows, w którym występuje wcześniej zainstalowana wersja oprogramowania Java oraz działa instancja JAWS. Po ponownym rozruchu, w systemie może brakować pliku WindowsAccessBridge-64.dll w katalogu systemowym (C:\Windows\System32) dla 64-bitowych produktów Java albo w katalogu systemowym, używanym przez WOW64 (C:\Windows\SysWoW64) dla 32-bitowych produktów Java.
    Uszkodzeniu funkcjonalności Java Access Bridge można zapobiec, stosując jedno z następujących rozwiązań tymczasowych:
    • Zatrzymać JAWS przed uruchomieniem instalatora oprogramowania Java.
    • Odinstalować istniejące JRE przed instalowaniem nowej wersji oprogramowania Java.
    • Odinstalować istniejące JRE po zainstalowaniu nowej wersji oprogramowania Java i ponownym rozruchu komputera.
    Celem tych tymczasowych rozwiązań jest uniknięcie sytuacji, w której istniejące JRE jest odinstalowywane przy użyciu instalatora oprogramowania Java, gdy działa JAWS.
    JDK-8223293 (niepubliczne)
Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u221 jest 15 października 2019 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u221) w dniu 15 listopada 2019 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera także poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Critical Patch Update. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u221 Bug Fixes.

» Uwagi do wydania 8u221


Java 8 Update 211 (8u211)

Najważniejsze cechy wydania
  • IANA — dane 2018g
    JDK 8u211 zawiera dane IANA, dotyczące stref czasowych, w wersji 2018g. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Nowa funkcja: Obsługa japońskiego znaku logograficznego, przedstawiającego nową erę japońską
    Kod U+32FF został zarezerwowany przez Unicode Consortium do reprezentowania japońskiego znaku logograficznego, przedstawiającego nową erę, która zaczyna się od maja 2019 roku. Odpowiednie metody z klasy Character zwracają właściwości identyczne z właściwościami już istniejących znaków przedstawiających ery japońskie (np. U+337E dla ery „Meizi”). Szczegółowe informacje dotyczące tego znaku i jego kodu są dostępne na stronie http://blog.unicode.org/2018/09/new-japanese-era.html.
    Zob. JDK-8211398
  • Zmiana: Dodano certyfikat GlobalSign R6 poziomu głównego
    Następujący certyfikat poziomu głównego został dodany do magazynu „cacerts” zaufanych certyfikatów w OpenJDK:
    • GlobalSign
      • globalsignrootcar6
        DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R6

    JDK-8216577 (niepubliczne)
  • Zmiana: Certyfikaty serwerów TLS, zakotwiczone do głównego certyfikatu firmy Symantec, przestają być traktowane jako zaufane
    JDK — zgodnie z podobnymi planami ogłoszonymi wcześniej przez Google, Mozilla, Apple i Microsoft — przestaje traktować jako zaufane certyfikaty serwerów TLS wystawione przez firmę Symantec. Lista certyfikatów, które przestają być uznawane za zaufane, obejmuje zarządzane przez Symantec certyfikaty GeoTrust, Thawte i VeriSign.
    Certyfikaty serwerów TLS, wydane przed 16 kwietnia 2019 roku, będą — do chwili ich wygaśnięcia — uznawane za zaufane. Certyfikaty wydane po tej dacie będą odrzucane. Informacje, jak zastąpić swoje certyfikaty wydane przez firmę Symantec certyfikatem DigiCert, są dostępne na stronie pomocy technicznej DigiCert (DigiCert przejęła 1 grudnia 2017 roku weryfikację i wydawanie wszystkich certyfikatów Website Security SSL/TLS firmy Symantec).
    Wyjątkiem od tej zasady jest to, że certyfikaty serwerów TLS, wydawane przez dwie podległe jednostki certyfikujące (zarządzane przez Apple) i wymienione poniżej, nadal będą uznawane za zaufane, o ile zostaną wydane najpóźniej w dniu 31 grudnia 2019 r.
    Zob. JDK-8207258
  • Zmiana: Nazwa nowej ery japońskiej
    Nazwa zastępcza „NewEra”, używana dla japońskiej ery, która zaczyna się w dniu 1 maja 2019 roku, została zmieniona na zadeklarowaną przez rząd japoński nazwę „Reiwa”. Aplikacje, zależne od zastępczej nazwy używanej do uzyskania singletona nowej ery (JapaneseEra.valueOf("NewEra")), przestaną działać.
    Zob. JDK-8205432
  • Zmiana: Obsługa nowej ery japońskiej w klasie java.time.chrono.JapaneseEra
    Klasa JapaneseEra oraz jej metody of(int), valueOf(String) i values() zostały zmodyfikowane tak, aby umożliwiały w przyszłości dodawanie nowych er japońskich (np. określono w jaki sposób są definiowane singletony, jakie są powiązane wartości całkowitoliczbowe ery itd.)
    Zob. JDK-8212941
Data ważności oprogramowania Java

Datą ważności wydania 8u211 jest 16 lipca 2019 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u211) w dniu 16 sierpnia 2019 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u211 Bug Fixes.

» Uwagi do wydania 8u211


Java 8 Update 201 (8u201)

Najważniejsze cechy wydania
  • IANA — dane 2018e
    JDK 8u201 zawiera dane IANA, dotyczące stref czasowych, w wersji 2018e. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Zmiana: Wyłączenie zestawów szyfrowania TLS anonimowe i NULL
    Zestawy szyfrowania TLS anonimowe i NULL zostały dodane do właściwości zabezpieczeń jdk.tls.disabledAlgorithms i są teraz domyślnie wyłączone.
    Zob. JDK-8211883
  • Zmiana: Narzędzie jarsigner informuje o wygasaniu na podstawie znacznika czasu
    Narzędzie jarsigner pokazuje teraz więcej informacji o czasie życia pliku JAR zaopatrzonego w znacznik czasu. Są wyświetlane nowe komunikaty o błędach i ostrzeżenia, gdy — na podstawie znacznika czasu — plik wygasł lub wygaśnie w ciągu roku.
    Zob. JDK-8191438
Data ważności oprogramowania Java

Datą ważności wersji 8u201 jest 16 kwietnia 2019 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u201) w dniu 16 maja 2019 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u201 Bug Fixes.

» Uwagi do wydania 8u201


Java 8 Update 191 (8u191)

Najważniejsze cechy wydania
  • IANA — dane 2018e
    JDK 8u191 zawiera dane IANA, dotyczące stref czasowych, w wersji 2018e. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Zmiana: Zmieniono w systemie główną lokalizację pliku usagetracker.properties
    Lokalizacja pliku usagetracker.properties w systemie plików Windows została zmieniona z %ProgramData%\Oracle\Java\ na %ProgramFiles%\Java\conf
    Nie ma żadnych zmian w ścieżce pliku w systemach Linux, Solaris i macOS. JDK-8204901 (niepubliczne)
  • Zmiana: Wyłączenie wszystkich zestawów szyfrowania DES TLS
    Zestawy szyfrowania TLS oparte na algorytmie DES są obecnie uznawane za przestarzałe i nie powinny już być używane. Zestawy szyfrowania oparte na algorytmie DES został domyślnie zdezaktywowane w implementacji SunJSSE poprzez dodanie identyfikatora "DES" do właściwości zabezpieczeń jdk.tls.disabledAlgorithms. Można je ponownie uaktywnić, usuwając wpis "DES" z właściwości zabezpieczeń jdk.tls.disabledAlgorithms z pliku java.security lub dynamicznie wywołując metodę Security.setProperty(). W obu tych przypadkach trzeba, po ponownym włączeniu algorytmu DES, dodać do listy włączonych zestawów szyfrowania zestawy szyfrowania oparte na algorytmie DES, używając metody SSLSocket.setEnabledCipherSuites() lub SSLEngine.setEnabledCipherSuites().
    Należy pamiętać, że przed tą zmianą zestawy DES40_CBC (lecz nie wszystkie DES) zostały wyłączone za pomocą właściwości zabezpieczeń jdk.tls.disabledAlgorithms.
    Zob. JDK-8208350
  • Zmiana: Usunięcie kilku jednostek certyfikujących (CA) poziomu głównego firmy Symantec
    Następujące certyfikaty poziomu głównego, wystawiane przez firmę Symantec, nie są już używane i zostały usunięte:
    • Symantec
      • equifaxsecureca
        DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US
      • equifaxsecureglobalebusinessca1
        DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US
      • equifaxsecureebusinessca1
        DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US
      • verisignclass1g3ca
        DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
      • verisignclass2g3ca
        DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US
      • verisignclass1g2ca
        DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US
      • verisignclass1ca
        DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

    Zob. JDK-8191031
  • Zmiana: Usunięcie jednostki certyfikującej (CA) Baltimore CyberTrust, podpisującej kod
    Następujący certyfikat poziomu głównego, wystawiany przez firmę Baltimore CyberTrust i używany do podpisywania kodu, nie jest już używany i został usunięty:
    • baltimorecodesigningca
      DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE

    Zob. JDK-8189949
  • Poprawka: Niepowodzenie komunikacji LDAPS
    Dla kodu aplikacji, używającego protokołu LDAPS z limitem czasu połączenia z gniazdem <= 0 (wartość domyślna), działającego z aktualizacją CPU z lipca 2018 (8u181, 7u191 i 6u201), może podczas ustanawiania połączenia być zgłaszany wyjątek.
    Ramki najwyższego poziomu ze śladu stosu Exception aplikacji mogą mieć postać podobną do następującej:
    javax.naming.ServiceUnavailableException: ; socket closed
    at com.sun.jndi.ldap.Connection.readReply(Unknown Source)
    at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ...
    Problem ten został rozwiązany i poprawka jest dostępna w następujących wydaniach:
    • 8u181
    • 7u191

    Zob. JDK-8211107
Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u191 jest 15 stycznia 2019 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u191) w dniu 15 lutego 2019 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u191 Bug Fixes.

» Uwagi do wydania 8u191


Java 8 Update 181 (8u181)

Najważniejsze cechy wydania
  • IANA — dane 2018e
    JDK 8u181 zawiera dane IANA, dotyczące stref czasowych, w wersji 2018e. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Usunięta funkcja: Usunięto bazę danych Java DB
    Java DB, znana także jako Apache Derby, została w tym wydaniu usunięta.
    Zalecamy uzyskanie Apache Derby bezpośrednio ze strony:
    https://db.apache.org/derby (projekt Apache)
    JDK-8197871 (niepubliczne)
  • Zmiana: Udoskonalenie obsługi protokołu LDAP
    Dla połączeń LDAPS została włączona identyfikacja punktu końcowego.
    W celu zwiększenia odporności połączeń LDAPS (zabezpieczony LDAP poprzez TLS) zostały domyślnie włączone algorytmy identyfikacji punktu końcowego.
    Może się zdarzyć sytuacja, że aplikacja, która wcześniej mogła nawiązywać połączenie z serwerem LDAPS, nie będzie już mogła tego zrobić. Dla takiej aplikacji, jeśli jest to niezbędne, można wyłączyć identyfikację punktu końcowego, używając nowej właściwości systemowej: com.sun.jndi.ldap.object.disableEndpointIdentification.
    W celu wyłączenia algorytmów identyfikacji punktu końcowego należy tę właściwość zdefiniować (albo ustawić ją na wartość true).
    JDK-8200666 (niepubliczne)
  • Zmiana: Usprawnione przechodzenie przez stos
    Do fazy tworzenia obiektu, podczas deserializacji, zostały dodane nowe testy dostępu. Nie powinno to mieć żadnego wpływu na zwykłe użycie procesu deserializacji. Zmiana ta może jednak oddziaływać na odzwierciedlające struktury, korzystające z wewnętrznych API z JDK. Jeśli trzeba, można wyłączyć nowe testy, ustawiając właściwość systemową jdk.disableSerialConstructorChecks na wartość „true”. W tym celu trzeba do wiersza polecenia Java dodać argument -Djdk.disableSerialConstructorChecks=true.
    JDK-8197925 (niepubliczne)
  • Poprawka: Awaria JVM podczas G1 GC
    Klasę „klass”, która była uważana za nieosiągalną wskutek współbieżnego oznaczenia G1, można wyszukać w katalogu ClassLoaderData/SystemDictionary, a jej pola _java_mirror i _class_loader można przechowywać w obiekcie poziomu głównego (lub w innym osiągalnym obiekcie), aby ją ponownie uaktywnić. Gdy klasa „klass” jest w ten sposób ożywiana, trzeba o tym powiadomić część SATB z G1, gdyż w przeciwnym razie — podczas fazy współbieżnego oznaczania jako komentarz — nastąpi błędne usunięcie tej klasy „klass” z pamięci.
    Zob. JDK-8187577
  • Poprawka: Większa stabilność przy starszych bibliotekach NUMA (-XX+UseNuma)
    Poprawka z JDK 8 Update 152 wprowadziła regresję, która może powodować awarię HotSpot JVM podczas uruchamiania, gdy flaga UseNUMA jest używana w systemach Linux z wersjami libnuma starszymi niż 2.0.9. Ten problem został rozwiązany.
    Zob. JDK-8198794
Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u181 jest 16 października 2018 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u181) w dniu 16 listopada 2018 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u181 Bug Fixes.

» Uwagi do wydania 8u181


Java 8 Update 171 (8u171)

Najważniejsze cechy wydania
  • IANA — dane 2018c
    JDK 8u171 zawiera dane IANA, dotyczące stref czasowych, w wersji 2018c. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Nowa funkcja: Udoskonalone mechanizmy magazynu kluczy
    Wprowadzono nową właściwość zabezpieczeń o nazwie jceks.key.serialFilter. Jeśli ten filtr zostanie skonfigurowany, magazyn kluczy (KeyStore) JCEKS będzie go używał podczas deserializacji zaszyfrowanego obiektu "Key", przechowywanego w SecretKeyEntry. Jeśli filtr ten nie zostanie skonfigurowany lub będzie dla niego zwracany wynik nierozstrzygnięty UNDECIDED (np. nie uzyska się zgodności dla żadnego z wzorców), to będzie uwzględniana konfiguracja skonfigurowana przez jdk.serialFilter.
    Jeśli zostanie także podana właściwość systemowa jceks.key.serialFilter, to będzie miała ona pierwszeństwo przed zdefiniowaną tu wartością właściwości zabezpieczeń.
    We wzorcu tego filtra jest używany ten sam format co dla filtra jdk.serialFilter. Wzorzec domyślny zezwala na java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type oraz javax.crypto.spec.SecretKeySpec, lecz odrzuca wszystkie pozostałe.
    Klienci przechowujący tajny klucz (SecretKey), który nie podlega serializacji do powyższych typów, muszą — aby było możliwe wyodrębnianie klucza — zmodyfikować filtr.
    JDK-8189997 (niepubliczne)
  • Nowa funkcja: Właściwość systemowa wyłączająca śledzenie ostatniego użycia JRE
    Wprowadzono nową właściwość systemową jdk.disableLastUsageTracking wyłączającą śledzenie ostatniego użycia JRE dla działającej maszyny wirtualnej. Właściwość tę można ustawić przy użyciu wiersza polecenia, używając opcji -Djdk.disableLastUsageTracking=true lub -Djdk.disableLastUsageTracking. Jeśli ta właściwość systemowa zostanie ustawiona, śledzenie ostatniego użycia JRE będzie wyłączone bez względu na ustawioną wartość właściwości com.oracle.usagetracker.track.last.usage w usagetracker.properties.
    JDK-8192039 (niepubliczne)
  • Uwaga: Użycie klasy CipherOutputStream
    Specyfikacja klasy javax.crypto.CipherOutputStream została objaśniona tak, aby zasygnalizować, że klasa ta wychwytuje wyjątek BadPaddingException i inne wyjątki zgłaszane przy nieudanych testach integralności, wykonywanych podczas deszyfrowania. Wyjątki te nie są ponownie zgłaszane, tak że klient nie jest informowany o niepowodzeniu testów integralności. Ze względu na ten sposób działania klasa ta może nie być odpowiednia do użycia przy deszyfrowaniu w trybie operacji z identyfikacją (na przykład GCM), gdy aplikacja wymaga jawnego powiadomienia o nieudanej identyfikacji. Aplikacje, zamiast używać tej klasy, mogą korzystać z Cipher API.
    JDK-8182362 (niepubliczne)
  • Zmiana: Dodatkowy certyfikat TeliaSonera poziomu głównego
    Do magazynu kluczy cacerts dodano certyfikat "TeliaSonera Root CA v1".
    JDK-8190851 (niepubliczne)
  • Zmiana: Wyłączono podpisy XML podpisywane przy użyciu kluczy EC mniejszych niż 224-bitowe
    Aby zwiększyć odporność połączeń SSL/TLS, wyłączono (w połączeniach SSL/TLS w JDK) zestawy szyfrujące 3DES poprzez właściwość zabezpieczeń jdk.tls.disabledAlgorithms.
    JDK-8175075 (niepubliczne)
  • Poprawka: Wyłączono połączenia RMI tunelowane przez HTTP po stronie serwera
    Domyślnie w tym wydaniu zostały wyłączone połączenia RMI tunelowane przez HTTP po stronie serwera. Działanie to można cofnąć, ustawiając właściwość wykonawczą sun.rmi.server.disableIncomingHttp na wartość false. Należy uważać, aby nie pomylić jej z właściwością sun.rmi.server.disableHttp, która wyłącza tunelowanie HTTP po stronie klienta i jest domyślnie ustawiona na wartość false.
    JDK-8193833 (niepubliczne)
Data ważności oprogramowania Java

Datą ważności wydania 8u171 jest 17 lipca 2018 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u171) w dniu 17 sierpnia 2018 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u171 Bug Fixes.

» Uwagi do wydania 8u171


Java 8 Update 161 (8u161)

Najważniejsze cechy wydania
  • IANA — dane 2017c
    JDK 8u161 zawiera dane IANA, dotyczące stref czasowych, w wersji 2017c. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Nowa funkcja: Obsługa parametrów DHE o rozmiarze do 8192 bitów i parametrów DSA o rozmiarze do 3072 bitów
    Zapewnienie dostawcom zabezpieczeń JDK obsługi generowania parametrów protokołu Diffiego-Hellmana i DSA o rozmiarze do 3072 bitów, wstępnie obliczanych parametrów protokołu Diffiego-Hellmana o rozmiarze do 8192 bitów oraz wstępnie obliczanych parametrów DSA o rozmiarze do 3072 bitów.
    Zob. JDK-8072452
  • Nowa funkcja: Negocjowane parametry przemijające protokołu Diffiego-Hellmana oparte na ciałach skończonych (FFDHE) dla TLS
    Implementacja JDK SunJSSE obsługuje teraz mechanizmy TLS FFDHE zdefiniowane w dokumencie RFC 7919. Jeśli serwer nie może przetworzyć rozszerzenia TLS supported_groups lub grup podanych w rozszerzeniu, aplikacje mogą dostosować obsługiwane nazwy grup za pomocą właściwości jdk.tls.namedGroups albo wyłączyć mechanizmy FFDHE, ustawiając właściwość systemową jsse.enableFFDHEExtension na wartość false.
    Zob. JDK-8140436
  • Nowa funkcja: Dodanie do metody org.omg.CORBA.ORBstring_to_object dodatkowych sprawdzeń typu procedury wejściowej (stub) IDL
    Aplikacje, które w sposób jawny lub niejawny wywołują metodę org.omg.CORBA.ORB.string_to_object i chcą zapewnić spójność procedury wejściowej IDL, używanej w przepływie wywołania ORB::string_to_object, powinny określić dodatkowe sprawdzanie typu procedury wejściowej IDL. Jest to funkcja opcjonalna, która domyślnie nie jest włączana.
    Aby można było skorzystać z dodatkowego sprawdzania typu, należy w jeden z następujących sposobów skonfigurować listę poprawnych nazw klas interfejsu IDL dla klas procedur wejściowych IDL:
    • Określić właściwość zabezpieczeń com.sun.CORBA.ORBIorTypeCheckRegistryFilter w pliku conf/security/java.security (Java SE 9) lub w pliku jre/lib/security/java.security (Java SE 8 i wersje wcześniejsze).
    • Określić właściwość systemową com.sun.CORBA.ORBIorTypeCheckRegistryFilter z listą klas. Jeśli właściwość systemowa zostanie ustawiona, jej wartość przesłoni odpowiadającą jej właściwość zdefiniowaną w konfiguracji java.security.

    Jeśli właściwość com.sun.CORBA.ORBIorTypeCheckRegistryFilter nie zostanie ustawiona, sprawdzanie typu jest przeprowadzane tylko dla zbioru nazw klas typów interfejsu IDL odpowiadających wbudowanym klasom procedur wejściowych IDL.
    JDK-8160104 (niepubliczne)
  • Zmiana: Weryfikacja klucza publicznego RSA
    Przy aktualizacji 8u161, implementacja algorytmu RSA w dostawcy SunRsaSign spowoduje odrzucenie każdego klucza publicznego RSA, którego wykładnik nie zawiera się w obowiązującym przedziale zdefiniowanym w standardzie PKCS#1 w wersji 2.2. Ta zmiana będzie miała wpływ na połączenia JSSE oraz na aplikacje oparte na rozszerzeniu JCE.
    JDK-8174756 (niepubliczne)
  • Zmiana: Ograniczenie kluczy Diffiego-Hellmana mniejszych niż 1024-bitowe
    Klucze Diffiego-Hellmana mniejsze niż 1024-bitowe nie są wystarczająco silne do praktycznego użycia i domyślnie powinny być ograniczane w połączeniach SSL/TLS/DTLS. Zgodnie z tym, klucze Diffiego-Hellmana mniejsze niż 1024-bitowe zostały domyślnie wyłączone poprzez dodanie wpisu "DH keySize < 1024" do właściwości "jdk.tls.disabledAlgorithms" w pliku java.security. Mimo że nie jest to zalecane, administratorzy mogą zaktualizować tę właściwość zabezpieczeń ("jdk.tls.disabledAlgorithms") i zezwolić na mniejsze klucze (na przykład, ustawiając "DH keySize < 768").
    JDK-8148108 (niepubliczne)
  • Zmiana: Aktualizacja domyślnego rozmiaru klucza dostawcy
    Zmiana ta powoduje aktualizację dostawców JDK, w której wyniku — jeśli aplikacja nie zainicjalizowała jawnie obiektów java.security.KeyPairGenerator i java.security.AlgorithmParameterGenerator z określonym rozmiarem klucza — dostawcy JDK będą dla algorytmu DSA używać domyślnego rozmiaru 2048 bitów (zamiast rozmiaru 1024 bity).
    Jeśli wystąpią problemy ze zgodnością, istniejące aplikacje mogą ustawiać właściwość jdk.security.defaultKeySize (wprowadzoną w JDK-8181048), określając algorytm i właściwy domyślny rozmiar klucza.
    JDK-8178466 (niepubliczne)
Data ważności oprogramowania Java

Datą ważności wersji 8u161 jest 17 kwietnia 2018 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u161) w dniu 17 maja 2018 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u161 Bug Fixes.

» Uwagi do wydania 8u161


Java 8 Update 151 (8u151)

Najważniejsze cechy wydania
  • IANA — dane 2017b
    JDK 8u151 zawiera dane IANA, dotyczące stref czasowych, w wersji 2017b. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Zmiany w certyfikatach: Usunięcie unieważnionego certyfikatu Swisscom "swisscomrootevca2" poziomu głównego
    Certyfikat Swisscom poziomu głównego został unieważniony przez Swisscom i został usunięty: Swisscom Root EV CA 2
    alias: "swisscomrootevca2 [jdk]"
    DN: CN=Swisscom Root EV CA 2, OU=Digital Certificate Services, O=Swisscom, C=ch
    JDK-8186330 (niepubliczne)
  • Nowe funkcje Nowa właściwość zabezpieczeń do kontrolowania zasad kryptograficznych
    W tym wydaniu zostaje wprowadzona nowa funkcja pozwalająca kontrolować pliki zasad jurysdykcji JCE poprzez nową właściwość zabezpieczeń. W starszych wydaniach — aby pakiet JDK mógł używać nieograniczonych mechanizmów kryptograficznych — pliki jurysdykcji JCE musiały być pobierane i instalowane osobno. Czynności pobierania i instalowania nie są już konieczne. W celu włączenia nieograniczonych mechanizmów kryptograficznych można użyć nowej właściwości crypto.policy zabezpieczeń. Jeśli ta nowa właściwość crypto.policy zostanie ustawiona w pliku java.security lub zostanie ustawiona dynamicznie za pomocą wywołania Security.setProperty() przed zainicjalizowaniem środowiska JCE, to ustawienie to będzie uwzględniane. Domyślnie właściwość ta będzie niezdefiniowana. Jeśli właściwość pozostanie niezdefiniowana i w zastanym katalogu lib/security nie będzie plików jurysdykcji JCE, to poziomem domyślnym dla mechanizmów kryptograficznych będzie poziom ograniczony (limited). Aby skonfigurować JDK do używania nieograniczonych mechanizmów kryptograficznych, należy ustawić właściwość crypto.policy na wartość „unlimited”. Więcej informacji jest dostępnych w pliku java.security, dostarczanym z tym wydaniem.

    Uwaga: W systemie Solaris jest zalecane — przed przystąpieniem do instalowania nowych aktualizacji JDK — usunięcie starych pakietów SVR4. Jeśli uaktualnienie oparte na SVR4 (bez odinstalowywania starych pakietów) jest przeprowadzane dla wydania JDK starszego niż 6u131, 7u121 lub 8u111, należy ustawić w pliku java.security nową właściwość crypto.policy.

    Jest to spowodowane tym, że stare pliki jurysdykcji JCE, pozostające w katalogu <java-home>/lib/security, mogą nie spełniać najnowszych standardów zabezpieczeń związanych z podpisywaniem archiwów JAR, które (standardy) zostały odświeżone w aktualizacjach 6u131, 7u121, 8u111 i nowszych. Jeśli będą używane stare pliki, może się pojawić komunikat o wyjątku, podobny do następującego:

    Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers! at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524) [Przyczyna: java.lang.SecurityException: Pliki zasad jurysdykcji nie są podpisane przez zaufanych wystawców! Przy javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593) przy javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)]

    Zob. JDK-8157561
  • Zmiany Refaktoryzacja istniejących dostawców, tak aby odwoływali się do tym samych stałych określających domyślne wartości długości klucza
    W tym zakresie zostały dokonane dwie zmiany:
    1. Wprowadzono nową właściwość systemową, umożliwiającą użytkownikom konfigurowanie domyślnego rozmiaru klucza używanego przez implementacje KeyPairGenerator i AlgorithmParameterGenerator dostawców JDK. Właściwość ta ma nazwę "jdk.security.defaultKeySize" i jej wartością jest lista wpisów rozdzielonych przecinkiem. Każdy wpis składa się nazwy algorytmu (nie jest uwzględniana wielkość liter) i oddzielonego dwukropkiem (:) domyślnego rozmiaru klucza, wyrażonego w formacie dziesiętnym. Dodatkowo są ignorowane wszystkie spacje.

    Domyślnie właściwość ta nie ma przypisanej wartości — dostawcy JDK będą używać własnych wartości domyślnych. Wpisy zawierające nierozpoznaną nazwę algorytmu będą ignorowane. Wpis będzie także ignorowany, jeśli podany domyślny rozmiar klucza nie będzie możliwą do przeanalizowania pod względem składni dziesiętną liczbą całkowitą.

    1. Implementacja KeyPairGenerator DSA dostawcy SUN nie implementuje już interfejsu java.security.interfaces.DSAKeyPairGenerator. Aplikacje rzutujące obiekt KeyPairGenerator DSA dostawcy SUN na java.security.interfaces.DSAKeyPairGenerator mogą ustawiać właściwość jdk.security.legacyDSAKeyPairGenerator. Jeśli właściwość ta będzie miała wartość „true”, dostawca SUN zwróci obiekt KeyPairGenerator DSA implementujący interfejs java.security.interfaces.DSAKeyPairGenerator. Ta zastana implementacja będzie używać tej samej wartości domyślnej, która została określona w interfejsie przez narzędzie javadoc.
    Domyślnie właściwość ta nie będzie miała przypisanej wartości, a dostawca SUN będzie zwracać obiekt KeyPairGenerator DSA, który nie implementuje wspomnianego wcześniej interfejsu i tym samym będzie mógł ustalić swoją własną, właściwą dla dostawcy wartość domyślną, określoną w klasie java.security.KeyPairGenerator lub — jeśli zostanie ustawiona — przez właściwość systemową jdk.security.defaultKeySize.
    JDK-8181048 (niepubliczne)
Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u151 jest 16 stycznia 2018 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u151) w dniu 16 lutego 2018 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u151 Bug Fixes.

» Uwagi do wydania 8u151


Java 8 Update 144 (8u144)

Najważniejsze cechy wydania
  • IANA — dane 2017b
    JDK 8u144 zawiera dane IANA, dotyczące stref czasowych, w wersji 2017b. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: java.util.zip.ZipFile.getEntry() zawsze zwraca, dla wpisu katalogu, wystąpienie ZipEntry z nazwą wpisu zakończoną ukośnikiem (/)
    Dokumentacja java.util.zip.ZipEntry API zawiera informację: A directory entry is defined to be one whose name ends with a /[Wpis katalogu to wpis zawierający nazwę kończącą się ukośnikiem (/)]. W poprzednich wydaniach JDK metoda java.util.zip.ZipFile.getEntry(String entryName) może jednak zwracać wystąpienie ZipEntry zawierające nazwę niekończącą się ukośnikiem (/) dla istniejące wpisu katalogu zip, gdy przekazany argument entryName nie kończy się ukośnikiem (/) i w pliku zip nie istnieje zgodny wpis katalogu o nazwie entryName + /. Od tego wydania nazwa wystąpienia ZipEntry zwracana przez metodę java.util.zip.ZipFile.getEntry() zawsze kończy się ukośnikiem (/) dla dowolnego wpisu katalogu w pliku zip.
    Aby przywrócić poprzednie działanie, należy ustawić właściwość systemową jdk.util.zip.ensureTrailingSlash na wartość „false”.

    Zmiana ta została dokonana w celu umożliwienia cofnięcia skutków zmian wprowadzonych przez JDK 8u141, gdy są weryfikowane podpisane pliki JAR i niektóre aplikacje WebStart nie mogą zostać załadowane.
    Zob. JDK-8184993
Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u144 jest 17 października 2017 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u144) w dniu 17 listopada 2017 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u144 Bug Fixes.

» Uwagi do wydania 8u144


Java 8 Update 141 (8u141)

Najważniejsze cechy wydania
  • IANA — dane 2017b
    JDK 8u141 zawiera dane IANA, dotyczące stref czasowych, w wersji 2017b. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Zmiany w certyfikatach: Dodano nowe certyfikaty Let's Encrypt do jednostek certyfikujących (CA) poziomu głównego
    Dodano jeden nowy certyfikat poziomu głównego:
    ISRG Root X1
    alias: letsencryptisrgx1
    DN: CN=ISRG Root X1, O=Internet Security Research Group, C=US

    JDK-8177539 (niepubliczne)
  • Rozszerzenia diagnostyczne JMX
    Zmodyfikowano API com.sun.management.HotSpotDiagnostic::dumpHeap tak, aby był zgłaszany wyjątek IllegalArgumentException, jeśli podana nazwa pliku nie kończy się sufiksem .hprof. Działanie istniejących aplikacji, które nie podają nazwy pliku z rozszerzeniem .hprof, będzie się kończyło niepowodzeniem, ze zwracanym wyjątkiem IllegalArgumentException. W takim przypadku można w tych aplikacjach wprowadzić obsługę wyjątku albo przywrócić stare działanie, ustawiając właściwość systemową jdk.management.heapdump.allowAnyFileSuffix na wartość „true”.
    JDK-8176055 (niepubliczne)
  • Ściślejsza kontrola bezpieczeństwa przy przetwarzaniu plików WSDL przez narzędzie wsimport
    Narzędzie wsimport zostało zmodyfikowane tak, aby w opisach usług internetowych nie były dozwolone definicje DTD, w szczególności:
    • Deklaracja DOCTYPE jest niedozwolona w dokumentach
    • Domyślnie, zewnętrzne encje ogólne nie są dołączane
    • Domyślnie, zewnętrzne encje parametryczne nie są dołączane
    • Zewnętrzne definicje DTD są całkowicie ignorowane
    Aby przywrócić poprzednie działanie, należy:
    • Ustawić właściwość systemową com.sun.xml.internal.ws.disableXmlSecurity na wartość true
    • Użyć narzędzia wsimport z opcją -disableXmlSecurity
      UWAGA: Obsługa tej opcji dla narzędzia wsimport w pakietach JDK 7 i JDK 6 zostanie zapewniona poprzez poprawkę zawartą w lipcowej CPU
    JDK-8182054 (niepubliczne)
  • Niestandardowy HostnameVerifier włącza rozszerzenie SNI
    Wcześniejsze wydania aktualizacji JDK 8 nie zawsze wysyłały rozszerzenie Server Name Indication (SNI) w fazie TLS ClientHello, jeśli był używany niestandardowy weryfikator nazwy hosta. Weryfikator ten jest ustawiany za pomocą metody setHostnameVerifier(HostnameVerifier v) w HttpsURLConnection. Poprawka ta zapewnia wysyłanie nazwy serwera do treści wywołania ClientHello.
    Zob. JDK-8144566
  • Udoskonalone sprawdzanie ograniczeń algorytmów
    Ze względu na konieczność ograniczenia używania słabych algorytmów w sytuacjach szczególnie podatnych na zagrożenie, zostały dodane dodatkowe funkcje do konfigurowania właściwości zabezpieczeń jdk.certpath.disabledAlgorithms i jdk.jar.disabledAlgorithms w pliku java.security.

    jdk.certpath.disabledAlgorithms: Największa zmiana dotyczy właściwości certpath. Poprzednio były dostępne tylko dwa typy ograniczenia — pełne wyłączanie algorytmu na podstawie jego nazwy albo pełne wyłączanie algorytmu na podstawie rozmiaru klucza, dokonywane podczas sprawdzania certyfikatów, łańcuchów certyfikacji i podpisów certyfikatów. Wskutek tego konfiguracje były konfiguracjami bezwzględnymi, pozbawionymi elastyczności. W celu zapewnienia elastyczności pod względem dopuszczania lub odrzucania certyfikatów zostały wprowadzone trzy nowe ograniczenia.

    jdkCA sprawdza zakończenie łańcucha certyfikacji, korzystając z pliku cacerts. W przypadku „SHA1 jdkCA” użycie SHA1 jest sprawdzane w całym łańcuchu certyfikacji, lecz łańcuch musi się kończyć na oznaczonym głównym kluczu publicznym w magazynie kluczy „cacerts”. Jest to przydatne dla organizacji, które mają swoją własną, zaufaną, prywatną jednostkę certyfikującą, używającą SHA1 z głównym kluczem organizacji, lecz chcą blokować łańcuchy certyfikacji z głównym kluczem z publicznej jednostki certyfikującej, używającej SHA1.

    denyAfter sprawdza, czy podana data przypada przed bieżącą lub przed datą PKIXParameter. W przypadku użycia „SHA1 denyAfter 2018-01-01”, certyfikat z algorytmem SHA1 może być używane przed rokiem 2018, lecz po tej dacie będzie odrzucany. Ograniczenie to może być używane w założeniach systemowych dla organizacji planującej odejście od tego algorytmu w ustalonym terminie. Dla podpisywanych plików JAR data jest porównywana ze znacznikiem czasu TSA. Data jest określana w GMT.

    usage sprawdza podany algorytm pod kątem określonego użycia. Ograniczenie to może być używane, jeśli wyłączenie algorytmu we wszystkich zastosowaniach jest niecelowe. Istnieją trzy możliwe do określenia użycia:

    • TLSServer ogranicza łańcuchy certyfikacji serwera TLS, gdy identyfikacja serwera jest przeprowadzana jako identyfikacja klienta.
    • TLSClient ogranicza łańcuchy certyfikacji klienta TLS, gdy identyfikacja klienta jest przeprowadzana jako identyfikacja serwera.
    • SignedJAR ogranicza algorytmy w certyfikatach w podpisanych plikach JAR. Typ użycia jest podawany po słowie kluczowym „usage”; można podać więcej niż jeden typ, rozdzielając je spacją.
      Na przykład „SHA1 usage TLSServer TLSClient” nie zezwoli na certyfikaty SHA1 dla operacji TLSServer i TLSClient, lecz będą dozwolone podpisane pliki JAR.

    Ograniczając algorytm, można wszystkie te ograniczenia połączyć za pomocą operatora „&”. Na przykład, aby wyłączyć łańcuchy certyfikacji SHA1, kończące się na oznaczonym kluczu publicznym, tylko dla operacji TLSServer, należałoby użyć ograniczenia „SHA1 jdkCA & usage TLSServer”.

    jdk.jar.disabledAlgorithms: Do tej właściwości jar zostało dodane jedno dodatkowe ograniczenie odnoszące się do algorytmów manifestu JAR.

    denyAfter sprawdza ograniczenia algorytmu w skrócie manifestu w podpisanym pliku JAR. Podana w tym ograniczeniu data jest porównywana ze znacznikiem czasu TSA podpisanego pliku JAR. Jeśli nie ma znacznika czasu lub jeśli jego data przypada po podanej, to podpisany plik JAR będzie traktowany jako niepodpisany. Jeśli data ze znacznika czasu przypada przed podaną, to .jar będzie funkcjonował jako podpisany plik JAR. Składnia ograniczenia SHA1 w plikach JAR po 1 stycznia 2018 roku jest następująca: SHA1 denyAfter 2018-01-01. Jest ona identyczna ze składnią dla właściwości certpath, jednak na podstawie tego ograniczenia nie nastąpi sprawdzenie certyfikatu.
    Zob. JDK-8176536

Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u141 jest 17 października 2017 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u141) w dniu 17 listopada 2017 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

To wydanie zawiera poprawki eliminujące luki zabezpieczeń, opisane na stronie Oracle Java SE Critical Patch Update Advisory. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u141 Bug Fixes.

» Uwagi do wydania 8u141


Java 8 Update 131 (8u131)

Najważniejsze cechy wydania
  • Dane IANA 2016j
    JDK 8u131 zawiera dane stref czasowych IANA w wersji 2016j. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Wprowadzenie nowego modelu porządkowania okien
    Na platformie OS X środowisko AWT używało macierzystych usług do implementacji zależności "nadrzędne-podrzędne" dla okien. Było to przyczyną negatywnych wizualnych efektów, zwłaszcza w środowisku z więcej niż jednym monitorem. W celu wyeliminowania negatywnych cech tego rozwiązania został wprowadzony nowy model porządkowania okien, w pełni implementowany w warstwie JDK. Poniżej są wymienione obowiązujące w nim główne zasady:
    • Okno powinno być umieszczane nad najbliższym oknem nadrzędnym.
    • Jeśli okno ma kilka okien podrzędnych, wszystkie powinny być umieszczane w tej samej warstwie, a okno z łańcucha okna aktywnego powinno być umieszczane nad jego rodzeństwem.
    • Porządkowanie nie powinno być wykonywane dla okna zwiniętego do ikony ani w trakcie zwijania okna do ikony.
    Reguły te mają zastosowanie do każdej ramki lub każdego okna z hierarchii okien zawierającej to okno, na którym jest obecnie ustawiony fokus. Zob. JDK-8169589
  • Poprawka: Wyeliminowanie wyjątku IllegalArgumentException z uzgadniania TLS
    Ostatnie wydanie poprawki JDK-8173783 może być przyczyną problemu dla niektórych serwerów TLS. Przyczyną problemu jest wyjątek IllegalArgumentException zgłaszany przez kod uzgadniania TLS:

    java.lang.IllegalArgumentException: System property
    jdk.tls.namedGroups(null) contains no supported elliptic curves


    Problem może wystąpić, gdy serwer nie obsługuje kryptografii krzywych eliptycznych dla pola rozszerzenia nazwy krzywej eliptycznej (jeśli to pole istnieje). Użytkownikom zaleca się uaktualnienie do tego wydania. Domyślnie aktualizacje JDK 7 i nowsze rodziny JDK są dostarczane z dostawcą zabezpieczeń SunEC, który zapewnia obsługę kryptografii krzywych eliptycznych. Problem ten nie powinien mieć wpływu na te wydania (pod warunkiem, że dostawcy zabezpieczeń nie zostaną zmodyfikowani). Zob. JDK-8173783
  • Dodano MD5 do właściwości zabezpieczeń jdk.jar.disabledAlgorithms
    W tym wydaniu JDK zostało wprowadzone nowe ograniczenie dotyczące weryfikacji plików JAR podpisanych z użyciem algorytmu MD5. Jeśli dla podpisanego pliku JAR jest używany algorytm MD5, to operacje weryfikacji podpisu będą ignorowały podpis i traktowały plik JAR jako niepodpisany. Może się to potencjalnie zdarzyć dla następujących typów aplikacji używających podpisanych plików JAR:
    • Aplety lub aplikacje Web Start
    • Aplikacje autonomiczne lub serwerowe działające z włączonym modułem SecurityManager, które są konfigurowane przy użyciu pliku założeń systemowych nadającego uprawnienia na podstawie jednostki podpisującej kod zawarty w pliku JAR.

    Lista wyłączonych algorytmów jest określana poprzez właściwość zabezpieczeń jdk.jar.disabledAlgorithms z pliku java.security. Ta właściwość zawiera wykaz wyłączonych algorytmów i rozmiarów kluczy dla plików JAR podpisanych kryptograficznie.

    W celu sprawdzenia, czy do podpisania pliku JAR został użyty słaby algorytm lub słaby klucz, można użyć narzędzia jarsigner dostarczanego z tym pakietem JDK. Uruchamiając "jarsigner -verify" w odniesieniu do pliku JAR podpisanego z użyciem słabego algorytmu lub słabego klucza, uzyskuje się więcej informacji o wyłączonym algorytmie lub kluczu.

    Na przykład, aby sprawdzić plik JAR o nazwie test.jar, należałoby użyć następującego polecenia:

    jarsigner -verify test.jar

    Jeśli ten przykładowy plik został podpisany przy użyciu słabego algorytmu, takiego jak MD5withRSA, zostanie wyświetlone:

    The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled. Re-run jarsigner with the -verbose option for more details. (Ten plik jar będzie traktowany jako niepodpisany, ponieważ został podpisany przy użyciu słabego algorytmu, który obecnie jest wyłączony. Aby uzyskać więcej szczegółów, proszę ponownie uruchomić narzędzie jarsigner, używając opcji -verbose.)

    Więcej szczegółów można uzyskać, używając opcji -verbose:

    jarsigner -verify -verbose test.jar

    Zostanie wówczas wyświetlone:
    - 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
    
    W celu rozwiązania tego problemu należy podpisać plik JAR, używając silniejszego algorytmu lub większego klucza. Można także te ograniczenia wycofać, usuwając możliwe do zastosowania słabe algorytmy lub rozmiary kluczy z właściwości jdk.jar.disabledAlgorithms; rozwiązanie to nie jest jednak zalecane. Przed przystąpieniem do ponownego podpisywania zakwestionowanych plików JAR należy usunąć z nich istniejące podpisy. Można to wykonać w następujący sposób za pomocą narzędzia zip:

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

    Proszę okresowo sprawdzać stronę „Oracle JRE and JDK Cryptographic Roadmap” (pod adresem http://java.com/cryptoroadmap) pod kątem planowanych ograniczeń w zakresie podpisywanych plików JAR oraz pod kątem innych składników zabezpieczeń. JDK-8171121 (niepubliczne)
  • Nowa właściwość systemowa kontrolująca buforowanie dla połączenia HTTP SPNEGO.
    Została wprowadzona nowa właściwość systemowa, właściwa dla implementacji JDK, kontrolująca buforowanie dla połączeń HTTP SPNEGO (Negotiate/Kerberos). Buforowanie dla połączeń HTTP SPNEGO pozostaje domyślnie włączone i dlatego — jeśli ta właściwość nie zostanie jawnie określona — nie będzie żadnej zmiany w działaniu. Gdy jest nawiązywane połączenie z serwerem HTTP, który do negocjacji uwierzytelnień używa protokołu SPNEGO, i jeśli łączenie oraz identyfikacja przebiegną pomyślnie, informacje uwierzytelniające będą buforowane i używane przy dalszych połączeniach z tym serwerem. Ponadto w przypadku serwera HTTP, używającego protokołu SPNEGO, zazwyczaj jest utrzymywana aktywność użytego połączenia i jest ono ponownie używane dla dalszych żądań kierowanych do tego serwera. W niektórych aplikacjach może być pożądane całkowite wyłączenie buforowania dla protokołu HTTP SPNEGO (Negotiate/Kerberos) w celu wymuszenia przeprowadzania nowej identyfikacji przy każdym nowym żądaniu kierowanym do serwera.

    Wraz z tą zmianą wprowadzamy nową właściwość systemową, umożliwiającą kontrolę zasad buforowania dla połączeń HTTP SPNEGO. Jeśli właściwość jdk.spnego.cache zostanie zdefiniowana i będzie dawać w wyniku wartość „false”, to zostanie całkowicie wyłączone buforowanie dla połączeń HTTP SPNEGO. Ustawienie tej właściwości systemowej na wartość „false” może jednak stać się przyczyną niepożądanych efektów ubocznych:
    • Wydajność połączeń HTTP SPNEGO może ulec znacznemu pogorszeniu, ponieważ połączenie będzie ponownie identyfikowane przy każdym nowym żądaniu, co wymaga kilku wymian informacji z serwerem.
    • Dla każdego nowego żądania trzeba będzie przekazywać uwierzytelnienia, co — w zależności od tego, czy jest czy nie jest dostępna identyfikacja przezroczysta, a także w zależności od implementacji globalnego uwierzytelniacza — może powodować wyświetlanie wyskakującego okna, wzywającego użytkownika do podawania uwierzytelnień przy każdym nowym żądaniu.
    JDK-8170814 (niepubliczne)
  • Nowa właściwość systemowa kontrolująca buforowanie dla połączenia HTTP NTLM.
    Została wprowadzona nowa właściwość systemowa, właściwa dla implementacji JDK, kontrolująca buforowanie dla połączenia HTTP NTLM. Buforowanie dla połączenia HTTP NTLM pozostaje domyślnie włączone i dlatego — jeśli ta właściwość nie zostanie jawnie określona — nie będzie żadnej zmiany w działaniu. Na niektórych platformach implementacja HTTP NTLM z pakietu JDK może obsługiwać identyfikację przezroczystą, w której uwierzytelnienia użytkownika są używane na poziomie systemu. Gdy identyfikacja przezroczysta nie jest dostępna lub nie zakończy się pomyślnie, JDK będzie obsługiwał jedynie uzyskiwanie uwierzytelnień z globalnego uwierzytelniacza. Jeśli połączenie z serwerem zostanie pomyślnie ustanowione, informacje uwierzytelniające będą buforowane i używane przy dalszych połączeniach z tym serwerem. Ponadto w przypadku serwera HTTP NTLM zazwyczaj jest utrzymywana aktywność użytego połączenia i jest ono ponownie używane dla dalszych żądań kierowanych do tego serwera. W niektórych aplikacjach może być pożądane całkowite wyłączenie buforowania dla protokołu HTTP NTLM w celu wymuszenia przeprowadzania nowej identyfikacji przy każdym nowym żądaniu kierowanym do serwera.

    Wraz z tą zmianą wprowadzamy nową właściwość systemową, umożliwiającą kontrolę zasad buforowania dla połączeń HTTP NTLM. Jeśli właściwość jdk.ntlm.cache zostanie zdefiniowana i będzie dawać w wyniku wartość „false”, to zostanie całkowicie wyłączone buforowanie dla połączeń HTTP NTLM. Ustawienie tej właściwości systemowej na wartość „false” może jednak stać się przyczyną niepożądanych efektów ubocznych:
    • Wydajność połączeń HTTP NTLM może ulec znacznemu pogorszeniu, ponieważ połączenie będzie ponownie identyfikowane przy każdym nowym żądaniu, co wymaga kilku wymian informacji z serwerem.
    • Dla każdego nowego żądania trzeba będzie przekazywać uwierzytelnienia, co — w zależności od tego, czy jest czy nie jest dostępna identyfikacja przezroczysta, a także w zależności od implementacji globalnego uwierzytelniacza — może powodować wyświetlanie wyskakującego okna, wzywającego użytkownika do podawania uwierzytelnień przy każdym nowym żądaniu.
    JDK-8163520 (niepubliczne)
  • Nowa wersja narzędzia VisualVM
    4 października 2016 r. została wydana wersja 1.3.9 narzędzia VisualVM http://visualvm.github.io/relnotes.html; wersja ta została zintegrowana z 8u131. Zob. JDK-8167485
Data ważności oprogramowania Java

Datą ważności wydania 8u131 jest 18 lipca 2017 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u131) w dniu 18 sierpnia 2017 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory. Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u131 Bug Fixes.

» Uwagi do wydania 8u131


Java 8 Update 121 (8u121)

Najważniejsze cechy wydania
  • Dane IANA 2016i
    JDK 8u121 zawiera dane stref czasowych IANA w wersji 2016i. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Przewijanie tekstu przy użyciu gładzika w systemie OS X 10.12 Sierra jest bardzo szybkie
    Metoda MouseWheelEvent.getWheelRotation() zwracała w systemie Mac OS X zaokrąglone wyniki dla macierzystych zdarzeń NSEvent deltaX/Y. W najnowszej wersji Mac OS Sierra 10.12 są generowane bardzo małe wartości NSEvent deltaX/Y, których zaokrąglenie i zsumowanie prowadzi do bardzo dużej wartości zwracanej z metody MouseWheelEvent.getWheelRotation(). Poprawka JDK-8166591 powoduje kumulowanie wartości NSEvent deltaX/Y, zaś metodaMouseWheelEvent.getWheelRotation() zwraca wartości niezerowe tylko wtedy, gdy zakumulowana wartość przekroczy próg i wartość zerową. Jest to zgodne ze specyfikacją metody MouseWheelEvent.getWheelRotation(): "Zwraca liczbę całkowitą odpowiadającą liczbie „kliknięć”, o którą zostało obrócone kółko myszy. Jeśli mysz jest wyposażona w kółko o dużej rozdzielczości, może nastąpić obrót częściowy. W takim przypadku, dopóki nie zostanie zakumulowane pełne „kliknięcie”, metoda zwraca wartość zero." Dla wartości obrotu kółka precyzyjnego należy, zamiast tej metody, użyć metody MouseWheelEvent.getPreciseWheelRotation(). Zob. JDK-8166591
  • Zwiększenie domyślnej siły kryptografii EC w JDK
    Aby zwiększyć domyślną siłę kryptografii EC, klucze EC mniejsze niż 224-bitowe zostały w JDK zdezaktywowane w procesie przetwarzania ścieżki certyfikacji (poprzez właściwość zabezpieczeń jdk.certpath.disabledAlgorithms) oraz w połączeniach SSL/TLS (poprzez właściwość zabezpieczeń jdk.tls.disabledAlgorithms). Aplikacje mogą modyfikować to ograniczenie we właściwościach zabezpieczeń, zezwalając — jeśli jest to faktycznie potrzebne — mniejsze klucze (na przykład "EC keySize < 192"). Krzywe EC mniejsze niż 256-bitowe zostały usunięte z implementacji SSL/TLS w JDK. Nowa właściwość systemowa jdk.tls.namedGroups definiuje listę włączonych nazwanych krzywych (w kolejności od najbardziej preferowanych) dla zestawów szyfrujących EC. Jeśli aplikacja wymaga dostosowania domyślnie włączonych krzywych EC lub ich preferowanej kolejności, należy tę właściwość systemową odpowiednio zmodyfikować. Na przykład:
        jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1"
    

    Należy pamiętać, że dla domyślnie włączonych lub dostosowanych krzywych EC obowiązują ograniczenia algorytmu. Na przykład dostosowane krzywe nie mogą ponownie uaktywnić wyłączonych kluczy EC, zdefiniowanych przez właściwości zabezpieczeń środowiska Java. Zob. JDK-8148516
  • Nowa opcja --allow-script-in-comments narzędzia javadoc
    Narzędzie javadoc będzie odrzucało wszelkie wystąpienia kodu JavaScript w komentarzach dokumentacyjnych i w opcjach wiersza polecenia javadoc, chyba że zostanie użyta opcja --allow-script-in-comments. Jeżeli opcja --allow-script-in-comments zostanie użyta, narzędzie javadoc zachowa kod JavaScript w komentarzach dokumentacyjnych i w opcjach wiersza polecenia. Jeśli ta opcja wiersza polecenia nie zostanie ustawiona, a zostanie wykryty kod JavaScript, to narzędzie javadoc zwróci błąd.
    JDK-8138725 (niepubliczne)
  • Zwiększenie minimalnej długości klucza do 1024 dla podpisów XML
    Tryb weryfikacji zabezpieczeń, dostępny w implementacji narzędzia XML Signature, został rozszerzony tak, aby domyślnie nie były dozwalane klucze RSA i DSA mniejsze niż 1024-bitowe, ponieważ nie są one już wystarczająco bezpieczne dla podpisów cyfrowych. Ponadto do pliku java.security została dodana nowa właściwość jdk.xml.dsig.SecureValidationPolicy zabezpieczeń, która — gdy jest używany tryb weryfikacji zabezpieczeń — może być używana do kontroli różnych wprowadzonych ograniczeń. Tryb weryfikacji zabezpieczeń jest włączany przez ustawienie właściwości org.jcp.xml.dsig.secureValidation narzędzia XML Signature na wartość „true” za pomocą metody javax.xml.crypto.XMLCryptoContext.setProperty albo poprzez uruchamianie kodu z użyciem obiektu SecurityManager. Jeśli podpis XML zostanie wygenerowany ze słabym kluczem RSA lub DSA (bądź taki klucz będzie weryfikowany) zostanie zgłoszony wyjątek XMLSignatureException z komunikatem „RSA keys less than 1024 bits are forbidden when secure validation is enabled” (Klucze RSA mniejsze niż 1024-bitowe są niedozwolone, gdy jest włączona weryfikacja zabezpieczeń) lub „DSA keys less than 1024 bits are forbidden when secure validation is enabled” (Klucze DSA mniejsze niż 1024-bitowe są niedozwolone, gdy jest włączona weryfikacja zabezpieczeń).
    JDK-8140353 (niepubliczne)
  • Ograniczenie certyfikatów z kluczami DSA mniejszymi niż 1024-bitowe
    Klucze DSA mniejsze niż 1024-bitowe nie są wystarczająco silne i powinny być ograniczane podczas konstruowania i weryfikowania ścieżki certyfikacji. W związku z tym, klucze DSA mniejsze niż 1024-bitowe zostały domyślne zdezaktywowane poprzez dodanie wpisu "DSA keySize < 1024" do właściwości "jdk.certpath.disabledAlgorithms" zabezpieczeń. Aplikacje mogą modyfikować to ograniczenie we właściwości zabezpieczeń ("jdk.certpath.disabledAlgorithms") i zezwalać na mniejsze klucze, jeśli rzeczywiście jest to potrzebne (na przykład "DSA keySize < 768"). JDK-8139565 (niepubliczne)
  • Dodanie dalszych testów do kodu analizy składniowej kodowania DER
    Dodano dalsze testy do kodu analizy składniowej kodowania DER w celu wychwycenia różnych błędów kodowania. Ponadto podpisy, które zawierają konstruowane kodowanie o nieokreślonej długości, będą podczas analizy składniowej przyczyną zgłaszania wyjątku IOException. Proszę zwrócić uwagę, że zmiana ta nie wpływa na podpisy generowane przez domyślnych dostawców z JDK. JDK-8168714 (niepubliczne)
  • Dodatkowe ograniczenia dostępu dla metody URLClassLoader.newInstance
    Obiekty, tworzone przez metodę java.net.URLClassLoader.newInstance, mogą być używane do ładowania klas z listy podanych adresów URL. Jeśli kod wywołujący nie ma dostępu do jednego lub większej liczby adresów URL i artefakty URL, do których można uzyskać dostęp, nie zawierają wymaganej klasy, zostanie zgłoszony wyjątek ClassNotFoundException lub podobny. Poprzednio, gdyby wystąpiła odmowa udzielenia dostępu do adresu URL, zostałby zwrócony wyjątek SecurityException. Jeśli niezbędne byłoby przywrócenie poprzedniego funkcjonowania, zmianę tę można wyłączyć, ustawiając właściwość systemową jdk.net.URLClassPath.disableRestrictedPermissions. JDK-8151934 (niepubliczne)
  • Nowa konfigurowalna właściwość w ustawieniach logging.properties java.util.logging.FileHandler.maxLocks
    Do ustawień java.util.logging.FileHandler została dodana nowa konfigurowalna właściwość "java.util.logging.FileHandler.maxLocks". Tę nową konfigurowalną właściwość rejestrowania w dziennikach można zdefiniować w pliku konfiguracji "logging"; właściwość ta umożliwia określenie maksymalnej liczby współbieżnych blokad pliku dziennika, które może obsłużyć procedura FileHandler. Wartość domyślna wynosi 100. W środowisku o bardzo dużym poziomie współbieżności, w którym wiele (ponad 101) autonomicznych aplikacji klienckich używa jednocześnie JDK Logging API z procedurą FileHandler, może nastąpić przekroczenie domyślnego limitu 100 i nie będzie można uzyskać blokad plików, co spowoduje zgłoszenie wyjątku IOException. W takim przypadku można za pomocą nowej właściwości rejestrowania w dziennikach zwiększyć maksymalną liczbę blokad jeszcze przed implementacją aplikacji. Jeśli nie zostanie użyta, wartość domyślna maxLocks (100) pozostanie niezmieniona. Więcej informacji jest dostępnych w dokumentacji API java.util.logging.LogManager i java.util.logging.FileHandler. Zob. JDK-8153955
Uwagi
Zwiększona ochrona w zakresie zdalnego ładowania klas JNDI

Zdalne ładowanie klas poprzez fabryki obiektów JNDI przechowywane w usługach nazewniczych i katalogowych jest domyślnie wyłączone. Aby włączyć zdalne ładowanie klas poprzez rejestr RMI lub dostawcę usługi nazewniczej COS, należy ustawić następującą właściwość systemową na wartość „true”:

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

JDK-8158997 (niepubliczne)

jarsigner -verbose -verify powinno wyświetlać algorytmy używane do podpisania pliku jar

Narzędzie jarsigner zostało rozszerzone o pokazywanie szczegółów algorytmów i kluczy użytych do wygenerowania podpisanego pliku JAR, a ponadto będzie sygnalizowało, jeśli którekolwiek z nich zostały uznane za słabe.

W szczególności, gdy zostanie wywołane polecenie "jarsigner -verify -verbose nazwa_pliku.jar", zostanie wyświetlona osobna sekcja prezentująca informacje o podpisie oraz datę i godzinę (jeśli istnieją) zawarte w podpisanym pliku JAR, nawet jeśli jest on z różnych powodów traktowany jako niepodpisany. Jeśli którykolwiek algorytm lub klucz zostanie, zgodnie z właściwością jdk.jar.disabledAlgorithms zabezpieczeń uznany za słaby, to zostanie oznaczony etykietą „(weak)”.

Na przykład:

- 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 

Zob. JDK-8163304

Znane problemy
javapackager i fx\:deploy pakują cały zestaw JDK zamiast JRE

W narzędziu Java Packager for Mac występuje znany błąd, wskutek którego z pakietem aplikacji może być pakowany cały zestaw JDK, co prowadzi do powstania niezwykle dużego pakietu. Tymczasowym rozwiązaniem tego problemu jest użycie, podczas tworzenia pakietu, opcji -Bruntime. Na przykład: -Bruntime=JavaAppletPlugin.plugin, gdzie JavaAppletPlugin.plugin dla pakowanego JRE znajduje się w bieżącym katalogu. Zob. JDK-8166835

Gdy funkcja „Kontrola konta użytkownika” (UAC) jest wyłączona, instalacja oprogramowania Java skończy się niepowodzeniem dla użytkowników, którzy nie mają uprawnień administratora.

Gdy funkcja „Kontrola konta użytkownika” (UAC) jest wyłączona, instalacja oprogramowania Java w systemie Windows skończy się niepowodzeniem dla użytkowników, którzy nie mają uprawnień administratora; nie zostanie przy tym wyświetlone żadne ostrzeżenie ani żadne wezwanie. Instalator pozostawi w katalogu %TEMP% katalog jds<numer>.tmp.
JDK-8161460 (niepubliczne)

Nowe funkcje
Dodano właściwość związaną z zabezpieczeniami, pozwalającą konfigurować bezpieczny tryb weryfikacji podpisu XML

Została dodana nowa, związana z zabezpieczeniami, właściwość jdk.xml.dsig.secureValidationPolicy umożliwiająca konfigurowanie poszczególnych ograniczeń, które są wymuszane, gdy zostanie włączony bezpieczny tryb weryfikacji podpisu XML (XML Signature). W pliku konfiguracyjnym java.security wartością domyślną tej właściwości jest:

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

Więcej informacji można znaleźć w definicji właściwości w pliku java.security. Zob. JDK-8151893

Konfiguracja filtra serializacji

Filtrowanie serializacji wprowadza nowy mechanizm, który umożliwia filtrowanie przychodzących strumieni danych związanych z serializacją obiektów w celu zwiększenia bezpieczeństwa i stabilności. Każda klasa ObjectInputStream podczas deserializacji stosuje do zawartości strumienia filtr, jeśli został on skonfigurowany. Filtry są ustawiane za pomocą właściwości systemowej lub konfigurowanej właściwości zabezpieczeń. Wartości wzorców "jdk.serialFilter" są opisane w dokumencie JEP 290 Serialization Filtering oraz w <JRE>/lib/security/java.security. Czynności związane z filtrowaniem są rejestrowane przy użyciu obiektu "logger" dla interfejsu java.io.serialization, jeśli rejestrowanie w dzienniku zostało włączone. Zob. JDK-8155760

Lepsze sprawdzanie ograniczeń RMI

Rejestr RMI i funkcja DGC (Distributed Garbage Collection) używają mechanizmów JEP 290 Serialization Filtering do zwiększenia stabilności usługi. Rejestr RMI i funkcja DGC implementują wbudowane filtry typu „biała lista” dla typowych klas, oczekiwanych do użycia z poszczególnymi usługami. Za pomocą właściwości systemowej lub właściwości zabezpieczeń można skonfigurować dodatkowe wzorce filtrowania. Składnia wzorców właściwości "sun.rmi.registry.registryFilter" i "sun.rmi.transport.dgcFilter" jest opisana w dokumencie JEP 290 oraz w <JRE>/lib/security/java.security. JDK-8156802 (niepubliczne)

Dodanie mechanizmu zezwalającego na wyłączenie jednostek certyfikujących (CA), innych niż domyślne, z ograniczeń dotyczących algorytmów

W pliku java.security zostało dodane do właściwości jdk.certpath.disabledAlgorithms dodatkowe ograniczenie o nazwie "jdkCA". Ograniczenie to nie zezwala na określony algorytm tylko wtedy, gdy jest on używany w łańcuchu certyfikacji, który się kończy na oznaczonym głównym kluczu publicznym w magazynie kluczy lib/security/cacerts. Jeśli ograniczenie jdkCA nie zostanie ustawione, będą niedozwolone wszystkie łańcuchy zawierające dany algorytm. Ograniczenia jdkCA można użyć tylko raz w wyrażeniu DisabledAlgorithm. Przykład: Aby to ograniczenie było stosowane do certyfikatów SHA-1, należy wprowadzić następujący wpis: SHA1 jdkCA
Zob. JDK-8140422

Data ważności oprogramowania Java

Datą ważności wersji 8u121 jest 18 kwietnia 2017 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u121) w dniu 18 maja 2017 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory. Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u121 Bug Fixes.

» Uwagi do wydania 8u121


Java 8 Update 111 (8u111)

Najważniejsze cechy wydania
  • IANA Data 2016f
    JDK 8u111 zawiera dane stref czasowych IANA w wersji 2016f. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software. Zob. JDK-8159684.
  • Zmiany w certyfikatach: Nowa jednostka certyfikująca (CA) głównego poziomu podpisująca kod JCE
    W celu zapewnienia obsługi dłuższych kluczy i silniejszych algorytmów podpisu została utworzona nowa jednostka certyfikująca (CA) głównego poziomu podpisująca kod dostawcy JCE; jej certyfikat został dodany do Oracle JDK. Od teraz, do podpisywania dostawców JCE, będą używane nowe certyfikaty podpisujące kod dostawców JCE. Domyślnie nowe wystąpienia o certyfikaty podpisujące kod dostawców JCE będą wydawane z tej jednostki certyfikującej.

    Istniejące certyfikaty, pochodzące z bieżącej głównej jednostki certyfikującej podpisywanie kodu dostawców JCE, nadal będą pozytywnie weryfikowane. Dana główna jednostka certyfikująca może jednak w przyszłości zostać wyłączona. Zaleca się występowanie o nowe certyfikaty oraz ponowne podpisywanie istniejących plików JAR dostawców. Szczegóły procesu podpisywania dostawcy JCE są dostępne w dokumencie How to Implement a Provider in the Java Cryptography Architecture. JDK-8141340 (niepubliczne)
  • Usługi menu usług
    Na niektórych platformach wystąpiły problemy podczas zarządzania cyklem życia składników menu AWT. Poprawka ta poprawia synchronizację stanu menu i ich pojemników. JDK-8158993 (niepubliczne)
  • Wyłączenie identyfikacji podstawowej przy tunelowaniu HTTPS
    W pewnych środowiskach niektóre schematy identyfikacji mogą być niepożądane podczas obsługi protokołu HTTPS przez proxy. Dlatego schemat identyfikacji podstawowej (schemat „Basic”) został domyślnie zdezaktywowany w środowisku Oracle Java Runtime poprzez dodanie wpisu „Basic” do właściwości jdk.http.auth.tunneling.disabledSchemes. Teraz serwery proxy, wymagające identyfikacji podstawowej (Basic) podczas przygotowywania tunelu dla protokołu HTTPS, nie będą domyślnie mogły tego wykonać. Jeśli jest to niezbędne, można ten schemat identyfikacji ponownie uaktywnić, usuwając wpis Basic z właściwości sieciowej jdk.http.auth.tunneling.disabledSchemes albo ustawiając — w wierszu polecenia — właściwość systemową o tej samej nazwie na wartość "" (puste). Ponadto właściwości sieciowych jdk.http.auth.tunneling.disabledSchemes i jdk.http.auth.proxying.disabledSchemes oraz właściwości systemowych o tych samych nazwach można — odpowiednio — użyć do wyłączenia innych schematów identyfikacji, które mogą być aktywne, gdy jest ustanawiany tunel dla protokołu HTTPS albo gdy obsługa protokołu HTTP jest realizowana poprzez proxy. JDK-8160838 (niepubliczne)
  • Ograniczenie plików JAR podpisanych z użyciem słabych algorytmów i kluczy
    To wydanie JDK wprowadza nowe ograniczenia w sposobie weryfikacji podpisanych plików JAR. Jeśli dla podpisanego pliku JAR jest używany wyłączony algorytm lub klucz o rozmiarze mniejszym niż minimalny, to operacje weryfikacji podpisu będą ignorowały podpis i traktowały plik JAR jako niepodpisany. Może się to potencjalnie zdarzyć dla następujących typów aplikacji używających podpisanych plików JAR:
    1. Aplety lub aplikacje Web Start
    2. Aplikacje autonomiczne lub serwerowe działające z włączonym modułem SecurityManager, które są konfigurowane przy użyciu pliku założeń systemowych nadającego uprawnienia na podstawie jednostki podpisującej kod zawarty w pliku JAR.

    Lista wyłączonych algorytmów jest określana poprzez nową właściwość zabezpieczeń, tj. jdk.jar.disabledAlgorithms, w pliku java.security. Właściwość ta zawiera listę wyłączonych algorytmów i rozmiarów kluczy dla plików JAR podpisywanych kryptograficznie.

    W tym wydaniu zostały ograniczone następujące algorytmy i rozmiary kluczy:
    1. MD2 (w algorytmie skrótu „digest” albo podpisu)
    2. Klucze RSA o rozmiarze mniejszym niż 1024 bity
    UWAGA: W aktualizacji CPU przewidzianej na kwiecień 2017 r. jest planowane ograniczenie — w plikach JAR — podpisów opartych na algorytmie MD5.

    W celu sprawdzenia, czy do podpisania pliku JAR został użyty słaby algorytm lub słaby klucz, można użyć narzędzia jarsigner dostarczanego z tym pakietem JDK. Uruchamiając jarsigner -verify -J-Djava.security.debug=jar w odniesieniu do pliku JAR podpisanego z użyciem słabego algorytmu lub słabego klucza, uzyskuje się więcej informacji o wyłączonym algorytmie lub kluczu.

    Na przykład, aby sprawdzić plik JAR o nazwie test.jar, należałoby użyć następującego polecenia:
    jarsigner -verify -J-Djava.security.debug=jar test.jar

    Jeśli ten przykładowy plik został podpisany przy użyciu słabego algorytmu, takiego jak MD2withRSA, to zostanie wyświetlony następujący wynik:
    jar: beginEntry META-INF/my_sig.RSA
    jar: processEntry: processing block
    jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
    jar: done with meta!

    Zaktualizowane polecenie jarsigner zakończy działanie, kierując na standardowe wyjście następujące ostrzeżenie:
    "Signature not parsable or verifiable. The jar will be treated as unsigned. The jar may have been signed with a weak algorithm that is now disabled. For more information, rerun jarsigner with debug enabled (-J-Djava.security.debug=jar)"

    W celu rozwiązania tego problemu należałoby ten plik JAR ponownie podpisać, używając silniejszego algorytmu lub klucza o większym rozmiarze. Można także te ograniczenia wycofać, usuwając możliwe do zastosowania słabe algorytmy lub rozmiary kluczy z właściwości jdk.jar.disabledAlgorithms; rozwiązanie to nie jest jednak zalecane. Przed przystąpieniem do ponownego podpisywania zakwestionowanych plików JAR należy usunąć z nich istniejące podpisy. Można to wykonać w następujący sposób za pomocą narzędzia zip:

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

    Proszę okresowo sprawdzać stronę Oracle JRE and JDK Cryptographic Roadmap (pod adresem http://java.com/cryptoroadmap) pod kątem planowanych ograniczeń w zakresie podpisywanych plików JAR oraz pod kątem innych składników zabezpieczeń. W szczególności proszę zwrócić uwagę, że w aktualizacji CPU przewidzianej na kwiecień 2017 r. jest planowane ograniczenie — w plikach JAR — podpisów opartych na algorytmie MD5.

    Aby sprawdzić, czy używane pliki JAR zostały podpisane z użyciem algorytmu MD5, należy dodać wpis MD5 do właściwości jdk.jar.disabledAlgorithms, na przykład:

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

    i następnie uruchomić w odniesieniu do plików JAR polecenie jarsigner -verify -J-Djava.security.debug=jar, jak opisano powyżej.
    JDK-8155973 (niepubliczne)
  • Dodano komunikat ostrzegawczy do dialogowego okna uwierzytelniacza wdrażania
    Do dialogowego okna uwierzytelniacza wdrażania zostało dodane ostrzeżenie pojawiające się, gdy jest używana identyfikacja podstawowa HTTP i jest używany serwer proxy lub nie są używane protokoły SSL/TLS:
    "WARNING: Basic authentication scheme will effectively transmit your credentials in clear text. Do you really want to do this?"
    JDK-8161647 (niepubliczne)
Znane problemy
Niektóre zdarzenia nie są dostępne w zapisach narzędzia JFR w systemie Windows
Następujące zdarzenia nie są dostępne — dla wersji 8u111 — w zapisach narzędzia JFR w systemie Windows:
  1. hotspot/jvm/os/processor/cpu_load
  2. os/processor/context_switch_rate

Wynika to z regresyjnej poprawki JDK-8063089, która została wprowadzona w wersji 8u111, w powiązaniu ze zmianami w JDK-8162419. Poprawka dla JDK-8063089 nie mogła zostać zawarta w wersji 8u111. Będzie dostępna w następnym kompilacie 8u111 BPR i w następnym wydaniu publicznym.
JDK-8063089 (niepubliczne)

JVM zwraca wyjątki NullPointerException w systemie Mac OS Sierra 10.12

W systemie Mac OS Sierra 10.12, jeśli użytkownik naciśnie klawisz modyfikujący (taki jak Command, Shift lub Alt), gdy aplet działa w przeglądarce, może zostać wyświetlone okno komunikatu o błędzie wewnętrznym. W obszarze „Dock" w systemie Mac OS będzie także pokazywana ikona „exec”. Użytkownik może zamknąć aplet albo spróbować go uruchomić, nie naciskając klawisza modyfikującego. Zob. JDK-8165867.

Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u111 jest 17 stycznia 2017 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u111) w dniu 17 lutego 2017 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory. Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u111 Bug Fixes.

» Uwagi do wydania 8u111



Java 8 Update 101 (8u101)

Najważniejsze cechy wydania
  • Dane IANA 2016d
    JDK 8u101 zawiera dane stref czasowych IANA w wersji 2016d. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software. Zob. JDK-8151876.
  • Zmiany w certyfikatach
    Dodano nowe certyfikaty DTrust do jednostek certyfikujących (CA) poziomu głównego
    Dodano dwa nowe certyfikaty poziomu głównego:
    • 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
    Zob. JDK-8153080

    Dodano nowe certyfikaty Iden do jednostek certyfikujących (CA) poziomu głównego
    Dodano trzy nowe certyfikaty poziomu głównego:
    • 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.
    Zob. JDK-8154757

    Usunięto certyfikat CA poziomu głównego dla Comodo
    Certyfikat CA poziomu głównego "UTN - DATACorp SGC" dla Comodo został usunięty z pliku cacerts. Zob. JDK-8141540

    Usunięto certyfikat "Sonera Class1 CA"
    Certyfikat CA poziomu głównego "Sonera Class1 CA" został usunięty z pliku cacerts. Zob. JDK-8141276.
  • Zwiększenie kontroli dostępu do interfejsu javax.rmi.CORBA.ValueHandler
    Klasa javax.rmi.CORBA.Util udostępnia metody, które mogą być używane przez procedury wejścia i powiązania w celu wykonywania typowych operacji. Działa także jako fabryka dla procedur ValueHandler. Interfejs javax.rmi.CORBA.ValueHandler udostępnia usługi wspomagające odczyt i zapis typów wartości w strumieniach GIOP. Poziom bezpieczeństwa, związany z używaniem tych narzędzi, został zwiększony poprzez wprowadzenie uprawnienia java.io.SerializablePermission("enableCustomValueHanlder"). Służy ono do ustanowienia relacji zaufania między użytkownikami interfejsów (API) javax.rmi.CORBA.Util i javax.rmi.CORBA.ValueHandler.

    Wymaganym uprawnieniem jest "enableCustomValueHanlder" SerializablePermission. Wykonywanie kodu (kodu innego podmiotu), działającego przy zainstalowanym składniku SecurityManager, lecz niemającego — podczas wywoływania Util.createValueHandler() — tego nowego uprawnienia, zakończy się niepowodzeniem (zostanie zwrócony wyjątek AccessControlException).

    To sprawdzenie uprawnienia można przesłonić w JDK8u (i wydaniach wcześniejszych), definiując właściwość systemową "jdk.rmi.CORBA.allowCustomValueHandler".

    Dlatego aplikacje zewnętrzne, które jawnie wywołują procedurę javax.rmi.CORBA.Util.createValueHandler, wymagają zmiany w konfiguracji, gdy jest zainstalowany SecurityManager i nie jest spełniony żaden z dwóch następujących warunków:
    1. Uprawnienie java.io.SerializablePermission("enableCustomValueHanlder") nie jest udzielane przez składnik SecurityManager.
    2. W przypadku aplikacji działających na podstawie JDK8u (lub wydań wcześniejszych) systemowa właściwość "jdk.rmi.CORBA.allowCustomValueHandler" nie została zdefiniowana albo została ustawiona na wartość "false" (wielkość liter nie ma znaczenia).

    Proszę zwrócić uwagę, że literówka w "enableCustomValueHanlder" zostanie poprawiona w wydaniach w październiku 2016 r. W tych i przyszłych wydaniach pakietu JDK poprawnym uprawnieniem SerializationPermission będzie "enableCustomValueHandler".
    JDK-8079718 (niepubliczne)
  • Dodano do narzędzia jarsigner opcję umożliwiającą określanie algorytmu haszowania znacznika czasu
    Do narzędzia jarsigner została dodana nowa opcja -tsadigestalg, określająca algorytm tworzenia skrótu (digest) komunikatu, używany do generowania metryki komunikatu wysyłanej do serwera TSA. W starszych wydaniach JDK używanym algorytmem tworzenia skrótu komunikatu był SHA-1. Jeśli ta nowa opcja nie zostanie podana, w pakiecie JDK 7 Update i w nowszych wydaniach rodziny JDK będzie używany algorytm SHA-256. W pakietach JDK 6 Update, algorytm SHA-1 pozostanie algorytmem domyślnym, lecz do strumienia wyjścia standardowego będzie kierowane ostrzeżenie. Zob. JDK-8038837
  • Magazyn kluczy MSCAPI może obsługiwać certyfikaty o identycznych nazwach
    Magazyn kluczy (obiekt KeyStore) Java SE nie zezwala na certyfikaty mające te same aliasy. W systemie Windows, certyfikaty przechowywane w jednym magazynie kluczy mogą mieć jednak nieunikatowe przyjazne nazwy. Poprawka JDK-6483657 umożliwia operowanie na takich certyfikatach o nieunikatowych nazwach poprzez Java API, czyniąc (w sposób sztuczny) widoczne aliasy unikatowymi. Proszę zwrócić uwagę, że ta poprawka nie umożliwia tworzenia, za pomocą Java API, certyfikatów o identycznych nazwach. Umożliwia jedynie obsługę takich certyfikatów (tj. o identycznych nazwach), które zostały dodane do magazynu kluczy za pomocą narzędzi udostępnianych przez inne podmioty. Nadal jest zalecane projektowanie, w którym nie występują certyfikaty o identycznych nazwach. W szczególności z dokumentacji platformy Java nie zostanie usunięte następujące zdanie:
    „In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case.” (W celu uniknięcia problemów zaleca się nieużywanie — w magazynie kluczy — aliasów, które różnią się jedynie wielkością liter.)
    Zob. JDK-6483657.
  • Metody z Deployment Toolkit API nie instalują już środowiska JRE
    Oferowane przez Deployment Toolkit API metody installLatestJRE() i installJRE(requestedVersion) z deployJava.js i metoda install() z dtjava.js nie instalują już środowiska JRE. Jeśli używana przez użytkownika wersja środowiska Java nie zapewnia wymaganego podstawowego poziomu bezpieczeństwa, użytkownik zostanie przekierowany do serwisu java.com w celu uzyskania zaktualizowanej wersji JRE. JDK-8148310 (niepubliczne)
  • DomainCombiner, podczas łączenia obiektów ProtectionDomain nie będzie już uzgadniał wykonawczych założeń systemowych dla statycznych obiektów ProtectionDomain
    Dla aplikacji, które używają statycznych obiektów ProtectionDomain (utworzonych przy użyciu konstruktora 2-argumentowego) z niewystarczającym zestawem uprawnień, może po tej poprawce być zwracany wyjątek AccessControlException. W aplikacjach tych statyczne obiekty ProtectionDomain powinny zostać zastąpione dynamicznymi (z użyciem konstruktora 4-argumentowego), których uprawnienia zostaną rozszerzone przez bieżące założenie systemowe, albo powinien zostać utworzony statyczny obiekt ProtectionDomain ze wszystkimi niezbędnymi uprawnieniami. JDK-8147771 (niepubliczne)
Znane problemy
Środowisko JRE 8u101 nie jest rozpoznawane przez Internet Explorer (IE), gdy jest używany statyczny ID klasy

Jeśli do uruchomienia apletu lub aplikacji Web Start — gdy jest używane środowisko JRE 8u101 — zostanie użyty statyczny ID klasy, użytkownicy zobaczą niepożądane okno dialogowe wzywające do użycia najnowszej wersji środowiska JRE lub anulowania uruchomienia, mimo że mają zainstalowane najnowsze środowisko JRE (JRE 8u101) i z niego korzystają. Ten specyficzna sytuacja dotyczy tylko systemu Windows i przeglądarki IE.

Do wyboru wersji środowiska JRE nie jest zalecane (od JDK 5u6 z grudnia 2005) używanie statycznego ID klasy: http://www.oracle.com/technetwork/java/javase/family-clsid-140615.html.

W celu obejścia tego problemu użytkownicy mogą zastosować jedno z dwóch następujących rozwiązań:
  • Wybrać opcję uruchomienia z najnowszą wersją (8u101) i zignorować ostrzeżenie.
  • Zainstalować wersję JRE 8u102 (zamiast JRE 8u101) i tym samym wyeliminować ten problem.
W celu rozwiązania tego problemu twórcy aplikacji mogą zastosować jedno z dwóch następujących rozwiązań:
  • Użyć dynamicznego ID klasy zamiast statycznego ID klasy.
  • Użyć atrybutu java_version, gdy jest używany aplet HTML, albo deskryptora JNLP, gdy jest używany protokół JNLP.
JDK-8147457 (niepubliczne)

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory. Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u101 Bug Fixes.

Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u101 jest 19 października 2016 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u101) w dniu 19 listopada 2016 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

» Uwagi do wydania 8u101


Java 8 Update 91 (8u91)

Najważniejsze cechy wydania
  • Dane IANA 2016a
    JDK 8u91 zawiera dane stref czasowych IANA w wersji 2016a. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Wydłużenie czasu uruchamiania apletów - poprawione
    Poprawka JDK-8080977 wprowadziła opóźnienie uruchamiania apletu. Opóźnienie to występuje tylko w IE i wynosi około 20 sekund. Poprawka JDK-8136759 wyeliminowała to opóźnienie. Zob. JDK-8136759
  • Poprawka: Generowanie podpisu DSA podlega teraz sprawdzeniu siły klucza
    W przypadku generowania podpisu, jeśli siła zabezpieczeń algorytmu generowania skrótu (digest) jest słabsza niż siła zabezpieczeń klucza używanego do podpisania podpisu (np. użycie (2048, 256)-bitowych kluczy DSA z podpisem SHA1withDSA), to operacja zakończy się niepowodzeniem i zostanie zgłoszony błąd: „The security strength of SHA1 digest algorithm is not sufficient for this key size” (Siła zabezpieczeń algorytmu skrótu SHA1 jest niewystarczająca dla tego rozmiaru klucza). JDK-8138593 (niepubliczne)
  • Poprawka: Problem z apletem LiveConnect dla przeglądarki Firefox 42
    Ponieważ problem ten może prowadzić do zawieszenia się przeglądarki, wywołania JavaScript-To-Java nie są przetwarzane, gdy wtyczka Java jest uruchamiana z plugin-container.exe (domyślne działanie przeglądarki Firefox 42) i statusem apletu nie jest „gotowy” (2). Jeśli aplet nie jest gotowy (jego status jest inny niż 2), nie jest wykonywana faktyczna metoda Java, a jest jedynie zwracana wartość null.

    Jeśli wtyczka jest uruchamiana z pliku plugin-container.exe, nie należy używać wywołań JavaScript-To-Java, które — do ich ukończenia — wymagają więcej niż 11 sekund (wartość domyślna ustawienia dom.ipc.plugins.hangUITimeoutSecs) lub wyświetlają dialogowe okno modalne podczas wywołania JavaScript-To-Java. W takim przypadku musi nastąpić zablokowanie głównego wątku przeglądarki, co może spowodować zawieszenie się przeglądarki oraz zakończenie działania wtyczki.

    Obejście problemu dla przeglądarki Firefox 42: Użytkownicy mogą ustawić dom.ipc.plugins.enabled=false. Efektem ubocznym tego sposobu jest to, że zmiana tego ustawienia dotyczy wszystkich wtyczek. JDK-8144079 (niepubliczne)
  • Poprawka: Nowy atrybut dla serwerów JMX RMI JRMP określa listę nazw klas, które mają być używane podczas deserializacji uwierzytelnień serwera
    Dla środowiska został zdefiniowany nowy atrybut polecenia java, umożliwiający serwerowi JMX RMI JRMP określenie listy nazw klas. Nazwy te odpowiadają domknięciom (closure) nazw klas, które są oczekiwane przez serwer podczas deserializacji uwierzytelnień. Na przykład, jeśli oczekiwane uwierzytelnienia miałyby postać
     List<string>
    , to domknięcia stanowiłyby wszystkie klasy nieabstrakcyjne (concrete), których należałoby oczekiwać w szeregowej postaci listy wartości napisowych.

    Domyślnie ten atrybut jest używany tylko przez agenta domyślnego z:
     {   
       "[Ljava.lang.String;",   
       "java.lang.String" 
     } 
    
    Podczas deserializacji uwierzytelnień będą akceptowane jedynie tablice wartości napisowych (string) i wartości napisowe. Nazwa atrybutu:
    "jmx.remote.rmi.server.credential.types"
    
    Przykład uruchamiania (przez użytkownika) serwera z podanymi nazwami klas uwierzytelnień:
    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);
    
    Nowej funkcji należy używać, podając bezpośrednio:
    "jmx.remote.rmi.server.credential.types"

    JDK-8144430 (niepubliczne)
  • Poprawka: Wyłączenie algorytmu podpisu MD5withRSA w dostawcy JSSE
    Algorytm podpisu MD5withRSA jest obecnie uznawany za mało bezpieczny i nie należy go używać. Dlatego algorytm MD5withRSA został domyślnie zdezaktywowany w implementacji Oracle JSSE poprzez dodanie "MD5withRSA" do właściwości zabezpieczeń "jdk.tls.disabledAlgorithms". Obecnie komunikaty uzgadniania protokołu TLS i certyfikaty X.509, które zostały podpisane przy użyciu algorytmu MD5withRSA, domyślnie nie są już akceptowane. Zmiana ta rozszerza poprzednie ograniczenie certyfikatów opartych na MD5 ("jdk.certpath.disabledAlgorithms"), obejmując także komunikaty uzgadniania protokołu TLS w wersji 1.2. Jeśli trzeba, algorytm ten można ponownie uaktywnić, usuwając wpis "MD5withRSA" z właściwości zabezpieczeń "jdk.tls.disabledAlgorithms". JDK-8144773 (niepubliczne)
  • Poprawka: Dodano nowe certyfikaty do jednostek certyfikujących (CA) poziomu głównego
    Dodano osiem nowych certyfikatów poziomu głównego:
    • 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
    Zob. JDK-8145954 i JDK-8145955.
Uwagi

Usuwanie zainstalowanych statycznie środowisk JRE
Instalatory oprogramowania Java dla systemu Windows, wydane przed wersją 8u91, domyślnie nie usuwały zainstalowanych statycznie środowisk JRE. Aby usunąć zainstalowane statycznie środowiska JRE, użytkownik musiał wybrać je ręcznie w interfejsie instalatora oprogramowania Java. Obecnie, w wydaniach oprogramowania Java 8u91 i nowszych, zainstalowane statycznie środowiska JRE będą automatycznie usuwane, jeśli nie będą zapewniały wymaganego podstawowego poziomu bezpieczeństwa. Więcej informacji dotyczących instalacji statycznej jest dostępnych na stronie Java Runtime Environment Configuration.

Data ważności oprogramowania Java

Datą ważności wydania 8u91 jest 19 lipca 2016 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u91) w dniu 19 sierpnia 2016 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory. Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u91 Bug Fixes.

» Uwagi do wydania 8u91


Java 8 Update 77 (8u77)

Najważniejsze cechy wydania
Data ważności oprogramowania Java

Datą ważności wydania 8u77 jest 19 kwietnia 2016 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u77) w dniu 19 maja 2016 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Uwagi

Ten zestaw Security Alert (8u77) bazuje na wcześniejszym wydaniu PSU (Patch Set Update) 8u74. Wszyscy użytkownicy wcześniejszych wydań JDK 8 powinni przeprowadzić aktualizację do tego wydania. Więcej informacji o różnicach między poprawkami Critical Patch Update a zestawami Patch Set Update jest dostępnych na stronie Java CPU and PSU Releases Explained.

Poprawka „Security Alert for CVE-2016-0636” nie ma wpływu na pakiety z materiałami demonstracyjnymi, przykładami i dokumentacją dla wersji 8u77 i dlatego pakiety dla wersji 8u73 pozostają aktualną wersją do chwili wydania kwietniowej poprawki „Critical Patch Update”.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory.

» Uwagi do wydania 8u77


Java 8 Update 73 (8u73)

Najważniejsze cechy wydania
Data ważności oprogramowania Java

Datą ważności wersji 8u73 jest 19 kwietnia 2016 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u73) w dniu 19 maja 2016 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Uwagi

Oracle stanowczo zaleca, aby użytkownicy oprogramowania Java, którzy pobrali wersje dotknięte tym problemem i którzy planują przyszłe instalacje z użyciem tych pobranych wersji, zrezygnowali z używania ich. Użytkownicy oprogramowania Java, którzy zainstalowali wersje poprawek „Critical Patch Update” ze stycznia 2016 r. dla Java SE 6, 7 lub 8, nie muszą podejmować żadnych działań. Użytkownicy oprogramowania Java, którzy nie zainstalowali wersji poprawek „Critical Patch Update” ze stycznia 2016 r. dla Java SE 6, 7 lub 8, powinni uaktualnić oprogramowanie do wydań Java SE 6, 7 lub 8 z poprawki „Security Alert for CVE-2016-0603”.

Poprawka „Security Alert for CVE-2016-0603” nie ma wpływu na pakiety z materiałami demonstracyjnymi, przykładami i dokumentacją dla wersji 8u73 i dlatego pakiety dla wersji 8u71 pozostają aktualną wersją do chwili wydania kwietniowej poprawki „Critical Patch Update”.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory. Należy pamiętać, że wersja 8u73 nie zawiera kompilatów PSU dostępnych w wersji 8u72. Klienci, którzy wymagają dodatkowych poprawek zawartych w wersji 8u72, powinni przeprowadzić uaktualnienie nie do wersji 8u73, lecz 8u74.

» Uwagi do wydania 8u73


Java 8 Update 71 (8u71)

Najważniejsze cechy wydania
  • Dane IANA 2015g
    JDK 8u71 zawiera dane stref czasowych IANA w wersji 2015g. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Mimo uruchomienia narzędzia jps przez użytkownika „root” nie są pokazywane wszystkie informacje
    Po poprawce JDK-8050807 (poprawka w wersjach 8u31, 7u75 i 6u91) uruchomienie narzędzia jps przez użytkownika „root” nie powodowało pokazywania wszystkich informacji z procesów Java uruchomionych w niektórych systemach przez innych użytkowników. Zostało to poprawione. Zob. JDK-8075773.
  • Poprawka: Programy instalacyjne są wstrzymywane przy konfiguracjach ESC
    Użytkownicy uruchamiający Internet Explorer Enhance Security Configuration (ESC) w systemie Windows Server 2008 R2 mogą napotykać problemy podczas instalowania oprogramowania Java w trybie interakcyjnym. Problem ten został rozwiązany w wersji 8u71. Programy instalacyjne, uruchamiane w trybie interakcyjnym, nie będą już wstrzymywane przy konfiguracjach ESC. Zob. JDK-8140197.
  • Poprawka: Rozwiązano problem z algorytmami PBE korzystającymi z szyfrowania AES
    Poprawiono błąd PBE występujący przy korzystania z 256-bitowego szyfrowania AES, objawiający się tym, że wyprowadzane klucze mogły się różnić od kluczy wyprowadzanych poprzednio z tego samego hasła oraz mogły nie być im równoważne. JDK-8138589 (niepubliczne).
  • Poprawka: Dodano domyślny limit maksymalnego rozmiaru encji XML
    Został dodany domyślny limit maksymalnego rozmiaru encji XML. Więcej informacji o limitach przetwarzania kodu XML jest dostępnych na stronie The Java Tutorials, Processing Limits. JDK-8133962 (niepubliczne).
  • Poprawka: Rozwiązano problem z dokumentacją opcji REMOVEOLDERJRES dla Enterprise MSI
    Dokumentacja Enterprise MSI zawiera wykaz opcji konfiguracyjnych. Brakowało opcji REMOVEOLDERJRES używanej do odinstalowywania starych środowisk JRE. Opcję tę dodano wraz z opisem:
    Jeśli zostanie ustawiona na 1, nastąpi usunięcie starszych wydań środowiska JRE zainstalowanych w systemie.
    Domyślnie: 0, tzn. nie są usuwane żadne starsze środowiska JRE
    JDK-8081237 (niepubliczne)
Data ważności oprogramowania Java

Datą ważności wydania 8u71 jest 19 kwietnia 2016 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u71) w dniu 19 maja 2016 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u71 Bug Fixes.

» Uwagi do wydania 8u71


Java 8 Update 66 (8u66)

Najważniejsze cechy wydania

Wydanie 8u66, kompilat 18, rozwiązuje problem z przeglądarką Firefox.

  • Poprawka: Wywoływanie _releaseObject z niewłaściwego wątku
    Wskutek ostatniej zmiany, dokonanej w przeglądarce Firefox, wywołanie _releaseObject jest dokonywane z wątku innego niż główny. Może to doprowadzić do sytuacji „ścigania się”, która może spowodować awarię przeglądarki. Problem ten został rozwiązany w kompilacie 18 wydania 8u66. Więcej informacji jest dostępnych na stronie Bugs@Mozilla 1221448. Zob. JDK-8133523.
Wtyczka Java nie działa w przeglądarce Firefox po zainstalowaniu oprogramowania Java

Firefox 42 może się zawieszać, gdy jest podejmowana próba uruchomienia wtyczki Java Sposoby obejścia są podane w obszarze często zadawanych pytań. Zob. JDK-8142908 (niepubliczne).

Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u66 jest 19 stycznia 2016 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u66) w dniu 19 lutego 2016 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u66 Bug Fixes.

» Uwagi do wydania 8u66


Java 8 Update 65 (8u65)

Najważniejsze cechy wydania
  • Dane IANA 2015f
    JDK 8u65 zawiera dane stref czasowych IANA w wersji 2015f. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Obsługa tabeli ISO 4217 „Bieżące kody funduszy” (A.2)
    Ten dodatek wprowadza obsługę tabeli A.2 standardu ISO 4217 zawierającej kody funduszy. Poprzednio JDK obsługiwał jedynie waluty wymienione w tabeli A.1. Zob. JDK-8074350.
  • Poprawka: [mac osx] Zainstalowany klient JRE AU nie może zostać zaktualizowany do NEXTVER w systemie Mac 10.11
    W wydaniu 8u65 zostaje wprowadzony nowy program instalacyjny, umożliwiający użytkownikom systemu OS X aktualizację do najnowszej wersji. Program instalacyjny będzie stosował aktualizację zarówno ręczne, jak i automatyczne, oraz pakiety udostępnione w serwisach java.com i OTN. Użytkownicy, którzy napotkają problemy ze zgodnością nowego programu instalacyjnego, mogą samodzielnie pobrać i zainstalować program instalacyjny .pkg, dostępny w portalu My Oracle Support.
  • Poprawka: Maszyna wirtualna HotSpot powinna używać interfejsu PICL do uzyskania rozmiaru linii pamięci podręcznej systemu SPARC
    Obecnie, w celu ustalenia rozmiaru linii pamięci podręcznej, jest w systemie Solaris/SPARC wymagana biblioteka libpicl. Jeśli biblioteki tej nie będzie albo jeśli usługa PICL będzie niedostępna, JVM wyświetli ostrzeżenie i zostaną wyłączone optymalizacje kompilatora korzystające z instrukcji BIS (Block Initializing Store). Zob. JDK-8056124.
  • Poprawka: Ustawienie dns_lookup_realm powinno mieć domyślnie wartość „false”
    Ustawienie dns_lookup_realm w pliku Kerberos krb5.conf ma domyślnie wartość „false”. Zob. JDK-8080637.
  • Poprawka: Wstępne załadowanie biblioteki libjsig.dylib powoduje zakleszczenie, jeśli nastąpi wywołanie metody signal()
    Aby zostało włączony mechanizm signal-chaining, aplikacje muszą wstępnie ładować bibliotekę libjsig. Poprzednio w systemie OS X — gdy została wstępnie załadowana biblioteka libjsig.dylib — każde wywołanie (z kodu macierzystego) funkcji signal() powodowało zakleszczenie. Zostało to poprawione. Zob. JDK-8072147.
  • Poprawka: Lepsza dynamika grup
    W implementacji OpenJDK SSL/TLS/DTLS (dostawca SunJSSE) domyślnie są używane grupy Diffiego-Hellmana oparte na bezpiecznych liczbach pierwszych. Użytkownicy mogą dostosowywać grupy Diffiego-Hellmana poprzez właściwość zabezpieczeń jdk.tls.server.defaultDHEParameters.
  • Poprawka: Wirtualna maszyna ulega awarii, gdy klasa jest redefiniowana przy użyciu metody Instrumentation.redefineClasses
    Awaria wirtualnej maszyny Javy (JVM) mogła wystąpić, gdy klasa była redefiniowana za pomocą metody Instrumentation.redefineClasses(). Awaria mogła powodować błąd segmentacji przy SystemDictionary::resolve_or_null albo błąd wewnętrzny z komunikatem „tag mismatch with resolution error table” (niezgodność znacznika z tabelą błędów rozstrzygnięcia). Zostało to poprawione. Zob. JDK-8076110.
Uwagi

W systemie OS X 10.11 El Capitan, przy włączonym mechanizmie SIP (System Integrity Protection), niektóre zmienne środowiskowe przeznaczone do wykrywania błędów w aplikacjach, takie jak DYLD_LIBRARY_PATH, zostać usunięte ze środowiska, gdy oprogramowanie Java jest uruchamiane z wiersza poleceń lub gdy użytkownik kliknie dwukrotnie na pliku JAR. Aplikacje nie powinny zdawać się na te zmienne; są one przeznaczone wyłącznie do wykrywania błędów w procesie tworzenia aplikacji.

Jeśli jest wymagana odporność na kolizje, nie wolno używać algorytmu MD5 dla podpisów cyfrowych. Aby można było zapobiec używaniu MD5 jako algorytmu dla podpisów cyfrowych podczas operacji związanych z certyfikatami X.509, MD5 został dodany do właściwości zabezpieczeń jdk.certpath.disabledAlgorithms. W przypadku aplikacji, które nadal używają certyfikatu podpisanego przy użyciu algorytmu MD5, należy możliwie szybko uaktualnić słaby certyfikat.

Znane problemy

[macosx] Problemy związane z ułatwieniami dostępu (a11y) na ekranach ofert sponsorów
Użytkownicy, którzy używają klawiatury w celu uzyskania dostępu do interfejsu użytkownika w programie instalacyjnym oprogramowania Java, nie będą mogli korzystać z hiperłączy i pól wyboru na ekranach z ofertą dodatkowego oprogramowania. Jako rozwiązanie — inne niż ustawianie preferencji związanych z dodatkowym oprogramowaniem prezentowanym w interfejsie użytkownika — użytkownicy mogą wyłączyć oferty poprzez Java Control Panel albo przekazując w wierszu polecenia opcję SPONSORS=0. Więcej informacji jest dostępnych na stronie Jak zainstalować oprogramowanie Java bez żadnych ofert sponsorów? Zob. JDK-8061886 (niepubliczne).

Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u65 jest 19 stycznia 2016 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u65) w dniu 19 lutego 2016 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u65 Bug Fixes.

» Uwagi do wydania 8u65


Java 8 Update 60 (8u60)

Najważniejsze cechy wydania
  • Dane IANA 2015e
    JDK 8u60 zawiera dane stref czasowych IANA w wersji 2015e. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Ustawienie dns_lookup_realm powinno mieć domyślnie wartość „false”
    Ustawienie dns_lookup_realm w pliku Kerberos krb5.conf ma domyślnie wartość false. Zob. 8080637.
  • Poprawka: Wyłączenie zestawów szyfrowania RC4
    Zestawy szyfrowania TLS oparte RC4 (np. TLS_RSA_WITH_RC4_128_SHA) są obecnie uznawane za mało bezpieczne i nie powinny już być używane (zob. RFC 7465). Dlatego zestawy szyfrowania TLS oparte na RC4 zostały domyślnie zdezaktywowane w implementacji Oracle JSSE poprzez dodanie RC4 do właściwości zabezpieczeń jdk.tls.disabledAlgorithms i usunięcie ich z listy domyślnie włączanych zestawów szyfrowania. Można je ponownie uaktywnić, usuwając RC4 z właściwości zabezpieczeń jdk.tls.disabledAlgorithms z pliku java.security lub dynamicznie wywołując metodę Security.setProperty() oraz ponownie dodając je — za pomocą metod SSLSocket/SSLEngine.setEnabledCipherSuites() — do listy włączanych zestawów szyfrowania. Można także użyć opcji -Djava.security.properties wiersza polecenia; wskutek jej użycia nastąpi przesłonięcie właściwości jdk.tls.disabledAlgorithms. Na przykład:
    java -Djava.security.properties=my.java.security ...
    gdzie my.java.security jest plikiem zawierającym właściwość bez RC4:
    jdk.tls.disabledAlgorithms=SSLv3
    Nawet przy tej opcji ustawionej z wiersza polecenia, trzeba ponownie dodać zestawy szyfrujące oparte na RC4 do listy włączonych zestawów szyfrujących, używając metody SSLSocket/SSLEngine.setEnabledCipherSuites(). Zob. 8076221.
  • Poprawka: Wykrywanie typu magazynu kluczy JKS i PKCS12
    Tryb zgodności magazynów kluczy: W celu zapewnienie interoperacyjności, typ JKS magazynu kluczy Java obecnie domyślnie obsługuje tryb zgodności magazynów kluczy. Tryb ten umożliwia magazynom kluczy JKS uzyskiwanie dostępu do plików w formacie zarówno JKS, jaki i PKCS12. Aby wyłączyć tryb zgodności magazynów kluczy, należy ustawić właściwość zabezpieczeń keystore.type.compat na napisową wartość false. Zob. 8062552.
  • Poprawka: Zaprzestanie używanie metod klasy „Unsafe” monitorowania w wydaniu JDK 8u
    Metody monitorEnter, monitorExit i tryMonitorEnter klasy sun.misc.Unsafe są w pakiecie JDK 8u60 oznaczane jako już nieużywane i w następnych wydania zostaną usunięte. Metody te nie są używane w samym pakiecie JDK i są bardzo rzadko używane poza nim. Zob. 8069302.
  • Poprawka: Wyodrębnianie danych JFR z głównego pliku przy użyciu SA
    DumpJFR to narzędzie oparte na interfejsach SA (Serviceability Agent), które może być używane do wyodrębniania danych JFR (Java Flight Recorder) z głównych plików i aktywnych procesów Hotspot. Narzędzia DumpJFR można użyć w jeden z następujących sposobów:
    • Dołączyć DumpJFR do aktywnego procesu:

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

    • Dołączyć DumpJFR do podstawowego pliku:

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

    Narzędzie DumpJFR zrzuca dane JFR do pliku o nazwie recording.jfr w bieżącym folderze roboczym. Zob. 8065301 (niepubliczne).
  • Poprawka: Lokalne zmienne o nazwie „enum” prowadzą do nieprzewidywalnych błędów kompilatora
    Parser javac niepoprawnie analizuje zmienne lokalne o nazwie „enum”; prowadzi to do nieprzewidywalnych błędów, gdy takie zmienne lokalne są kompilowane z opcją „source” odpowiadającą wydaniu, w którym konstrukcja „enum” nie jest dostępna (na przykład: -source 1.4). Zob. 8069181.
Java Development Kit dla ARM, w wersji 8u60

To wydanie zawiera Java Development Kit dla ARM, w wersji 8u60 (JDK 8u60 for ARM). Informacje dotyczące obsługi urządzeń ARM są dostępne na stronie JDK for ARM Downloads. Wymagania systemowe, instrukcje instalacji i porady dot. rozwiązywania problemów są dostępne na stronie Installation Instructions.

Ograniczenie: Obsługa macierzystego śledzenia pamięci jest w JDK for ARM ograniczona. Opcja XX:NativeMemoryTracking=detail wiersza polecenia java nie jest obsługiwana dla celów ARM (użytkownikowi jest wyświetlany komunikat o błędzie). Zamiast niej należy użyć opcji:
XX:NativeMemoryTracking=summary

Aktualizacje dokumentacje wynikające z ulepszeń motoru Nashorn
JDK 8u60 zawiera nowe ulepszenia motoru Nashorn. Wskutek tego, następujące zmiany w dokumentacji należy czytać w powiązaniu z aktualną dokumentacją motoru Nashorn.
  • Dodatek: W poprzednie części stwierdziliśmy, że każdy obiekt JavaScript, gdy jest eksponowany dla Java API, implementuje interfejs java.util.Map. Jest to prawdziwe nawet dla tablic JavaScript. Takie działanie jest jednak często niepożądane lub nieoczekiwane, gdy kod Java oczekuje obiektów już po analizie składniowej JSON. Biblioteki Java, operujące na obiektach po analizie JSON, zazwyczaj oczekują, aby dla tablic był eksponowany interfejs java.util.List. Jeśli trzeba eksponować obiekty JavaScript, tak aby tablice były eksponowane jako listy, a nie jako odwzorowania, można użyć funkcji Java.asJSONCompatible(obj), gdzie obj jest poziomem głównym drzewa obiektów JSON.
  • Poprawka: Ostrzeżenie zamieszczone pod koniec sekcji Mapping Data Types nie jest już ważne. Nashorn gwarantuje, podczas eksponowania na zewnątrz, konwersję wewnętrznych napisów JavaScript na java.lang.String.
  • Poprawka: Stwierdzenie „For example, arrays must be explicitly converted,...” [Na przykład, tablice muszą być jawnie konwertowane...] w części Mapping Data Types nie jest poprawne. Tablice są automatycznie konwertowane na typy tablicowe Java, takie jak java.util.List, java.util.Collection, java.util.Queue czy java.util.Deque.
Zmiany w Deployment Rule Set v1.2
JDK 8u60 implementuje Deployment Rule Set (DRS) 1.2, który wprowadza następujące zmiany:
  • Dodanie elementu "checksum" jako elementu podrzędnego dla "id", dzięki czemu niepodpisane pliki jar mogą być identyfikowane za pomocą sumy kontrolnej SHA-256 nieskompresowanej formy pliku jar:
    • Element "checksum" będzie uzgadniany tylko dla niepodpisanych plików jar, a dana haszowana wartość będzie porównywana tylko z zdekompresowanym plikiem jar.
    • Element "checksum" (podobny do elementu "certificate") ma dwa argumenty: "hash" i "algorithm"; w przeciwieństwie do elementu "certificate" jedyną obsługiwaną wartością elementu "algorithm" jest "SHA-256". Każda inna użyta wartość będzie ignorowana.
  • Zezwolenie na stosowanie elementu "message" do wszystkich typów reguł, podczas gdy poprzednio można było go stosować tylko do reguły blokowania:
    • W regule uruchamiania element „message” spowoduje wyświetlanie okna dialogowego tam, gdzie bez reguły uruchamiania domyślnym działaniem byłoby pokazanie okna dialogowego dot. certyfikatu lub niepodpisania. Komunikat zostanie wyświetlony w oknie komunikatu.
    • Przy użyciu reguły domyślnej komunikat zostanie wyświetlony tylko wtedy, gdy czynnością domyślną jest blokowanie. W takim przypadku komunikat będzie dołączany do okna dialogowego dot. blokowania.
  • Zawieranie (w formie echa) bloków "customer" w narzędziu Java Console, plikach śledzenia oraz w rekordach narzędzia Java Usage Tracker.
    • Przed DRS 1.2 elementy "customer" mogły być zawierane (wraz z dowolnymi elementami podrzędnymi) w pliku ruleset.xml. Element ten i wszystkie jego elementy podrzędne są ignorowane. W DRS 1.2 elementy te nadal są funkcjonalnie ignorowane. Jednak:
      • Podczas analizy składniowej pliku ruleset.xml wszystkie elementy "customer" będą zawierane (w formie echa) w narzędziu Java Console i pliku śledzenia wdrażania (jeśli konsola i śledzenie zostaną włączone).
      • Gdy będzie używana reguła, wszystkie zawarte w niej rekordy "customer" będą dodawane do rekordu narzędzia JUT (Java Usage Tracker), o ile zostało ono włączone.
W wyniku powyższych zmian definicja DTD dla DRS 1.2 ma następującą postać:
<!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 ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u60 jest 20 października 2015 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u60) w dniu 20 listopada 2015 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u60 Bug Fixes.

» Uwagi do wydania 8u60


Java 8 Update 51 (8u51)

Najważniejsze cechy wydania
  • Dane IANA 2015d
    JDK 8u51 zawiera dane stref czasowych IANA w wersji 2015d. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Dodać nowe poziomy główne Comodo do głównych jednostek certyfikujących
    Dodano cztery nowe certyfikaty poziomu głównego dla Commodo:
    1. COMODO ECC Certification Authority
      alias: comodoeccca
      DN: CN=COMODO ECC Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
    2. COMODO RSA Certification Authority
      alias: comodorsaca
      DN: CN=COMODO RSA Certification Authority, O=COMODO CA Limited, L=Salford, ST=Greater Manchester, C=GB
    3. USERTrust ECC Certification Authority
      alias: usertrusteccca
      DN: CN=USERTrust ECC Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
    4. USERTrust RSA Certification Authority
      alias: usertrustrsaca
      DN: CN=USERTrust RSA Certification Authority, O=The USERTRUST Network, L=Jersey City, ST=New Jersey, C=US
    Zob. JDK-8077997 (niepubliczne).
  • Poprawka: Dodać nowe poziomy główne GlobalSign do głównych jednostek certyfikujących
    Dodano dwa nowe certyfikaty poziomu głównego dla GlobalSign:
    1. GlobalSign ECC Root CA - R4
      alias: globalsigneccrootcar4
      DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R4
    2. GlobalSign ECC Root CA - R5
      alias: globalsigneccrootcar5
      DN: CN=GlobalSign, O=GlobalSign, OU=GlobalSign ECC Root CA - R5
    Zob. JDK-8077995 (niepubliczne).
  • Poprawka: Dodać Actalis do głównych jednostek certyfikujących
    Dodano nowy certyfikat poziomu głównego:
    Actalis Authentication Root CA
    alias: actalisauthenticationrootca
    DN: CN=Actalis Authentication Root CA, O=Actalis S.p.A./03358520967, L=Milan, C=IT

    Zob. JDK-8077903 (niepubliczne).
  • Poprawka: Dodać nowy poziom główny Entrust ECC
    Dodano nowy certyfikat poziomu głównego:
    Entrust Root Certification Authority - EC1
    alias: entrustrootcaec1
    DN: CN=Entrust Root Certification Authority - EC1, OU="(c) 2012 Entrust, Inc. - for authorized use only", OU=www.entrust.net/legal-terms, O="Entrust, Inc.", C=US

    Zob. JDK-8073286 (niepubliczne).
  • Poprawka: Usunąć stare certyfikaty Valicert Class 1 i 2 Policy poziomu głównego
    Usunięto dwa certyfikaty poziomu głównego z kluczami 1024-bitowymi:
    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
    Zob. JDK-8077886 (niepubliczne).
  • Poprawka: Usunąć stare certyfikaty Thawte poziomu głównego
    Usunięto dwa certyfikaty poziomu głównego z kluczami 1024-bitowymi:
    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
    Zob. JDK-8074423 (niepubliczne).
  • Poprawka: Usunąć stare certyfikaty Verisign, Equifax i Thawte poziomu głównego
    Usunięto pięć certyfikatów poziomu głównego z kluczami 1024-bitowymi:
    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
    Zob. JDK-8076202 (niepubliczne).
  • Poprawka: Usunąć certyfikaty TrustCenter CA poziomu głównego z certyfikatów jednostek certyfikujących
    Usunięto trzy certyfikaty poziomu głównego:
    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
    Zob. JDK-8072958 (niepubliczne).
  • Poprawka: Zdezaktualizować szyfrowania RC4 w dostawcy SunJSSE
    RC4 jest traktowany jako słaby algorytm szyfrowania. Serwery nie powinny wybierać szyfrowania RC4, chyba że w żądanych algorytmach szyfrowania nie ma żadnego silniejszego. W celu definiowania zastanych algorytmów w implementacji Oracle JSSE została dodana nowa właściwość zabezpieczeń jdk.tls.legacyAlgorithms. Algorytmy związane z szyfrowaniem RC4 zostały dodane do listy zastanych algorytmów. Zob. JDK-8074006 (niepubliczne).
  • Poprawka: Zabronić używania zestawów szyfrujących RC4
    RC4 jest traktowany jako ryzykowny algorytm szyfrowania. Zestawy szyfrujące RC4 zostały usunięte z listy — w implementacji Oracle JSSE — domyślnie włączanych zestawów szyfrujących (zarówno po stronie serwera, jak i klienta). Zestawy te można nadal włączać za pomocą metod SSLEngine.setEnabledCipherSuites() i SSLSocket.setEnabledCipherSuites(). Zob. JDK-8077109 (niepubliczne).
  • Poprawka: Udoskonalone sprawdzanie certyfikatów
    W wyniku tej poprawki punkt końcowy JSSE domyślnie nie przeprowadza odwrotnego wyszukiwania (reverse lookup) adresów IP w JDK. Jeśli aplikacja wymaga przeprowadzenia odwrotnego wyszukiwania nazw dla nieprzetworzonych adresów IP w połączeniach SSL/TLS i wystąpią problemy z identyfikacją zgodności przez punkt końcowy, można za pomocą właściwości systemowej "jdk.tls.trustNameService" włączyć odwrotne wyszukiwanie nazw. Należy pamiętać, że — jeśli usługa dostarczania nazw nie jest usługą zaufaną — włączenie odwrotnego wyszukiwania nazw może ułatwić ataki MITM. Zob. JDK-8067695 (niepubliczne).
Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u51 jest 20 października 2015 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u51) w dniu 20 listopada 2015 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u51 Bug Fixes.

» Uwagi do wydania 8u51


Java 8 Update 45 (8u45)

Najważniejsze cechy wydania
  • Dane IANA 2015a
    JDK 8u45 zawiera dane stref czasowych IANA w wersji 2015a. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Poprawa obsługi plików jar. Zaczynając od wersji JDK 8u45, narzędzie jar nie zezwala już na stosowanie początkowego składnika ścieżki w postaci ukośnika "/" i ".." (dwie kropki) w wejściowej nazwie pliku dla archiwum zip podczas tworzenia nowego pliku i/lub ekstrahowania z pliku zip lub jar. Jeśli jest to konieczne, należy — w celu zachowania dwóch kropek i/lub składnika ścieżki bezwzględnej — użyć w sposób jawny nowego parametru "-P" wiersza polecenia. Zob. 8064601 (niepubliczne).
  • Poprawka: Działanie aplikacji jnlp z zagnieżdżoną sekcją „resource” kończy się niepowodzeniem (jest zgłaszany wyjątek NPE) podczas ładowania w jre8u40. Aplikacja jnlp, ze znacznikami zagnieżdżonymi w znaczniku <java> lub , może być przyczyną wyjątku NPE. Ten problem został teraz wyeliminowany. Znacznik powinien być używany tylko wtedy, gdy faktycznie jest używany znacznik <java>. Zob. 8072631 (niepubliczne).
Data ważności oprogramowania Java

Datą ważności wydania 8u45 jest 14 lipca 2015 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u45) w dniu 14 sierpnia 2015 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u45 Bug Fixes.

» Uwagi do wydania 8u45


Java 8 Update 40 (8u40)

Najważniejsze cechy wydania
  • Dane IANA 2014j
    JDK 8u40 zawiera dane stref czasowych IANA w wersji 2014j. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Domyślne i statyczne metody w interfejsie w JDI, JDWP i JDB. Zaczynając od JDK 8, jest możliwe zawarcie (w interfejsie) bezpośrednio wykonywalnych metod statycznych i domyślnych. Metody te nie są wykonywalne poprzez JDWP ani JDI i dlatego nie można poprawnie wykryć w nich błędów. Więcej informacji jest dostępnych na stronie JDK 8 Compatibility Guide. Zob. 8042123.
  • Poprawka: Java Access Bridge można włączać z panelu sterującego dla 32-bitowych środowisk JRE. Poprzednio pole wyboru „Enable Java Access Bridge” było usuwane z panelu Java Control Panel przy deinstalacji 64-bitowego środowiska JRE, nawet jeśli w systemie nadal występowało 32-bitowe środowisko JRE. Zaczynając od wersji JDK 8u40, pole wyboru „Enable Java Access Bridge” jest zachowywane w Control Panel -> Ease of Access -> Ease of Access Center -> Use the computer without a display, jeśli występuje 32-bitowe środowisko JRE. Użytkownik może zatem włączyć Java Access Bridge poprzez panel sterujący 8030124.
  • Poprawka: Unowocześnienie stosu multimediów JavaFX w systemie Mac OS X. Do multimediów JavaFX dodano platformę odtwarzacza opartą na AVFoundation. Starą platformę opartą na QTKit można teraz usuwać w celu zapewnienia zgodności z Mac App Store. Zob. 8043697 (niepubliczne).
  • Poprawka: Brak API DOM. W wydaniu JDK 8u40 stare wtyczkowe API DOM zostały nieodwracalnie usunięte. Jeśli aplet do komunikowania się z przeglądarką potrzebuje klasy com.sun.java.browser.dom.DOMService, użytkownicy mogą zaktualizować aplet, tak aby używał klasy netscape.javascript.JSObject albo mogą nadal używać wersji JDK 8 Update 31. Problem ten został rozwiązany w kompilacie 26; zostały opublikowane nowe programy instalacyjne 8u40. Osoby, u których ten problem występuje, powinny pobrać i uruchomić zaktualizowany program instalacyjny JDK 8u40. Zob. 8074564.
  • Poprawka: Mac 10.10: W przypadku aplikacji uruchamianej z ekranem startowym występują problemy z ustawieniem fokusu. Dla aplikacji uruchamianych jako aplikacje Web Start lub aplikacje autonomiczne, z użyciem ekranu startowego, nie można ustawić fokusu za pomocą klawiatury. Obejście: Uruchomić javaws z opcją -Xnosplash. Problem ten został rozwiązany w kompilacie 27; został opublikowany nowy program instalacyjny 8u40. Osoby, u których ten problem występuje, powinny pobrać i uruchomić zaktualizowany program instalacyjny JDK 8u40. Zob. 8074668.
  • Udoskonalenia narzędzia Java Packager
    JDK 8u40 zawiera następujące udoskonalenia w narzędziu Java Packager:
  • API już nieużywane
    Mechanizmy przesłaniania standardów definiowanych poza JCP (endorsed-standards) i rozszerzeń (extension) są już nieużywane i w przyszłych wydaniach mogą zostać usunięte. Nie ma żadnych zmian dotyczących trybu wykonawczego. W przypadku istniejących aplikacji, które korzystają z mechanizmu przesłaniania standardów definiowanych poza JCP (endorsed-standards) lub mechanizmu rozszerzeń (extension), zaleca się odejście od używania tychże mechanizmów. Jako pomoc w wykrywaniu istniejących użyć tych mechanizmów została udostępniona opcja -XX:+CheckEndorsedAndExtDirs wiersza polecenia. Jej działanie zakończy się niepowodzeniem, jeśli będzie spełniony którykolwiek z następujących warunków:
    • została ustawiona właściwość systemowa -Djava.endorsed.dirs lub -Djava.ext.dirs w celu zmiany domyślnej lokalizacji;
    • istnieje katalog ${java.home}/lib/endorsed;
    • ${java.home}/lib/ext zawiera jakiekolwiek pliki JAR z wyłączeniem dostarczanych przez JDK;
    • dowolny systemowy katalog rozszerzeń, specyficzny dla platformy, zawiera jakiekolwiek pliki JAR.
    Opcja -XX:+CheckEndorsedAndExtDirs wiersza polecenia jest obsługiwana w JDK 8u40 i wersjach nowszych.
  • Różnice w stronie narzędzia jjs
    Japońska wersja strony Pomocy dla jjs różni się od wersji angielskiej. Niektóre nieobsługiwane opcje zostały usunięte z angielskiej wersji strony narzędzia jjs. Japońska wersja dokumentu zostanie zaktualizowana w przyszłości. Zob. 8062100 (niepubliczne). Inne zmiany, dokonane na stronie narzędzia jjs, są opisane na stronie Tools Enhancements in JDK 8.
  • Zmiana wartości domyślnych G1HeapWastePercent i G1MixedGCLiveThresholdPercent
    Wartość domyślna G1HeapWastePercent została zmieniona z 10 na 5 w celu zmniejszenia konieczności używania pełnych obszarów GC. Z tego samego powodu wartość domyślna G1MixedGCLiveThresholdPercent została zmieniona z 65 na 85.
  • Nowy interfejs filtrowania dostępu do klas Java
    Interfejs jdk.nashorn.api.scripting.ClassFilter pozwala ograniczyć dostęp, do określonych klas Java, ze skryptów wykonywanych przez motor skryptów Nashorn. Zob. także Restricting Script Access to Specified Java Classes w dokumencie Nashorn User's Guide oraz „8043717 (niepubliczne)”.
  • Problemy z dostawcami JCE pochodzącymi od innych firm
    Poprawka JDK-8023069 (w JDK 8u20) zaktualizowała dostawców SunJSSE i SunJCE wraz z niektórymi wewnętrznymi interfejsami. Dostawcy JCE, pochodzący od innych firm (np. RSA JSAFE), używają niektórych interfejsów sun.* internal i dlatego nie będą współpracować ze zaktualizowanym dostawcą SunJSSE. Takich dostawców, aby zapewnić ich współpracę ze zaktualizowanym dostawcą SunJSSE, trzeba zaktualizować. Osoby, u których ten problem wystąpił, powinny się zwrócić do podmiotu dostarczającego JCE o aktualizację. Zob. 8058731.
  • Ponownie włączone szyfrowanie w środowisku Solaris Crypto Framework
    Jeśli jest używany system Solaris 10, została dokonana zmiana ponownego włączenia operacji z użyciem MD5, SHA1 i SHA2 poprzez środowisko Solaris Crypto Framework. Jeśli wystąpi wyjątek CloneNotSupportedException lub błąd PKCS11 CKR_SAVED_STATE_INVALID, gdy jest używany JDK 8u40, należy sprawdzić i zastosować podane poniżej poprawki lub ich nowsze wersje:
    • 150531-02 dla procesorów sparc
    • 150636-01 dla procesorów x86
  • Aktualizacje podręcznika rozwiązywania problemów dla NMT
    Native Memory Tracking (NMT) to funkcja środowiska Java Hotspot VM śledząca wewnętrzne wykorzystywania pamięci dla HotSpot JVM. Funkcja NMT może być używana to monitorowania przydziałów wewnętrznej pamięci VM oraz diagnozowania wycieków pamięci VM. Strona opisująca udoskonalenia VM została zaktualizowana z uwzględnieniem funkcji NMT. Zob. Java Virtual Machine Enhancements in Java SE 8. Podręcznik rozwiązywania problemów został zaktualizowany z uwzględnieniem funkcji NMT. Zob. Native Memory Tracking.
  • Funkcja Multiple JRE Launcher już nieużywana
    Funkcja Launch-Time JRE Version lub Multiple JRE Launcher jest już nieużywana w JDK 8u40. Wdrożone aplikacje, które wymagają określonej wersji środowiska Java i które korzystają z tej funkcji, trzeba przełączyć do alternatywnych rozwiązań wdrożeniowych, takich jak Java WebStart.
  • Ulepszenia JavaFX
    Zaczynając od wersji JDK 8u40, formanty JavaFX zostały udoskonalone tak, aby współpracowały z technikami wspomagającymi; znaczy to, że formanty Java FX są teraz wyposażone w ułatwienia dostępu. Ponadto został udostępniony publiczny zestaw API umożliwiający programistom tworzenie własnych formantów z ułatwieniami dostępu. Obsługa ułatwień dostępu obejmuje systemy Windows oraz Mac OS X. Jej zakres to:
    • Możliwość odczytu formantów JavaFX przez czytnik ekranu
    • Możliwość poruszania się po formantach JavaFX za pomocą klawiatury
    • Możliwość korzystania ze specjalnego trybu z dużym kontrastem, w którym formanty są bardziej widoczne dla użytkowników.
    Zob. 8043344 (niepubliczne).

    Wersja JDK 8u40 zawiera następujące nowe formanty JavaFX dla interfejsu użytkownika: pokrętło, tekst formatowany oraz standardowy zestaw alarmowych okien dialogowych.
    • Pokrętło: Jest to jednowierszowe pole tekstowe pozwalające użytkownikowi wybrać liczbę lub wartość obiektu z uporządkowanej sekwencji. Więcej informacji jest dostępnych w opisie klasy javafx.scene.control.Spinner.
    • Tekst sformatowany: Nowa klasa TextFormatter umożliwia formatowanie tekstów dla podklas klasy TextInputControl (na przykład dla pola tekstowego [TextField] i obszaru tekstowego [TextArea]). Więcej informacji jest dostępnych w opisie klasy javafx.scene.control.TextFormatter.
    • Okno dialogowe: Klasa Dialog umożliwia tworzenie własnych okien dialogowych w aplikacjach. Ponadto jest dostępna klasa Alert (rozszerzająca klasę Dialog) zapewniająca obsługę niektórych wbudowanych typów okien dialogowych, które mogą być wyświetlane użytkownikom jako wezwanie do udzielenia odpowiedzi. Więcej informacji jest dostępnych w opisie klas javafx.scene.control.Dialog, javafx.scene.control.Alert, javafx.scene.control.TextInputDialog oraz Javafx.scene.control.ChoiceDialog.
    Zob. 8043350 (niepubliczne).
Funkcje komercyjne
  • AppCDS (Application Class Data Sharing)
    Funkcja AppCDS (Application Class Data Sharing) rozszerza CDS, umożliwiając umieszczanie klas ze standardowych katalogów rozszerzeń oraz ze ścieżki klas aplikacji w udostępnianym archiwum. Jest to funkcja eksperymentalna, nielicencjonowana do użytku komercyjnego. Zob. opcja -XX:+UseAppCDS na stronie narzędzia java launcher.
  • CMM (Cooperative Memory Management)
    Zaczynając od wersji JDK 8u40, do JDK została dodana właściwość "memory pressure" (nacisk na pamięć). Nacisk na pamięć reprezentuje łączne wykorzystanie pamięci RAM w systemie. Im większa wartość, tym szybciej zabraknie pamięci w systemie. Jest to funkcja eksperymentalna, nielicencjonowana do użytku komercyjnego. W reakcji na zwiększoną wartość nacisku na pamięć, JDK spróbuje zmniejszyć wykorzystanie pamięci przez siebie. Jest to realizowane głównie przez zmniejszenie sterty Java. Działania, które JDK podejmie w celu zmniejszenia wykorzystania pamięci, mogą prowadzić do zmniejszenia wydajności. Jest to wybór zamierzony. Poziom nacisku jest dostarczany przez aplikację za pomocą obiektu JMX MXBean z użyciem skali od 0 (brak nacisku) do 10 (niemal brak pamięci). Aby można było tę funkcję włączyć, należy zarejestrować jdk.management.cmm.SystemResourcePressureMXBean. Nacisk na pamięć jest następnie ustawiany za pomocą atrybutu "MemoryPressure".
    Dostępna jest także nowa opcja -XX:MemoryRestriction wiersza polecenia, przyjmująca jeden z następujących argumentów: none, low, medium lub high. Opcja ta ustawia w JDK początkowy i będzie działać także we wszystkich przypadkach niezarejestrowania obiektu MXBean. Funkcja CMM (Cooperative Memory Management) wymaga G1 GC (-XX:+UseG1GC). Funkcja ta nie jest zgodna z opcją -XX:+ExplicitGCInvokesConcurrent.
  • Nowe opcje komercyjne
    Dwie nowe opcje VM są teraz dostępne dla posiadaczy licencji komercyjnych:
    • -XX:+ResourceManagement
    • -XX:ResourceManagementSampleInterval=wartość (milisekundy)
    Więcej informacji jest dostępnych w dokumentacji Java Launcher.
  • Nowa dokumentacja instalatora MSI:
    Dostępny jest dokument Microsoft Windows Installer (MSI) Enterprise JRE Installer Guide. Do używania programu instalacyjnego MSI Enterprise JRE Installer do celów produkcyjnych jest wymagana licencja komercyjna. Więcej informacji dotyczących komercyjnych funkcji i sposobu ich włączania.
Data ważności oprogramowania Java

Datą ważności wydania 8u40 jest 14 kwietnia 2015 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u40) w dniu 14 maja 2015 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u40 Bug Fixes.

» Uwagi do wydania 8u40


Java 8 Update 31 (8u31)

Najważniejsze cechy wydania
  • Dane IANA 2014j
    JDK 8u31 zawiera dane stref czasowych IANA w wersji 2014j. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Domyślne wyłączenie protokołu SSLv3
    Zaczynając od wydania JDK 8u31, nastąpiło zdezaktywowanie protokołu SSLv3 (Secure Socket Layer), który przestaje być normalnie dostępnym. Proszę się przyjrzeć właściwości jdk.tls.disabledAlgorithms w pliku \lib\security\java.security. Jeśli protokół SSLv3 jest bezwzględnie wymagany, można go ponownie uaktywnić, usuwając wpis "SSLv3" z właściwości jdk.tls.disabledAlgorithms w pliku java.security albo dynamicznie ustawiając tę właściwość zabezpieczeń jeszcze przed zainicjalizowaniem JSSE.
  • Zmiany w panelu Java Control Panel
    Zaczynając od wydania JDK 8u31, protokół SSLv3 został usunięty z opcji Java Control Panel Advanced. Jeśli protokół SSLv3 jest wymagany dla aplikacji, można go ponownie włączyć, postępując w następujący sposób:
    • Włączanie protokołu SSLv3 na poziomie JRE: jak opisano w poprzedniej sekcji.
    • Włączanie protokołu SSLv3 na poziomie wprowadzania do środowiska wykonawczego: otworzyć plik deployment.properties do edycji i dodać następujący wpis:

      deployment.security.SSLv3=true
Data ważności oprogramowania Java

Datą ważności wydania 8u31 jest 14 kwietnia 2015 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u31) w dniu 14 maja 2015 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u31 Bug Fixes.

» Uwagi do wydania 8u31


Java 8 Update 25 (8u25)

Najważniejsze cechy wydania
  • Dane IANA 2014c
    JDK 8u25 zawiera dane stref czasowych IANA w wersji 2014c. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
  • Poprawka: Obniżenie preferencyjnego trybu RC4 na liście włączonych pakietów szyfrujących
    Poprawka ta obniża preferencję pakietów szyfrujących opartych na RC4, występujących na liście włączonych pakietów szyfrujących od dostawcy SunJSSE. Zob. 8043200 (niepubliczne).
  • Poprawka: JRE 8u20 ulega awarii, gdy w systemie Windows jest używany japoński komunikator
    Wirtualna maszyna VM ulega awarii, gdy w systemie Windows są używane składniki Swing i jednocześnie są wprowadzane niektóre japońskie lub chińskie znaki. Ten problem został teraz wyeliminowany. Zob. 8058858 (niepubliczne).
Instrukcje wyłączania protokołu SSL v3.0 w Oracle JDK i JRE

Firma Oracle zaleca użytkownikom i programistom wyłączenie używania protokołu SSLv3.
» W jaki sposób użytkownicy oprogramowania Java mogą stwierdzić, że nie są zagrożeni przez lukę POODLE z SSL V3.0?

Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u25 jest 20 stycznia 2015 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u25) w dniu 20 lutego 2015 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Java SE Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u25 Bug Fixes.

» Uwagi do wydania 8u25


Java 8 Update 20 (8u20)

Najważniejsze cechy wydania
  • Nowe flagi dodane do Java Management API
    Umożliwiono zarządzanie flagami MinHeapFreeRatio i MaxHeapFreeRatio. Znaczy to, że można je zmieniać w trybie wykonawczym za pomocą interfejsu Management API środowiska Java. Obsługa tych flag została także dodana do mechanizmu ParallelGC jako część zasad adaptacyjnej zmiany rozmiaru.
  • Zmiany w instalatorze oprogramowania Java
    • Jest dostępny nowy instalator Microsoft Windows Installer (MSI) Enterprise JRE umożliwiający użytkownikom zainstalowanie JRE w swojej firmie. Więcej informacji jest dostępnych w sekcji Downloading the Installer na stronie JRE Installation for Microsoft Windows. Instalator MSI Enterprise JRE jest dostępny tylko w ramach pakietów Java SE Advanced i Java SE Suite. Więcej informacji o tych komercyjnych produktach jest dostępnych na stronie Java SE Advanced and Java SE Suite.
    • Narzędzie Java Uninstall zostaje zintegrowane z programem instalacyjnym, tak aby była dostępna opcja usunięcia starszych wersji oprogramowania Java z systemu. Zmiana ma zastosowanie w 32- i 64-bitowych systemach Windows. Zob. Odinstalowywanie JRE.
  • Zmiany w panelu Java Control Panel
    • Karta Update (Aktualizacja) z panelu Java Control Panel umożliwia użytkownikom automatyczną aktualizację 64-bitowych wersji JRE (dodatkowo do wersji 32-bitowych) zainstalowanych w systemie.
    • Poziom zabezpieczeń Medium (Średni) został usunięty. Obecnie są dostępne tylko poziomy High (Wysoki) i Very High (Bardzo wysoki). Aplety, które nie są zgodne z najnowszymi praktykami w zakresie zabezpieczeń, mogą nadal być autoryzowane do uruchamiania; w tym celu należy umieścić ich witryny na liście Exception Site List (Lista wyjątków witryn). Lista wyjątków witryn umożliwia użytkownikom zezwalanie na uruchamianie apletów — które byłyby dozwolone poprzez wybór poziomu Medium — na podstawie konkretnych witryn, tym samym minimalizując ryzyko użycia mniej restrykcyjnych ustawień.
  • Zaktualizowany kompilator Java
    Kompilator javac został zaktualizowany tak, aby została zaimplementowana analiza typu „definite assignment” dla dostępu do pustego pola „final” z użyciem zmiennej „this”. Więcej informacji jest dostępnych na stronie JDK 8 Compatibility Guide.
  • Zmiana minimalnej wymaganej wersji środowiska Java dla wtyczki Java i programu Java WebStart
    Minimalną wymaganą wersją środowiska Java dla wtyczki Java i programu Java WebStart jest teraz Java 5. Aplety, które nie działają w środowisku Java 5 lub nowszym, muszą — aby nadal funkcjonowały — zostać przeprogramowane do nowszej wersji środowiska Java. Aplety napisane dla starszych wersji, lecz mogące funkcjonować w środowisku co najmniej Java 5, będą nadal działały.
  • Zmiana formatowania wyników narzędzia UsageTracker
    Formatowanie wyników narzędzia UsageTracker zostało zmienione i — w celu uniknięcia pomyłek — są stosowane cudzysłowy. Może wymagać to zmian w sposobie odczytywania takich informacji. Funkcję tę można skonfigurować tak, aby działała jak w poprzednich wersjach, aczkolwiek zalecany jest nowy format. Zob. dokumentację Java Usage Tracker.
  • Zmiany w narzędziach pakowania aplikacji Java
    • Nazwa javafxpackager została zmieniona na javapackager
    • Do polecenia deploy narzędzia javapackager została dodana opcja "-B", umożliwiająca przekazywanie argumentów do narzędzi pakujących, które są używane do tworzenia aplikacji samoistnych (self-contained). Więcej informacji jest dostępnych w dokumentacji javapackager (Windows)/(Unix).
    • Do JavaFX Ant Task Reference został dodany argument parametru pomocniczego . Umożliwia on określenie argumentu (w elemencie ) dla narzędzia pakującego, które jest używane do tworzenia aplikacji samoistnych (self-contained).
Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u20 jest 14 października 2014 r. Ważność oprogramowania Java wygasa, gdy staje się dostępna nowa wersja eliminująca luki zabezpieczeń. W przypadku systemów, które nie będą się mogły skomunikować z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u20) w dniu 14 listopada 2014 r. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępna nowa wersja lub zostanie osiągnięta data wygaśnięcia ważności) środowisko Java będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania Java do nowej wersji.

Poprawki błędów

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u20 Bug Fixes.

» Uwagi do wydania 8u20


Java 8 Update 11 (8u11)

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u11 Bug Fixes.

» Uwagi do wydania 8u11


Java 8 Update 5 (8u5)

Wersja ta zawiera poprawki eliminujące luki w zabezpieczeniach. Więcej informacji jest dostępnych na stronie Oracle Critical Patch Update Advisory.

Lista poprawek zawartych w tym wydaniu jest dostępna na stronie JDK 8u5 Bug Fixes.

» Uwagi do wydania 8u5


Java 8 Release

» Uwagi do wydania JDK i JRE 8


To może również zainteresować:




Wybór języka | Java - informacje | Asysta Techniczna | Programiści
Prywatność  | Warunki korzystania | Znaki towarowe | Zastrzeżenie

Oracle