Java 8 - zmiany w wydaniu

Najważniejsze cechy wydania Java 8

Artykuł dotyczy:

Platformy: Brak
Przeglądarki: Brak
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 441 (8u441)

Najważniejsze cechy wydania

JDK 8u441 zawiera dane stref czasowych IANA 2024b.
Więcej informacji można znaleźć na stronie Wersje danych stref czasowych w oprogramowaniu JRE.
Pakiet JavaFX nie będzie już uwzględniany w JDK/JRE 8
Niniejsze wydanie JDK i JRE 8 (aktualizacja 441) to ostatnie wydanie zawierające pakiet JavaFX. Zgodnie z ogłoszeniem z 2020 r. asysta techniczna dla pakietu JavaFX w JDK 8, ostatniej wersji pakietu JavaFX od Oracle z komercyjną asystą techniczną, zakończy się w marcu 2025 r. W związku z tym aktualizacja 441 pakietu JDK 8 jest ostatnim uaktualnieniem JDK/JRE 8 z pakietem JavaFX. Oracle kontynuuje rozwój pakietu JavaFX i jego wydawanie w formie samodzielnych modułów za pośrednictwem projektu OpenJFX tylko dla najnowszych wersji Java. Więcej szczegółów jest dostępnych w dokumencie Java SE Spring 2024 Roadmap Update.
Inne uwagi: Asysta techniczna dotycząca bazy danych stref czasowych 2024b
Baza danych stref czasowych IANA została uaktualniona do wersji 2024b. Wersja ta uwzględnia głównie zmiany dokonane w celu poprawienia danych historycznych dotyczących Meksyku, Mongolii i Portugalii. Wprowadza również zmianę jednego skrótu znacznika czasu dla strefy czasowej "MET". Ponadto "Azja/Czojbalsan" to nowy alias dla "Azja/Ułan Bator".
Zob. JDK-8339637

Dbanie o aktualność pakietu JDK

Oracle zaleca aktualizowanie pakietu JDK z użyciem każdej krytycznej poprawki aktualizacyjnej (Critical Patch Update — CPU). Chcąc ustalić, czy dane wydanie jest najnowszym, można za pomocą strony Security Baseline sprawdzić, która wersja jest najnowsza dla określonej rodziny wydań.

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JDK (wersja 8u441) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 15 kwietnia 2025 r.

Dostępna dla wszystkich użytkowników usługa Java Management Service ułatwia znajdowanie podatnych na ataki wersji Java w używanych systemach. Subskrybenci Java SE i klienci używający Oracle Cloud mogą używać usługi Java Management Service w celu aktualizowania środowisk wykonawczych Java oraz wykonywania dalszych analiz zabezpieczeń, takich jak identyfikowanie potencjalnie podatnych na ataki bibliotek innych firm używanych przez programy Java użytkownika. Każdy użytkownik, który korzysta już z usługi Java Management Service, może kliknąć tutaj, aby zalogować się do swojego pulpitu informacyjnego. W dokumentacji usługi Java Management Service znajduje się lista funkcji dostępnych dla wszystkich użytkowników oraz funkcji dostępnych tylko dla klientów. Więcej informacji na temat używania usługi Java Management Service do monitorowania i zabezpieczenia instalacji Java.

W przypadku systemów, które nie będą mogły skomunikować się z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u441) w dniu 15-05-2025. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

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 błędów wchodzących w skład tego wydania jest dostępna na stronie Uwagi do wydania 8u441.

Java 8 Update 431 (8u431)

Najważniejsze cechy wydania

JDK 8u431 zawiera dane stref czasowych IANA 2024a.
Więcej informacji można znaleźć na stronie Wersje danych stref czasowych w oprogramowaniu JRE.
Rozwiązano istotne problemy: uaktualnienie JDK RPM pozostawia wpis dot. alternatyw bez właściciela
Rozwiązano problem z wpisami w grupach "java" i "javac", które nie były odpowiednio zarządzane podczas uaktualniania RPM.
W wyniku uaktualniania starszego pakietu Java RPM zainstalowanego we współużytkowanym katalogu (/usr/lib/jvm/jdk-${FEATURE}-oracle-${ARCH}) do pakietu Java RPM instalowanego w specyficznym dla wersji katalogu (/usr/lib/jvm/jdk-${VERSION}-oracle-${ARCH}) starsze wpisy Java w grupach "java" i "javac" nie są usuwane.
JDK-8336107 (niepubliczne)
Inne uwagi: nowe domyślne limity w implementacjach HTTP oprogramowania JDK
Do protokołu HTTP w JDK dodano nowe domyślne limity.
Wbudowana w pakiecie JDK implementacja procedury obsługi protokołu URL dla HTTP (HttpURLConnection) ma teraz domyślny limit maksymalnego rozmiaru nagłówków odpowiedzi przyjmowanych od podmiotów zdalnych. Limit jest domyślnie ustawiony na 384 kB (393216 bajtów) i jest obliczany jako skumulowany rozmiar wszystkich nazw nagłówków i wartości nagłówków plus obciążenie 32 bajtów na parę wartości nazw nagłówków.
JDK-8328286 (niepubliczne)
Inne uwagi: dodano certyfikaty TLS firmy SSL.com poziomu głównego do jednostki certyfikującej (CA) wystawione w 2022 r.
Do magazynu zaufanych cacerts zostały dodane następujące certyfikaty poziomu głównego:
+ SSL.com
+ ssltlsrootecc2022
DN: CN=SSL.com TLS ECC Root CA 2022, O=SSL Corporation, C=US
+ SSL.com
+ ssltlsrootrsa2022
DN: CN=SSL.com TLS RSA Root CA 2022, O=SSL Corporation, C=US
Zob. JDK-8341057
Inne uwagi: certyfikaty serwerów TLS zakotwiczone przez certyfikaty Entrust poziomu głównego i wystawione po 11 listopada 2024 r. przestają być traktowane jako zaufane
JDK - zgodnie z podobnymi planami ogłoszonymi wcześniej przez Google i Mozilla - przestanie traktować jako zaufane certyfikaty serwerów TLS wystawione po 11 listopada 2024 r. i zakotwiczone przez certyfikaty Entrust poziomu głównego. Lista certyfikatów, których to dotyczy, uwzględnia certyfikaty marki AffirmTrust zarządzane przez firmę Entrust.
Zob. JDK-8337664

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JDK (wersja 8u431) po wydaniu następnej krytycznej poprawki aktualizacyjnej planowanej na 21 stycznia 2025 r.

W przypadku systemów, które nie będą mogły skomunikować się z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u431) w dniu 21-02-2025. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

Java 8 Update 421 (8u421)

Najważniejsze cechy wydania

JDK 8u421 zawiera dane stref czasowych IANA 2024a.
Więcej informacji można znaleźć na stronie Wersje danych stref czasowych w oprogramowaniu JRE.
Znany problem: używanie magazynu kluczy przeglądarki w systemie Windows
Po włączeniu w systemie Windows funkcji "Używaj certyfikatów i kluczy w magazynie kluczy przeglądarki" (jest ona włączona domyślnie) aplikacja Java WebStart i wtyczka Java Plugin będą mogły uzyskiwać dostęp do certyfikatów, które są aktualnie traktowane przez komputer lokalny jako zaufane. Nie ma gwarancji dostępności pełnej listy zaufanych certyfikatów, ponieważ certyfikaty są ładowane dynamicznie. W wyniku tego aplety Java i aplikacje Java WebStart mogą napotykać problemy związane z weryfikacją podpisów oraz bezpiecznymi połączeniami powodowane przez brak odpowiednich certyfikatów, co jest spowodowane tym, że struktura wdrażania może uzyskiwać dostęp tylko do certyfikatów, które są "aktywne" w czasie uruchamiania aplikacji.
JDK-8330728 (niepubliczne)
Inne uwagi: dodawanie argumentu STATIC=1 do instalatora oprogramowania JRE
Ta poprawka będzie dodawać argument instalatora STATIC=1 i usuwać argument instalatora RETAIN_ALL_VERSIONS=1. Przekazanie wartości STATIC=1 będzie chronić starsze wersje oprogramowania JRE 8 przed odinstalowaniem w trakcie ręcznego uaktualniania lub automatycznej aktualizacji.
JDK-8313223 (niepubliczne)
Inne uwagi: dodano certyfikaty głównego urzędu certyfikacji R46 i E46 firmy GlobalSign
Do magazynu zaufanych "cacerts" zostały dodane następujące certyfikaty główne:
+ GlobalSign + globalsignr46 DN: CN=GlobalSign Root R46, O=GlobalSign nv-sa, C=BE + GlobalSign + globalsigne46 DN: CN=GlobalSign Root E46, O=GlobalSign nv-sa, C=BE
Zob. JDK-8316138
Inne uwagi: instalator utworzy katalog złączenia w nowej lokalizacji
Oprogramowanie JRE zostanie zainstalowane w lokalizacji C:\Program Files\Java\latest\jre-$fullversion, gdzie $fullversion to wersja techniczna oprogramowania JRE. Na przykład aktualizacja 8u421 zostanie zainstalowana w lokalizacji C:\Program Files\Java\latest\jre-1.8.0_421.

Folder "C:\Program Files" zostanie zmieniony na "C:\Program Files (x86)" dla 32-bitowej wersji Java.

