{"id":10029,"date":"2021-12-21T16:02:11","date_gmt":"2021-12-21T15:02:11","guid":{"rendered":"https:\/\/vived.io\/jvm-tuesday-vol-69-co-przyniesie-java-18\/"},"modified":"2022-09-19T13:10:44","modified_gmt":"2022-09-19T11:10:44","slug":"jvm-tuesday-vol-69-co-przyniesie-java-18","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/jvm-tuesday-vol-69-co-przyniesie-java-18\/","title":{"rendered":"JVM Tuesday vol. 69 – Co przyniesie Java 18?"},"content":{"rendered":"\n

JDK 18 znalaz\u0142a si\u0119 pocz\u0105tkiem grudnia w fazie \u201cRampdown\u201d. Jest to javowa nomenklatura na popularny w wielu projektach przedwdro\u017ceniowy \u201cfeature freeze\u201d – w JDK nie pojawi\u0105 si\u0119 ju\u017c \u017cadne zaskakuj\u0105ce zmiany, tw\u00f3rcy skupi\u0105 si\u0119 obecnie wy\u0142\u0105cznie na poprawie bug\u00f3w. Dla nas oznacza to za\u015b ostateczn\u0105 list\u0119 wszystkich featur\u00f3w, kt\u00f3re do JDK trafi\u0105. Dlatego te\u017c dzisiaj, troch\u0119 nietypowo, znowu edycja specjalna – kompiluj\u0105ca wszystko, co trafi do nas wraz z JDK 18.<\/p>\n\n\n\n

Nowe funkcjonalno\u015bci<\/h2>\n\n\n\n
\"\"<\/figure>\n\n\n\n

408: Simple Web Server<\/a><\/p>\n\n\n\n

413: Code Snippets in Java API Documentation<\/a><\/p>\n\n\n\n

Zacznijmy od nowo\u015bci, kt\u00f3re maj\u0105 najwi\u0119ksze prawdopodobie\u0144stwo bycia u\u017cytymi przez \u201cprzemys\u0142owego\u201d programist\u0119. Je\u017celi w tej sekcji spodziewali\u015bcie si\u0119 jednak jakiego\u015b nowego syntaxu j\u0119zyka mo\u017cecie si\u0119 nieco rozczarowa\u0107. Nowo\u015bci dostarczane z now\u0105 edycj\u0105 Javy s\u0105 mocno hmmm\u2026 specjalistyczne.<\/p>\n\n\n\n

Specjalistyczne, bo raczej nie spodziewam si\u0119, \u017ce zapowied\u017a wbudowania w Jav\u0119 minimalistycznego Web Server wywr\u00f3ci spos\u00f3b w jaki programujemy. Narz\u0119dzie ma by\u0107 przydatne do tworzenia prototyp\u00f3w, i ad hocowego kodowania oraz testowania, zw\u0142aszcza w kontek\u015bcie edukacyjnym – i o ile rozumiem w jaki\u015b spos\u00f3b jego wprowadzenie, to naprawd\u0119 nie potrafi\u0119 si\u0119 nim jako\u015b \u201cjara\u0107\u201d.<\/p>\n\n\n\n

Narz\u0119dzie uruchamiane ma by\u0107 z wiersza polecenia i potrafi\u0107 serwowa\u0107 statyczne pliki w bie\u017c\u0105cym katalogu komend\u0105 java -m jdk.httpserver<\/em>. <\/em>Wersja CLI posiada\u0107 b\u0119dzie podstawowe opcje konfiguracyjne, jak wyb\u00f3r portu czy adresu do zbindowania. Dla tych, kt\u00f3rzy chc\u0105 troch\u0119 bardziej pokonfigurowa\u0107 swoje rozwi\u0105zanie, dost\u0119pna b\u0119dzie te\u017c mo\u017cliwo\u015b\u0107 odpalenia ca\u0142o\u015bci z poziomu kodu javowego.<\/p>\n\n\n\n

Druga zmiana jest ciekawsza, aczkolwiek znaj\u0105c mi\u0142o\u015b\u0107 bran\u017cy do pisania dokumentacji, ponownie dotknie tylko wybranych programist\u00f3w JEP 413 wprowadza znacznik @snippet do JavaDoc, co ma na celu upro\u015bci\u0107 do\u0142\u0105czanie przyk\u0142adowego kodu \u017ar\u00f3d\u0142owego do dokumentacji API.<\/p>\n\n\n\n

Do tej pory dokumentacja nie posiada\u0142a specjalnego tagu pozwalaj\u0105cego programistom przekaza\u0107 przyk\u0142adowe u\u017cycia API. Teraz to si\u0119 zmieni. Co ciekawe, tw\u00f3rcy API zapewnili u\u017cytkownikom dwa r\u00f3\u017cne warianty. Przyk\u0142ady b\u0119dzie mo\u017cna przekaza\u0107 \u201cinline\u201d:<\/p>\n\n\n\n

\/**\n * The following code shows how to use {@code Optional.isPresent}:\n * {@snippet :\n * if (v.isPresent()) {\n *     System.out.println("v: " + v.get());\n * }\n * }\n *\/<\/code><\/pre>\n\n\n\n
Ale r\u00f3wnie\u017c jako zewn\u0119trzny plik:<\/p>\n\n\n\n
\/**\n * The following code shows how to use {@code Optional.isPresent}:\n * {@snippet file="ShowOptional.java" region="example"}\n *\/\n---------------------------\npublic class ShowOptional {\n    void show(Optional<String> v) {\n        \/\/ @start region="example"\n        if (v.isPresent()) {\n            System.out.println("v: " + v.get());\n        }\n        \/\/ @end\n    }\n}\n<\/code><\/pre>\n\n\n\n
Zmiany pod mask\u0105<\/h2>\n\n\n\n
\"\"<\/figure><\/div>\n\n\n\n
416: Reimplement Core Reflection with Method Handles<\/a><\/p>\n\n\n\n
400: UTF-8 by Default<\/a><\/p>\n\n\n\n
418: Internet-Address Resolution SPI<\/a><\/p>\n\n\n\n
Je\u017celi chodzi o dodatki z kategorii #nikogo, JEP 416 \u2013 Reimplement Core Reflection with Method Handles zdecydowanie nale\u017cy do moich ulubionych. JEP ten przynosi bowiem unifikacje sposobu, w jaki dzia\u0142a refleksja w Javie. W jego ramach dochodzi do reimplementacji java.lang.reflect.Method, java.lang.reflect.Constructor<\/em>, i java.lang.reflect.Field<\/em> na mechanizm invoke, wprowadzony w JDK 1.7. Jest to rodzaj sp\u0142aty d\u0142ugu technicznego przez zesp\u00f3\u0142 pracuj\u0105cy nad j\u0119zykiem i maszyn\u0105 wirtualn\u0105, jako u\u017cytkownicy nie zauwa\u017cymy wi\u0119c jakich\u015b znacz\u0105cych zmian. JEP 416 jest jednak w zasadzie niezb\u0119dny do wprowadznia zmian w architekt\u00f3rze JVMa, kt\u00f3re przyjd\u0105 wraz z projektem Loom i Valhalla.<\/p>\n\n\n\n
Nast\u0119pnym jest JEP o bardzo \u0142adnym, okr\u0105g\u0142ym numerze 400, kt\u00f3ry wprowadza wreszcie UTF-8 do Javy domy\u015blny spos\u00f3b kodowania znak\u00f3w. Cho\u0107 historycznie by\u0142o z tym r\u00f3\u017cnie obecnie \u017cyjemy w \u015bwiecie  w kt\u00f3rym enkodowanie znak\u00f3w wydaje si\u0119 by\u0107 rozwi\u0105zanym problemem. Globalizacja (i po cz\u0119\u015bci te\u017c rozw\u00f3j hardware) sprawi\u0142y, \u017ce zamiast wielu lokalnych standard\u00f3w mamy obecnie jeden \u2013 Unicode Transformation Format, czyli popularny UTF, potrafi\u0105cy reprezentowa\u0107 znaki z wszystkich j\u0119zyk\u00f3w i dialekt\u00f3w, a dodatkowo wiele wi\u0119cej, jak kochane przez wszystkich emoji. W zwi\u0105zku z faktem, \u017ce wiele j\u0119zyk\u00f3w programowania postanowi\u0142o ju\u017c dawno uczyni\u0107 go rozwi\u0105zaniem domy\u015blnym, na podobny krok zdecydowa\u0142a si\u0119 r\u00f3wnie\u017c Java. <\/p>\n\n\n\n
O ile dla sta\u0142ych czytelnik\u00f3w wi\u0119kszo\u015b\u0107 z powy\u017cszych opisywanych zmian nie b\u0119dzie niczym nowym, tak jako ostatni przedstawimy Wam JEP, kt\u00f3ry umkn\u0105\u0142 naszej uwadze, a jest do\u015b\u0107 ciekawy. java.net.INetAddress to API s\u0142u\u017c\u0105ce do rozwi\u0105zywania nazwy host\u00f3w na adresy IP (i odwrotnie). Interfejs API obecnie korzysta z natywnego rozwi\u0105zywania DNS\u00f3w dostarczanego przez systemy operacyjne. Takowe w wi\u0119kszo\u015bci przypadk\u00f3w operuje na lokalnym pliku hosts i zewn\u0119trznych DNS-ach. S\u0105 to rozwi\u0105zania synchroniczne, w zwi\u0105zku z tym na potrzeby prac nad projektem Loom musza pojawi\u0107 si\u0119 w JVMie alternatywy. Dlatego te\u017c w ramach prac nad JEP-418 interfejs INetAddress ma by\u0107 oddzielony od implementacji, co umo\u017cliwi stworzenie odpowiednich alternatyw dzia\u0142aj\u0105cych w spos\u00f3b nieblokuj\u0105cy<\/p>\n\n\n\n
Lektura nadprogramowa:<\/h3>\n\n\n\n