{"id":11209,"date":"2022-10-12T10:56:20","date_gmt":"2022-10-12T08:56:20","guid":{"rendered":"https:\/\/vived.io\/?p=11209"},"modified":"2022-10-12T15:49:52","modified_gmt":"2022-10-12T13:49:52","slug":"wysyp-nowych-jepow-templating-kolekcje-project-liliput-i-inne-jvm-weekly-108","status":"publish","type":"post","link":"https:\/\/vived.io\/pl\/wysyp-nowych-jepow-templating-kolekcje-project-liliput-i-inne-jvm-weekly-108\/","title":{"rendered":"Wysyp nowych JEP\u00f3w: Templating, kolekcje, Project Liliput i inne – JVM Weekly 108"},"content":{"rendered":"\n

1. Wysyp nowych JEP\u00f3w – Spring Templating, kolekcje, Project Liliput i inne<\/h2>\n\n\n\n

Jeste\u015bmy do\u015b\u0107 \u015bwie\u017co po premierze nowego JDK, dlatego te\u017c do\u015b\u0107 klasycznie wchodzimy w okres wi\u0119kszego dynamizmu publikacji nowych JEP-\u00f3w. W ostatnich tygodniach pojawi\u0142o si\u0119 par\u0119 ciekawych, kt\u00f3rym teraz si\u0119 przygl\u0105dniemy.<\/p>\n\n\n\n

\n\n\n\n

Nieca\u0142y miesi\u0105c temu opowiada\u0142em o wymianach mailowych dotycz\u0105cych projektu Amber<\/a>, a ju\u017c jeste\u015bmy w stanie zobaczy\u0107 ich pierwsze efekty. Ot\u00f3\u017c zar\u00f3wno nienazwane lokalne zmienne<\/a>, jak i Pattern Matching dla Rekord\u00f3w<\/a> doczeka\u0142y si\u0119 swoich w\u0142asnych JEP-\u00f3w w formie Draft. W por\u00f3wnaniu do wcze\u015bniejszych, nieco chaotycznych z perspektywy zewn\u0119trznego czytelnika dyskusji mailingowych, zainteresowani s\u0105 w stanie teraz zapozna\u0107 si\u0119 z bardziej wykrystalizowan\u0105, skondensowan\u0105 propozycj\u0105. <\/p>\n\n\n\n

\n\n\n\n

Kandydackich JEP-\u00f3w, kt\u00f3ry tym razem mo\u017ce zainteresowa\u0107 szerok\u0105 publik\u0119 jest JEP 431: Sequenced Collections<\/strong><\/a>. Jak sama nazwa wskazuje, jest to propozycja wsp\u00f3lnego interfejsu dla kolekcji zachowuj\u0105cych kolejno\u015b\u0107 znajduj\u0105cych si\u0119 w nich element\u00f3w. Ch\u0119\u0107 wsp\u00f3lnej abstrakcji wynika z tego, \u017ce w tym momencie w zasadzie ka\u017cda ze znajduj\u0105cych si\u0119 w JDK kolekcji zachowuje si\u0119 w tej materii nieco inaczej. Nowy interfejs ma zapewni\u0107 ustandaryzowany spos\u00f3b wybierania pierwszego i ostatniego elementu kolekcji.<\/p>\n\n\n\n

void addFirst(E)\nvoid addLast(E)\nE getFirst()\nE getLast()\nE removeFirst()\nE removeLast()<\/code><\/pre>\n\n\n\n
Rozbudowane maj\u0105 by\u0107 te\u017c interfejsy poszczeg\u00f3lnych kolekcji, a ka\u017cda z powy\u017cszych metod doczeka\u0107 ma si\u0119 defaultowej implementacji. Jest to wi\u0119c kolejny przyk\u0142ad, jak wprowadzone jeszcze w JDK 8 mechanizmy u\u0142atwiaj\u0105 ewolucj\u0119 API biblioteki standardowej<\/p>\n\n\n\n
Kocham fakt, \u017ce w summary ca\u0142o\u015bci znalaz\u0142 si\u0119 cytat z Kierkegaard  <\/p>\n\n\n\n
„Life can only be understood backwards; but it must be lived forwards.” <\/p><\/blockquote>\n\n\n\n
Stuart Marks, tw\u00f3rca JEP-a musi mie\u0107 zaci\u0105gi do filozofii \ud83d\ude09 A \u017ce te\u017c uwielbiam du\u0144czyka, to te\u017c mi si\u0119 zrobi\u0142o od razu ch\u0142odno na serduszku.<\/p>\n\n\n
\n
\"\"
Inny cytat mistrza<\/figcaption><\/figure><\/div>\n\n\n
\n\n\n\n
Kolejnym JEP-em, nad kt\u00f3rym trwaj\u0105 obecnie intensywne prace jest JEP 430: String Templates (Preview)<\/a><\/strong>. Zaskakuj\u0105ce jest, jak do\u015b\u0107 p\u00f3\u017ano w swoim cyklu \u017cycia (j\u0119zyk ma w ko\u0144cu ju\u017c troch\u0119 lat na karku) tw\u00f3rcy Javy zdecydowali si\u0119 zabra\u0107 za u\u0142atwienie programistom pracy z d\u0142u\u017cszymi fragmentami tekstu, czyli na funkcjonalno\u015b\u0107 istniej\u0105c\u0105 w zasadzie w chyba ka\u017cdym innym j\u0119zyku JVM-owym. Po d\u0142ugich latach dopieszczania blok\u00f3w tekstu, kolejnym krokiem jest ich udynamicznienie. Tw\u00f3rcy proponuj\u0105 nast\u0119puj\u0105cy syntax:<\/p>\n\n\n\n
String name = "Joan";\nString info = STR."My name is \\{name}";\nassert info.equals("My name is Joan");   \/\/ true<\/code><\/pre>\n\n\n\n
W kt\u00f3rym STR to tak zwany template processor<\/code>, automatycznie importowany do ka\u017cdego pliku Javowego .<\/p>\n\n\n\n
Bardzo polecam lektur\u0119 oryginalnego JEP-a. W \u015brodku znajdziecie bowiem do\u015b\u0107 gruntowne por\u00f3wnanie syntax’u templatingu (i \u0142\u0105cz\u0105cej si\u0119 z nim interpolacji) w innych j\u0119zyk\u00f3w, a tak\u017ce sensownie wy\u0142o\u017cone argumenty za i przeciw poszczeg\u00f3lnymi podej\u015bciami. Na szali po\u0142o\u017cone zostaj\u0105 r\u00f3wnie\u017c rozwi\u0105zania ju\u017c w JDK istniej\u0105ce. Og\u00f3lnie ca\u0142o\u015b\u0107 jest dla mnie kolejnym przyk\u0142adem tego, jak „oczywiste” na pierwszy rzut oka rozwi\u0105zania wcale nie s\u0105 takie oczywiste. I to w\u0142a\u015bnie zwykle ta lekcja stanowi dla mnie o warto\u015bci lektury JEP-\u00f3w.<\/p>\n\n\n\n
\n\n\n\n
A na koniec – Project Liliput, o kt\u00f3rym by\u0142o cicho jako\u015b od maja i wczoraj rano wzi\u0105\u0142 mnie z zaskoczenia nowym JEP-em: 64 bit object headers<\/a><\/strong>. celem Liliputa jest zmniejszenie rozmiaru nag\u0142\u00f3wk\u00f3w obiekt\u00f3w Java w maszynie JVM Hotspot ze 128 bit\u00f3w do 64 bit\u00f3w lub mniej. W tej chwili bowiem ka\u017cdy obiekt, niezale\u017cnie czy ma\u0142y, czy du\u017cy, posiada sta\u0142y narzut w teorii 128-bit\u00f3w, a w praktyce (przy w\u0142\u0105czonej kompresji nag\u0142\u00f3wk\u00f3w) 96-bit\u00f3w. W ramach tej przestrzeni znajduj\u0105 si\u0119 wska\u017aniki do obiektu, jego hashcode, dane zwi\u0105zane z Garbage Collectorami czy te\u017c lockami. 128-bit\u00f3w nie wydaje si\u0119 du\u017cym narzutem pami\u0119ci, nale\u017cy jednak pami\u0119ta\u0107, \u017ce m\u00f3wimy tutaj o nag\u0142\u00f3wku, kt\u00f3ry dok\u0142adany jest do ka\u017cdego jednego obiektu. W wielu zastosowaniach np. Gdy tworzone jest wiele malutkich obiekt\u00f3w (tw\u00f3rcy powo\u0142uj\u0105 si\u0119 np. na machin\u0119 learning), ten narzut staje si\u0119 bardzo istotny, st\u0105d prace nad Liliputem. Tw\u00f3rcom uda\u0142o si\u0119 w tej chwili uzyska\u0107 64-bitowe nag\u0142\u00f3wki, kosztem zmniejszenia mo\u017cliwego poziomu skomplikowania hashcodu i kilku innych optymalizacji. Wspomniany JEP zawiera szczeg\u00f3\u0142y, kt\u00f3re dok\u0142adnie fragmenty uleg\u0142y redukcji i jakie implikacje zmiany mog\u0105 mie\u0107 dla przysz\u0142ego rozwoju min. Valhalli.<\/p>\n\n\n
\n
\"\"
Bo grzebanie w internalach JVM to jednak troch\u0119 Jenga<\/figcaption><\/figure><\/div>\n\n\n
\u0179r\u00f3d\u0142a<\/h3>\n\n\n\n