Złączenie zostanie utworzone w lokalizacji C:\Program Files\Java\latest\jre-1.8. Będzie ono wskazywać najnowsze oprogramowanie JRE z rodziny 8.
JDK-8329700 (niepubliczne)

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JDK (wersja 8u421) po wydaniu następnej aktualizacji z poprawkami krytycznymi planowanej na 15 października 2024 r.

W systemach, które nie będą mogły komunikować się z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie tego środowiska JRE (wersja 8u421) w dniu 15-11-2024. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

Java 8 Update 411 (8u411)

Najważniejsze cechy wydania

JDK 8u411 zawiera dane stref czasowych IANA 2024a.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: dodano certyfikaty poziomu głównego R1 i E1 firmy Certainly
Do magazynu zaufanych cacerts zostały dodane następujące certyfikaty poziomu głównego: + Certainly + certainlyrootr1 DN: CN=Certainly Root R1, O=Certainly, C=US + Certainly + certainlyroote1 DN: CN=Certainly Root E1, O=Certainly, C=US
Zob. JDK-8321408
Nowa funkcja: domyślne włączanie trybu weryfikacji zabezpieczeń narzędzia XML Signature
Tryb weryfikacji zabezpieczeń narzędzia XML Signature jest domyślnie włączony (wcześniej nie był domyślnie włączany, jeśli nie był uruchomiony z menedżerem zabezpieczeń). Gdy jest włączony, weryfikacja podpisów XML podlega dokładniejszemu sprawdzaniu algorytmów i innych ograniczeń zgodnie z określoną właściwością zabezpieczeń jdk.xml.dsig.secureValidationPolicy.
Jeśli to konieczne i na własne ryzyko, można w aplikacjach wyłączyć ten tryb, ustawiając we właściwości org.jcp.xml.dsig.secureValidation wartość Boolean.FALSE z interfejsem API DOMValidateContext.setProperty().
Zob. JDK-8259801

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JDK (wersja 8u411) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 16 lipca 2024 r.

W przypadku systemów, które nie będą mogły skomunikować się z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u411) w dniu 16-08-2024. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

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 uwzględnionych w tym wydaniu jest dostępna na stronie uwag do wydania 8u411.

Java 8 Update 401 (8u401)

Najważniejsze cechy wydania

JDK 8u401 zawiera dane stref czasowych IANA 2023c.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: nowa właściwość systemowa do przełączania trybu weryfikacji zabezpieczeń podpisów XML
Dodano nową właściwość systemową o nazwie org.jcp.xml.dsig.secureValidation. Można jej używać do włączania lub wyłączania trybu weryfikacji zabezpieczeń podpisów XML. Tę właściwość systemową należy ustawić na wartość "true" w celu włączenia lub na wartość "false" w celu wyłączenia. Każda inna wartość tej właściwości systemowej jest traktowana jako "false". Jeśli ta właściwość systemowa jest ustawiona, ma pierwszeństwo przed wartością właściwości XMLCryptoContext. Tryb weryfikacji zabezpieczeń jest domyślnie włączony, jeśli kod jest wykonywany z użyciem składnika SecurityManager. W przeciwnym razie tryb ten jest domyślnie wyłączony.
Zob. JDK-8301260
Nowa funkcja: zdarzenie JDK Flight Recorder dotyczące deserializacji
Dodano nowe zdarzenie JDK Flight Recorder (JFR) do monitorowania deserializacji obiektów. Kiedy JFR jest włączony, a jego konfiguracja obejmuje zdarzenia deserializacji, będzie on emitował zdarzenie za każdym razem, gdy działający program podejmie próbę deserializacji obiektu. Zdarzenie deserializacji nosi nazwę java/deserialization i jest domyślnie wyłączone. Zdarzenie deserializacji zawiera informacje używane przez mechanizm filtra serializacji. Ponadto, jeśli jest włączony filtr, zdarzenie JFR wskazuje, czy filtr zaakceptował, czy odrzucił deserializację obiektu.
Zob. JDK-8261160

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JDK (wersja 8u401) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 16 kwietnia 2024 r.

Subskrypcja Java SE - klienci, którzy zarządzają aktualizacjami/instalacjami środowiska JRE dla dużej liczby komputerów, powinni rozważyć użycie usługi Java Management Service (JMS).

W przypadku systemów, które nie będą mogły skomunikować się z serwerami Oracle, pomocniczy mechanizm spowoduje wygaśnięcie ważności tego środowiska JRE (wersja 8u401) w dniu 16-05-2024. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępne nowe wydanie 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 nowszej wersji. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

Java 8 Update 391 (8u391)

Najważniejsze cechy wydania

JDK 8u391 zawiera dane stref czasowych IANA 2023c.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Nowe zdarzenie JFR: jdk.SecurityProviderService
Do szczegółów rekordu wywołań funkcji java.security.Provider.getService(String type, String algorithm) zostało dodane nowe zdarzenie JFR (Java Flight Recorder).
Zob. JDK-8254711
Usunięta funkcja: Usunięto certyfikat poziomu głównego RootCA1 firmy SECOM Trust Systems
Następujący certyfikat poziomu głównego firmy SECOM Trust Systems został usunięty z magazynu kluczy cacerts:
+ alias name "secomscrootca1 [jdk]" Nazwa wyróżniająca: OU=Security Communication RootCA1, O=SECOM Trust.net, C=JP
Zob. JDK-8295894
Usunięta funkcja: Usunięcie obsługi architektury ARM32 w systemie Linux w pakiecie JDK 8
Obsługa platformy dla architektury ARM32 w systemie Linux została usunięta w pakiecie JDK 8. W wyniku tego pobieranie interfejsu ABI typu hard float dla architektury ARM32 nie będzie dostępne. Systemy operacyjne obsługujące architekturę ARM32 osiągnęły koniec okresu eksploatacji i z tego powodu nie jest dla nich dostępna żadna znana asysta techniczna.
JDK-8305927 (niepubliczne)
Inne uwagi: Dodano certyfikat Certigna poziomu głównego do jednostki certyfikującej (CA)
Następujący certyfikat poziomu głównego został dodany do magazynu zaufanych "cacerts":
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna Root CA, OU=0002 48146308100036, O=Dhimyotis, C=FR
Zob. JDK-8314960

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JDK (wersja 8u391) po wydaniu następnej krytycznej poprawki aktualizacyjnej planowanej na 16 stycznia 2024 r.

Subskrypcja Java SE — klienci, którzy zarządzają aktualizacjami/instalacjami JRE dla dużej liczby komputerów typu Desktop, powinni rozważyć użycie konsoli Java Advanced Management Console (AMC).

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 8u391) w dniu 2024-02-16. Jeśli zostanie spełniony którykolwiek z tych warunków (stanie się dostępne nowe wydanie lub zostanie osiągnięta data ważności), środowisko JRE będzie prezentowało użytkownikom dodatkowe ostrzeżenia i przypomnienia o konieczności aktualizacji oprogramowania do nowszej wersji. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

Java 8 Update 381 (8u381)

Najważniejsze cechy wydania

JDK 8u381 zawiera dane stref czasowych IANA 2023c.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Zezwalanie na obsługę dodatkowych znaków dla GB18030-2022
Chiński narodowy komitet normalizacyjny (CESI) niedawno opublikował normę GB18030-2022 będącą zaktualizowaną wersją normy GB18030 i synchronizującą GB18030 ze standardem Unicode w wersji 11.0. Implementacja zestawu znaków dla tej nowej normy zastąpiła wcześniejszą normę 2000. Ta nowa norma zawiera jednak pewne niekompatybilne zmiany z poprzedniej implementacji. Dla tych, którzy potrzebują używać starego odwzorowania, została wprowadzona nowa systemowa właściwość jdk.charset.GB18030. Jeśli jej wartość zostanie ustawiona na 2000, to dla zestawu znaków GB18030 będą używane odwzorowania z wcześniejszych wydań JDK, bazujące na normie 2000.
Zob. JDK-8307229
JDK teraz akceptuje klucze RSA w formacie PKCS#1
Prywatne i publiczne klucze RSA w formacie PKCS#1 mogą być teraz akceptowane przez dostawców JDK, takich jak RSA KeyFactory.impl od dostawcy SunRsaSign. Obiekt prywatnego lub publicznego klucza RSA powinien być w formacie PKCS#1, a kodowanie prywatnego lub publicznego klucza RSA powinno być zgodne ze składnią ASN.1 dla PKCS#1.
Zob. JDK-8023980
Inne uwagi: Obsługa cgroup v2 i udoskonalenia w wersji 8u381
JDK 8u381 zawiera szereg udoskonaleń i poprawek mających na celu poprawę obsługi cgroup v1 i v2 dla kontenerów. Udoskonalenia obejmują dokładne wykrywanie limitów zasobów dla kontenerów, poprawne raportowanie zgromadzonych miar kontenerów, wyświetlanie dodatkowych informacji o kontenerach oraz poprawę stabilności aplikacji w konteneryzowanych środowiskach.
Zob. JDK-8307634
Inne uwagi: Dodano certyfikat TWCA poziomu głównego do jednostki certyfikującej (CA)
Następujący certyfikat poziomu głównego został dodany do magazynu zaufanych cacerts::
+ TWCA + twcaglobalrootca DN: CN=TWCA Global Root CA, OU=Root CA, O=TAIWAN-CA, C=TW
Zob. JDK-8305975
Inne uwagi: Dodano 4 certyfikaty GTS poziomu głównego do jednostki certyfikującej (CA)
Do magazynu zaufanych cacerts zostały dodane następujące certyfikaty poziomu głównego:
+ Google Trust Services LLC + gtsrootcar1 DN: CN=GTS Root R1, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootcar2 DN: CN=GTS Root R2, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar3 DN: CN=GTS Root R3, O=Google Trust Services LLC, C=US + Google Trust Services LLC + gtsrootecccar4 DN: CN=GTS Root R4, O=Google Trust Services LLC, C=US
Zob. JDK-8307134
Inne uwagi: Dodano 2 certyfikaty TLS firmy Microsoft Corporation poziomu głównego do jednostki certyfikującej (CA)
Do magazynu zaufanych cacerts zostały dodane następujące certyfikaty poziomu głównego:
+ Microsoft Corporation + microsoftecc2017 DN: CN=Microsoft ECC Root Certificate Authority 2017, O=Microsoft Corporation, C=US + Microsoft Corporation + microsoftrsa2017 DN: CN=Microsoft RSA Root Certificate Authority 2017, O=Microsoft Corporation, C=US
Zob. JDK-8304760

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JRE (wersja 8u381) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 17 października 2023 r.

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 8u381) w dniu 2023-11-17. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

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 uwag do wydania JDK 8u381.

