{"id":101268,"date":"2021-09-15T10:22:53","date_gmt":"2021-09-15T08:22:53","guid":{"rendered":"https:\/\/prohoster.info\/blog\/novosti-interneta\/vypusk-java-se-17"},"modified":"2021-09-15T10:22:53","modified_gmt":"2021-09-15T08:22:53","slug":"vypusk-java-se-17","status":"publish","type":"post","link":"https:\/\/prohoster.info\/pl\/blog\/news\/vypusk-java-se-17","title":{"rendered":"Wydanie Java SE 17","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"
Po sze\u015bciu miesi\u0105cach rozwoju, firma Oracle wyda\u0142a platform\u0119 Java SE 17 (Java Platform, Standard Edition 17), kt\u00f3rej etalonow\u0105 implementacj\u0105 jest otwarty projekt OpenJDK. Z wyj\u0105tkiem usuni\u0119cia niekt\u00f3rych przestarza\u0142ych funkcji, Java SE 17 zachowuje zgodno\u015b\u0107 wsteczn\u0105 z wcze\u015bniejszymi wersjami platformy Java \u2014 wi\u0119kszo\u015b\u0107 wcze\u015bniej napisanych projekt\u00f3w Java b\u0119dzie dzia\u0142a\u0107 bez zmian na nowej wersji. Gotowe do zainstalowania pakiety Java SE 17 (JDK, JRE i Server JRE) s\u0105 dost\u0119pne dla system\u00f3w Linux (x86_64, AArch64), Windows (x86_64) i macOS (x86_64, AArch64). Opracowana w ramach projektu OpenJDK etalonowa implementacja Java 17 jest ca\u0142kowicie otwarta na licencji GPLv2 z wyj\u0105tkami GNU ClassPath, kt\u00f3re zezwalaj\u0105 na dynamiczne powi\u0105zanie z komercyjnymi produktami. <\/p>\n
Java SE 17 nale\u017cy do kategorii wyda\u0144 z d\u0142ugoterminowym wsparciem (LTS), aktualizacje b\u0119d\u0105 wydawane do 2029 roku. Wsparcie dla poprzedniego wydania po\u015bredniego Java 16 zostanie zako\u0144czone. Poprzednia wersja LTS Java 11 b\u0119dzie wspierana do 2026 roku. Nast\u0119pne wydanie LTS zaplanowane jest na wrzesie\u0144 2024 roku. Przypominamy, \u017ce pocz\u0105wszy od wydania Java 10 projekt przeszed\u0142 na nowy proces rozwoju, kt\u00f3ry zak\u0142ada kr\u00f3tszy cykl wydawania nowych wersji. Nowe funkcje s\u0105 teraz rozwijane w jednej stale aktualizowanej ga\u0142\u0119zi master, do kt\u00f3rej dodawane s\u0105 gotowe zmiany, a co sze\u015b\u0107 miesi\u0119cy odga\u0142\u0119ziaj\u0105 si\u0119 ga\u0142\u0119zie do stabilizacji nowych wyda\u0144. <\/p>\n
Zaproponowano eksperymentaln\u0105 implementacj\u0119 dopasowania wzorca w wyra\u017ceniach \u201eswitch\u201d, umo\u017cliwiaj\u0105c\u0105 wykorzystanie w etykietach \u201ecase\u201d nie dok\u0142adnych warto\u015bci, lecz elastycznych wzorc\u00f3w obejmuj\u0105cych od razu szereg warto\u015bci, dla kt\u00f3rych wcze\u015bniej konieczne by\u0142o u\u017cywanie rozbudowanych \u0142a\u0144cuch\u00f3w wyra\u017ce\u0144 \u201eif\u2026else\u201d. Ponadto w obr\u0119bie \u201eswitch\u201d zapewniono mo\u017cliwo\u015bci obs\u0142ugi warto\u015bci NULL. Object o = 123L; String formatted = switch (o) { case Integer i -> String.format(\"int %d\", i); case Long l -> String.format(\"long %d\", l); case Double d -> String.format(\"double %f\", d); case String s -> String.format(\"String %s\", s); default -> o.toString(); };\n
Ustalono stabilizacj\u0119 wsparcia dla klas i interfejs\u00f3w zapiecz\u0119towanych (\u201esealed\u201d), kt\u00f3re nie mog\u0105 by\u0107 u\u017cywane przez inne klasy i interfejsy do dziedziczenia, rozszerzania ani nadpisywania implementacji. Klasy zapiecz\u0119towane oferuj\u0105 r\u00f3wnie\u017c bardziej deklaratywny spos\u00f3b ograniczenia u\u017cycia superklasy ni\u017c modyfikatory dost\u0119pu, oparty na wyra\u017anym wyliczeniu podklas, kt\u00f3re mog\u0105 by\u0107 rozszerzane. package com.example.geometry; public sealed class Shape permits com.example.polar.Circle, com.example.quad.Rectangle, com.example.quad.simple.Square {\u2026}\n
Proponowana jest druga wst\u0119pna implementacja API Vector, kt\u00f3ra dostarcza funkcje dla oblicze\u0144 wektorowych, wykonywanych z wykorzystaniem instrukcji wektorowych procesor\u00f3w x86_64 i AArch64, umo\u017cliwiaj\u0105cych jednoczesne zastosowanie operacji na kilku warto\u015bciach (SIMD). W przeciwie\u0144stwie do mo\u017cliwo\u015bci automatycznej wektoryzacji operacji skalarowych dost\u0119pnych w kompilatorze JIT HotSpot, nowe API umo\u017cliwia wyra\u017ane zarz\u0105dzanie wektoryzacj\u0105 dla r\u00f3wnoleg\u0142ego przetwarzania danych.\n
Dodano wst\u0119pne wdro\u017cenie API Foreign Function & Memory, dzi\u0119ki kt\u00f3remu aplikacje mog\u0105 komunikowa\u0107 si\u0119 z kodem i danymi znajduj\u0105cymi si\u0119 poza Java runtime. Nowe API umo\u017cliwia efektywne wywo\u0142ywanie funkcji wykonywanych poza JVM oraz dost\u0119p do pami\u0119ci, kt\u00f3ra nie jest zarz\u0105dzana przez JVM. Na przyk\u0142ad, mo\u017cna wywo\u0142ywa\u0107 funkcje z zewn\u0119trznych bibliotek wsp\u00f3\u0142dzielonych i uzyskiwa\u0107 dost\u0119p do danych procesu bez u\u017cywania JNI.\n
Silnik renderuj\u0105cy dla macOS, zapewniaj\u0105cy obs\u0142ug\u0119 API Java 2D, kt\u00f3re z kolei jest wykorzystywane w API Swing, dostosowano do u\u017cycia z graficznym API Metal. Domy\u015blnie na platformie macOS nadal u\u017cywane jest OpenGL, a aby w\u0142\u0105czy\u0107 obs\u0142ug\u0119 Metal, nale\u017cy ustawi\u0107 parametr \u2018-Dsun.java2d.metal=true\u2019 oraz mie\u0107 co najmniej wersj\u0119 macOS 10.14.x.\n
Dodano port dla platformy macOS\/AArch64 (komputery Apple z nowymi chipami Apple M1). Cech\u0105 portu jest wsparcie mechanizmu ochrony pami\u0119ci W^X (Write XOR Execute), w kt\u00f3rym strony pami\u0119ci nie mog\u0105 by\u0107 jednocze\u015bnie dost\u0119pne do zapisu i wykonania. (kod mo\u017ce by\u0107 wykonany tylko po zablokowaniu zapisu, a zapis do strony pami\u0119ci mo\u017cliwy jest tylko po zablokowaniu wykonania).\n
Przywr\u00f3cono stosowanie wy\u0142\u0105cznie \u015bcis\u0142ej (strictfp) semantyki dla wyra\u017ce\u0144 z zmienn\u0105 przecinkow\u0105. Zaprzestano wsparcia dla semantyki \u2018default\u2019, dost\u0119pnej od wersji Java 1.2, kt\u00f3ra obejmowa\u0142a uproszczenia dla system\u00f3w z bardzo starymi wsp\u00f3\u0142procesorami matematycznymi x87 (po wprowadzeniu instrukcji SSE2 potrzeba dodatkowej semantyki znikn\u0119\u0142a).\n
Zrealizowane zosta\u0142y nowe typy interfejs\u00f3w do generator\u00f3w liczb pseudolosowych, a tak\u017ce wprowadzono dodatkowe algorytmy dla lepszej generacji liczb losowych. Aplikacje otrzyma\u0142y mo\u017cliwo\u015b\u0107 wyboru algorytmu generowania liczb pseudolosowych. Ulepszono wsparcie dla generacji strumieni losowych obiekt\u00f3w.\n
Wprowadzono obowi\u0105zkow\u0105 \u015bcis\u0142\u0105 inkapsulacj\u0119 wszystkich wewn\u0119trznych element\u00f3w JDK, z wyj\u0105tkiem krytycznych API, takich jak sun.misc.Unsafe. \u015acis\u0142a inkapsulacja blokuje pr\u00f3by dost\u0119pu z kodu do wewn\u0119trznych klas, metod i p\u00f3l. Wcze\u015bniej tryb \u015bcis\u0142ej inkapsulacji mo\u017cna by\u0142o wy\u0142\u0105czy\u0107 za pomoc\u0105 opcji \u2018\u2014illegal-access=permit\u2019, ale teraz zosta\u0142a og\u0142oszona przestarza\u0142\u0105. Dla aplikacji, kt\u00f3re potrzebuj\u0105 dost\u0119pu do wewn\u0119trznych klas, metod i p\u00f3l, nale\u017cy wyra\u017anie okre\u015bli\u0107 je za pomoc\u0105 opcji \u2018\u2014add-opens\u2019 lub atrybutu Add-Opens w pliku manifestu.\n