{"id":16857,"date":"2023-10-11T11:24:13","date_gmt":"2023-10-11T09:24:13","guid":{"rendered":"https:\/\/vived.io\/?p=16857"},"modified":"2023-10-11T11:25:12","modified_gmt":"2023-10-11T09:25:12","slug":"pulumi-infrastructure-as-a-code-w-javie-kotlinie-i-scali-jvm-weekly-151","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/pulumi-infrastructure-as-a-code-w-javie-kotlinie-i-scali-jvm-weekly-151\/","title":{"rendered":"Pulumi: Infrastructure-as-a-Code w Javie, Kotlinie i Scali – JVM Weekly 151"},"content":{"rendered":"\n

1. Pierwszy zestaw nowych JEP-\u00f3w po premierze JDK 21.<\/h2>\n\n\n\n

JEP 455: Primitive types in Patterns, instanceof, and switch (Preview)<\/a><\/h3>\n\n\n\n

Ten JEP jest… zaskakuj\u0105co skomplikowany – ale mog\u0142em si\u0119 tego spodziewa\u0107, przecie\u017c dotyczy to typ\u00f3w prymitywnych, a to zawsze komplikuje. Dlatego pos\u0142u\u017c\u0119 si\u0119 przyk\u0142adem.<\/p>\n\n\n\n

Aktualnie, u\u017cycie wzorc\u00f3w typ\u00f3w prymitywnych w Javie wi\u0105\u017ce si\u0119 z ograniczeniami. Na przyk\u0142ad, chocia\u017c mo\u017cemy modelowa\u0107 dokumenty JSON przy u\u017cyciu rekord\u00f3w (jak w poni\u017cszym kodzie), mamy ograniczenie w zakresie zagnie\u017cd\u017conych wzorc\u00f3w typ\u00f3w prymitywnych:<\/p>\n\n\n\n

if (json instanceof JsonObject(var map)\n    && map.get("age") instanceof JsonNumber(double age))\n{\n    return new Customer(name, (int)age); \n}<\/code><\/pre>\n\n\n\n
W powy\u017cszym fragmencie, chocia\u017c oczekujemy, \u017ce warto\u015b\u0107 „age” b\u0119dzie zawsze int<\/code>, mo\u017cemy jedynie ekstrahowa\u0107 warto\u015b\u0107 double<\/code> i musimy polega\u0107 na manualnej konwersji (cast) do int<\/code>. Problem wynika z tego, jak JSON reprezentuje liczby oraz jak wiele bibliotek do obs\u0142ugi JSON w Javie je potem interpretuje.<\/p>\n\n\n\n
JSON nie rozr\u00f3\u017cnia pomi\u0119dzy r\u00f3\u017cnymi typami liczbowymi. W standardzie JSON wszystkie liczby s\u0105 zapisywane jako liczby zmiennoprzecinkowe. Oznacza to, \u017ce kiedy mamy warto\u015b\u0107 „age”: 25 w dokumencie JSON, ta warto\u015b\u0107 jest interpretowana jako liczba zmiennoprzecinkowa, mimo \u017ce mo\u017ce reprezentowa\u0107 wiek jako warto\u015b\u0107 ca\u0142kowita.<\/p>\n\n\n\n
Gdy Java odczytuje warto\u015b\u0107 z JSON, wiele bibliotek (na przyk\u0142ad javax.json<\/code>, org.json<\/code> itp.) interpretuje wszystkie liczby jako double<\/code>, poniewa\u017c double<\/code> mo\u017ce reprezentowa\u0107 zar\u00f3wno liczby ca\u0142kowite, jak i zmiennoprzecinkowe.<\/p>\n\n\n\n
Dlatego w powy\u017cszym przyk\u0142adzie, kiedy pr\u00f3bujesz dopasowa\u0107 warto\u015b\u0107 „age” do wzorca JsonNumber<\/code>, warto\u015b\u0107 jest dost\u0119pna jako double<\/code> – jest najbardziej og\u00f3lny spos\u00f3b reprezentowania liczb zmiennoprzecinkowych w Javie. Je\u015bli chcesz uzyska\u0107 warto\u015b\u0107 jako int<\/code>, musisz jawnie j\u0105 rzutowa\u0107 (i potencjalnie akceptowa\u0107 ryzyko utraty precyzji w przypadku liczb, kt\u00f3re nie pasuj\u0105 dok\u0142adnie do zakresu int<\/code>).<\/p>\n\n\n\n
Propozycj\u0105 rozwi\u0105zania jest umo\u017cliwienie u\u017cycia wzorc\u00f3w typ\u00f3w pierwotnych w spos\u00f3b bardziej uniwersalny, w taki spos\u00f3b, aby by\u0142y one zgodne z instanceof<\/code> oraz by by\u0142y dopuszczalne w szerszej gamie przypadk\u00f3w. Na przyk\u0142ad, chcieliby\u015bmy u\u017cy\u0107 int<\/code> bezpo\u015brednio w wzorcu JsonNumber<\/code>, tak aby wzorzec pasowa\u0142 tylko wtedy, gdy warto\u015b\u0107 double<\/code> w obiekcie JsonNumber<\/code> mo\u017ce by\u0107 konwertowana na int<\/code> bez utraty informacji:<\/p>\n\n\n\n
if (json instanceof JsonObject(var map)\n    && map.get("name") instanceof JsonString(String name)\n    && map.get("age") instanceof JsonNumber(int age))\n{\n    return new Customer(name, age);         \/\/ bez konwersji!\n}\n<\/code><\/pre>\n\n\n\n
Dzi\u0119ki takiemu podej\u015bciu, mo\u017cna eliminowa\u0107 potrzeb\u0119 obszernych i potencjalnie niebezpiecznych konwersji.<\/p>\n\n\n\n
To tylko jeden przyk\u0142ad, w JEP-ie znajdziecie tego znaczenie wi\u0119cej.<\/p>\n\n\n\n
JEP 458: Launch Multi-File Source-Code Programs<\/a><\/h3>\n\n\n\n
Nast\u0119pny JEP to kolejne ju\u017c po u\u0142atwienie tworzenia prostych, bazowych aplikacji. Nie wiem, czy kt\u00f3rykolwiek komercyjny programista jeszcze to pami\u0119ta, ale launcher aplikacji Java (czyli java<\/code>) od JDK umo\u017cliwia odpalanie nie skompilowanych plik\u00f3w .java<\/code>. Dlaczego jest to w zasadzie nieu\u017cywana metoda? Wynika to z faktu, \u017ce do tej pory nale\u017ca\u0142o ograniczy\u0107 si\u0119 przy jej u\u017cyciu do jednego pliku. A przecie\u017c ka\u017cdy dojrza\u0142y programista Javy wie, \u017ce w jednej klasie to w zasadzie co najwy\u017cej da si\u0119 wzorzec strukturalny zainicjowa\u0107, a nie napisa\u0107 co\u015b cokolwiek realnie u\u017cytecznego.<\/p>\n\n\n
\n
\"\"
Troch\u0119 \u015bmieszkuje, ale musz\u0119 przyzna\u0107 \u017ce nawet ja przeprosi\u0142em si\u0119 do skryptowania z Pythonem.<\/figcaption><\/figure><\/div>\n\n\n
Teraz zostanie rozbudowany, aby m\u00f3g\u0142 uruchamia\u0107 te\u017c programy dostarczane jako wiele plik\u00f3w \u017ar\u00f3d\u0142owych Java, automatycznie kompiluj\u0105c zale\u017cno\u015bci, je\u015bli tylko zachowuj\u0105 standardow\u0105 struktur\u0119 pakiet\u00f3w. Je\u015bli klasa w jednym pliku \u017ar\u00f3d\u0142owym odwo\u0142uje si\u0119 do klasy w innym pliku, launcher automatycznie znajduje i kompiluje ten drugi plik. Mo\u017cliwe jest r\u00f3wnie\u017c korzystanie z wcze\u015bniej skompilowanych klas. Przej\u015bcie z pojedynczego pliku .java<\/code> do wielu plik\u00f3w wymaga od programist\u00f3w i ucz\u0105cych si\u0119 Javy bardziej skomplikowanych krok\u00f3w, takich jak korzystanie z javac<\/code>, tak\u017ce mamy kolejny uk\u0142on w stron\u0119 nowicjuszy, jak w przypadku JEP 445: Unnamed Classes and Instance Main Methods (Preview)<\/strong><\/a><\/p>\n\n\n\n
JEP 457: Class-File API (Preview)<\/a><\/h3>\n\n\n\n
\u017beby wyt\u0142umaczy\u0107, o co chodzi w tym JEP-ie, musz\u0119 najpierw opowiedzie\u0107 o ASM. ASM to biblioteka w Javie przeznaczona do dynamicznej manipulacji i tworzenia bytecodu. Daje mo\u017cliwo\u015b\u0107 niskopoziomowej analizy, tworzenia oraz modyfikacji istniej\u0105cych klas. Wielu tw\u00f3rc\u00f3w wykorzystuje ASM do dodawania funkcjonalno\u015bci do klas, takich jak logowanie czy monitorowanie, jak r\u00f3wnie\u017c do tworzenia nowego kodu opartego na specyfikacji bytecodu. Przyk\u0142ady bibliotek korzystaj\u0105cych z ASM to AspectJ, Kryo, FindBugs czy JaCoCo, stanowi on te\u017c baz\u0119 dla popularnego (w\u015br\u00f3d tw\u00f3rc\u00f3w narz\u0119dzi) ByteBuddy’ego.<\/p>\n\n\n\n
Co ciekawe, JDK (Java Development Kit) r\u00f3wnie\u017c wykorzystuje ASM w swoim wn\u0119trzu. ASM sta\u0142a si\u0119 kluczow\u0105 bibliotek\u0105 przy implementacji pewnych funkcjonalno\u015bci JDK, takich jak generowanie proxy dla lambd. W praktyce bowiem, cho\u0107 JDK posiada w\u0142asne narz\u0119dzia do manipulacji bytecodem, to w\u0142a\u015bnie ASM przez lata by\u0142a jednym z g\u0142\u00f3wnych narz\u0119dzi wykorzystywanych do takich cel\u00f3w ze wzgl\u0119du na swoj\u0105 wydajno\u015b\u0107 i elastyczno\u015b\u0107. JEP 457 d\u0105\u017cy\u0142 do dostarczenia standardowego JDK do odczytywania, zapisywania i modyfikowania plik\u00f3w klasy Java, co umo\u017cliwi\u0107 ma pozbycie si\u0119 wewn\u0119trznego u\u017cycia ASM w JDK. Inicjatywa ta ma te\u017c na celu zast\u0105pienie istniej\u0105cych wykorzysta\u0144 biblioteki ASM w JDK, co mo\u017ce ostatecznie prowadzi\u0107 do usuni\u0119cia ASM z JDK.<\/p>\n\n\n\n
Temat sta\u0142 si\u0119 szczeg\u00f3lnie kluczowy w ostatnich latach. Pocz\u0105tkowo JVM oraz format plik\u00f3w klas ewoluowa\u0142y stosunkowo wolno, o tyle w ostatnich latach tempo tego rozwoju znacz\u0105co si\u0119 zwi\u0119kszy\u0142o. Przyk\u0142adowo, taka Valhalla co chwile proponuje nowe (cho\u0107 cz\u0119sto kr\u00f3tko \u017cyj\u0105ce) propozycje nowego bajtkody i deskryptory p\u00f3l. Blokowanie rozwoju JVM na konieczno\u015bci aktualizacji zewn\u0119trznych bibliotek, takich jak ASM, staje si\u0119 po prostu w zwi\u0105zku z tym nieutrzymywalne. Posiadanie dedykowanej biblioteki standardowej do modyfikacji klas w JDK, kt\u00f3ra rozwija si\u0119 w parze z JVM, usprawni elastyczno\u015b\u0107 ca\u0142ego procesu. Dodatkowo, nast\u0105pi\u0107 ma konsolidacja wszystkich customowych rozwi\u0105za\u0144, kt\u00f3re w tej chwili znalaz\u0142y swoje miejsce w JDK.<\/p>\n\n\n\n
Wi\u0119cej na temat Class File API znajdziecie w filmiku:<\/p>\n\n\n\n
\n