Java 8 Update 371 (8u371)

Najważniejsze cechy wydania

JDK 8u371 zawiera dane stref czasowych IANA 2022g.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Dodano domyślną natywną bibliotekę GSS-API w systemie Windows
Natywna biblioteka GSS-API została dodana do pakietu JDK w systemie Windows. Biblioteka ta występuje tylko po stronie klienta i używa domyślnych uwierzytelnień. Zostanie załadowana, jeśli właściwość systemowa sun.security.jgss.native zostanie ustawiona na wartość „true”. Użytkownik nadal może ładować natywną bibliotekę GSS-API innego podmiotu, ustawiając właściwość systemową sun.security.jgss.lib na ścieżkę biblioteki.
Zob. JDK-6722928
Usunięto funkcje i opcje: Implementacja motoru javax.script i API com.apple.concurrent.Dispatch zostały usunięte dla procesorów macOS AArch64
Motor AppleScript implementujący API motoru został usunięty bez zastąpienia. Motor AppleScript działał niespójnie. Brakowało pliku konfiguracyjnego usług (META-INF/services) i motor przypadkowo działał wtedy, gdy był instalowany pakiet JDK 7 lub JDK 8 w systemie, w którym już występował AppleScriptEngine.jar w wersji dostarczanej przez Apple.
API com.apple.concurrent.Dispatch był interfejsem API tylko dla systemów Mac. Został wprowadzony do JDK 7u4 z portem kodu Apple JDK 6. Programistów zachęca się do używania w zamian standardowych API java.util.concurrent.Executor i java.util.concurrent.ExecutorService.
Zob. JDK-8297475
Inne uwagi: Dodano certyfikat Certigna (Dhimyotis) poziomu głównego do jednostki certyfikującej (CA)
Następujący certyfikat poziomu głównego został dodany do magazynu zaufanych cacerts:
+ Certigna (Dhimyotis) + certignarootca DN: CN=Certigna, O=Dhimyotis, C=FR
Zob. JDK-8245654
Inne uwagi: Usunięto SSLv2Hello i SSLv3 z domyślnie włączanych protokołów TLS
SSLv2Hello i SSLv3 zostały usunięte z domyślnie włączanych protokołów TLS.

Po tej aktualizacji, jeśli SSLv3 zostanie usunięty z właściwości jdk.tls.disabledAlgorithms zabezpieczeń, API SSLSocket.getEnabledProtocols(), SSLServerSocket.getEnabledProtocols(), SSLEngine.getEnabledProtocols() i SSLParameters.getProtocols() będą zwracać "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1". "SSLv3" nie będzie zwracany na tej liście.
Jeśli klient lub serwer nadal musi używać protokołu SSLv3, to można go włączyć za pomocą właściwości systemowych jdk.tls.client.protocols lub jdk.tls.server.protocols bądź za pomocą API SSLSocket.setEnabledProtocols(), SSLServerSocket.setEnabledProtocols() i SSLEngine.setEnabledProtocols().
Zob. JDK-8190492

Dbanie o aktualność pakietu JDK

Oracle zaleca aktualizowanie pakietu JDK z użyciem każdej krytycznej poprawki aktualizacyjnej (Critical Patch Update — CPU). Na stronie Security Baseline można ustalić najnowszą wersję dla każdej rodziny wydań.

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie Critical Patch Updates, Security Alerts and Bulletins. Nie zaleca się używania tej wersji JDK (wersja 8u371) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 18 lipca 2023 r.

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 8u371) w dniu 2023-08-18. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

Java 8 Update 361 (8u361)

Najważniejsze cechy wydania

JDK 8u361 zawiera dane stref czasowych IANA 2022d, 2022e i 2022f.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Obsługa algorytmu RSASSA-PSS w odpowiedzi OCSP
Są już obsługiwane odpowiedzi OCSP podpisane przy użyciu algorytmu RSASSA-PSS.
Zob. JDK-8274471
Inne uwagi: Motor JavaScript dla języka FXML domyślnie wyłączony
Motor JavaScript dla języka FXML obecnie jest domyślnie wyłączony. Domyślnie nie będzie już ładowany żaden plik .fxml zawierający instrukcję przetwarzania "javascript" i będzie zgłaszany wyjątek.
Ładowanie można włączyć, ustawiając następującą właściwość systemową: -Djavafx.allowjs=true
JDK-8294779 (niepubliczne)
Inne uwagi: Niepoprawna obsługa w konstruktorze ProcessBuilder argumentów ujętych w cudzysłów
Przywrócono ProcessBuilder w systemie Windows w celu rozwiązania problemu spowodowanego przez JDK-8250568. Poprzednio argument przekazywany do konstruktora ProcessBuilder, zaczynający się znakiem cudzysłowu oraz kończący się ukośnikiem odwrotnym i następującym po nim znakiem cudzysłowu, był niepoprawnie przekazywany do polecenia i mógł być przyczyną niepowodzenia polecenia. Na przykład argument "C:\\Program Files\" był widziany przez polecenie jako argument z dodatkowymi znakami cudzysłowu. Ta aktualizacja przywraca długo funkcjonujące działanie, zgodnie z którym ukośnik odwrotny przed znakiem cudzysłowu nie jest traktowany specjalnie.
Zob. JDK-8282008
Inne uwagi: Możliwość konfigurowania domyślnego limitu czasu utrzymywania aktywności połączenia HttpURLConnection
Zostały dodane dwie właściwości systemowe określające utrzymywanie aktywności połączenia HttpURLConnection w przypadku, gdy serwer nie określa czasu utrzymywania aktywności. Są definiowane dwie właściwości do kontrolowania osobno połączeń z serwerami i z serwerami proxy. Są to odpowiednio http.keepAlive.time.server i http.keepAlive.time.proxy. Więcej informacji jest dostępnych na stronie Networking Properties.
Zob. JDK-8278067
Inne uwagi:Narzędzie VisualVM nie jest już dołączane do pakietu
Ta wersja JDK nie zawiera już kopii narzędzia Java VisualVM. Narzędzie VisualVM jest obecnie dostępne do osobnego pobrania ze strony https://visualvm.github.io.
Zob. JDK-8294184

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JRE (wersja 8u361) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 18 kwietnia 2023 r.

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 8u361) w dniu 2023-05-18. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

Java 8 Update 351 (8u351)

Najważniejsze cechy wydania

Dane IANA TZ 2022b, 2022c.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Inne uwagi: Uaktualnienie domyślnego algorytmu MAC w PKCS12
Został zaktualizowany domyślny algorytm MAC, używany w magazynie kluczy PKCS #12. Nowy algorytm bazuje na SHA-256 i jest silniejszy niż stary algorytm oparty na SHA-1. Aby uzyskać szczegółowe informacje, proszę przejrzeć w pliku java.security właściwości zabezpieczeń zaczynające się tekstem keystore.pkcs12.
Zob. JDK-8267880
Inne uwagi: Wyłączono pliki JAR podpisane z użyciem SHA-1
Pliki JAR podpisane z użyciem algorytmu SHA-1 są obecnie domyślnie ograniczone i traktowane jak niepodpisane. Dotyczy to algorytmów używanych do tworzenia skrótów (digest), podpisywania i opcjonalnie datowania pliku JAR. Dotyczy także algorytmów podpisywania i tworzenia skrótów, które to algorytmy są używane w certyfikatach w łańcuchu certyfikatów jednostki podpisującej kod i datującej oraz we wszystkich odpowiedziach CRL lub OCSP służących do sprawdzania, czy te certyfikaty zostały cofnięte. Ograniczenia te mają zastosowanie także do wszystkich dostawców podpisanych rozszerzeń JCE.
Zob. JDK-8269039
Inne uwagi: Dezaktualizacja 3DES i RC4 w protokole Kerberos
Typy szyfrowania (e-typy) des3-hmac-sha1 i rc4-hmac w protokole Kerberos zostały zdezaktualizowane i są domyślnie wyłączone. Aby je włączyć (wraz z innymi słabymi e-typami, w tym des-cbc-crc i des-cbc-md5), użytkownicy mogą na własne ryzyko ustawić allow_weak_crypto = true w pliku konfiguracyjnym krb5.conf. Aby wyłączyć podzbiór słabych e-typów, użytkownicy mogą wyszczególnić preferowane e-typy w ustawieniach default_tkt_enctypes, default_tgs_enctypes lub permitted_enctypes.
Zob. JDK-8139348

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JRE (wersja 8u351) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 17 stycznia 2023 r.

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 8u351) w dniu 2023-02-17. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u351

