{"id":18200,"date":"2024-06-07T12:48:20","date_gmt":"2024-06-07T10:48:20","guid":{"rendered":"https:\/\/vived.io\/?p=18200"},"modified":"2024-06-07T12:49:28","modified_gmt":"2024-06-07T10:49:28","slug":"feature-freeze-dla-jdk-23-co-przyniesie-nowa-edycja-jvm-weekly-vol-174","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/feature-freeze-dla-jdk-23-co-przyniesie-nowa-edycja-jvm-weekly-vol-174\/","title":{"rendered":"Feature Freeze dla JDK 23: Co przyniesie nowa edycja? – JVM Weekly vol. 174"},"content":{"rendered":"\n

Stable<\/h2>\n\n\n\n

467: Markdown Documentation Comments<\/a><\/h3>\n\n\n\n
\"\"<\/figure>\n\n\n\n

JEP 467<\/a> wprowadza mo\u017cliwo\u015b\u0107 pisania komentarzy dokumentacyjnych JavaDoc za pomoc\u0105 Markdown, opr\u00f3cz dotychczasowego formatu HTML i tag\u00f3w JavaDoc. U\u0142atwia to tworzenie i czytanie dokumentacji umieszczanej bezpo\u015brednio w kodzie \u017ar\u00f3d\u0142owym.<\/p>\n\n\n\n

Jaki jest problem?:<\/strong> Obecne komentarze dokumentacyjne JavaDoc korzystaj\u0105 z HTML i specyficznych tag\u00f3w JavaDoc, co jest trudne do pisania i czytania. HTML ma to do siebie, \u017ce bardzo „zanieczyszcza” tre\u015b\u0107, co zniech\u0119ca programist\u00f3w do tworzenia dobrze sformatowanej dokumentacji. Dodatkowo, tagi do dokumentowania JavaDoc s\u0105 mniej znane i cz\u0119sto wymagaj\u0105 konsultacji z ich w\u0142asn\u0105 dokumentacj\u0105 (co jak na to spojrze\u0107 robi robi si\u0119 nieco meta).<\/p>\n\n\n\n

Solution:<\/strong> JEP 467 wprowadza wsparcie dla Markdown w komentarzach dokumentacyjnych, co umo\u017cliwia bardziej zwi\u0119z\u0142e i czytelne formatowanie dokumentacji. Markdown jest obecnie standardem w\u015br\u00f3d j\u0119zyk\u00f3w znacznik\u00f3w u\u017cywanych przez programist\u00f3w, a na jego popularyzacje wp\u0142yn\u0105\u0142 min. GitHub, wi\u0119c sk\u0142adnia po prostu jest szeroko u\u017cywana i znana (ciekawostka – wszystkie edycje JVM Weekly powstaj\u0105 oryginalnie w\u0142a\u015bnie w Markdownie). Dzi\u0119ki temu programi\u015bci mog\u0105 pisa\u0107 dokumentacj\u0119 szybciej i z mniejszym wysi\u0142kiem, nadal maj\u0105c mo\u017cliwo\u015b\u0107 korzystania z HTML i tag\u00f3w JavaDoc tam, gdzie jest to konieczne (dodatkowo – wiele popularnych parser\u00f3w Markdown jest kompatybilnych ze wstawkami z HTML).<\/p>\n\n\n\n

Przyk\u0142ad kodu:<\/h4>\n\n\n\n

Tradycyjny komentarz JavaDoc:<\/p>\n\n\n\n

\/**\n * Returns a <b>hash code<\/b> value for the object.\n * <p>\n * The general contract of {@code hashCode} is:\n * <ul>\n * <li>Must consistently return the same integer for the same object,\n *     provided no information used in {@code equals} comparisons is modified.\n * <li>If two objects are equal according to the {@link #equals(Object)} method,\n *     calling {@code hashCode} on each must produce the same result.\n * <li>It is not required that unequal objects produce distinct integers,\n *     but this improves the performance of hash tables.\n * <\/ul>\n *\n * @implSpec\n * The {@code hashCode} method defined by class {@code Object} returns distinct\n * integers for distinct objects as far as is practical.\n *\n * @return  a hash code value for this object.\n * @see     java.lang.Object#equals(java.lang.Object)\n * @see     java.lang.System#identityHashCode\n *\/\n<\/code><\/pre>\n\n\n\n
Ten sam komentarz Markdown:<\/p>\n\n\n\n
\/\/\/ Returns a **hash code** value for the object.\n\/\/\/ \n\/\/\/ The general contract of `hashCode` is:\n\/\/\/\n\/\/\/ - Must consistently return the same integer for the same object,\n\/\/\/   provided no information used in `equals` comparisons is modified.\n\/\/\/ - If two objects are equal according to the [equals][#equals(Object)] method,\n\/\/\/   calling `hashCode` on each must produce the same result.\n\/\/\/ - It is not required that unequal objects produce distinct integers,\n\/\/\/   but this improves the performance of hash tables.\n\/\/\/\n\/\/\/ @implSpec\n\/\/\/ The `hashCode` method defined by class `Object` returns distinct\n\/\/\/ integers for distinct objects as far as is practical.\n\/\/\/\n\/\/\/ @return  a hash code value for this object.\n\/\/\/ @see     java.lang.Object#equals(java.lang.Object)\n\/\/\/ @see     java.lang.System#identityHashCode\n<\/code><\/pre>\n\n\n\n
471: Deprecate the Memory-Access Methods in sun.misc.Unsafe for Removal<\/a><\/h3>\n\n\n\n
\"\"<\/figure>\n\n\n\n
JEP 471 ma na celu deprekacj\u0119 metod dost\u0119pu do pami\u0119ci w klasie sun.misc.Unsafe<\/code> z zamiarem ich usuni\u0119cia w przysz\u0142ych wydaniach JDK. Propozycja ta ma na celu zach\u0119cenie programist\u00f3w do migracji na obs\u0142ugiwane zamienniki, aby aplikacje mog\u0142y p\u0142ynnie przechodzi\u0107 na nowsze wersje JDK.<\/p>\n\n\n\n
Jaki jest problem?<\/strong>: Metody dost\u0119pu do pami\u0119ci pochodz\u0105ce z sun.misc.Unsafe<\/code> s\u0105 niebezpieczne i mog\u0105 prowadzi\u0107 do nieokre\u015blonego zachowania, w tym wywalenia si\u0119 ca\u0142ego JVM. Pomimo \u017ce nie by\u0142y one przeznaczone do szerokiego u\u017cycia, sta\u0142y si\u0119 popularne w\u015br\u00f3d programist\u00f3w, kt\u00f3rzy szukali wi\u0119kszej wydajno\u015bci i mocy ni\u017c oferowane przez standardowe API. Brak kontroli bezpiecze\u0144stwa przed ich u\u017cyciem mo\u017ce prowadzi\u0107 do b\u0142\u0119d\u00f3w i awarii aplikacji.<\/p>\n\n\n\n
Solution:<\/strong> JEP 471 wprowadza deprecjacj\u0119 metod dost\u0119pu do pami\u0119ci w sun.misc.Unsafe<\/code>, zach\u0119caj\u0105c programist\u00f3w do przej\u015bcia na bezpieczne i wydajne zamienniki: VarHandle<\/code> (JEP 193<\/a>) i MemorySegment<\/code> (JEP 454<\/a>). Propozycja przewiduje stopniowe usuwanie dost\u0119pu do metod z sun.misc.Unsafe<\/code> w kilku fazach, zaczynaj\u0105c od ostrze\u017ce\u0144 kompilacji, poprzez ostrze\u017cenia w czasie wykonania, a\u017c po faktyczne usuni\u0119cie metod. Dodano nowe opcje wiersza polece\u0144, takie jak --sun-misc-unsafe-memory-access={allow|warn|debug|deny}<\/code>, umo\u017cliwiaj\u0105ce deweloperom granularne testowanie ocen\u0119 wp\u0142ywu deprecjacji metod dost\u0119pu do pami\u0119ci.<\/p>\n\n\n\n
Przyk\u0142ad kodu:<\/h4>\n\n\n\n
Przyk\u0142ad kodu z u\u017cyciem sun.misc.Unsafe<\/code>:<\/strong><\/p>\n\n\n\n
class Foo {\n\n    private static final Unsafe UNSAFE = ...; \n    private static final long X_OFFSET;\n\n    static {\n        try {\n            X_OFFSET = UNSAFE.objectFieldOffset(Foo.class.getDeclaredField("x"));\n        } catch (Exception ex) { throw new AssertionError(ex); }\n    }\n\n    private int x;\n\n    public boolean tryToDoubleAtomically() {\n        int oldValue = x;\n        return UNSAFE.compareAndSwapInt(this, X_OFFSET, oldValue, oldValue * 2);\n    }\n}\n<\/code><\/pre>\n\n\n\n
Przyk\u0142ad kodu z u\u017cyciem VarHandle<\/code>:<\/strong><\/p>\n\n\n\n
class Foo {\n\n    private static final VarHandle X_VH;\n\n    static {\n        try {\n            X_VH = MethodHandles.lookup().findVarHandle(Foo.class, "x", int.class);\n        } catch (Exception ex) { throw new AssertionError(ex); }\n    }\n\n    private int x;\n\n    public boolean tryAtomicallyDoubleX() {\n        int oldValue = x;\n        return X_VH.compareAndSet(this, oldValue, oldValue * 2);\n    }\n}\n<\/code><\/pre>\n\n\n\n
474: ZGC: Generational Mode by Default<\/a><\/h3>\n\n\n\n
\"\"<\/figure>\n\n\n\n
JEP 474 wprowadza zmian\u0119 domy\u015blnego trybu dzia\u0142ania Z Garbage Collector (ZGC) na tryb generacyjny. Dotychczasowy tryb niegeneracyjny zostanie oznaczony jako przestarza\u0142y i planowany do usuni\u0119cia w przysz\u0142ych wydaniach JDK.<\/p>\n\n\n\n
Jaki jest problem?:<\/strong> Utrzymywanie zar\u00f3wno generacyjnego, jak i niegeneracyjnego trybu ZGC spowalnia rozw\u00f3j nowych funkcji. Tryb generacyjny ZGC jest uwa\u017cany za lepsze rozwi\u0105zanie dla wi\u0119kszo\u015bci przypadk\u00f3w u\u017cycia, co czyni tryb niegeneracyjny zb\u0119dnym.<\/p>\n\n\n\n
Jak proposal rozwi\u0105zuje ten problem?:<\/strong> Propozycja zmienia domy\u015bln\u0105 warto\u015b\u0107 opcji ZGenerational<\/code> na true<\/code>, w\u0142\u0105czaj\u0105c tym samym tryb generacyjny ZGC jako domy\u015blny. Po wprowadzeniu tych zmian, uruchomienie JVM z opcj\u0105 -XX:+UseZGC<\/code> b\u0119dzie domy\u015blnie uruchamia\u0142o tryb generacyjny ZGC. Tryb niegeneracyjny zostanie oznaczony jako przestarza\u0142y, a w przysz\u0142o\u015bci planowane jest jego ca\u0142kowite usuni\u0119cie.<\/p>\n\n\n\n
\n\n\n\n
Preview<\/h2>\n\n\n\n
455: Primitive Types in Patterns, instanceof, and switch (Preview)<\/a><\/h3>\n\n\n\n
\"\"<\/figure>\n\n\n\n
JEP 455 wprowadza pattern matching dla typ\u00f3w prymitywnych w instanceof<\/code> i switch<\/code>, umo\u017cliwiaj\u0105c u\u017cycie tych typ\u00f3w w kontekstach zagnie\u017cd\u017conych i na tak zwanym top-level.<\/p>\n\n\n\n
Jaki jest problem?:<\/strong> Obecne ograniczenia dotycz\u0105ce typ\u00f3w prymitywnych w instanceof<\/code> i switch<\/code> powoduj\u0105 trudno\u015bci w pisaniu w oparciu o nie jednolitego i ekspresyjnego kodu. Na przyk\u0142ad, switch<\/code> nie obs\u0142uguje wzorc\u00f3w typu prymitywnego, a instanceof<\/code> nie wspiera bezpiecznego rzutowania na typy prymitywne, co prowadzi do niesp\u00f3jnego, potencjalnie skomplikowanego kodu.<\/p>\n\n\n\n
Solution:<\/strong> JEP 455 umo\u017cliwia u\u017cycie pattern matchingu typ\u00f3w prymitywnych w instanceof<\/code> i switch<\/code>, co pozwala na bezpieczne i ekspresyjne rzutowanie. To eliminuje potrzeb\u0119 r\u0119cznych, potencjalnie niebezpiecznych rzutowa\u0144 oraz umo\u017cliwia bardziej zwi\u0119z\u0142y kod.<\/p>\n\n\n\n
Przyk\u0142ad kodu:<\/h4>\n\n\n\n
switch (x.getStatus()) {\n    case 0 -> "okay";\n    case 1 -> "warning";\n    case 2 -> "error";\n    case int i -> "unknown status: " + i;\n}\n\nif (i instanceof byte b) {\n    ... \/\/ u\u017cyj b\n}\n<\/code><\/pre>\n\n\n\n
466: Class-File API (Second Preview)<\/a><\/h3>\n\n\n\n
\"\"<\/figure>\n\n\n\n
JEP 466 proponuje standardowe API do parsowania, generowania i transformowania plik\u00f3w klas Java. Jest to druga wersja preview API, kt\u00f3ra zosta\u0142a udoskonalona na podstawie do\u015bwiadcze\u0144 i opinii z pierwszej wersji preview wprowadzonej w JEP 457.<\/p>\n\n\n\n
Jaki jest problem?:<\/strong> Obecnie istnieje wiele bibliotek do obs\u0142ugi plik\u00f3w klas Java, jednak ka\u017cda z nich ma swoje wady i zalety. Problemem jest szybka ewolucja formatu plik\u00f3w klas, co powoduje, \u017ce biblioteki te nie zawsze s\u0105 aktualne w stosunku do najnowszych wersji JDK. To prowadzi do problem\u00f3w z kompatybilno\u015bci\u0105 i utrudnia wprowadzanie nowych funkcji w JDK, kt\u00f3re to samo u\u017cywam min. biblioteki ASM.<\/p>\n\n\n\n
Solution<\/strong>: JEP 466 wprowadza standardowe API do obs\u0142ugi plik\u00f3w klas, kt\u00f3re b\u0119dzie ewoluowa\u0107 razem z formatem plik\u00f3w klas. API to zapewnia:<\/p>\n\n\n\n