Java 8 Update 341 (8u341)

Najważniejsze cechy wydania

Dane IANA TZ 2022a.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Obsługa wiązania kanału HTTPS dla usług Java GSS/Kerberos
Dodano mechanizmy obsługi dla tokenów wiązań kanałów TLS używanych do identyfikacji negocjowanej lub identyfikacji Kerberos, poprzez połączenia HTTPS, z użyciem klasy javax.net.HttpsURLConnection.

Tokeny wiązania kanałów są coraz bardziej wymagane jako udoskonalona forma zabezpieczeń. Działają, komunikując z klienta serwerowi zrozumienie powiązania między bezpieczeństwem zapewnianym przez serwer (reprezentowanych przez certyfikat TLS serwera) a uwierzytelniami identyfikującymi na wyśzym poziomie (takimi jaknazwa użytkownika i hasło). Serwer może wówczas wykryć, czy klient nie został wprowadzony w błąd przez atak MITM, i może zamknąć sesję/połączenie.
Zob. JDK-8279842
Nowa funkcja: Domyślne włączenie protokołu TLSv1.3 w pakiecie JDK 8u dla ról poziomu klienta
Implementacja protokołu TLSv1.3 jest dostępna w pakiecie JDK 8u, począwszy od aktualizacji 8u261, i jest domyślnie włączana dla ról poziomu serwera, ale wyłączana dla ról poziomu klienta. Zaczynając od tego wydania, protokół TLSv1.3 będzie domyślnie włączany dla ról poziomu klienta. Więcej szczegółów można znaleźć w sekcji Additional Information dokumentu Oracle JRE and JDK Cryptographic Roadmap.
Zob. JDK-8245263
Inne uwagi:Aktualizacja klasy java.net.InetAddress do wykrywania niejednoznacznych literałów adresów IPv4
Klasa java.net.InetAddress została uaktualniona tak, aby były akceptowane wyłącznie literały adresów IPv4 w notacji dziesiętnej kropkowej. Metody z klasy InetAddress zostały zaktualizowane tak, aby dla niepoprawnych literałów adresów IPv4 był zwracany wyjątek java.net.UnknownHostException. Aby ten test wyłączyć, należy ustawić właściwość systemową jdk.net.allowAmbiguousIPAddressLiterals na wartość „true”.
Zob. JDK-8277608 (niepubliczne)
Inne uwagi: Rozszerzenia pakietów JDK obcinane podczas pobierania za pomocą przeglądarki Firefox w wersji 102
W serwisach oracle.com i java.com niektóre rozszerzenia pakietów JDK są obcinane, gdy pakiety są pobierane za pomocą przeglądarki Firefox w wersji 102. Niektóre pobrane pakiety nie mają rozszerzeń, takich jak .exe, .rpm czy .deb. Nie mając możliwości uaktualnienia przeglądarki Firefox do wersji ESR 102.0.1 lub 103, gdy zostanie ona wydana, można skorzystać z następującego tymczasowego rozwiązania:
– dodać ręcznie rozszerzenia do nazw plików po ich pobraniu
– użyć innej przeglądarki
Zob. JDK-8277093

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JRE (wersja 8u341) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 18 października 2022 r.

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 8u341) w dniu 2022-11-18. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u341

Java 8 Update 333 (8u333)

Najważniejsze cechy wydania

Dane IANA TZ 2021a.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Zmiana: Domyślne włączenie alternatywnych strumieni danych w systemie Windows
Implementacja klasy java.io.File w systemie Windows została zmieniona, tak że ścisłe testy ważności nie są domyślnie wykonywane dla ścieżek plików. Dotyczy to także zezwolenia na dwukropki (:) w ścieżce, w miejscach innych niż bezpośrednio po literze dysku. Dopuszczane są także ścieżki reprezentujące w systemie plików NTFS alternatywne strumienie danych (ADS — Alternate Data Streams), takie jak „nazwa_pliku:nazwa_strumienia”. Wskutek tej zmiany domyślne funkcjonowanie klasy java.io.File jest przywracane do stanu sprzed aktualizacji CPU z kwietnia 2022, kiedy to ścisłe testy ważności nie były domyślnie wykonywane dla ścieżek plików w systemie Windows. Aby ponownie włączyć w klasie java.io.File ścisłe testy ważności, należy właściwość systemową jdk.io.File.enableADS ustawić na false (wielkość liter nie ma znaczenia). Może to być preferowane, jeśli na przykład nie są używane specjalne ścieżki (takie jak NUL:) do urządzeń w systemie Windows.
Zob. JDK-8285445

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JRE (wersja 8u333) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 19 lipca 2022 r.

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 8u333) w dniu 2022-08-19. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

To wydanie bazuje na poprzedniej aktualizacji CPU i nie zawiera żadnych dodatkowych poprawek w zakresie zabezpieczeń. Bardziej szczegółowa lista poprawek zawartych w tym wydaniu jest dostępna na stronie uwag do wydania JDK 8u333.

» Uwagi do wydania 8u333

Java 8 Update 331 (8u331)

Najważniejsze cechy wydania

Dane IANA TZ 2021e.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja:Nowe limity przetwarzania kodu XML
Zostały dodane trzy limity przetwarzania. Są to:
- jdk.xml.xpathExprGrpLimit
  Opis: Ogranicza liczbę grup, które może zawierać wyrażenie XPath.
  Typ: integer
  Wartość: Dodatnia liczba całkowita. Wartość 0 lub mniejsza oznacza brak limitu. Jeśli wartość nie będzie liczbą całkowitą, zostanie zgłoszony NumberFormatException. Domyślnie 10.
- jdk.xml.xpathExprOpLimit
  Opis: Ogranicza liczbę operatorów, które może zawierać wyrażenie XPath.
  Typ: integer
  Wartość: Dodatnia liczba całkowita. Wartość 0 lub mniejsza oznacza brak limitu. Jeśli wartość nie będzie liczbą całkowitą, zostanie zgłoszony NumberFormatException. Domyślnie 100.
- jdk.xml.xpathTotalOpLimit
  Opis: Ogranicza łączną liczbę operatorów XPath w arkuszu stylów XSL.
  Typ: integer
  Wartość: Dodatnia liczba całkowita. Wartość 0 lub mniejsza oznacza brak limitu. Jeśli wartość nie będzie liczbą całkowitą, zostanie zgłoszony NumberFormatException. Domyślnie 10000.
Obsługiwane procesory
- Przez procesor XPath są obsługiwane jdk.xml.xpathExprGrpLimit i jdk.xml.xpathExprOpLimit.
- Przez procesor XSLT są obsługiwane wszystkie trzy limity.
Ustawianie właściwości
Dla procesora XSLT można zmieniać właściwości przez TransformerFactory. Na przykład:
```
<code>        TransformerFactory factory = TransformerFactory.newInstance();

        factory.setAttribute("jdk.xml.xpathTotalOpLimit", "1000");
```
Dla obu procesorów (XPath i XSLT) właściwości można ustawiać, używając właściwości systemowej i pliku konfiguracyjnego jaxp.properties znajdującego się w katalogu conf instalacji Java. Na przykład:
```
<code>        System.setProperty("jdk.xml.xpathExprGrpLimit", "20");
```
lub w pliku jaxp.properties:
```
<code>        jdk.xml.xpathExprGrpLimit=20
```
JDK-8270504 (niepubliczne)
Inne uwagi: Eksponowanie w magazynie macOS KeychainStore tylko certyfikatów z poprawnymi ustawienia zaufania jako wpisów zaufanych certyfikatów
W systemie macOS tylko certyfikaty z poprawnymi ustawieniami zaufania, określonymi w łańcuchu kluczy użytkownika, będą eksponowane jako wpisy zaufanych certyfikatów w magazynie kluczy typu KeychainStore. Ponadto wywołanie metody KeyStore::setCertificateEntry lub polecenia keytool -importcert w odniesieniu do magazynu kluczy KeychainStore kończy się teraz niepowodzeniem i jest zwracany KeyStoreException. Aby dodać zaufany certyfikat do łańcucha kluczy użytkownika, należy teraz użyć w systemie macOS polecenia "security add-trusted-cert".
JDK-8278449 (niepubliczne)
Inne uwagi: Analiza składniowa adresów URL we wbudowanych dostawcach JNDI usług LDAP, DNS, RMI i CORBA została bardziej uściślona. Siłę analizy składniowej można kontrolować za pomocą właściwości systemowych:
Analiza składniowa adresów URL we wbudowanych dostawcach JNDI usług LDAP, DNS i RMI została bardziej uściślona. Siłę analizy składniowej można kontrolować za pomocą właściwości systemowych:
```
<code>  -Dcom.sun.jndi.ldapURLParsing="legacy" | "compat" | "strict" (to control "ldap:" URLs)


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

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

  -Dcom.sun.jndi.corbaURLParsing="legacy" | "compat" | "strict" (to control "iiop:" and "iiopname:" URLs)
```
Wartością domyślną jest dla wszystkich wartość "compat".
- Tryb "legacy" wyłącza nową weryfikację.
- Tryb "compat" ogranicza niezgodności.
- Tryb "strict" jest bardziej ścisły i może powodować regresję przez odrzucanie adresów URL, które aplikacja mogłaby uznać za poprawne.
Jeśli zostanie wykryty niedozwolony napis tworzący URL, zostanie zgłoszony javax.naming.NamingException (lub jego podklasa).
JDK-8278972 (niepubliczne)

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JRE (wersja 8u331) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 19 lipca 2022 r.

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 8u331) w dniu 2022-08-19. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u331

Java 8 Update 321 (8u321)

Najważniejsze cechy wydania

IANA TZ - dane 2021b, 2021c, 2021d, 2021e.
JDK 8u321JDK1 zawiera dane stref czasowych IANA w wersjach 2021b, 2021c, 2021d, 2021e. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Nowe właściwości konfiguracyjne SunPKCS11
Dostawca SunPKCS11 dodaje nowe atrybuty konfiguracyjne dostawcy w celu zapewnienia lepszej kontroli korzystania z zasobów natywnych. Dostawca SunPKCS11 używa zasobów natywnych do pracy z natywnymi bibliotekami PKCS11. W celu umożliwienia zarządzania zasobami natywnymi i lepszej ich kontroli zostały dodane dodatkowe atrybuty konfiguracyjne pozwalające kontrolować częstotliwość czyszczenia odwołań do zasobów natywnych oraz likwidować token PKCS11 po wylogowaniu użytkownika.
Zob. JDK-8240256
Usunięte funkcje i opcje: Usunięcie certyfikatu GlobalSign poziomu głównego dla Google
Następujący certyfikat poziomu głównego dla Google został usunięty z magazynu kluczy cacerts:
+ alias name "globalsignr2ca [jdk]" Distinguished Name: CN=GlobalSign, O=GlobalSign, OU=GlobalSign Root CA - R2
Zob. JDK-8225083
Inne uwagi: Zaktualizowano dane stref czasowych do wersji 2021c
Baza danych stref czasowych IANA, na której się opierają biblioteki Date/Time z pakietu JDK, została dostosowana do niektórych reguł dotyczących stref czasowych, obowiązujących od wersji 2021c. Proszę zwrócić uwagę, że przy tej aktualizacji zostały zmodyfikowane — zgodnie ze zmianami wprowadzonymi w wersji 2021b — niektóre z reguł dotyczących stref czasowych, obowiązujących przed rokiem 1970. Więcej informacji można znaleźć w ogłoszeniu wersji 2021b
Zob. JDK-8274407

Dbanie o aktualność pakietu JDK

Oracle zaleca aktualizowanie pakietu JDK z użyciem każdej krytycznej poprawki aktualizacyjnej (Critical Patch Update — CPU). Chcąc ustalić, czy dane wydanie jest najnowszym, można za pomocą strony „Security Baseline” sprawdzić, która wersja jest najnowsza dla określonej rodziny wydań.

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie Critical Patch Updates, Security Alerts and Bulletins. Nie zaleca się używania tej wersji JRE (wersja 8u291) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 20 lipca 2021 r.

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 8u291) w dniu 2021-08-20. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u321

Java 8 Update 311 (8u311)

Najważniejsze cechy wydania

Dane IANA TZ 2021a.
Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Renderer Marlin w pakiecie JDK 8u
Zaczynając od wersji 8u311, rasteryzator grafiki Marlin i jego artefakty będą kompilowane i dystrybuowane jako składnik pakietów JDK/JRE. Nie jest to domyślny motor renderowania, ale jest dostępna opcja włączenia go; w tym celu należy ustawić następującą właściwość systemową:
sun.java2d.renderer=sun.java2d.marlin.MarlinRenderingEngine
Zob. JDK-8143849
Nowa funkcja: Podzbiór filtrów deserializacji kontekstowej
Umożliwia skonfigurowanie dla aplikacji filtrów deserializacji kontekstowej i deserializacji dynamicznie wybieranej z użyciem klasy "factory" filtrów (obejmującą całą maszynę JVM), która jest wywoływana w celu wybrania filtra dla poszczególnych strumieni deserializacji. Działanie podzbioru jest w pełni zgodne z opisanym w dokumencie JEP 415: Context-Specific Deserialization Filters i ma na celu umożliwienie skonfigurowania klasy "factory" za pomocą właściwości określanej w wierszu polecenia lub w pliku właściwości zabezpieczeń.
Szczegółowe informacje są dostępne w dokumentach Context-Specific Deserialization Filter i Serialization Filtering Guide.
JDK-8268680 (niepubliczne)
Usunięte funkcje i opcje: Usunięcie certyfikatu IdenTrust poziomu głównego
Następujący certyfikat IdenTrust poziomu głównego został usunięty z magazynu kluczy cacerts:
+ alias name "identrustdstx3 [jdk]"
Distinguished Name: CN=DST Root CA X3, O=Digital Signature Trust Co.
Zob. JDK-8225082
Inne uwagi: Wydanie nie rozpoznaje poprawnie systemu Windows 11
To wydanie nie identyfikuje poprawnie systemu Windows 11. Właściwość os.name jest w systemie Windows 11 ustawiana na Windows 10. W dziennikach błędów HotSpot system OS jest identyfikowany jako Windows 10, ale jest w nich jednak pokazywany numer kompilacji. Numerem kompilacji systemu Windows 11 jest 22000.194 lub numer wyższy.
Zob. JDK-8274840
Inne uwagi: Zaktualizowano preferencję dot. domyślnie włączanych zestawów szyfrujących
Została skorygowana domyślna kolejność (wg priorytetu) zestawów szyfrujących od TLS 1.0 do TLS 1.3.
Dla TLS 1.3 zestaw szyfrujący TLS_AES_256_GCM_SHA384 jest preferowany przez zestawem TLS_AES_128_GCM_SHA256.
Dla TLS 1.0 do TLS 1.2 obniżono priorytet niektórych z pośrednich zestawów, jak następuje:
- Obniżono — w stosunku do zestawów szyfrujących obsługujących utajnianie z wyprzedzeniem — priorytet zestawów szyfrujących nieobsługujących utajniania z wyprzedzeniem.
- Obniżono priorytet zestawów szyfrujących, w których jest używany algorytmem SHA-1.
Zob. JDK-8163326
Inne uwagi: Zmodyfikowano działanie klasy HttpURLConnection, gdy nie zostanie znaleziony odpowiedni serwer proxy
W tym wydaniu JDK zostało zmodyfikowano działanie klasy HttpURLConnection, gdy jest używana podklasa ProxySelector. Jeśli skonfigurowanym serwerom proxy nie udawało się ustanowić połączenia, klasa HttpURLConnection podejmowała próbę ustanowienia połączenia bezpośredniego. Zaczynając od tego wydania, domyślne działanie zostało zmienione tak, aby przy pierwszej nieudanej próbie ustanowienia połączenia przez serwer proxy nie było używane połączenie bezpośrednie.
Zob. JDK-8161016

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie „Critical Patch Updates, Security Alerts and Bulletins”. Nie zaleca się używania tej wersji JRE (wersja 8u311) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 18 stycznia 2022 r.

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 8u311) w dniu 2022-02-18. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u311

Java 8 Update 301 (8u301)

Najważniejsze cechy wydania

Dane IANA TZ 2021a.
JDK 8u301 zawiera dane IANA, dotyczące stref czasowych, w wersji 2021a. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Dostosowywanie generowania magazynu kluczy PKCS12
Zostały dodane nowe właściwości systemowe i zabezpieczeń, umożliwiające użytkownikom dostosowywanie generowania magazynów kluczy PKCS #12. Nowa funkcja obejmuje algorytmy i parametry ochrony kluczy, ochrony certyfikatów i danych MacData. Szczegółowe wyjaśnienie i możliwe wartości tych właściwości można znaleźć w sekcji "PKCS12 KeyStore properties" pliku java.security.
Zob. JDK-8076190
Usunięte funkcje i opcje: Usunięcie certyfikatów poziomu głównego z kluczami 1024-bitowymi
Certyfikaty poziomu głównego ze słabymi 1024-bitowymi kluczami publicznymi RSA zostały usunięte z magazynu kluczy cacerts.
Zob. JDK-8243559
Usunięte funkcje i opcje: Usunięcie certyfikatu CA Sonera Class2 firmy Telia Company
Następujący certyfikat poziomu głównego został usunięty z magazynu kluczy cacerts:
+ Telia Company + soneraclass2ca DN: CN=Sonera Class2 CA, O=Sonera, C=FI
Zob. JDK-8225081
Inne uwagi: Uaktualnienie domyślnych algorytmów szyfrowania PKCS12
Zostały zaktualizowane domyślne algorytmy szyfrowania, używane w magazynie kluczy PKCS #12. Nowe algorytmy bazują na AES-256 oraz SHA-256 i są silniejsze niż stare, oparte na RC2, DESede i SHA-1. Aby uzyskać szczegółowe informacje, proszę przejrzeć w pliku java.security właściwości zabezpieczeń zaczynające się tekstem keystore.pkcs12.
W celu zapewnienia zgodności została zdefiniowana nowa właściwość systemowa o nazwie keystore.pkcs12.legacy, pozwalająca przywrócić stare, słabsze algorytmy. Dla tej właściwości nie definiuje się żadnej wartości.
Zob. JDK-8153005

Dbanie o aktualność pakietu JDK

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie Critical Patch Updates, Security Alerts and Bulletins. Nie zaleca się używania tej wersji JRE (wersja 8u301) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 19 października 2021 r.

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 8u301) w dniu 2021-11-19. 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u301

Java 8 Update 291 (8u291)

Najważniejsze cechy wydania

IANA TZ - dane 2020e, 2020f, 2021a.
JDK 8u291 zawiera dane stref czasowych IANA w wersjach 2020e, 2020f, 2021a. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Inne uwagi: Nowe właściwości systemowe i zabezpieczeń kontrolujące rekonstrukcję odległych obiektów przez wbudowane w pakiet JDK implementacje JNDI RMI i LDAP
jdk.jndi.object.factoriesFilter: Ta właściwość systemowa i zabezpieczeń umożliwia określenie filtra szeregowego, kontrolującego zestaw klas „factory” obiektów, którym to klasom zezwolono na tworzenie instancji obiektów z odwołań (do obiektów) zwróconych z systemów nazewniczych/katalogowych. Klasa „factory”, określona przez instancję referencyjną, jest uzgadniana z tym filtrem podczas zdalnej rekonstrukcji instancji referencyjnej. Właściwość „filter” obsługuje składnię filtra opartą na wzorcu, w formacie określonym przez JEP 290. Ta właściwość ma zastosowanie do wbudowanych implementacji dostawcy zarówno JNDI/RMI, jak i JNDI/LDAP. Wartość domyślna zezwala każdej klasie „factory” obiektu, określonej w odwołaniu, odtworzenie obiektu referencyjnego.
JDK-8244473 (niepubliczne)
Inne uwagi: Domyślna wersja Java nie jest aktualizowana do uruchamiania pliku jar dwukrotnym kliknięciem
Jeśli zmienna środowiskowa PATH zawiera rekord skonfigurowany przez programy instalacyjne Oracle JDK z nowszych wydań, to program instalacyjny Oracle JRE wstawia po tym rekordzie (w zmiennej środowiskowej PATH) ścieżkę prowadzącą do katalogu zawierającego polecenia Java (java.exe, javaw.exe i javaws.exe). Poprzednio program instalacyjny Oracle JRE ignorował zmiany dokonane w zmiennej środowiskowej PATH przez programy instalacyjne Oracle JDK z nowszych wydań i niepoprawnie aktualizował wartość zmiennej środowiskowej PATH. Dodatkowe informacje techniczne są dostępne w następującym opisie CSR: https://bugs.openjdk.java.net/browse/JDK-8259858
Zob. JDK-8259215
Inne uwagi: Wyłączenie TLS 1.0 i 1.1
TLS 1.0 i 1.1 to wersje protokołu TLS, które już nie są uznawane za bezpieczne — zostały wyparte przez bezpieczniejsze i nowocześniejsze wersje (TLS 1.2 i 1.3).
Te stare wersje są obecnie domyślnie wyłączone. Jeśli w związku z tym wystąpią problemy, można — na własną odpowiedzialność — ponownie je włączyć, usuwając TLSv1 i/lub TLSv1.1 ze zmiennej zabezpieczeń jdk.tls.disabledAlgorithms z pliku konfiguracyjnego java.security.
Zob. JDK-8202343
Inne uwagi: Wyłączenie TLS 1.0 i 1.1 dla apletów Java Plugin i aplikacji Java Web Start
Wersje TLS 1.0 i 1.1 zostały wyłączone. Protokoły te domyślnie NIE są używane przez aplety Java Plugin i aplikacje Java Web Start. W razie wystąpienia problemów, można te protokoły włączyć za pomocą panelu Java Control Panel.
JDK-8255892 (niepubliczne)

Dbanie o aktualność pakietu JDK

Oracle zaleca aktualizowanie pakietu JDK z użyciem każdej krytycznej poprawki aktualizacyjnej (Critical Patch Update — CPU). Chcąc ustalić, czy dane wydanie jest najnowszym, można za pomocą strony „Security Baseline” sprawdzić, która wersja jest najnowsza dla określonej rodziny wydań.

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie Critical Patch Updates, Security Alerts and Bulletins. Nie zaleca się używania tej wersji JRE (wersja 8u291) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 20 lipca 2021 r.

Poprawki błędów

» Uwagi do wydania 8u291

Java 8 Update 281 (8u281)

Najważniejsze cechy wydania

Dane IANA 2020d
JDK 8u281 zawiera dane stref czasowych IANA w wersji 2020d. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Do polecenia keytool generowania pary kluczy została dodana nowa opcja „groupname”
Do polecenia keytool -genkeypair została dodana nowa opcja -groupname umożliwiająca użytkownikowi, podczas generowania pary kluczy, określenie nazwanej grupy. Na przykład, jeśli zostanie użyte polecenie keytool -genkeypair -keyalg EC -groupname secp384r1, nastąpi wygenerowanie pary kluczy EC z użyciem krzywej secp384r1. Ponieważ może istnieć kilka krzywych o tym samym rozmiarze, jest preferowane korzystanie z opcji -groupname, zamiast opcji -keysize.
Zob. JDK-8213400
Nowa funkcja: Biblioteka Apache Santuario została zaktualizowana do wersji 2.1.4
Biblioteka Apache Santuario została uaktualniona do wersji 2.1.4. Wskutek tego została wprowadzona nowa właściwość systemowa com.sun.org.apache.xml.internal.security.parser.pool-size.
Ta nowa właściwość systemowa ustawia rozmiar puli wewnętrznej pamięci podręcznej konstruktora DocumentBuilder, używanej podczas przetwarzania podpisów dokumentów XML. Funkcja ta jest równoważna właściwości systemowej org.apache.xml.security.parser.pool-size używanej w Apache Santuario i ma tę samą wartość domyślną równą 20.
Zob. JDK-8231507
Nowa funkcja: Obsługa rozszerzenia „certificate_authorities”
„certificate_authorities” jest opcjonalnym rozszerzeniem wprowadzonym w TLS 1.3. Służy do zasygnalizowania jednostek certyfikujących (CA) obsługiwanych przez punkt końcowy i powinna być używana przez odbiorczy punkt końcowy do kierowania wyborem certyfikatu.
Zob. JDK-8206925
Inne uwagi: Zmieniono metodę Properties.loadFromXML tak, aby była zgodna ze specyfikacją
Implementacja metody java.util.Properties loadFromXML została zmieniona tak, aby była zgodna z jej specyfikacją. W szczególności używana implementacja parsera odrzuca niezgodne dokumenty XML, zgłaszając wyjątek InvalidPropertiesFormatException określony przez metodę loadFromXML.
Zob. JDK-8213325
Inne uwagi: Nazwa „US/Pacific-New” strefy czasowej została usunięta z pakietu tzdata2020b.
W związku z aktualizacją pakietu JDK (do pakietu tzdata2020b) zostały usunięte od dawna zdezaktualizowane pliki pacificnew i systemv. Wskutek tego nazwa „US/Pacific-New” strefy czasowej, deklarowana w pliku pacificnew, nie jest już dostępna do użycia.
Zob. JDK-8254177

Dbanie o aktualność pakietu JDK

Oracle zaleca aktualizowanie pakietu JDK z użyciem każdej krytycznej poprawki aktualizacyjnej (Critical Patch Update — CPU). Chcąc ustalić, czy dane wydanie jest najnowszym, można za pomocą strony „Security Baseline” sprawdzić, która wersja jest najnowsza dla określonej rodziny wydań.

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie Critical Patch Updates, Security Alerts and Bulletins. Nie zaleca się używania tej wersji JRE (wersja 8u281) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 20 kwietnia 2021 r.

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 8u281) w dniu 15 maja 2021 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u281

Java 8 Update 271 (8u271)

Najważniejsze cechy wydania

IANA — dane 2020a
JDK 8u271 zawiera dane IANA, dotyczące stref czasowych, w wersji 2020a. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Słabe nazwane krzywe domyślnie wyłączone w protokole TLS, ścieżkach CertPath i podpisanych archiwach JAR
Słabe nazwane krzywe zostały domyślnie wyłączone przez dodanie ich do następujących właściwości disabledAlgorithms: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms i jdk.jar.disabledAlgorithms. Ponieważ istnieje 47 nazwanych krzywych, które powinny zostać wyłączone, dodawanie poszczególnych nazwanych krzywych do właściwości disabledAlgorithms byłoby czasochłonne. Aby temu zapobiec, została zaimplementowana nowa właściwość zabezpieczeń jdk.disabled.namedCurves, która pomaga wyszczególnić nazwane krzywe wspólne dla wszystkich właściwości disabledAlgorithms. Chcąc użyć tej nowej właściwości we właściwościach disabledAlgorithms, należy poprzedzić pełną nazwę właściwości słowem kluczowym include. Użytkownicy nadal mogą dodawać poszczególne nazwane krzywe do właściwości disabledAlgorithms, niezależnie od tej nowej właściwości. Żadnych innych właściwości nie można zawrzeć we właściwościach disabledAlgorithms.
Zob. JDK-8233228
Nowa funkcja: Obsługa odwołań między dziedzinami Kerberos (RFC 6806)
Klient Kerberos został wzbogacony o obsługę kanonizacji nazw obiektów „principal” i odwołań między dziedzinami, zgodnie z rozszerzeniem protokołu RFC 6806.
Dzięki tej nowej funkcji klient Kerberos może korzystać z bardziej dynamicznych konfiguracji środowiska i nie musi koniecznie wiedzieć z góry, jak dotrzeć do dziedziny docelowego obiektu "principal" (użytkownik lub usługa).
Zob. JDK-8223172
Usunięta funkcja: Wtyczka Java Plugin została usunięta JDK 8u dla platform Linux, Solaris i MacOS
NPAPI jest uważany za wtyczkę podatną na zagrożenia i został wyłączony w wielu przeglądarkach. Żadne przeglądarki nie obsługują obecnie opartej na NPAPI wtyczki Java Plugin na platformach Linux, Solaris i MacOS.
Zaczynając od wydania 8u271, element wtyczki Java Plugin odpowiedzialny za integrację i interakcję z przeglądarką (w szczególności biblioteka libnpjp2) oraz powiązany artefakt nie będą tworzone i nie będą częścią dystrybucji JRE na platformach Linux, Solaris i MacOS.
JDK-8240210 (niepubliczne)
Inne uwagi: dodano właściwość do mechanizmów kontroli identyfikacji LDAP w celu identyfikacji przy użyciu niezabezpieczonych połączeń LDAP
Została dodana nowa właściwość środowiskowa jdk.jndi.ldap.mechsAllowedToSendCredentials pozwalająca kontrolować, które mechanizmy identyfikacji LDAP mogą wysyłać uwierzytelnienia przez połączenia niezabezpieczone przy użyciu protokołu TLS. Szyfrowane połączenie LDAP to połączenie otwarte przy użyciu schematu ldaps lub ldap, a następnie uaktualnione do TLS za pomocą rozszerzonej operacji STARTTLS.
JDK-8237990 (niepubliczne)

Dbanie o aktualność pakietu JDK

Oracle zaleca aktualizowanie pakietu JDK z użyciem każdej krytycznej poprawki aktualizacyjnej (Critical Patch Update — CPU). Chcąc ustalić, czy dane wydanie jest najnowszym, można za pomocą strony "Security Baseline" sprawdzić, która wersja jest najnowsza dla określonej rodziny wydań.

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie Critical Patch Updates, Security Alerts and Bulletins. Nie zaleca się używania tej wersji JRE (wersja 8u271) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 19 stycznia 2021 r.

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 8u271) w dniu 20 lutego 2021 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u271

Java 8 Update 261 (8u261)

Najważniejsze cechy wydania

IANA — dane 2020a
JDK 8u201 zawiera dane IANA, dotyczące stref czasowych, w wersji 2020a. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Zmiana zależności biblioteki (DLL) JDK/JRE Runtime Windows Visual Studio
W ramach bieżącej obsługi do kompilacji pakietów JDK 7 i JDK 8 dla Windows będzie używany łańcuch narzędzi Microsoft Visual Studio 2017. JDK 8u261, z aktualizacji CPU z lipca 2020 roku, został skompilowany za pomocą Visual Studio 2017. Wraz z wydaniem aktualizacji CPU w październiku 2020 roku pakiet JDK 7u281 przejdzie do Visual Studio 2017.
JDK-8246783 (niepubliczne)
Nowa funkcja: JEP 332 Transport Layer Security (TLS) 1.3
JDK 8u261 zawiera implementację specyfikacji Transport Layer Security (TLS) 1.3 (RFC 8446). Więcej szczegółów (w tym lista obsługiwanych funkcji) jest dostępnych w dokumentacji Java Secure Socket Extension (JSSE) Reference Guide i JEP 332.
Zob. JDK-814252
Nowa funkcja: Nowe właściwości systemowe do konfigurowania schematów podpisów TLS
Zostały dodane dwie nowe właściwości systemowe służące do dostosowywania schematów podpisów TLS w pakiecie JDK.
Po stronie klienta dodano jdk.tls.client.SignatureSchemes, a po stronie serwera — jdk.tls.server.SignatureSchemes.
Zob. JDK-8242141
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.enableFFDHE na wartość false.
Zob. JDK-8140436

Dbanie o aktualność pakietu JDK

Oracle zaleca aktualizowanie pakietu JDK z użyciem każdej krytycznej poprawki aktualizacyjnej (Critical Patch Update — CPU). Chcąc ustalić, czy dane wydanie jest najnowszym, można za pomocą strony "Security Baseline" sprawdzić, która wersja jest najnowsza dla określonej rodziny wydań.

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie Critical Patch Updates, Security Alerts and Bulletins. Nie zaleca się używania tej wersji JRE (wersja 8u251) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 13 października 2020 r.

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 8u261) w dniu 13 listopada 2020 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u261

Java 8 Update 251 (8u251)

Najważniejsze cechy wydania

IANA — dane 2019c
JDK 8u251 zawiera dane IANA, dotyczące stref czasowych, w wersji 2019c. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Dodano obsługę algorytmów PKCS#1 v2.2, w tym podpisu RSASSA-PSS
Wyposażono dostawców SunRsaSign i SunJCE w mechanizmy obsługi kolejnych algorytmów zdefiniowanych w PKCS#1 v2.2, takich jak podpis RSASSA-PSS oraz OAEP z użyciem algorytmów skrótów FIPS 180-4. Do odpowiednich klas JCA/JCE (w pakietach java.security.spec i javax.crypto.spec) zostały dodane nowe konstruktory i metody w celu zapewnienia obsługi dodatkowych parametrów RSASSA-PSS.
Zob. JDK-8146293
Inne uwagi: WebEngine ogranicza wywołania metod JavaScript dla niektórych klas
Programy JavaScript, które są uruchamiane w kontekście strony internetowej załadowanej przez WebEngine, mogą się komunikować z obiektami Java przekazanymi z aplikacji do programu JavaScript. Programy JavaScript odwołujące się do obiektów java.lang.Class są ograniczane do następujących metod:
getCanonicalName getEnumConstants getFields getMethods getName getPackageName getSimpleName getSuperclass getTypeName getTypeParameters isAssignableFrom isArray isEnum isInstance isInterface isLocalClass isMemberClass isPrimitive isSynthetic toGenericString toString

Żadnych metod nie można wywoływać dla następujących klas:
java.lang.ClassLoader java.lang.Module java.lang.Runtime java.lang.System java.lang.invoke.* java.lang.module.* java.lang.reflect.* java.security.* sun.misc.*

JDK-8236798 (niepubliczne)
Inne uwagi: Nowa wersja JDK 8 specyficzna dla Oracle aktualizuje właściwość systemową, umożliwiając wycofanie do zastanego formatu kodowania Base64
Wersja Oracle JDK 8u231 uaktualniła biblioteki Apache Santuario do wersji v2.1.3. To uaktualnienie stało się przyczyną następującego problemu: dla podpisu XML z użyciem kodowania Base64 jest dołączany do zakodowanego wyniku sufiks &#xd lub &#13. Ta zmiana funkcjonalna została dokonana w kodzie źródłowym (codebase) Apache Santuario w celu zapewnienia zgodności z RFC 2045. Zespół Santuario zobowiązał się do zapewnienia zgodności swoich bibliotek z RFC 2045.
Zob. JDK-8236645

Dbanie o aktualność pakietu JDK

Oracle zaleca aktualizowanie pakietu JDK z użyciem każdej krytycznej poprawki aktualizacyjnej (Critical Patch Update — CPU). Chcąc ustalić, czy dane wydanie jest najnowszym, można za pomocą strony "Security Baseline" sprawdzić, która wersja jest najnowsza dla określonej rodziny wydań.

Krytyczne poprawki aktualizacyjne (CPU — Critical Patch Update) eliminujące luki zabezpieczeń są ogłaszane z rocznym wyprzedzeniem na stronie Critical Patch Updates, Security Alerts and Bulletins. Nie zaleca się używania tej wersji JRE (wersja 8u251) po wydaniu następnej krytycznej poprawki aktualizacyjnej, planowanej na 14 lipca 2020 r.

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 8u251) w dniu 14 sierpnia 2020 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. Więcej informacji jest dostępnych w podrozdziale 23.1.2 JRE Expiration Date w dokumencie Java Platform, Standard Edition Deployment Guide.

Poprawki błędów

» Uwagi do wydania 8u251

Java 8 Update 241 (8u241)

Najważniejsze cechy wydania

IANA — dane 2019c
JDK 8u241 zawiera dane IANA, dotyczące stref czasowych, w wersji 2019c. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Umożliwienie ograniczania działania mechanizmów SASL
Została dodana nowa, związana z zabezpieczeniami, właściwość jdk.sasl.disabledMechanisms, za pomocą której można wyłączać mechanizmy SASL. Każdy wyłączony mechanizm będzie ignorowany, jeśli zostanie określony w argumencie mechanisms metody Sasl.createSaslClient lub w argumencie mechanism metody Sasl.createSaslServer. Wartością domyślną tej właściwości jest wartość pusta, co oznacza, że standardowo nie będą wyłączane żadne mechanizmy.
Zob. JDK-8200400
Nowa funkcja: Uaktualniono dostawcę SunPKCS11 o obsługę PKCS#11 v2.40
Dostawca SunPKCS11 został uaktualniony o obsługę PKCS#11 v2.40. W tej wersji dodano obsługę kolejnych algorytmów, takich jak zestaw szyfrowania AES/GCM/NoPadding, podpisy DSA z użyciem skrótów (digest) komunikatów z rodziny SHA-2 oraz podpisy RSASSA-PSS, gdy odpowiadające mechanizmy PKCS11 są obsługiwane przez używaną bibliotekę PKCS11.
Zob. JDK-8080462
Inne uwagi: Nowe testy certyfikatów głównych kluczy publicznych
Zostały dodane nowe testy sprawdzające, czy główne klucze publiczne są certyfikatami CA i czy zawierają właściwe rozszerzenia. Główne klucze publiczne są używane do weryfikacji łańcuchów certyfikacji, używanych w protokole TLS i podpisanym kodzie. Certyfikaty głównych kluczy publicznych muszą zawierać rozszerzenie „Basic Constraints” z polem cA ustawionym na wartość „true” Ponadto, jeśli zawierają rozszerzenie „Key Usage”, musi być ustawiony bit keyCertSign.
JDK-8230318 (niepubliczne)
Inne uwagi: Wymagana pełna zgodność zaufanego certyfikatu serwera TLS
Certyfikat serwera TLS musi być w pełni zgodny z zaufanym certyfikatem po stronie klienta, aby został uznany za zaufany podczas ustanawiania połączenia TLS.
JDK-8227758 (niepubliczne)
Inne uwagi: Dodano drugi certyfikat LuxTrust poziomu głównego
Certyfikat LuxTrust poziomu głównego został dodany do magazynu „cacerts” zaufanych certyfikatów
Zob. JDK-8232019
Inne uwagi: Dodano 4 certyfikaty Amazon poziomu głównego
4 certyfikaty Amazon poziomu głównego zostały dodane do magazynu „cacerts” zaufanych certyfikatów
Zob. JDK-8232019
Poprawki błędów: Obsługa czcionek OpenType CFF
Poprzednio Oracle JDK 8 nie uwzględniał czcionek OpenType CFF (czcionki .otf) w standardowych czcionkach logicznych (takich jak „Dialog” i „SansSerif”). Skutkiem tego było pomijanie glifów w renderowanych tekstach. W niektórych ekstremalnych przypadkach, gdy w systemie były zainstalowane tylko czcionki CFF, mógł być zgłaszany wyjątek Java.
Problemem tym było dotkniętych kilka dystrybucji Linuksa, ponieważ używały tych czcionek do obsługi niektórych języków, takich jak chiński, japoński i koreański.
Czcionki te są teraz używane w pakiecie Oracle JDK 8 i tym samym problem ten został rozwiązany.
Zob. JDK-8209672
Poprawki błędów: Lepsza obsługa filtra serializacji
Systemową właściwość jdk.serialFilter można ustawić tylko z wiersza polecenia. Jeśli filtr nie został ustawiony z wiersza polecenia, można go ustawić za pomocą metody java.io.ObjectInputFilter.Config.setSerialFilter. Ustawienie jdk.serialFilter bez java.lang.System.setProperty nie ma żadnego skutku.
JDK-8231422 (niepubliczne)

Data ważności oprogramowania Java

Datą ważności wersji 8u241 jest 14 kwietnia 2020 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 8u241) w dniu 14 maja 2020 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

» Uwagi do wydania 8u241

Java 8 Update 231 (8u231)

Najważniejsze cechy wydania

IANA — dane 2019b
JDK 8u231 zawiera dane IANA, dotyczące stref czasowych, w wersji 2019b. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.
Nowa funkcja: Nowa właściwość systemowa jdk.jceks.iterationCount
Wprowadzono nową właściwość systemową kontrolującą liczbę iteracji, używaną dla magazynu kluczy jceks. Wartością domyślną pozostaje 200000, lecz można określać wartości z przedziału od 10000 do 5000000. Nowa właściwość systemowa ma nazwę jdk.jceks.iterationCount a podaną wartością powinna być liczba całkowita z akceptowanego przedziału. Jeśli wystąpi błąd analizy składniowej, zostanie użyta wartość domyślna.
JDK-8223269 (niepubliczne)
Nowa funkcja: Nowe zdarzenia zabezpieczeń JFR (Java Flight Recorder)
Do obszaru biblioteki zabezpieczeń zostały dodane cztery nowe zdarzenia JFR. Zdarzenia te są domyślnie wyłączone i można je włączyć za pomocą plików konfiguracyjnych JFR lub używając standardowych opcji JFR.
Zob. JDK-8148188
Usunięto funkcje i opcje: Usunięto z oprogramowania JavaFX rasteryzator T2K i motor układu ICU
Z oprogramowania JavaFX został usunięty rasteryzator T2K i motor układu ICU.
Zob. JDK-8187147
Inne uwagi: [client-libs i javaFX] W systemach Linux/Unix domyślnym rasteryzatorem jest teraz GTK3
W nowszych wersjach systemów Linux, Solaris i innych uniksowych środowiskach typu Desktop jest używany rasteryzator GTK3, przy jednoczesnej obsłudze GTK2.
Uprzednio JDK domyślnie ładował starsze biblioteki GTK2. W tym wydaniu domyślnie są ładowane biblioteki GTK3. Ładowanie zazwyczaj jest uaktywniane przez moduły Swing GTK Look And Feel.
Można przywrócić starszy sposób funkcjonowania, używając właściwości systemowej -Djdk.gtk.version=2.2
Zob. JDK-8222496
Inne uwagi: Usunięcie przestarzałych krzywe NIST EC z domyślnych algorytmów TLS
Ta zmiana polega na usunięciu krzywych NIST EC z domyślnych nazwanych grup, używanych podczas negocjacji TLS. Usunięte krzywe: sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1 i secp256k1.
Krzywe te można włączyć, używając właściwości systemowej jdk.tls.namedGroups. Zawiera ona ujęto w cudzysłów listę włączonych nazwanych grup rozdzielonych przecinkiem, podanych w preferowanej kolejności. Na przykład:
java -Djdk.tls.namedGroups="secp256r1, secp384r1, secp521r1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1" ...
JDK-8228825 (niepubliczne)

Data ważności oprogramowania Java

Datą wygaśnięcia ważności wersji 8u231 jest 14 stycznia 2020 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 8u231) w dniu 14 lutego 2020 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

» Uwagi do wydania 8u231

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

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

» 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

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

» 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

» 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

» 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 systemową właściwość 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

» 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

» 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

» 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. Właściwość ta zawiera listę wyłączonych algorytmów i rozmiarów kluczy dla plików JAR podpisywanych 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 filename.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 jds<number>.tmp in the %TEMP%.
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

» 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:

hotspot/jvm/os/processor/cpu_load
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

» 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

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

» Uwagi do wydania 8u91

Java 8 Update 77 (8u77)

Najważniejsze cechy wydania

Dane IANA 2016a
JDK 8u77 zawiera dane stref czasowych IANA w wersji 2016a. Więcej informacji jest dostępnych na stronie Timezone Data Versions in the JRE Software.

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

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.

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:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883097
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
- Dołączyć DumpJFR do podstawowego pliku:
  
  The embedded asset does not exist:
  Asset Type: jWidget_C
  Asset Id: 1371164883117
  PAGENAME: JCOM/jWidget_C/Raw_HTML/Display
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 poprzedniej 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 mapowania, 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ć:
The embedded asset does not exist:
Asset Type: jWidget_C
Asset Id: 1385352043373
PAGENAME: JCOM/jWidget_C/Raw_HTML/Display

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=See 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:
- Argumenty wiersza polecenia mogą być przekazywane do aplikacji samoistnych (self-contained). Argumenty domyślne są definiowane, gdy jest tworzony pakiet, i mogą być przesłaniane przez użytkownika w chwili uruchamiania aplikacji.
- Podczas instalowania aplikacji samoistnej (self-contained) można skonfigurować skojarzenia plików, tak aby system operacyjny automatycznie uruchamiał aplikację dla zarejestrowanych rozszerzeń plików lub typów MIME.
- UserJvmOptionsService API jest dostępny do modyfikacji opcji JVM w aplikacjach samoistnych (self-contained). Nowe ustawienia będą używane przy następnym uruchomieniu aplikacji.
- Jest obsługiwanych wiele punktów wejściowych dla aplikacji samoistnych (self-contained), dzięki czemu w jednym pakiecie aplikacji można zawrzeć zestaw produktów.
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 identyfikowaniu 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 użycia 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 użycie 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ć użycie pamięci przez siebie. Jest to realizowane głównie przez zmniejszenie sterty Java. Działania, które JDK podejmie w celu zmniejszenia użycia 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

Wydanie Java 8

» Uwagi do wydania JDK i JRE 8