![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/4inICPN.jpg\")
No dobra, to skoro oczywisto\u015bci mamy za sob\u0105, czas przej\u015b\u0107 do rzeczy, kt\u00f3re RZECZYWI\u015aCIE mieli\u015bcie okazje przegapi\u0107 \ud83d\ude07.<\/p>\n\n\n\n
Rok, w kt\u00f3rym umar\u0142 GraalVM EE, a narodzi\u0142 si\u0119 GraalOS<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/JbXmhww.jpg\")
<\/figure>\n\n\n\nRok 2023 zapami\u0119tamy te\u017c jako ten, podczas kt\u00f3rego GraalVM przeszed\u0142 spor\u0105 transformacj\u0119. Pierwsz\u0105 kluczow\u0105 zmian\u0105 by\u0142y kwestie licencyjne, kt\u00f3re to rozpocz\u0119\u0142y si\u0119 jeszcze w ko\u0144c\u00f3wce 2022. GraalVM, tradycyjnie oferowa\u0142 dwie edycje – Community (CE) i Enterprise (EE). Na JavaOne 2022 zapowiedziano w\u0142\u0105czenie GraalVM CE pod skrzyd\u0142a OpenJDK (w ramach projektu Galahad). W po\u0142owie 2023 zdecydowano si\u0119 na r\u00f3wnie du\u017cy krok, je\u015bli chodzi Enterprise Edition. Ta zosta\u0142a zast\u0105piona przez Oracle GraalVM, now\u0105 dystrybucj\u0119 z modelem licencyjnym, znanym jako GraalVM Free Terms and Conditions (GFTC). Ta zmiana licencyjna u\u0142awia darmowe u\u017cycie najnowszej wersji Oracle GraalVM zar\u00f3wno w \u015brodowiskach deweloperskich, jak i komercyjnych, co stanowi znacz\u0105cy krok naprz\u00f3d w por\u00f3wnaniu do poprzednich ogranicze\u0144 licencyjnych.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/09\/image-10.png\")
Zaznaczam jednak, \u017ce \u201ePowy\u017csze nie stanowi porady prawnej, a jedynie komentarz laika. Przed u\u017cyciem skontaktujcie si\u0119 z Waszym w\u0142asnym dzia\u0142em prawnym\u201d<\/figcaption><\/figure><\/div>\n\n\nKolejn\u0105 istotn\u0105 nowo\u015bci\u0105 jest wprowadzenie Graal Cloud Native (GCN). To specjalna wersja zestawu modu\u0142\u00f3w frameworka Micronaut (o Micronaucie jeszcze b\u0119dzie troch\u0119 p\u00f3\u017aniej), zaprojektowana do tworzenia mikroserwis\u00f3w w spos\u00f3b pe\u0142ni kompatybilna z kompilacj\u0105 GraalVM Native Image. Mo\u017cna je de facto uzna\u0107 za pierwszy pe\u0142noprawny framework GraalVM-First.<\/p>\n\n\n\n
R\u00f3wnie\u017c w 2023 opublikowany zosta\u0142 GraalOS, nowe \u015brodowisko uruchomieniowe dla aplikacji chmurowych, skoncentrowane na optymalizacji funkcji serverless poprzez mo\u017cliwo\u015b\u0107 odpalenia ich (dzi\u0119ki GraalVM) na serwerach bare metal. GraalOS wykorzystuje kompilacj\u0119 ahead-of-time (AOT) do konwersji aplikacji w samodzielne natywne pliki wykonywalne, co pozwala na eliminacj\u0119 „cold start\u00f3w” i zwi\u0119ksza wydajno\u015b\u0107 aplikacji serverless. GraalOS w teorii ma by\u0107 dost\u0119pny dla ka\u017cdego \u015brodowiska, ale jest zaprojektowany do integracji z Oracle Cloud Infrastructure Functions i stanowi\u0107 ma przewag\u0119 konkurencyjn\u0105 tego \u015brodowiska. Zobaczymy, czy stanie si\u0119 odpowiednim argumentem dla rozwi\u0105zania Oracle.<\/p>\n\n\n\n
Warto zauwa\u017cy\u0107, \u017ce AWS Lambda umo\u017cliwia ju\u017c obs\u0142ug\u0119 GraalVM w ramach tak zwanego niestandardowego \u015brodowiska wykonawczego. Jednak\u017ce zasadniczo wi\u0105\u017ce si\u0119 to z uruchomieniem kontenera z aplikacj\u0105 GraalVM. GraalOS umo\u017cliwia obej\u015bcie tej warstwy, eliminuj\u0105c potrzeb\u0119 uruchamiania kontenera i inicjowania maszyny JVM.<\/p>\n\n\n\n
Opr\u00f3cz powy\u017cszych zmian, ewolucje przeszed\u0142 r\u00f3wnie\u017c Truffle. Ten metaframework umo\u017cliwiaj\u0105cy tworzenie interpreter\u00f3w j\u0119zyk\u00f3w programowania na potrzeby ich uruchomienia w ramach GraalVM, zosta\u0142 oddzielony od g\u0142\u00f3wnej platformy. Same interpretery dla Pythona czy JavaScripta dost\u0119pne s\u0105 teraz jako osobne pakiety, kt\u00f3re mo\u017cemy zaczyta\u0107 jako zwyk\u0142a dependencja projektu, pomijaj\u0105c wcze\u015bniej wymagany customowy tooling.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- GraalVM EE is Dead, Long Live Oracle GraalVM – JVM Weekly vol. 47<\/a><\/li>\n\n\n\n
- What does GraalVM for JDK 21 have in common with the Rabbit of Caerbannog? Both surprise with their power – JVM Weekly vol. 58<\/a><\/li>\n<\/ul>\n\n\n\n
Rok, w kt\u00f3rym MicroProfile po\u0142\u0105czy\u0142 si\u0142y z Core Profile<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/xJBQkN7.jpg\")
<\/figure>\n\n\n\nTeraz cofniemy si\u0119 o ca\u0142e 12 miesi\u0119cy – MicroProfile 6.0 by\u0142 bowiem pierwsz\u0105 du\u017c\u0105 premier\u0105 roku 2023. Poza standaryzacj\u0105 nowego zestawu API, przyni\u00f3s\u0142 on za\u015b oczekiwane uporz\u0105dkowanie tego, jak wygl\u0105da obecnie relacja projektu z Jakarta EE.<\/p>\n\n\n\n
Wraz z Jakarta EE 10 pojawi\u0142 si\u0119 tak zwany Core Profile \u2013 zestaw API, kt\u00f3re zgodnie z planami tw\u00f3rc\u00f3w maj\u0105 stanowi\u0107 minimum niezb\u0119dne do tworzenia mikrous\u0142ug w Javie. Brzmi to bardzo podobnie do celu, jaki postawili sobie tw\u00f3rcy MicroProfile, dlatego od pocz\u0105tku zastanawiali\u015bmy si\u0119, w jaki spos\u00f3b pojawienie si\u0119 Core Profile na niego wp\u0142ynie. Jaka\u015b forma synergii wydawa\u0142a si\u0119 tutaj by\u0107 bardzo naturalna, ale r\u00f3wnocze\u015bnie od pocz\u0105tku pojawia\u0142y si\u0119 jasne komunikaty, \u017ce nie nale\u017cy spodziewa\u0107 si\u0119 dw\u00f3ch inicjatyw w jedn\u0105. Ich tw\u00f3rcy jednak zapewniali, \u017ce pozostaj\u0105 ze sob\u0105 w sta\u0142ym kontakcie i w przyjacielskich stosunkach.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/01\/image-2.png\")
I bardzo dobrze. Enterprise Java to za ma\u0142y \u015bwiatek, \u017ceby si\u0119 jeszcze dzieli\u0107.<\/figcaption><\/figure><\/div>\n\n\nPrzed premier\u0105 MicroProfile 6.0, strategi\u0105 standardu by\u0142o wybieranie sobie z Jakarta EE tych API, kt\u00f3re wed\u0142ug tw\u00f3rc\u00f3w projektu mia\u0142y by\u0107 najbardziej przydatne dla u\u017cytkownika MP. W wypadku MicroProfile 5.0 by\u0142o to wi\u0119c:<\/p>\n\n\n\n
\n- Jakarta Contexts and Dependency Injection (CDI)<\/li>\n\n\n\n
- Jakarta Annotations (JPA)<\/li>\n\n\n\n
- Jakarta RESTful Web Services (JAX-RS)<\/li>\n\n\n\n
- Jakarta JSON Binding (JSON-B)<\/li>\n\n\n\n
- Jakarta JSON Processing (JSON-P)<\/li>\n<\/ul>\n\n\n\n
Od wydania MicroProfile 6.0 projekt dokona\u0142 alignementu z Jakarta Core Profile. Oznacza to, \u017ce zamiast na pojedynczych API b\u0119dzie on posiada\u0142 zale\u017cno\u015b\u0107 na pe\u0142nym Profilu, a tranzytywne trafi\u0105 do niego r\u00f3wnie\u017c nast\u0119puj\u0105ce API:<\/p>\n\n\n\n
\n- Jakarta RESTful Web Services<\/li>\n\n\n\n
- Jakarta Interceptors<\/li>\n<\/ul>\n\n\n\n
Ze zrozumia\u0142ych powod\u00f3w, minimalna wersja Jakarta EE wspierana przez MicroProfile to teraz Jakarta EE 10.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n\n- Kotlin 1.8 is a phantom release – JVM Weekly #29<\/a><\/li>\n<\/ul>\n\n\n\n
Rok, w kt\u00f3rym Testcontainers sta\u0142y si\u0119 cz\u0119\u015bci\u0105 Docker<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/YvGU25Z.jpg\")
<\/figure>\n\n\n\nO ile w wypadku JavaScriptowych infrastrukturalnych projekt\u00f3w do\u015b\u0107 cz\u0119sto (a przynajmniej 2021 i 2022 nas w tym temacie dosy\u0107 rozpie\u015bci\u0142y) mamy do czynienia z og\u0142oszeniami nowych rund zewn\u0119trznego finansowania (Vercel, Deno), o tyle relatywnie rzadko s\u0142yszy si\u0119, aby jaka\u015b javowa biblioteka zak\u0142ada\u0142a w\u0142asn\u0105 chmur\u0119 (chyba, \u017ce bierzemy tutaj pod uwag\u0119 takiego Confluence i Kafk\u0119). Dlatego te\u017c ze sporym u\u015bmiechem \u015bledzi\u0142em tegoroczne og\u0142oszenia od AtomicJar.<\/p>\n\n\n\n
\u017beby przedstawi\u0107, na co maj\u0105 i\u015b\u0107 dane \u015brodki, warto przypomnie\u0107 sobie czym AtomicJar si\u0119 zajmuje. Kojarzycie TestContainers? Jest to biblioteka wspieraj\u0105ca dla JUnita, zapewniaj\u0105ca lekkie, jednorazowe instancje popularnych baz danych, przegl\u0105darek internetowych dla Selenium i og\u00f3lnie wszystkiego, co mo\u017cna \u0142atwo uruchomi\u0107 w kontenerze Dockera. Wprawdzie wiele os\u00f3b pewnie b\u0119dzie z\u017cyma\u0107 si\u0119 na uruchamianie kontener\u00f3w w testach jednostkowych, ale popularno\u015b\u0107 TestContainers udowadnia, jak bardzo cz\u0119sty jest to przypadek u\u017cycia.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/d9ab87a0ff5b0e6f3070819b131462bd60ca71f5r1-498-280_hq.gif\")
Po prostu nazwiemy nasze testy integracyjnymi.<\/figcaption><\/figure><\/div>\n\n\nW lutym AtomicJar pozyska\u0142o 25 milion\u00f3w dolar\u00f3w finansowania. \u015arodki te mia\u0142y na celu rozw\u00f3j TestContainers Cloud – rozwi\u0105zania Software-as-a-Service, kt\u00f3re umo\u017cliwia uruchamianie kontener\u00f3w nie lokalnie, ale w chmurze. Mia\u0142o to na celu u\u0142atwienie pracy programistom, zw\u0142aszcza w kontek\u015bcie ci\u0119\u017cszych test\u00f3w i ogranicze\u0144 sprz\u0119towych.<\/p>\n\n\n\n
Nast\u0119pnym krokiem by\u0142a premiera Testcontainers Desktop, aplikacj\u0119 maj\u0105c\u0105 na celu przyspieszenie startu test\u00f3w poprzez funkcje takie jak sta\u0142e porty czy mo\u017cliwo\u015b\u0107 zamra\u017cania kontener\u00f3w dla cel\u00f3w debugowania. Testcontainers Desktop stanowi\u0142 u\u0142atwienie dla tych, kt\u00f3rzy wci\u0105\u017c preferuj\u0105 lokalne \u015brodowisko testowe, jednocze\u015bnie daj\u0105c dost\u0119p do wersji pr\u00f3bnej Testcontainers Cloud.<\/p>\n\n\n\n
Kulminacyjnym wydarzeniem roku by\u0142o przej\u0119cie AtomicJar przez Docker w grudniu. Tranzakcja mia\u0142a strategiczne znaczenie zar\u00f3wno dla samego Dockera (kt\u00f3ry z przytupem wkroczy\u0142 w ten spos\u00f3b w rynek Cloud DevEnvironments), jak i dla Tescontiners, potencjalnie rozszerzaj\u0105c baz\u0119 u\u017cytkownik\u00f3w ich rozwi\u0105zania, kt\u00f3re dzi\u0119ki wsp\u00f3\u0142pracy z Dockerem ma szanse wyj\u015b\u0107 poza \u015bwiat Javy i sta\u0107 si\u0119 rynkowym standardem.<\/p>\n\n\n\n
Oby wi\u0119cej takich historii w 2024.<\/p>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/WkKFCpZ.jpg\")
A dla anty-fan\u00f3w TestContainers zostawiam klasyczny cytat z Rousseau. On ju\u017c w XVIII wieku wiedzia\u0142 jak wygl\u0105da prawdziwa in\u017cynieria.<\/figcaption><\/figure>\n\n\n\nWi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n\n- What does the „State of Developer Ecosystem 2022” tell us about Java and the JVM ? – JVM Weekly #32<\/a><\/li>\n\n\n\n
- Java, Kotlin, Scala: Insights from State of Developer Ecosystem 2023 – JVM Weekly vol. 62<\/a><\/li>\n\n\n\n
- Docker acquires AtomicJar, company behind Testcontainers – JVM Weekly vol. 64<\/a><\/li>\n<\/ul>\n\n\n\n
Rok, w kt\u00f3rym Spring po\u015brednio sta\u0142 si\u0119 cz\u0119\u015bci\u0105 Broadcom<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/SFfe11A.jpg\")
<\/figure>\n\n\n\nO ile powy\u017csze przej\u0119cie witam bardzo optymistycznie, to jednak nie ka\u017cde og\u0142oszenie tego typu to pow\u00f3d do rado\u015bci. Dla nikogo zaskoczeniem nie b\u0119dzie, \u017ce du\u017ce projekty Open-Source w dzisiejszych czasach zwykle posiadaj\u0105 swoich korporacyjnych sponsor\u00f3w, a wielu ludzi rozwijaj\u0105cych je robi\u0105 to w ramach firmowych etat\u00f3w. Dlatego te\u017c ruchy sp\u00f3\u0142ek gie\u0142dowych potrafi\u0105 mie\u0107 na ich rozw\u00f3j olbrzymi wp\u0142yw.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/11\/image-33.png\")
Powy\u017cszy obrazek jest tu bez \u017cadnego kontekstu i nie ma nic wsp\u00f3lnego z tre\u015bci\u0105 sekcji. W\u0142a\u015bciwie nie wiem sk\u0105d on si\u0119 tu w og\u00f3le wzi\u0105\u0142\u2026<\/figcaption><\/figure><\/div>\n\n\nPivotal Software (stoj\u0105cy za Springiem) i VMware maj\u0105 ze sob\u0105 silne powi\u0105zania historyczne i biznesowe, czego kulimancj\u0105 w 2019 by\u0142o przej\u0119cie Pivotala przez t\u0105 drug\u0105 firm\u0119. W 2023 dosz\u0142o do kolejnych akwizycji samego VMWare – Broadcom, znany g\u0142\u00f3wnie z produkcji p\u00f3\u0142przewodnik\u00f3w, podj\u0105\u0142 decyzj\u0119 o rozszerzeniu swojej dzia\u0142alno\u015bci na rynku oprogramowania. Wyb\u00f3r pad\u0142 na VMware, jako \u017ce firma uznawana jest za lidera w dziedzinie wirtualizacji i infrastruktury chmurowej, co stanowi\u0142o atrakcyjny kierunek rozwoju dla Broadcom. Przej\u0119cie rozpocz\u0119te w maju 2022, a b\u0119d\u0105ce jedn\u0105 z wi\u0119kszych transakcji tego typu opiewaj\u0105c\u0105 na 69 miliard\u00f3w dolar\u00f3w, domkni\u0119to finalnie w zesz\u0142ym tygodniu, 22 listopada.<\/p>\n\n\n\n
Bardzo szybko po transakcji dosz\u0142o do serii zwolnie\u0144 w firmie. Nie wiemy jaki jest ich zakres, ale na pewno zaafektowa\u0142y one te\u017c zesp\u00f3\u0142 odpowiadaj\u0105cy za najpopularniejszy javowy framework. Oliver Drotbohm, architekt Springa, kt\u00f3ry od ponad dekady prowadzi projekt Spring Data, podsumowa\u0142 ca\u0142o\u015b\u0107 wymownie.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/11\/QMoyrOJ.png\")
<\/figure><\/div>\n\n\nWi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n\n- Java, Kotlin, Scala: Insights from State of Developer Ecosystem 2023 – JVM Weekly vol. 62<\/a><\/li>\n<\/ul>\n\n\n\n
Rok, w kt\u00f3rym Oracle wywraca do g\u00f3ry nogami pricing ich wersji JDK<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/upXRdZ9.jpg\")
<\/figure>\n\n\n\nJak ju\u017c wspomnia\u0142em na samym pocz\u0105tku, poza wyj\u0105tkowymi okazjami jak JDK 21, Java bardzo rzadko trafia na j\u0119zyki spo\u0142eczno\u015bci programistycznej. O ile nas interesowa\u0107 mog\u0105 zmiany w maszynie wirtualnej i inne wiadomo\u015bci z ekosystemu, to jednak kto\u015b \u201eniezainwestowany\u201d w ekosystem o Javie s\u0142yszy g\u0142\u00f3wnie w momencie internetowych \u201edram\u201d. A z tak\u0105 mieli\u015bmy do czynienia pocz\u0105tkiem lutego, a wszystko przez to, \u017ce Oracle zdecydowa\u0142 si\u0119 zmieni\u0107 spos\u00f3b naliczania op\u0142at za swoje JDK. Nie mog\u0119 wi\u0119c nie po\u015bwi\u0119ci\u0107 miejsca temu faktowi w podsumowaniu roku.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/AYDGm7d.png\")
Fun Fact – z tego co uda\u0142o mi si\u0119 sprawdzi\u0107, to by\u0142 to jedyny raz w tym roku gdy co\u015b JVM-owego znalaz\u0142o si\u0119 na szczycie \/r\/programming<\/strong> – nie uda\u0142o si\u0119 to nawet JDK 21. Wida\u0107 co si\u0119 klika w internetach.<\/figcaption><\/figure><\/div>\n\n\n23 stycznia Oracle poinformowa\u0142, \u017ce zmienia model licencyjny Oracle JDK na Java SE Universal Subscription. Nowy cennik, zamiast bazowa\u0107 na stanowiskach roboczych i procesorach, opiera si\u0119 na ilo\u015bci pracownik\u00f3w zatrudnianych przez firm\u0119: w tych do 1000 pracownik\u00f3w op\u0142aty wynosz\u0105 15$\/mc, dla wi\u0119kszych 5,25$\/mc. Dla wielu (wi\u0119kszo\u015bci?) firm korzystaj\u0105cych z Oracle JDK oznacza to b\u0119dzie wzrost koszt\u00f3w, poniewa\u017c w obliczeniach brani s\u0105 pod uwag\u0119 nie tylko programi\u015bci, ale wszyscy pracownicy firmy \u2013 tak\u017ce ci spoza dzia\u0142u IT, a tak\u017ce np. kontraktorzy.<\/p>\n\n\n\n
Zmiany nie dotyczy ju\u017c p\u0142ac\u0105cych klient\u00f3w, kt\u00f3rzy b\u0119d\u0105 mogli si\u0119 rozlicza\u0107 na wsp\u00f3\u0142czesnych warunkach (aczkolwiek nie uda\u0142o mi si\u0119 dogrzeba\u0107, w jaki spos\u00f3b rozwi\u0105zane zostanie np. rozszerzenie licencji). Ko\u0144cz\u0105c na pozytywnej nucie, zapisy mog\u0105 by\u0107 teoretycznie korzystne dla niekt\u00f3rych firm, zw\u0142aszcza ma\u0142ych startup\u00f3w stricte technologicznych, posiadaj\u0105cych ma\u0142\u0105 ilo\u015b\u0107 pracownik\u00f3w. Enterprise trac\u0105 chyba w ka\u017cdej konfiguracji, ale mali, szybko skaluj\u0105cy si\u0119 mog\u0105 zyska\u0107 \u2013 aczkolwiek wbrew tej teorii mo\u017ce by\u0107 fakt wysokich op\u0142at per pracownik (15$\/mc) w firmach poni\u017cej 1000 zatrudnionych os\u00f3b.<\/p>\n\n\n\n
Nale\u017cy pami\u0119ta\u0107, \u017ce Oracle nie jest jedynym dostawc\u0105 JDK, wi\u0119c ka\u017cdy chc\u0105cy u\u017cywa\u0107 Javy za darmo, mo\u017ce u\u017cy\u0107 np. Adoptium. Co jest smutne \u2013 \u015bwietnie wiedz\u0105 to ludzie znaj\u0105cy ekosystem Javy, ale dla szerokiego odbiorcy jest to stan mocno nieintuicyjny. W ko\u0144cu nie ma alternatywnych dystrybucji Go czy Rusta (albo s\u0105 statystycznie pomijalne).<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/oeKK34d.jpg\")
<\/figure><\/div>\n\n\nWi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n\n- What does the „State of Developer Ecosystem 2022” tell us about Java and the JVM ? – JVM Weekly #32<\/a><\/li>\n<\/ul>\n\n\n\n
Rok pocz\u0105tku ko\u0144ca problemu nulli w Javie dzi\u0119ki projektowi Valhalla<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/DcbiUjo.jpg\")
<\/figure>\n\n\n\n2023 to te\u017c kolejny rok iteracji nad Valhall\u0105. Projekt ulega dalszej rewolucji i z ka\u017cd\u0105 kolejn\u0105 iteracj\u0105 staje si\u0119 coraz ciekawszy i ma szanse (troch\u0119 przypadkiem) da\u0107 nam usprawnienia, na kt\u00f3re programi\u015bci czekali… no w zasadzie od zawsze. Jedn\u0105 z funkcji j\u0119zyka, kt\u00f3re dostarczy\u0107 ma Valhalla s\u0105 Value Type (czy jak one si\u0119 tam teraz po kolejnych iteracjach maj\u0105 nazywa\u0107). G\u0142\u00f3wnym rozr\u00f3\u017cnieniem mi\u0119dzy \u201etypem referencyjnym\u201d (czyli obecnie istniej\u0105cymi w j\u0119zyku) a \u201etypem warto\u015bci\u201d jest fakt, \u017ce te drugie nie mog\u0105 przyjmowa\u0107 warto\u015bci null. W odr\u00f3\u017cnieniu od takiego Kotlina, w\u0142asno\u015b\u0107 ta nie jest \u0142atwo wyra\u017calna w samym j\u0119zyku. Dlatego te\u017c projektanci do Valhalli rozwa\u017caj\u0105 wprowadzenie nowego znacznika \u201enullness\u201d dla obiekt\u00f3w.<\/p>\n\n\n\n
Je\u015bli nie \u015bledzicie na bie\u017c\u0105co rozwoju Valhalli, mo\u017cliwe, \u017ce umkn\u0105\u0142 Wam fakt, \u017ce w pewnym momencie tw\u00f3rcy zaproponowali sufiksy .val<\/code> i .ref<\/code>. Mia\u0142y one informowa\u0107, czy chcemy u\u017cywa\u0107 danego obiektu jako warto\u015bci, czy jako referencji. To by\u0142o dla mnie najbardziej problematyczne spo\u015br\u00f3d proponowanych zmian, obawia\u0142em si\u0119 bowiem komplikacji sk\u0142adni. Na razie wygl\u0105da na to, \u017ce uda si\u0119 z nich zrezygnowa\u0107. Prace nad rozwojem ca\u0142ego projektu pozwoli\u0142y zredukowa\u0107 r\u00f3\u017cnice mi\u0119dzy typami prymitywnymi a obiektami do dw\u00f3ch fundamentalnych r\u00f3\u017cnic \u2013 posiadania warto\u015bci domy\u015blnej (jak 0 w przypadku int) oraz wsparcia dla nullowalno\u015bci.<\/p>\n\n\n\nW odr\u00f3\u017cnieniu od takiego Kotlina, w\u0142asno\u015b\u0107 ta nie jest \u0142atwo wyra\u017calna w samym j\u0119zyku. Dlatego te\u017c projektanci do Valhalli rozwa\u017caj\u0105 wprowadzenie nowego znacznika \u201enullness\u201d dla obiekt\u00f3w. Pojawi\u0142a si\u0119 propozycja wprowadzenia dw\u00f3ch dodatkowych oznacze\u0144 przy definiowaniu typu \u2013 ! oznaczaj\u0105cy nie dopuszczamy nulla oraz ? oznaczaj\u0105cy ten obiekt jest nullowalny. W skr\u00f3cie:<\/p>\n\n\n\n
Foo?<\/code> oznacza ten typ zawiera w swoim zbiorze warto\u015bci null
Foo!<\/code> oznacza ten typ nie zawiera w swoim zbiorze warto\u015bci null
Foo<\/code> oznacza \ud83e\udd37\u200d\u2642\ufe0f \u2013 inaczej m\u00f3wi\u0105c, nie okre\u015blony stan nullowalno\u015bci<\/p>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/8b5pwc.jpg\")
<\/figure><\/div>\n\n\nZ czasem, tw\u00f3rcy b\u0119d\u0105 d\u0105\u017cy\u0107 do tego, aby wersja bez odpowiedniej adnotacji przyjmowa\u0142a cechy wariant\u00f3w anotowanych \u2013 na ten moment wydaje si\u0119, \u017ce nieoznaczone Foo b\u0119dzie w wi\u0119kszo\u015bci przypadk\u00f3w traktowane jako nienulowalne.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n\n- Will Valhalla bring better nulls to Java? – JVM Weekly #33<\/a><\/li>\n\n\n\n
- Exploring the Newest Updates of Project Leyden, Valhalla & Hermes: JVM Weekly vol. 54<\/a><\/li>\n<\/ul>\n\n\n\n
![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/1AGUceM.png\")
A najlepiej to \u017cagladnijcie do oryginalnych dokument\u00f3w – te nulla to mega skomplikowany temat. I pewnie przegapi\u0142em jaki\u015b tekst kt\u00f3ry zd\u0105\u017cy\u0142 go wywr\u00f3ci\u0107 do g\u00f3ry nogami.<\/figcaption><\/figure><\/div>\n\n\nRok, w kt\u00f3rym z wypiekami na twarzy ogl\u0105da\u0142em JVM Language Summit<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/GouYQXi.jpg\")
<\/figure>\n\n\n\nJVMLS to roczne wydarzenie, kt\u00f3re gromadzi ekspert\u00f3w i in\u017cynier\u00f3w zwi\u0105zanymi z rozwojem JVM, aby omawia\u0107 aktualne udoskonalenia i przysz\u0142o\u015b\u0107 tej platformy. W tym roku mamy dost\u0119p do masy materia\u0142\u00f3w z eventu, co pozwoli\u0142o nam zerkn\u0105\u0107 pod mask\u0119 wielu projekt\u00f3w, kt\u00f3re zwykle pozostaj\u0105 w cieniu.<\/p>\n\n\n\n
Podczas JVMLS, sporo miejsca po\u015bwi\u0119cono Projektowi Leyden, kt\u00f3ry wprowadza now\u0105 technik\u0119 optymalizacji kodu Javy, opart\u0105 na „przesuwaniu i ograniczaniu” oblicze\u0144 . Projekt ten umo\u017cliwi\u0107 ma tworzeniu „kondensator\u00f3w”, kt\u00f3re analizuj\u0105 zachowanie aplikacji w czasie rzeczywistym i dostosowuj\u0105 j\u0105 do efektywnego dzia\u0142ania. Dzi\u0119ki temu, aplikacje Java mog\u0105 by\u0107 zoptymalizowane ju\u017c przed uruchomieniem, co skraca czas „rozgrzewania” i zapewnia d\u0142u\u017csze okresy szczytowej wydajno\u015bci. Na JVMLS po raz pierwszy mogli\u015bmy przygl\u0105dn\u0105\u0107 si\u0119 wynikom prac, zaprezentowany zosta\u0142 ApplicationModel<\/code>, bazowy interfejs modelu, a tak\u017ce patterny implmentacyjne.<\/p>\n\n\n\nKolejnym interesuj\u0105cym projektem jest Projekt Babylon, kt\u00f3ry ma na celu dostarczenie bardziej zaawansowanych mo\u017cliwo\u015bci ni\u017c istniej\u0105ce mechanizmy refleksji w Javie, poprzez wprowadzenie tak zwanej „refleksji kodu”. W odr\u00f3\u017cnieniu od standardowej refleksji, dzia\u0142aj\u0105cej w runtime, ta ma pozwoli\u0107 programistom na analiz\u0119 i manipulacj\u0119 kodem \u017ar\u00f3d\u0142owym r\u00f3wnie\u017c w czasie kompilacji, umo\u017cliwiaj\u0105c dynamiczne generowanie kodu dla r\u00f3\u017cnych \u015brodowisk uruchomieniowych, podobnie jak LINQ w j\u0119zyku C#.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/VT7M35t.jpg\")
Mo\u017ce nied\u0142ugo si\u0119 przestan\u0105 z nas \u015bmia\u0107<\/figcaption><\/figure><\/div>\n\n\nProjekt Panama te\u017c nie zwalnia, i po ogarni\u0119ciu tematy Foreign Memory i usprawnieniu pracy z programami napisanymi w j\u0119zykach „natywnych”, ma teraz na celu u\u0142atwienie integracji Javy z nietypowymi \u015brodowiskami uruchomieniowymi, takimi jak np. GPU. Dzi\u0119ki Panama, programi\u015bci b\u0119d\u0105 mieli lepsz\u0105 kontrol\u0119 nad transferem danych mi\u0119dzy r\u00f3\u017cnymi rodzajami pami\u0119ci oraz nad dzia\u0142aniem Garbage Collectora, co u\u0142atwi prac\u0119 z frameworkami zwi\u0105zanymi z uczeniem maszynowym i sztuczn\u0105 inteligencj\u0105. Jego tw\u00f3rcy mocno wsp\u00f3\u0142pracuj\u0105 i wymieniaj\u0105 do\u015bwiadczenia z TornadoVM, platform\u0105 pozwalaj\u0105c\u0105 na wykonywanie aplikacji Java na r\u00f3\u017cnych platformach sprz\u0119towych, w tym na GPU, FPGA i systemach wielordzeniowych.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/08\/image-9.png\")
Poniewa\u017c za cz\u0119sto dajemy si\u0119 tym naszym rdzeniom CPU wynudzi\u0107.<\/figcaption><\/figure><\/div>\n\n\nTornadoVM wykorzystuje kompilator JIT GraalVM, co pozwala na przekszta\u0142canie kodu Java w natywny kod maszynowy, co w wielu przypadkach znacz\u0105co przyspieszy\u0107 wydajno\u015b\u0107 aplikacji. Tworz\u0105 oni te\u017c u\u017cyteczne abstrakcje, u\u0142atwiaj\u0105c\u0105 tworzenie portowalnego kodu. W tym roku (rzutem na ta\u015bm\u0119, w grudniu) wreszcie ukaza\u0142a si\u0119 jego wersja 1.0<\/a>, wi\u0119c mo\u017cna my\u015ble\u0107 o szerszej adopcji \ud83d\ude09<\/p>\n\n\n\nZdecydowanie nie mog\u0119 si\u0119 doczeka\u0107 JVMLS 2024.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n\n- Panama, OpenCL and TornadoVM: Java’s entry into the GPU world – JVM Weekly vol. 55<\/a><\/li>\n\n\n\n
- Exploring the Newest Updates of Project Leyden, Valhalla & Hermes: JVM Weekly vol. 54<\/a><\/li>\n\n\n\n
- Project Babylon: Chance for LINQ (and more) in Java – JVM Weekly vol. 56<\/a><\/li>\n<\/ul>\n\n\n\n
Rok, w kt\u00f3rym zapowiedziano Kotlin 2.0<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/ZZX5j6E.jpg\")
<\/figure>\n\n\n\nW \u015bwiecie Kotlina szykuj\u0105 si\u0119 spore zmiany \u2013 przynajmniej je\u015bli chodzi o numeracje, aczkolwiek na niej si\u0119 nie sko\u0144czy.<\/p>\n\n\n\n
Tw\u00f3rcy og\u0142osili bowiem, \u017ce wydanie 1.9 b\u0119dzie ostatnim z linii 1.x. Wersja 1.10 si\u0119 nie poka\u017ce, zamiast niej przeskoczymy od razu do wydania 2.0. Wynika\u0107 ma to z faktu, \u017ce to w\u0142a\u015bnie na t\u0105 wersje planowane jest wydanie d\u0142ugo oczekiwanego kompilatora K2 \u2013 \u201ejednego, by wszystkimi rz\u0105dzi\u0107\u201d i maj\u0105cego zapewni\u0107 wsp\u00f3ln\u0105 infrastruktur\u0119 dla wszystkich potencjalnych target\u00f3w j\u0119zyka. Dzi\u0119ki temu jego tw\u00f3rcy nie b\u0119d\u0105 musieli ka\u017cdorazowo implementowa\u0107 tych samych funkcjonalno\u015bci na potrzeby JVM, WebAssembly czy Androida, co ma znacznie przyspieszy\u0107 ewolucje Kotlina. Zmiana jest wi\u0119c na tyle du\u017ca, \u017ce uznano za zasadne odpowiednie ukoronowanie jej podbiciem numeracji.<\/p>\n\n\n\n
Zmiana \u201edu\u017cej\u201d wersji j\u0119zyka potrafi\u0142a mocno zamiesza\u0107 w ekosystemie danego j\u0119zyka, jednak w wypadku Kotlina JetBrains obiecuje bardzo stabilny proces migracji. Ma by\u0107 to mo\u017cliwe do osi\u0105gni\u0119cia dzi\u0119ki dw\u00f3m sk\u0142adowym. Po pierwsze, zmiany motywuj\u0105ce podbicie numeracji odbywaj\u0105 si\u0119 pod mask\u0105, a tw\u00f3rcy celowo nie planuj\u0105 wprowadza\u0107 w nowym wydaniu \u017cadnych nowych nowo\u015bci w samym syntaksie j\u0119zyka \u2013 te zostawiaj\u0105 sobie na wydania 2.x, kt\u00f3re przyjd\u0105 po udanym przej\u015bciu na K2 (a ju\u017c kilka k\u0105sk\u00f3w zapowiedziano). Dodatkowo jednak JetBrains zyskuje na tym, \u017ce kontroluje zar\u00f3wno Kotlina, jak i jest g\u0142\u00f3wnym dostawc\u0105 narz\u0119dzi do niego. Pozwala to bowiem na znacznie sprawniejsze przeprowadzenie ca\u0142ej operacji, gdy wi\u0119kszo\u015b\u0107 najwa\u017cniejszego toolingu mo\u017ce by\u0107 rozwijana r\u00f3wnolegle z j\u0119zykiem.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/02\/image-11.png\")
JetBrians Applem DevToolingu<\/figcaption><\/figure><\/div>\n\n\nWi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Will Valhalla bring better nulls to Java? – JVM Weekly #33<\/a><\/li>\n\n\n\n
- Play Framework is reborn like a phoenix from the ashes…. and gets rid of Akka – JVM Weekly vol. 60<\/a><\/li>\n\n\n\n
- TLDW: Opinionated Wrap-up of KotlinConf 2023 Keynote – JVM Weekly vol. 40<\/a><\/li>\n<\/ul>\n\n\n\n
Rok, w kt\u00f3rym Roman Elizarov odszed\u0142 z Kotlina<\/h2>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/2vzPY2f.jpg\")
<\/figure>\n\n\n\nZostaj\u0105c w \u015bwiecie Kotlina ko\u0144c\u00f3wk\u0105 roku gruchn\u0119\u0142a du\u017ca informacja. Roman Elizarov, lead projektu, og\u0142osi\u0142 swoje odej\u015bcie z JetBrains z powod\u00f3w osobistych, ko\u0144cz\u0105c w ten spos\u00f3b r\u00f3wnie\u017c swoj\u0105 prac\u0119 nad j\u0119zykiem. Po\u017cegnanie odby\u0142o si\u0119 seri\u0105 tweet\u00f3w, w kt\u00f3rych wyra\u017caj\u0105c wdzi\u0119czno\u015b\u0107 za mo\u017cliwo\u015b\u0107 pracy nad Kotlinem i podkre\u015blaj\u0105c swoje wielkie uznanie dla spo\u0142eczno\u015bci Kotlina.<\/p>\n\n\n\n
Dowiedzieli\u015bmy si\u0119 te\u017c kto w przysz\u0142o\u015bci stanie za sterami j\u0119zyka \u2013 Mikhail Zarechenskiy<\/a>, wcze\u015bniej pracuj\u0105cy za kulisami w JetBrains, zostanie g\u0142\u00f3wnym projektantem Kotlina. Kluczowe zmiany w zespole obejmuj\u0105 te\u017c Hadi Hariri<\/a>, kt\u00f3rego mo\u017cecie zna\u0107 jako Co-hosta podcastu Talking Kotlin \u2013 przejmie on teraz wi\u0119cej obowi\u0105zk\u00f3w poza dzia\u0142aniami promocyjnymi i jego zaanga\u017cowaniem w KotlinConf. R\u00f3wnie\u017c drugi prowadz\u0105cy Talking Kotlin, Sebastian Aigner<\/a>, b\u0119dzie odgrywa\u0107 teraz wa\u017cniejsz\u0105 rol\u0119 w Kotlin Foundation, szczeg\u00f3lnie w wsparciu inicjatyw szerszego ekosystemu Kotlin. Egor Tolstoy<\/a> dalej za\u015b b\u0119dzie kierowa\u0107 zespo\u0142em od strony Product Managementu.<\/p>\n\n\n\nWi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Major changes in Kotlin\u2019s leadership: Roman Elizarov departs from JetBrains<\/a><\/li>\n<\/ul>\n\n\n\n
Rok, w kt\u00f3rym doczekali\u015bmy si\u0119 wysypu ciekawych nowych wyda\u0144<\/h2>\n\n\n\nFrameworki<\/h3>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/723JU7m.jpg\")
<\/figure>\n\n\n\nSpring Framework 6.1 I Spring Boot 3.2<\/h4>\n\n\n\n
W Spring Framework 6.1 pojawi\u0142o si\u0119 wsparcie dla dw\u00f3ch kluczowych nowo\u015bci: Wirtualnych W\u0105tk\u00f3w oraz Projektu CRAC. Dla przypomnienia: Wirtualne W\u0105tki to nowy koncept w Javie, wprowadzony w JDK 21 w ramach Projektu Loom, kt\u00f3ry zmienia podej\u015bcie do wsp\u00f3\u0142bie\u017cno\u015bci. W przeciwie\u0144stwie do tradycyjnych w\u0105tk\u00f3w, kt\u00f3re s\u0105 zarz\u0105dzane przez system operacyjny, w\u0105tki wirtualne s\u0105 zarz\u0105dzane przez JVM, co pozwala na tworzenie du\u017cej liczby w\u0105tk\u00f3w bez narzutu zwi\u0105zanego z tradycyjnymi w\u0105tkami.<\/p>\n\n\n\n
Projekt CRAC (Checkpoint\/Restore in Application Continuation) pozwala za\u015b na zapisanie stanu dzia\u0142aj\u0105cej JVM i jego przywr\u00f3cenie, skracaj\u0105c czas rozruchu aplikacji. To rozwi\u0105zanie redukuje problem „zimnego startu” aplikacji Javowych, co jest szczeg\u00f3lnie istotne dla aplikacji serwerowych i serverless. Spring integruje si\u0119 z CRAC, umo\u017cliwiaj\u0105c kontrolowane checkpointy i przywracanie stanu JVM.<\/p>\n\n\n\n
Dodatkowo, w Spring Boot 3.2.0 wprowadzono rozszerzone wsparcie dla Apache Pulsara oraz interfejs RestClient z Spring Framework 6.1, kt\u00f3ry dostarcza prekonfigurowany klient HTTP do obs\u0142ugi zapyta\u0144 REST. Dodano tak\u017ce wsparcie dla JdbcClient<\/code> oraz automatyczne logowanie Correlation Id podczas korzystania z Micrometera. Spring Boot 3.2.0 u\u0142atwia tak\u017ce budowanie obraz\u00f3w Docker z u\u017cyciem standardu Cloud-Native Buildpacks.<\/p>\n\n\n\nWi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Spring Framework 6.1 and Spring Boot 3.2: The tastiest bites<\/a><\/li>\n<\/ul>\n\n\n\n
Quarkus 3.0<\/h4>\n\n\n\n
Quarkus 3.0 wprowadza rozbudowane Dev UI, kt\u00f3re u\u0142atwia zarz\u0105dzanie i konfiguracj\u0119 aplikacji. Dzi\u0119ki funkcji Dev Mode, Quarkus umo\u017cliwia Continuous Testing, co przyczynia si\u0119 do wydajno\u015bci i komfortu pracy deweloper\u00f3w.<\/p>\n\n\n\n
Niezwykle ciekaw\u0105 nowo\u015bci\u0105 jest te\u017c Mutiny2, biblioteka stworzona przez zesp\u00f3\u0142 Quarkusa do programowania reaktywnego i asynchronicznego. Mutiny2 ma na celu uproszczenie kodu reaktywnego, oferuj\u0105c podej\u015bcie bardziej intuicyjne od innych bibliotek, jak RxJava i Project Reactor. Jest to tak\u017ce symboliczne zamkni\u0119cie pewnej epoki, poniewa\u017c Mutiny w nowej wersji przechodzi z w\u0142asnej implementacji Reactive Streams API na standardowe java.util.concurrent.Flow<\/code>.<\/p>\n\n\n\nJednak cho\u0107 Quarkus 3.0 przynosi wiele cennych zmian, brakuje pe\u0142nego wsparcia dla wirtualnych w\u0105tk\u00f3w, kt\u00f3re by\u0142o wspominane jako jedna z obiecuj\u0105cych funkcji.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- A peek under-the-hood of Java: Dynamic Agents and „tearing” – JVM Weekly vol. 43<\/a><\/li>\n<\/ul>\n\n\n\n
Micronaut 4.0<\/h4>\n\n\n\n
Micronaut Framework 4.0 porzuca wsparcia dla wersji Java starszych ni\u017c JDK 17, co umo\u017cliwi\u0142o dostosowanie API do nowych sk\u0142adni j\u0119zyka, takich jak Java Records, Sealed Classes, Switch Expressions, Text Blocks czy Pattern Matching dla instanceof. Klient HTTP Micronaut zosta\u0142 zaktualizowany do wersji opartej na kliencie HTTP Java wprowadzonym w JDK 11, co poprawi\u0142o wydajno\u015b\u0107. Micronaut 4.0 zosta\u0142 te\u017c zoptymalizowany pod k\u0105tem wykorzystania GraalVM, dzi\u0119ki czemu kompilowanie aplikacji Micronaut zale\u017cnych od innych bibliotek sta\u0142o si\u0119 \u0142atwiejsze.<\/p>\n\n\n\n
Ponadto, nowe wydanie wprowadza lepsze wsparcie dla chmur, modu\u0142ow\u0105 architektur\u0119 oraz wst\u0119pne wsparcie dla VirtualThreads<\/code>. Dodatkowo, Micronaut Serialization sta\u0142 si\u0119 domy\u015blnym modu\u0142em oferuj\u0105cym wydajne i bezpieczne interfejsy API serializacji\/deserializacji JSON.<\/p>\n\n\n\nWi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Rust-written JVM and Bytecode Transpiler: A Masterclass in Learning-by-Doing – JVM Weekly vol. 51<\/a><\/li>\n<\/ul>\n\n\n\n
Helidon 4.0<\/h4>\n\n\n\n
Helidon 4 zosta\u0142 pierwszym na \u015bwiecie frameworkiem do mikroserwis\u00f3w opartym o wirtualne w\u0105tki. G\u0142\u00f3wn\u0105 zmian\u0105 przychodz\u0105c\u0105 z wydaniem by\u0142o bowiem zast\u0105pienie Netty now\u0105 implementacj\u0105 serwera o nazwie N\u00edma. N\u00edma zosta\u0142 zaprojektowany tak, aby w pe\u0142ni wykorzystywa\u0107 wirtualne w\u0105tki Java 21, umo\u017cliwiaj\u0105c ka\u017cdemu requestowi dzia\u0142anie na dedykowanym wirtualnym w\u0105tku. Upraszcza to proces wykonywania blokuj\u0105cych operacji i zapewnia wysoki poziom wsp\u00f3\u0142bie\u017cno\u015bci, eliminuj\u0105c w ten spos\u00f3b potrzeb\u0119 skomplikowanego kodu asynchronicznego, co zwi\u0119ksza wydajno\u015b\u0107, zw\u0142aszcza (wed\u0142ug doniesie\u0144 samych tw\u00f3rc\u00f3w) w Helidon MP. Oznacza to r\u00f3wnie\u017c, \u017ce doczekali\u015bmy si\u0119 pierwszego framework wymagaj\u0105cego do dzia\u0142ania… Java 21.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/10\/image-10.png\")
Nie martw si\u0119 Netty, dalej mamy Ci\u0119 w sercach.<\/figcaption><\/figure><\/div>\n\n\nHelidon SE, stanowi\u0105cy podstawowy zestaw API dla Helidon, r\u00f3wnie\u017c przeszed\u0142 spor\u0105 transformacj\u0119. Adopcja wirtualnych w\u0105tk\u00f3w umo\u017cliwi\u0142a przej\u015bcie od asynchronicznych API do blokuj\u0105cych (a\u017c si\u0119 sam dziwie pisz\u0105c to zdanie). Ta zmiana upraszcza kod, czyni\u0105c go \u0142atwiejszym w pisaniu, utrzymaniu i zrozumieniu \u2013 daje nam to przedsmak tego, co czeka pewnie w przysz\u0142o\u015bci ca\u0142y ekosystem. Osoby korzystaj\u0105ce z Helidon 3 SE b\u0119d\u0105 musia\u0142y niestety znacznie dostosowa\u0107 sw\u00f3j kod do zaktualizowanych API. Chocia\u017c mo\u017ce to wymaga\u0107 pewnego pocz\u0105tkowego wysi\u0142ku, korzy\u015bci w postaci zwi\u0119kszonej wydajno\u015bci i prostoty kodu wydaj\u0105 si\u0119 tego warte.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Major changes in Kotlin’s leadership: Roman Elizarov departs from JetBrains \u2013 JVM Weekly vol. 59<\/a><\/li>\n<\/ul>\n\n\n\n
Dropwizard 3.0 i 4.0<\/h4>\n\n\n\n
Pami\u0119tam czasy, gdy u\u017cywa\u0142em Dropwizarda, kiedy ten szumnie obiecuj\u0105cy framework znajdowa\u0142 si\u0119 na samym szczycie popularno\u015bci. Mimo pierwotnego entuzjazmu, DropWizard zacz\u0105\u0142 traci\u0107 na znaczeniu i premiera wersji 3.0 i 4.0 przesz\u0142a bez echa w \u015bwiecie technologii.<\/p>\n\n\n\n
Pow\u00f3d dw\u00f3ch wersji na raz jest prosty: Dropwizard 3.0 opiera si\u0119 na Java EE i przestrzeni nazw javax.<\/code>, dzi\u0119ki czemu migracja z Dropwizard 2.x do wersji 3.0 powinna by\u0107 minimalna dla wielu projekt\u00f3w. Natomiast Dropwizard 4.0 opiera si\u0119 na zale\u017cno\u015bciach Jakarta EE oraz przestrzeni nazw jakarta.<\/code>, co mo\u017ce wi\u0105za\u0107 si\u0119 z wi\u0119kszym nak\u0142adem pracy przy migracji z Dropwizard 2.x do wersji 4.x.<\/p>\n\n\n\nObie wersje \u0142\u0105czy te\u017c troch\u0119 wsp\u00f3lnych zmian \u2013 podniesienie wymaganej wersji Javy do 11, wprowadzenie struktury pakiet\u00f3w opartej o JPMS (mam wra\u017cenie, \u017ce to jedno z pierwszych narz\u0119dzi bior\u0105cych ten standard na powa\u017cnie), aktualizacj\u0119 Jetty do wersji 10.0.x (kt\u00f3ra te\u017c wymaga minimum Javy 11), aktualizacj\u0119 Apache HttpClient do wersji 5.x oraz usuni\u0119cie wsparcia dla JUnit 4.x (przeniesione do dropwizard-testing-junit4). Dodatkowo, tylko Dropwizard 4.0 dosta\u0142 wsparcie dla Hibernate 6.0, wymagaj\u0105cego przej\u015bcia na jakarta.<\/code><\/p>\n\n\n\nWi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Dropwizard returns with parallel 3.0 and 4.0 release – JVM Weekly vol. 39<\/a><\/li>\n<\/ul>\n\n\n\n
Play Framework 2.9 i 3.0<\/h3>\n\n\n\n
Kolejne podw\u00f3jne wydanie. Play Framework powr\u00f3ci\u0142 bowiem z nowymi wydaniami 2.9 i 3.0. Kiedy\u015b uwa\u017cany za g\u0142\u00f3wnego konkurenta Springa, Play wr\u00f3ci\u0142 do \u017cycia po tym jak zosta\u0142 przekazany spo\u0142eczno\u015bci po pewnym okresie stagnacji i kontrowersji zwi\u0105zanych z toksyczn\u0105 now\u0105 licencj\u0105 Akka, kt\u00f3rego to rozwi\u0105zania wykorzystywa\u0142 wewn\u0119trznie.<\/p>\n\n\n\n
Dlatego wydanie 3.0 przynosi migracj\u0119 z Akki do Apache Pekko, forka Akka 2.6.x. Play 3.0 korzysta teraz z Pekko i jego komponent\u00f3w HTTP. Jednak\u017ce, dla aplikacji silnie zintegrowanych z Akk\u0105, ta zmiana mo\u017ce wymaga\u0107 pewnych wysi\u0142k\u00f3w migracyjnych. Dlatego r\u00f3wnocze\u015bnie wydano r\u00f3wnie\u017c Play 2.9, kt\u00f3re kontynuuje wykorzystanie Akki i Akka HTTP.<\/p>\n\n\n\n
Poza powy\u017cszym Play 2.9 i 3.0 skupiaj\u0105 si\u0119 na wsparciu dla zaktualizowanych j\u0119zyk\u00f3w programowania, kompatybilno\u015bci z Scala 3, a tak\u017ce na dostosowaniu do nowszych wersji bibliotek, takich jak Akka HTTP 10.2, Guice 6.0.0 i Jackson 2.14. Warto zaznaczy\u0107, \u017ce Play Framework 3.0 przestaje wspiera\u0107 starsze wersje Javy, a minimalna wymagana wersja to Java 11.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Play Framework is reborn like a phoenix from the ashes…. and gets rid of Akka – JVM Weekly vol. 60<\/a><\/li>\n<\/ul>\n\n\n\n
Grails 6<\/h4>\n\n\n\n
Grails 6.0, najnowsza ods\u0142ona frameworka do tworzenia aplikacji webowych w j\u0119zyku Groovy, wprowadza kilka istotnych usprawnie\u0144. Najwa\u017cniejsz\u0105 nowo\u015bci\u0105 jest Grails Forge UI, kt\u00f3ry umo\u017cliwia programistom bardziej efektywne zarz\u0105dzanie projektami napisanymi w tym frameworku. Nowy interfejs dostarcza uproszczonego procesu inicjowania projekt\u00f3w, intuicyjnej nawigacji, walidacji w czasie rzeczywistym, wizualnego zarz\u0105dzania zale\u017cno\u015bciami oraz responsywnego designu.<\/p>\n\n\n\n
Grails 6.0 r\u00f3wnie\u017c wzmocni\u0142 integracj\u0119 z Micronaut, u\u0142atwiaj\u0105c korzystanie z bean\u00f3w Micronauta w komponentach Grails oraz wykorzystuj\u0105c klienta HTTP Micronaut do bardziej p\u0142ynnej interakcji z REST API. Warto zaznaczy\u0107, \u017ce r\u00f3wnie\u017c Grails 6.0 podnosi minimalne wymagania dotycz\u0105ce JDK do wersji 11.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Panama, OpenCL and TornadoVM: Java’s entry into the GPU world – JVM Weekly vol. 55<\/a><\/li>\n<\/ul>\n\n\n\n
WildFly 30<\/h4>\n\n\n\n
Swoj\u0105 premier\u0119 mia\u0142 te\u017c okr\u0105g\u0142y WildFly 30. Mimo \u017ce oficjalna rekomendacja to nadal JDK 17 lub 11, znacz\u0105ca cz\u0119\u015b\u0107 tego wydania zosta\u0142a po\u015bwi\u0119cona integracji z Java SE 21. Najnowsza wersja przechodzi na tej wersji testy certyfikacyjne zar\u00f3wno Jakarta EE 10 Core Profile, jak i Microprofile. Wraz z coraz wi\u0119kszym naciskiem na JDK 21 przewiduje si\u0119, \u017ce WildFly 30 mo\u017ce by\u0107 ostatnim, kt\u00f3re wspiera JDK 11.<\/p>\n\n\n\n
Dodatkowo, wraz z przyj\u015bciem WildFly 30 nast\u0105pi\u0142a zmiana licencji z Lesser General Public License 2.1 na Apache Software License 2.0, podsumowuj\u0105c w ten spos\u00f3b d\u0142ugoletni\u0105 \u015bcie\u017ck\u0119. Przej\u015bcie z Lesser General Public License 2.1 (LGPL 2.1) na Apache Software License 2.0 (ASL 2.0) oznacza przej\u015bcie z licencji \u201es\u0142abej\u201d copyleft na bardziej liberaln\u0105.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Major changes in Kotlin\u2019s leadership: Roman Elizarov departs from JetBrains<\/a><\/li>\n<\/ul>\n\n\n\n
Vaadin Hilla 2.0<\/h4>\n\n\n\n
Oko\u0142o rok temu Vaadin zaprezentowa\u0142 Hille, nowy framework webowy dla programist\u00f3w Java, kt\u00f3ry umo\u017cliwia tworzenie kompletnych aplikacji z backendem opartym na Spring Boot i frontendem napisanym w TypeScript. Wcze\u015bniej znany jako Vaadin Fusion, Hille oferuje sp\u00f3jn\u0105 konfiguracj\u0119 dla Java i TypeScript, bogaty zestaw komponent\u00f3w interfejsu u\u017cytkownika oraz konkuruj\u0105cy z JHipsterem stos technologiczny.<\/p>\n\n\n\n
W najnowszej wersji 2.0 dodano ulepszony generator TypeScript, wsparcie dla WebSocket\u00f3w, kompatybilno\u015b\u0107 z GraalVM Native Image, uproszczon\u0105 tworzenie motyw\u00f3w graficznych i narz\u0119dzie SSO Kit do szybkiego wdro\u017cenia logowania jednokrotnego (SSO). Ta wersja korzysta z Spring Boot 3, Java 17 i Jakarta EE 10.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- JDK 21 Strikes Back: Stable Virtual Threads and Generational ZGC – JVM Weekly vol. 37<\/a><\/li>\n<\/ul>\n\n\n\n
Tooling<\/h3>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/Cb5NxD4.jpg\")
<\/figure>\n\n\n\nAI Assistant w IntelliJ Idea<\/h4>\n\n\n\n
Wydanie IntelliJ IDEA 2023.3 przynios\u0142o dost\u0119pnego dla wszystkich zainteresowanych Asystent AI, kt\u00f3ry opu\u015bci\u0142 faz\u0119 testow\u0105. Oferuje on ulepszon\u0105 generacj\u0119 kodu bezpo\u015brednio w edytorze, kontekstow\u0105 czat AI do zapyta\u0144 zwi\u0105zanych z projektem oraz akcje AI \u015bwiadome projektu, wykorzystuj\u0105ce rozszerzony kontekst do uzyskania bardziej kompleksowych wynik\u00f3w. Wyobra\u017acie sobie taki ChatGPT wbudowany w Wasze IDE, z kilkoma dodatkowymi usprawniaczami dzi\u0119ki byciu mocno zintegrowanym z samym IDE \u2013 tak zwanymi AI Actions.<\/p>\n\n\n\n
\n- Docker acquires AtomicJar, company behind Testcontainers – JVM Weekly vol. 64<\/a><\/li>\n<\/ul>\n\n\n\n
Gradle 8.0<\/h4>\n\n\n\n
Ga\u0142\u0105\u017a Gradle 8.x to przede wszystkim prace nad Kotlin DSL, alternatywn\u0105 sk\u0142adni\u0105 do tradycyjnego Groovy DSL, zapewniaj\u0105c lepsze podpowiadania sk\u0142adni przy edycji, kt\u00f3re sta\u0142o si\u0119 od tego wydania wariantem domy\u015blnym. Wraz z Gradle 8.0 poprawiona zostala kompilacji skrypt\u00f3w poprzez wprowadzenie interpretera dla deklaratywnych blok\u00f3w plugin\u00f3w {} w skryptach .gradle.kts, co daje zysk rz\u0119du 20%, zbli\u017caj\u0105c czas procesowania Kotlin DSL do Gradle DSL.<\/p>\n\n\n\n
Ale je\u015bli chodzi o Gradle, to jeszcze ciekawsze rzeczy pokaza\u0142o JetBrains.<\/p>\n\n\n\n
\n- Curious about Carbon Footprint your application has? There’s a tool to measure it – JVM Weekly #34<\/a><\/li>\n<\/ul>\n\n\n\n
Amper od JetBrains<\/h4>\n\n\n\n
Programi\u015bci do\u015bwiadczaj\u0105 zmieniaj\u0105cych si\u0119 trend\u00f3w w zarz\u0105dzaniu procesami budowania i integracji ci\u0105g\u0142ej. W ostatnich latach (a mo\u017ce nawet dekadzie), popularne sta\u0142y si\u0119 rozwi\u0105zania CI\/CD jak Github Actions czy TravisCI, oparte na deklaratywnych konfiguracjach w YAML. W ekosystemie Javy, mimo dost\u0119pno\u015bci Mavena z jego XML-em, wielu deweloper\u00f3w przenios\u0142o si\u0119 na Gradle ze wzgl\u0119du na jego wi\u0119ksz\u0105 elastyczno\u015b\u0107, cho\u0107 czasami prowadzi to do skomplikowanych skrypt\u00f3w.<\/p>\n\n\n\n
Ten trend wskazuje na ci\u0105g\u0142e wyzwania w zarz\u0105dzaniu z\u0142o\u017conymi projektami, szczeg\u00f3lnie w JetBrains, gdzie Kotlin Multiplatform uwidoczni\u0142 problematyk\u0119 Gradle. W odpowiedzi na te wyzwania, JetBrains rozpocz\u0105\u0142o Project Amper, maj\u0105cym na celu uproszczenie konfiguracji konfiguracji Gradle przez u\u017cycie YAML. Amper obecnie wspiera Kotlin i Kotlin Multiplatform, a tak\u017ce Jav\u0119 i Swifta. Ta inicjatywa ma na celu uczynienie Gradle bardziej dost\u0119pnym i mniej skomplikowanym.<\/p>\n\n\n
\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2023\/11\/image-14.png\")
Chyba nigdy nie uciekniemy od YAML-a<\/figcaption><\/figure><\/div>\n\n\n\n- Amper by JetBrains: Defining Gradle Builds through YAML – JVM Weekly vol. 61<\/a><\/li>\n<\/ul>\n\n\n\n
Oficjalne Java Extension for Visual Studio Code od Oracle<\/h4>\n\n\n\n
Oracle opublikowa\u0142o oficjalne rozszerzenie Javy dla \u015brodowiska Visual Studio Code, co stanowi stanowi z ich strony znaczny krok w uznaniu VSCode jako alternatywy dla tradycyjnych \u015brodowisk programistycznych. Pomimo istnienia wyspecjalizowanych narz\u0119dzi dla Javy, jak Intellij, coraz wi\u0119cej programist\u00f3w, w tym studenci i ci pracuj\u0105cy z r\u00f3\u017cnymi j\u0119zykami, preferuje u\u017cywanie tego toola. Rozszerzenie dostarcza funkcje takie jak auto-uzupe\u0142nianie, pod\u015bwietlanie b\u0142\u0119d\u00f3w, wsparcie dla debugowania oraz integracj\u0119 z projektami Gradle i Maven. Wa\u017cn\u0105 cech\u0105 jest wykorzystanie serwera j\u0119zyka opartego na protokole Language Server Protocol, pochodz\u0105cego z NetBeans (o samym LSP mo\u017cecie poczyta\u0107 troch\u0119 ni\u017cej).<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Major changes in Kotlin\u2019s leadership: Roman Elizarov departs from JetBrains<\/a><\/li>\n<\/ul>\n\n\n\n
Azul Zulu JDK 17 with CRaC support<\/h4>\n\n\n\n
Azul wyda\u0142 wersje swojego OpenJDK 17 – Zulu – z wbudowanym wsparciem dla CRaC API. Jak ju\u017c wspomnia\u0142em przy Springu, CRaC API umo\u017cliwia tworzenie „checkpoint\u00f3w” w trakcie pracy aplikacji, co pozwala na zapisanie pe\u0142nego stanu \u015brodowiska uruchomieniowego. Dzia\u0142a to podobnie do funkcji Save State w emulatorach, gdzie zapisywany jest ca\u0142y stan pami\u0119ci na dysk i mo\u017ce by\u0107 p\u00f3\u017aniej odtwarzany. Azul jest pierwszym dostawc\u0105, kt\u00f3ry oferuje komercyjne wsparcie dla tej technologii, co mo\u017ce by\u0107 interesuj\u0105ce w\u0142a\u015bnie dla early adopter\u00f3w nowych featur\u00f3w Spring Framework 6.1.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- JEP 450: The child of Project Lilliput – JVM Weekly vol. 44<\/a><\/li>\n<\/ul>\n\n\n\n
Liberica JDK Performance Edition<\/h4>\n\n\n\n
BellSoft wprowadzi\u0142 na rynek Liberica JDK Performance Edition, zmodyfikowan\u0105 wersj\u0119 JDK 11, w kt\u00f3rej zintegrowano poprawki wydajno\u015bciowe z JDK 17. To rozwi\u0105zanie umo\u017cliwia firmom korzystaj\u0105cym z JDK 11 zwi\u0119kszenie wydajno\u015bci aplikacji o 10-15% bez konieczno\u015bci zmian w kodzie. Liberica JDK Performance Edition jest dost\u0119pna dla subskrybent\u00f3w Liberica JDK od 1 sierpnia bez dodatkowych op\u0142at i jest dostarczana wraz z innymi narz\u0119dziami od BellSoft.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n\n- Fury: Compromise between speed and flexibility in the serialization process – JVM Weekly vol. 53<\/a><\/li>\n<\/ul>\n\n\n\n
Nowi ciekawi gracze<\/h3>\n\n\n\n![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/I1zbPjY.jpg\")
<\/figure>\n\n\n\nFury<\/h4>\n\n\n\n
Fury, stworzony przez Ant Group, to nowa biblioteka do serializacji, \u0141\u0105czy ona wydajno\u015b\u0107 serializacji statycznej z elastyczno\u015bci\u0105 dynamicznej serializacji, co mo\u017ce znale\u017a\u0107 zastosowanie w przypadku, gdy potrzebna jest du\u017ca przepustowo\u015b\u0107 w masowej transmisji danych. Oferuje ona pe\u0142n\u0105 kompatybilno\u015b\u0107 z rozwi\u0105zaniami ju\u017c istniej\u0105cymi w Javie i wykorzystuje nie tylko zaawansowane techniki serializacji, ale te\u017c operacje SIMD z Vector API oraz podej\u015bcie Zero-Copy, minimalizuj\u0105c op\u00f3\u017anienia podczas transferu danych. Fury wykorzystuje tak\u017ce kompilator JIT, kt\u00f3ry generuje zoptymalizowany kod serializacji w czasie rzeczywistym.<\/p>\n\n\n\n
<\/figure>\n\n\n\nRok 2023 zapami\u0119tamy te\u017c jako ten, podczas kt\u00f3rego GraalVM przeszed\u0142 spor\u0105 transformacj\u0119. Pierwsz\u0105 kluczow\u0105 zmian\u0105 by\u0142y kwestie licencyjne, kt\u00f3re to rozpocz\u0119\u0142y si\u0119 jeszcze w ko\u0144c\u00f3wce 2022. GraalVM, tradycyjnie oferowa\u0142 dwie edycje – Community (CE) i Enterprise (EE). Na JavaOne 2022 zapowiedziano w\u0142\u0105czenie GraalVM CE pod skrzyd\u0142a OpenJDK (w ramach projektu Galahad). W po\u0142owie 2023 zdecydowano si\u0119 na r\u00f3wnie du\u017cy krok, je\u015bli chodzi Enterprise Edition. Ta zosta\u0142a zast\u0105piona przez Oracle GraalVM, now\u0105 dystrybucj\u0119 z modelem licencyjnym, znanym jako GraalVM Free Terms and Conditions (GFTC). Ta zmiana licencyjna u\u0142awia darmowe u\u017cycie najnowszej wersji Oracle GraalVM zar\u00f3wno w \u015brodowiskach deweloperskich, jak i komercyjnych, co stanowi znacz\u0105cy krok naprz\u00f3d w por\u00f3wnaniu do poprzednich ogranicze\u0144 licencyjnych.<\/p>\n\n\n
Kolejn\u0105 istotn\u0105 nowo\u015bci\u0105 jest wprowadzenie Graal Cloud Native (GCN). To specjalna wersja zestawu modu\u0142\u00f3w frameworka Micronaut (o Micronaucie jeszcze b\u0119dzie troch\u0119 p\u00f3\u017aniej), zaprojektowana do tworzenia mikroserwis\u00f3w w spos\u00f3b pe\u0142ni kompatybilna z kompilacj\u0105 GraalVM Native Image. Mo\u017cna je de facto uzna\u0107 za pierwszy pe\u0142noprawny framework GraalVM-First.<\/p>\n\n\n\n
R\u00f3wnie\u017c w 2023 opublikowany zosta\u0142 GraalOS, nowe \u015brodowisko uruchomieniowe dla aplikacji chmurowych, skoncentrowane na optymalizacji funkcji serverless poprzez mo\u017cliwo\u015b\u0107 odpalenia ich (dzi\u0119ki GraalVM) na serwerach bare metal. GraalOS wykorzystuje kompilacj\u0119 ahead-of-time (AOT) do konwersji aplikacji w samodzielne natywne pliki wykonywalne, co pozwala na eliminacj\u0119 „cold start\u00f3w” i zwi\u0119ksza wydajno\u015b\u0107 aplikacji serverless. GraalOS w teorii ma by\u0107 dost\u0119pny dla ka\u017cdego \u015brodowiska, ale jest zaprojektowany do integracji z Oracle Cloud Infrastructure Functions i stanowi\u0107 ma przewag\u0119 konkurencyjn\u0105 tego \u015brodowiska. Zobaczymy, czy stanie si\u0119 odpowiednim argumentem dla rozwi\u0105zania Oracle.<\/p>\n\n\n\n
Warto zauwa\u017cy\u0107, \u017ce AWS Lambda umo\u017cliwia ju\u017c obs\u0142ug\u0119 GraalVM w ramach tak zwanego niestandardowego \u015brodowiska wykonawczego. Jednak\u017ce zasadniczo wi\u0105\u017ce si\u0119 to z uruchomieniem kontenera z aplikacj\u0105 GraalVM. GraalOS umo\u017cliwia obej\u015bcie tej warstwy, eliminuj\u0105c potrzeb\u0119 uruchamiania kontenera i inicjowania maszyny JVM.<\/p>\n\n\n\n
Opr\u00f3cz powy\u017cszych zmian, ewolucje przeszed\u0142 r\u00f3wnie\u017c Truffle. Ten metaframework umo\u017cliwiaj\u0105cy tworzenie interpreter\u00f3w j\u0119zyk\u00f3w programowania na potrzeby ich uruchomienia w ramach GraalVM, zosta\u0142 oddzielony od g\u0142\u00f3wnej platformy. Same interpretery dla Pythona czy JavaScripta dost\u0119pne s\u0105 teraz jako osobne pakiety, kt\u00f3re mo\u017cemy zaczyta\u0107 jako zwyk\u0142a dependencja projektu, pomijaj\u0105c wcze\u015bniej wymagany customowy tooling.<\/p>\n\n\n\n
Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Teraz cofniemy si\u0119 o ca\u0142e 12 miesi\u0119cy – MicroProfile 6.0 by\u0142 bowiem pierwsz\u0105 du\u017c\u0105 premier\u0105 roku 2023. Poza standaryzacj\u0105 nowego zestawu API, przyni\u00f3s\u0142 on za\u015b oczekiwane uporz\u0105dkowanie tego, jak wygl\u0105da obecnie relacja projektu z Jakarta EE.<\/p>\n\n\n\n Wraz z Jakarta EE 10 pojawi\u0142 si\u0119 tak zwany Core Profile \u2013 zestaw API, kt\u00f3re zgodnie z planami tw\u00f3rc\u00f3w maj\u0105 stanowi\u0107 minimum niezb\u0119dne do tworzenia mikrous\u0142ug w Javie. Brzmi to bardzo podobnie do celu, jaki postawili sobie tw\u00f3rcy MicroProfile, dlatego od pocz\u0105tku zastanawiali\u015bmy si\u0119, w jaki spos\u00f3b pojawienie si\u0119 Core Profile na niego wp\u0142ynie. Jaka\u015b forma synergii wydawa\u0142a si\u0119 tutaj by\u0107 bardzo naturalna, ale r\u00f3wnocze\u015bnie od pocz\u0105tku pojawia\u0142y si\u0119 jasne komunikaty, \u017ce nie nale\u017cy spodziewa\u0107 si\u0119 dw\u00f3ch inicjatyw w jedn\u0105. Ich tw\u00f3rcy jednak zapewniali, \u017ce pozostaj\u0105 ze sob\u0105 w sta\u0142ym kontakcie i w przyjacielskich stosunkach.<\/p>\n\n\n Przed premier\u0105 MicroProfile 6.0, strategi\u0105 standardu by\u0142o wybieranie sobie z Jakarta EE tych API, kt\u00f3re wed\u0142ug tw\u00f3rc\u00f3w projektu mia\u0142y by\u0107 najbardziej przydatne dla u\u017cytkownika MP. W wypadku MicroProfile 5.0 by\u0142o to wi\u0119c:<\/p>\n\n\n\n Od wydania MicroProfile 6.0 projekt dokona\u0142 alignementu z Jakarta Core Profile. Oznacza to, \u017ce zamiast na pojedynczych API b\u0119dzie on posiada\u0142 zale\u017cno\u015b\u0107 na pe\u0142nym Profilu, a tranzytywne trafi\u0105 do niego r\u00f3wnie\u017c nast\u0119puj\u0105ce API:<\/p>\n\n\n\n Ze zrozumia\u0142ych powod\u00f3w, minimalna wersja Jakarta EE wspierana przez MicroProfile to teraz Jakarta EE 10.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n O ile w wypadku JavaScriptowych infrastrukturalnych projekt\u00f3w do\u015b\u0107 cz\u0119sto (a przynajmniej 2021 i 2022 nas w tym temacie dosy\u0107 rozpie\u015bci\u0142y) mamy do czynienia z og\u0142oszeniami nowych rund zewn\u0119trznego finansowania (Vercel, Deno), o tyle relatywnie rzadko s\u0142yszy si\u0119, aby jaka\u015b javowa biblioteka zak\u0142ada\u0142a w\u0142asn\u0105 chmur\u0119 (chyba, \u017ce bierzemy tutaj pod uwag\u0119 takiego Confluence i Kafk\u0119). Dlatego te\u017c ze sporym u\u015bmiechem \u015bledzi\u0142em tegoroczne og\u0142oszenia od AtomicJar.<\/p>\n\n\n\n \u017beby przedstawi\u0107, na co maj\u0105 i\u015b\u0107 dane \u015brodki, warto przypomnie\u0107 sobie czym AtomicJar si\u0119 zajmuje. Kojarzycie TestContainers? Jest to biblioteka wspieraj\u0105ca dla JUnita, zapewniaj\u0105ca lekkie, jednorazowe instancje popularnych baz danych, przegl\u0105darek internetowych dla Selenium i og\u00f3lnie wszystkiego, co mo\u017cna \u0142atwo uruchomi\u0107 w kontenerze Dockera. Wprawdzie wiele os\u00f3b pewnie b\u0119dzie z\u017cyma\u0107 si\u0119 na uruchamianie kontener\u00f3w w testach jednostkowych, ale popularno\u015b\u0107 TestContainers udowadnia, jak bardzo cz\u0119sty jest to przypadek u\u017cycia.<\/p>\n\n\n W lutym AtomicJar pozyska\u0142o 25 milion\u00f3w dolar\u00f3w finansowania. \u015arodki te mia\u0142y na celu rozw\u00f3j TestContainers Cloud – rozwi\u0105zania Software-as-a-Service, kt\u00f3re umo\u017cliwia uruchamianie kontener\u00f3w nie lokalnie, ale w chmurze. Mia\u0142o to na celu u\u0142atwienie pracy programistom, zw\u0142aszcza w kontek\u015bcie ci\u0119\u017cszych test\u00f3w i ogranicze\u0144 sprz\u0119towych.<\/p>\n\n\n\n Nast\u0119pnym krokiem by\u0142a premiera Testcontainers Desktop, aplikacj\u0119 maj\u0105c\u0105 na celu przyspieszenie startu test\u00f3w poprzez funkcje takie jak sta\u0142e porty czy mo\u017cliwo\u015b\u0107 zamra\u017cania kontener\u00f3w dla cel\u00f3w debugowania. Testcontainers Desktop stanowi\u0142 u\u0142atwienie dla tych, kt\u00f3rzy wci\u0105\u017c preferuj\u0105 lokalne \u015brodowisko testowe, jednocze\u015bnie daj\u0105c dost\u0119p do wersji pr\u00f3bnej Testcontainers Cloud.<\/p>\n\n\n\n Kulminacyjnym wydarzeniem roku by\u0142o przej\u0119cie AtomicJar przez Docker w grudniu. Tranzakcja mia\u0142a strategiczne znaczenie zar\u00f3wno dla samego Dockera (kt\u00f3ry z przytupem wkroczy\u0142 w ten spos\u00f3b w rynek Cloud DevEnvironments), jak i dla Tescontiners, potencjalnie rozszerzaj\u0105c baz\u0119 u\u017cytkownik\u00f3w ich rozwi\u0105zania, kt\u00f3re dzi\u0119ki wsp\u00f3\u0142pracy z Dockerem ma szanse wyj\u015b\u0107 poza \u015bwiat Javy i sta\u0107 si\u0119 rynkowym standardem.<\/p>\n\n\n\n Oby wi\u0119cej takich historii w 2024.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n O ile powy\u017csze przej\u0119cie witam bardzo optymistycznie, to jednak nie ka\u017cde og\u0142oszenie tego typu to pow\u00f3d do rado\u015bci. Dla nikogo zaskoczeniem nie b\u0119dzie, \u017ce du\u017ce projekty Open-Source w dzisiejszych czasach zwykle posiadaj\u0105 swoich korporacyjnych sponsor\u00f3w, a wielu ludzi rozwijaj\u0105cych je robi\u0105 to w ramach firmowych etat\u00f3w. Dlatego te\u017c ruchy sp\u00f3\u0142ek gie\u0142dowych potrafi\u0105 mie\u0107 na ich rozw\u00f3j olbrzymi wp\u0142yw.<\/p>\n\n\n Pivotal Software (stoj\u0105cy za Springiem) i VMware maj\u0105 ze sob\u0105 silne powi\u0105zania historyczne i biznesowe, czego kulimancj\u0105 w 2019 by\u0142o przej\u0119cie Pivotala przez t\u0105 drug\u0105 firm\u0119. W 2023 dosz\u0142o do kolejnych akwizycji samego VMWare – Broadcom, znany g\u0142\u00f3wnie z produkcji p\u00f3\u0142przewodnik\u00f3w, podj\u0105\u0142 decyzj\u0119 o rozszerzeniu swojej dzia\u0142alno\u015bci na rynku oprogramowania. Wyb\u00f3r pad\u0142 na VMware, jako \u017ce firma uznawana jest za lidera w dziedzinie wirtualizacji i infrastruktury chmurowej, co stanowi\u0142o atrakcyjny kierunek rozwoju dla Broadcom. Przej\u0119cie rozpocz\u0119te w maju 2022, a b\u0119d\u0105ce jedn\u0105 z wi\u0119kszych transakcji tego typu opiewaj\u0105c\u0105 na 69 miliard\u00f3w dolar\u00f3w, domkni\u0119to finalnie w zesz\u0142ym tygodniu, 22 listopada.<\/p>\n\n\n\n Bardzo szybko po transakcji dosz\u0142o do serii zwolnie\u0144 w firmie. Nie wiemy jaki jest ich zakres, ale na pewno zaafektowa\u0142y one te\u017c zesp\u00f3\u0142 odpowiadaj\u0105cy za najpopularniejszy javowy framework. Oliver Drotbohm, architekt Springa, kt\u00f3ry od ponad dekady prowadzi projekt Spring Data, podsumowa\u0142 ca\u0142o\u015b\u0107 wymownie.<\/p>\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n Jak ju\u017c wspomnia\u0142em na samym pocz\u0105tku, poza wyj\u0105tkowymi okazjami jak JDK 21, Java bardzo rzadko trafia na j\u0119zyki spo\u0142eczno\u015bci programistycznej. O ile nas interesowa\u0107 mog\u0105 zmiany w maszynie wirtualnej i inne wiadomo\u015bci z ekosystemu, to jednak kto\u015b \u201eniezainwestowany\u201d w ekosystem o Javie s\u0142yszy g\u0142\u00f3wnie w momencie internetowych \u201edram\u201d. A z tak\u0105 mieli\u015bmy do czynienia pocz\u0105tkiem lutego, a wszystko przez to, \u017ce Oracle zdecydowa\u0142 si\u0119 zmieni\u0107 spos\u00f3b naliczania op\u0142at za swoje JDK. Nie mog\u0119 wi\u0119c nie po\u015bwi\u0119ci\u0107 miejsca temu faktowi w podsumowaniu roku.<\/p>\n\n\n 23 stycznia Oracle poinformowa\u0142, \u017ce zmienia model licencyjny Oracle JDK na Java SE Universal Subscription. Nowy cennik, zamiast bazowa\u0107 na stanowiskach roboczych i procesorach, opiera si\u0119 na ilo\u015bci pracownik\u00f3w zatrudnianych przez firm\u0119: w tych do 1000 pracownik\u00f3w op\u0142aty wynosz\u0105 15$\/mc, dla wi\u0119kszych 5,25$\/mc. Dla wielu (wi\u0119kszo\u015bci?) firm korzystaj\u0105cych z Oracle JDK oznacza to b\u0119dzie wzrost koszt\u00f3w, poniewa\u017c w obliczeniach brani s\u0105 pod uwag\u0119 nie tylko programi\u015bci, ale wszyscy pracownicy firmy \u2013 tak\u017ce ci spoza dzia\u0142u IT, a tak\u017ce np. kontraktorzy.<\/p>\n\n\n\n Zmiany nie dotyczy ju\u017c p\u0142ac\u0105cych klient\u00f3w, kt\u00f3rzy b\u0119d\u0105 mogli si\u0119 rozlicza\u0107 na wsp\u00f3\u0142czesnych warunkach (aczkolwiek nie uda\u0142o mi si\u0119 dogrzeba\u0107, w jaki spos\u00f3b rozwi\u0105zane zostanie np. rozszerzenie licencji). Ko\u0144cz\u0105c na pozytywnej nucie, zapisy mog\u0105 by\u0107 teoretycznie korzystne dla niekt\u00f3rych firm, zw\u0142aszcza ma\u0142ych startup\u00f3w stricte technologicznych, posiadaj\u0105cych ma\u0142\u0105 ilo\u015b\u0107 pracownik\u00f3w. Enterprise trac\u0105 chyba w ka\u017cdej konfiguracji, ale mali, szybko skaluj\u0105cy si\u0119 mog\u0105 zyska\u0107 \u2013 aczkolwiek wbrew tej teorii mo\u017ce by\u0107 fakt wysokich op\u0142at per pracownik (15$\/mc) w firmach poni\u017cej 1000 zatrudnionych os\u00f3b.<\/p>\n\n\n\n Nale\u017cy pami\u0119ta\u0107, \u017ce Oracle nie jest jedynym dostawc\u0105 JDK, wi\u0119c ka\u017cdy chc\u0105cy u\u017cywa\u0107 Javy za darmo, mo\u017ce u\u017cy\u0107 np. Adoptium. Co jest smutne \u2013 \u015bwietnie wiedz\u0105 to ludzie znaj\u0105cy ekosystem Javy, ale dla szerokiego odbiorcy jest to stan mocno nieintuicyjny. W ko\u0144cu nie ma alternatywnych dystrybucji Go czy Rusta (albo s\u0105 statystycznie pomijalne).<\/p>\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n 2023 to te\u017c kolejny rok iteracji nad Valhall\u0105. Projekt ulega dalszej rewolucji i z ka\u017cd\u0105 kolejn\u0105 iteracj\u0105 staje si\u0119 coraz ciekawszy i ma szanse (troch\u0119 przypadkiem) da\u0107 nam usprawnienia, na kt\u00f3re programi\u015bci czekali… no w zasadzie od zawsze. Jedn\u0105 z funkcji j\u0119zyka, kt\u00f3re dostarczy\u0107 ma Valhalla s\u0105 Value Type (czy jak one si\u0119 tam teraz po kolejnych iteracjach maj\u0105 nazywa\u0107). G\u0142\u00f3wnym rozr\u00f3\u017cnieniem mi\u0119dzy \u201etypem referencyjnym\u201d (czyli obecnie istniej\u0105cymi w j\u0119zyku) a \u201etypem warto\u015bci\u201d jest fakt, \u017ce te drugie nie mog\u0105 przyjmowa\u0107 warto\u015bci null. W odr\u00f3\u017cnieniu od takiego Kotlina, w\u0142asno\u015b\u0107 ta nie jest \u0142atwo wyra\u017calna w samym j\u0119zyku. Dlatego te\u017c projektanci do Valhalli rozwa\u017caj\u0105 wprowadzenie nowego znacznika \u201enullness\u201d dla obiekt\u00f3w.<\/p>\n\n\n\n Je\u015bli nie \u015bledzicie na bie\u017c\u0105co rozwoju Valhalli, mo\u017cliwe, \u017ce umkn\u0105\u0142 Wam fakt, \u017ce w pewnym momencie tw\u00f3rcy zaproponowali sufiksy W odr\u00f3\u017cnieniu od takiego Kotlina, w\u0142asno\u015b\u0107 ta nie jest \u0142atwo wyra\u017calna w samym j\u0119zyku. Dlatego te\u017c projektanci do Valhalli rozwa\u017caj\u0105 wprowadzenie nowego znacznika \u201enullness\u201d dla obiekt\u00f3w. Pojawi\u0142a si\u0119 propozycja wprowadzenia dw\u00f3ch dodatkowych oznacze\u0144 przy definiowaniu typu \u2013 ! oznaczaj\u0105cy nie dopuszczamy nulla oraz ? oznaczaj\u0105cy ten obiekt jest nullowalny. W skr\u00f3cie:<\/p>\n\n\n\n Z czasem, tw\u00f3rcy b\u0119d\u0105 d\u0105\u017cy\u0107 do tego, aby wersja bez odpowiedniej adnotacji przyjmowa\u0142a cechy wariant\u00f3w anotowanych \u2013 na ten moment wydaje si\u0119, \u017ce nieoznaczone Foo b\u0119dzie w wi\u0119kszo\u015bci przypadk\u00f3w traktowane jako nienulowalne.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n JVMLS to roczne wydarzenie, kt\u00f3re gromadzi ekspert\u00f3w i in\u017cynier\u00f3w zwi\u0105zanymi z rozwojem JVM, aby omawia\u0107 aktualne udoskonalenia i przysz\u0142o\u015b\u0107 tej platformy. W tym roku mamy dost\u0119p do masy materia\u0142\u00f3w z eventu, co pozwoli\u0142o nam zerkn\u0105\u0107 pod mask\u0119 wielu projekt\u00f3w, kt\u00f3re zwykle pozostaj\u0105 w cieniu.<\/p>\n\n\n\n Podczas JVMLS, sporo miejsca po\u015bwi\u0119cono Projektowi Leyden, kt\u00f3ry wprowadza now\u0105 technik\u0119 optymalizacji kodu Javy, opart\u0105 na „przesuwaniu i ograniczaniu” oblicze\u0144 . Projekt ten umo\u017cliwi\u0107 ma tworzeniu „kondensator\u00f3w”, kt\u00f3re analizuj\u0105 zachowanie aplikacji w czasie rzeczywistym i dostosowuj\u0105 j\u0105 do efektywnego dzia\u0142ania. Dzi\u0119ki temu, aplikacje Java mog\u0105 by\u0107 zoptymalizowane ju\u017c przed uruchomieniem, co skraca czas „rozgrzewania” i zapewnia d\u0142u\u017csze okresy szczytowej wydajno\u015bci. Na JVMLS po raz pierwszy mogli\u015bmy przygl\u0105dn\u0105\u0107 si\u0119 wynikom prac, zaprezentowany zosta\u0142 Kolejnym interesuj\u0105cym projektem jest Projekt Babylon, kt\u00f3ry ma na celu dostarczenie bardziej zaawansowanych mo\u017cliwo\u015bci ni\u017c istniej\u0105ce mechanizmy refleksji w Javie, poprzez wprowadzenie tak zwanej „refleksji kodu”. W odr\u00f3\u017cnieniu od standardowej refleksji, dzia\u0142aj\u0105cej w runtime, ta ma pozwoli\u0107 programistom na analiz\u0119 i manipulacj\u0119 kodem \u017ar\u00f3d\u0142owym r\u00f3wnie\u017c w czasie kompilacji, umo\u017cliwiaj\u0105c dynamiczne generowanie kodu dla r\u00f3\u017cnych \u015brodowisk uruchomieniowych, podobnie jak LINQ w j\u0119zyku C#.<\/p>\n\n\n Projekt Panama te\u017c nie zwalnia, i po ogarni\u0119ciu tematy Foreign Memory i usprawnieniu pracy z programami napisanymi w j\u0119zykach „natywnych”, ma teraz na celu u\u0142atwienie integracji Javy z nietypowymi \u015brodowiskami uruchomieniowymi, takimi jak np. GPU. Dzi\u0119ki Panama, programi\u015bci b\u0119d\u0105 mieli lepsz\u0105 kontrol\u0119 nad transferem danych mi\u0119dzy r\u00f3\u017cnymi rodzajami pami\u0119ci oraz nad dzia\u0142aniem Garbage Collectora, co u\u0142atwi prac\u0119 z frameworkami zwi\u0105zanymi z uczeniem maszynowym i sztuczn\u0105 inteligencj\u0105. Jego tw\u00f3rcy mocno wsp\u00f3\u0142pracuj\u0105 i wymieniaj\u0105 do\u015bwiadczenia z TornadoVM, platform\u0105 pozwalaj\u0105c\u0105 na wykonywanie aplikacji Java na r\u00f3\u017cnych platformach sprz\u0119towych, w tym na GPU, FPGA i systemach wielordzeniowych.<\/p>\n\n\n TornadoVM wykorzystuje kompilator JIT GraalVM, co pozwala na przekszta\u0142canie kodu Java w natywny kod maszynowy, co w wielu przypadkach znacz\u0105co przyspieszy\u0107 wydajno\u015b\u0107 aplikacji. Tworz\u0105 oni te\u017c u\u017cyteczne abstrakcje, u\u0142atwiaj\u0105c\u0105 tworzenie portowalnego kodu. W tym roku (rzutem na ta\u015bm\u0119, w grudniu) wreszcie ukaza\u0142a si\u0119 jego wersja 1.0<\/a>, wi\u0119c mo\u017cna my\u015ble\u0107 o szerszej adopcji \ud83d\ude09<\/p>\n\n\n\n Zdecydowanie nie mog\u0119 si\u0119 doczeka\u0107 JVMLS 2024.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszej edycji:<\/strong><\/p>\n\n\n\n W \u015bwiecie Kotlina szykuj\u0105 si\u0119 spore zmiany \u2013 przynajmniej je\u015bli chodzi o numeracje, aczkolwiek na niej si\u0119 nie sko\u0144czy.<\/p>\n\n\n\n Tw\u00f3rcy og\u0142osili bowiem, \u017ce wydanie 1.9 b\u0119dzie ostatnim z linii 1.x. Wersja 1.10 si\u0119 nie poka\u017ce, zamiast niej przeskoczymy od razu do wydania 2.0. Wynika\u0107 ma to z faktu, \u017ce to w\u0142a\u015bnie na t\u0105 wersje planowane jest wydanie d\u0142ugo oczekiwanego kompilatora K2 \u2013 \u201ejednego, by wszystkimi rz\u0105dzi\u0107\u201d i maj\u0105cego zapewni\u0107 wsp\u00f3ln\u0105 infrastruktur\u0119 dla wszystkich potencjalnych target\u00f3w j\u0119zyka. Dzi\u0119ki temu jego tw\u00f3rcy nie b\u0119d\u0105 musieli ka\u017cdorazowo implementowa\u0107 tych samych funkcjonalno\u015bci na potrzeby JVM, WebAssembly czy Androida, co ma znacznie przyspieszy\u0107 ewolucje Kotlina. Zmiana jest wi\u0119c na tyle du\u017ca, \u017ce uznano za zasadne odpowiednie ukoronowanie jej podbiciem numeracji.<\/p>\n\n\n\n Zmiana \u201edu\u017cej\u201d wersji j\u0119zyka potrafi\u0142a mocno zamiesza\u0107 w ekosystemie danego j\u0119zyka, jednak w wypadku Kotlina JetBrains obiecuje bardzo stabilny proces migracji. Ma by\u0107 to mo\u017cliwe do osi\u0105gni\u0119cia dzi\u0119ki dw\u00f3m sk\u0142adowym. Po pierwsze, zmiany motywuj\u0105ce podbicie numeracji odbywaj\u0105 si\u0119 pod mask\u0105, a tw\u00f3rcy celowo nie planuj\u0105 wprowadza\u0107 w nowym wydaniu \u017cadnych nowych nowo\u015bci w samym syntaksie j\u0119zyka \u2013 te zostawiaj\u0105 sobie na wydania 2.x, kt\u00f3re przyjd\u0105 po udanym przej\u015bciu na K2 (a ju\u017c kilka k\u0105sk\u00f3w zapowiedziano). Dodatkowo jednak JetBrains zyskuje na tym, \u017ce kontroluje zar\u00f3wno Kotlina, jak i jest g\u0142\u00f3wnym dostawc\u0105 narz\u0119dzi do niego. Pozwala to bowiem na znacznie sprawniejsze przeprowadzenie ca\u0142ej operacji, gdy wi\u0119kszo\u015b\u0107 najwa\u017cniejszego toolingu mo\u017ce by\u0107 rozwijana r\u00f3wnolegle z j\u0119zykiem.<\/p>\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Zostaj\u0105c w \u015bwiecie Kotlina ko\u0144c\u00f3wk\u0105 roku gruchn\u0119\u0142a du\u017ca informacja. Roman Elizarov, lead projektu, og\u0142osi\u0142 swoje odej\u015bcie z JetBrains z powod\u00f3w osobistych, ko\u0144cz\u0105c w ten spos\u00f3b r\u00f3wnie\u017c swoj\u0105 prac\u0119 nad j\u0119zykiem. Po\u017cegnanie odby\u0142o si\u0119 seri\u0105 tweet\u00f3w, w kt\u00f3rych wyra\u017caj\u0105c wdzi\u0119czno\u015b\u0107 za mo\u017cliwo\u015b\u0107 pracy nad Kotlinem i podkre\u015blaj\u0105c swoje wielkie uznanie dla spo\u0142eczno\u015bci Kotlina.<\/p>\n\n\n\n Dowiedzieli\u015bmy si\u0119 te\u017c kto w przysz\u0142o\u015bci stanie za sterami j\u0119zyka \u2013 Mikhail Zarechenskiy<\/a>, wcze\u015bniej pracuj\u0105cy za kulisami w JetBrains, zostanie g\u0142\u00f3wnym projektantem Kotlina. Kluczowe zmiany w zespole obejmuj\u0105 te\u017c Hadi Hariri<\/a>, kt\u00f3rego mo\u017cecie zna\u0107 jako Co-hosta podcastu Talking Kotlin \u2013 przejmie on teraz wi\u0119cej obowi\u0105zk\u00f3w poza dzia\u0142aniami promocyjnymi i jego zaanga\u017cowaniem w KotlinConf. R\u00f3wnie\u017c drugi prowadz\u0105cy Talking Kotlin, Sebastian Aigner<\/a>, b\u0119dzie odgrywa\u0107 teraz wa\u017cniejsz\u0105 rol\u0119 w Kotlin Foundation, szczeg\u00f3lnie w wsparciu inicjatyw szerszego ekosystemu Kotlin. Egor Tolstoy<\/a> dalej za\u015b b\u0119dzie kierowa\u0107 zespo\u0142em od strony Product Managementu.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n W Spring Framework 6.1 pojawi\u0142o si\u0119 wsparcie dla dw\u00f3ch kluczowych nowo\u015bci: Wirtualnych W\u0105tk\u00f3w oraz Projektu CRAC. Dla przypomnienia: Wirtualne W\u0105tki to nowy koncept w Javie, wprowadzony w JDK 21 w ramach Projektu Loom, kt\u00f3ry zmienia podej\u015bcie do wsp\u00f3\u0142bie\u017cno\u015bci. W przeciwie\u0144stwie do tradycyjnych w\u0105tk\u00f3w, kt\u00f3re s\u0105 zarz\u0105dzane przez system operacyjny, w\u0105tki wirtualne s\u0105 zarz\u0105dzane przez JVM, co pozwala na tworzenie du\u017cej liczby w\u0105tk\u00f3w bez narzutu zwi\u0105zanego z tradycyjnymi w\u0105tkami.<\/p>\n\n\n\n Projekt CRAC (Checkpoint\/Restore in Application Continuation) pozwala za\u015b na zapisanie stanu dzia\u0142aj\u0105cej JVM i jego przywr\u00f3cenie, skracaj\u0105c czas rozruchu aplikacji. To rozwi\u0105zanie redukuje problem „zimnego startu” aplikacji Javowych, co jest szczeg\u00f3lnie istotne dla aplikacji serwerowych i serverless. Spring integruje si\u0119 z CRAC, umo\u017cliwiaj\u0105c kontrolowane checkpointy i przywracanie stanu JVM.<\/p>\n\n\n\n Dodatkowo, w Spring Boot 3.2.0 wprowadzono rozszerzone wsparcie dla Apache Pulsara oraz interfejs RestClient z Spring Framework 6.1, kt\u00f3ry dostarcza prekonfigurowany klient HTTP do obs\u0142ugi zapyta\u0144 REST. Dodano tak\u017ce wsparcie dla Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Quarkus 3.0 wprowadza rozbudowane Dev UI, kt\u00f3re u\u0142atwia zarz\u0105dzanie i konfiguracj\u0119 aplikacji. Dzi\u0119ki funkcji Dev Mode, Quarkus umo\u017cliwia Continuous Testing, co przyczynia si\u0119 do wydajno\u015bci i komfortu pracy deweloper\u00f3w.<\/p>\n\n\n\n Niezwykle ciekaw\u0105 nowo\u015bci\u0105 jest te\u017c Mutiny2, biblioteka stworzona przez zesp\u00f3\u0142 Quarkusa do programowania reaktywnego i asynchronicznego. Mutiny2 ma na celu uproszczenie kodu reaktywnego, oferuj\u0105c podej\u015bcie bardziej intuicyjne od innych bibliotek, jak RxJava i Project Reactor. Jest to tak\u017ce symboliczne zamkni\u0119cie pewnej epoki, poniewa\u017c Mutiny w nowej wersji przechodzi z w\u0142asnej implementacji Reactive Streams API na standardowe Jednak cho\u0107 Quarkus 3.0 przynosi wiele cennych zmian, brakuje pe\u0142nego wsparcia dla wirtualnych w\u0105tk\u00f3w, kt\u00f3re by\u0142o wspominane jako jedna z obiecuj\u0105cych funkcji.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Micronaut Framework 4.0 porzuca wsparcia dla wersji Java starszych ni\u017c JDK 17, co umo\u017cliwi\u0142o dostosowanie API do nowych sk\u0142adni j\u0119zyka, takich jak Java Records, Sealed Classes, Switch Expressions, Text Blocks czy Pattern Matching dla instanceof. Klient HTTP Micronaut zosta\u0142 zaktualizowany do wersji opartej na kliencie HTTP Java wprowadzonym w JDK 11, co poprawi\u0142o wydajno\u015b\u0107. Micronaut 4.0 zosta\u0142 te\u017c zoptymalizowany pod k\u0105tem wykorzystania GraalVM, dzi\u0119ki czemu kompilowanie aplikacji Micronaut zale\u017cnych od innych bibliotek sta\u0142o si\u0119 \u0142atwiejsze.<\/p>\n\n\n\n Ponadto, nowe wydanie wprowadza lepsze wsparcie dla chmur, modu\u0142ow\u0105 architektur\u0119 oraz wst\u0119pne wsparcie dla Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Helidon 4 zosta\u0142 pierwszym na \u015bwiecie frameworkiem do mikroserwis\u00f3w opartym o wirtualne w\u0105tki. G\u0142\u00f3wn\u0105 zmian\u0105 przychodz\u0105c\u0105 z wydaniem by\u0142o bowiem zast\u0105pienie Netty now\u0105 implementacj\u0105 serwera o nazwie N\u00edma. N\u00edma zosta\u0142 zaprojektowany tak, aby w pe\u0142ni wykorzystywa\u0107 wirtualne w\u0105tki Java 21, umo\u017cliwiaj\u0105c ka\u017cdemu requestowi dzia\u0142anie na dedykowanym wirtualnym w\u0105tku. Upraszcza to proces wykonywania blokuj\u0105cych operacji i zapewnia wysoki poziom wsp\u00f3\u0142bie\u017cno\u015bci, eliminuj\u0105c w ten spos\u00f3b potrzeb\u0119 skomplikowanego kodu asynchronicznego, co zwi\u0119ksza wydajno\u015b\u0107, zw\u0142aszcza (wed\u0142ug doniesie\u0144 samych tw\u00f3rc\u00f3w) w Helidon MP. Oznacza to r\u00f3wnie\u017c, \u017ce doczekali\u015bmy si\u0119 pierwszego framework wymagaj\u0105cego do dzia\u0142ania… Java 21.<\/p>\n\n\n Helidon SE, stanowi\u0105cy podstawowy zestaw API dla Helidon, r\u00f3wnie\u017c przeszed\u0142 spor\u0105 transformacj\u0119. Adopcja wirtualnych w\u0105tk\u00f3w umo\u017cliwi\u0142a przej\u015bcie od asynchronicznych API do blokuj\u0105cych (a\u017c si\u0119 sam dziwie pisz\u0105c to zdanie). Ta zmiana upraszcza kod, czyni\u0105c go \u0142atwiejszym w pisaniu, utrzymaniu i zrozumieniu \u2013 daje nam to przedsmak tego, co czeka pewnie w przysz\u0142o\u015bci ca\u0142y ekosystem. Osoby korzystaj\u0105ce z Helidon 3 SE b\u0119d\u0105 musia\u0142y niestety znacznie dostosowa\u0107 sw\u00f3j kod do zaktualizowanych API. Chocia\u017c mo\u017ce to wymaga\u0107 pewnego pocz\u0105tkowego wysi\u0142ku, korzy\u015bci w postaci zwi\u0119kszonej wydajno\u015bci i prostoty kodu wydaj\u0105 si\u0119 tego warte.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Pami\u0119tam czasy, gdy u\u017cywa\u0142em Dropwizarda, kiedy ten szumnie obiecuj\u0105cy framework znajdowa\u0142 si\u0119 na samym szczycie popularno\u015bci. Mimo pierwotnego entuzjazmu, DropWizard zacz\u0105\u0142 traci\u0107 na znaczeniu i premiera wersji 3.0 i 4.0 przesz\u0142a bez echa w \u015bwiecie technologii.<\/p>\n\n\n\n Pow\u00f3d dw\u00f3ch wersji na raz jest prosty: Dropwizard 3.0 opiera si\u0119 na Java EE i przestrzeni nazw Obie wersje \u0142\u0105czy te\u017c troch\u0119 wsp\u00f3lnych zmian \u2013 podniesienie wymaganej wersji Javy do 11, wprowadzenie struktury pakiet\u00f3w opartej o JPMS (mam wra\u017cenie, \u017ce to jedno z pierwszych narz\u0119dzi bior\u0105cych ten standard na powa\u017cnie), aktualizacj\u0119 Jetty do wersji 10.0.x (kt\u00f3ra te\u017c wymaga minimum Javy 11), aktualizacj\u0119 Apache HttpClient do wersji 5.x oraz usuni\u0119cie wsparcia dla JUnit 4.x (przeniesione do dropwizard-testing-junit4). Dodatkowo, tylko Dropwizard 4.0 dosta\u0142 wsparcie dla Hibernate 6.0, wymagaj\u0105cego przej\u015bcia na Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Kolejne podw\u00f3jne wydanie. Play Framework powr\u00f3ci\u0142 bowiem z nowymi wydaniami 2.9 i 3.0. Kiedy\u015b uwa\u017cany za g\u0142\u00f3wnego konkurenta Springa, Play wr\u00f3ci\u0142 do \u017cycia po tym jak zosta\u0142 przekazany spo\u0142eczno\u015bci po pewnym okresie stagnacji i kontrowersji zwi\u0105zanych z toksyczn\u0105 now\u0105 licencj\u0105 Akka, kt\u00f3rego to rozwi\u0105zania wykorzystywa\u0142 wewn\u0119trznie.<\/p>\n\n\n\n Dlatego wydanie 3.0 przynosi migracj\u0119 z Akki do Apache Pekko, forka Akka 2.6.x. Play 3.0 korzysta teraz z Pekko i jego komponent\u00f3w HTTP. Jednak\u017ce, dla aplikacji silnie zintegrowanych z Akk\u0105, ta zmiana mo\u017ce wymaga\u0107 pewnych wysi\u0142k\u00f3w migracyjnych. Dlatego r\u00f3wnocze\u015bnie wydano r\u00f3wnie\u017c Play 2.9, kt\u00f3re kontynuuje wykorzystanie Akki i Akka HTTP.<\/p>\n\n\n\n Poza powy\u017cszym Play 2.9 i 3.0 skupiaj\u0105 si\u0119 na wsparciu dla zaktualizowanych j\u0119zyk\u00f3w programowania, kompatybilno\u015bci z Scala 3, a tak\u017ce na dostosowaniu do nowszych wersji bibliotek, takich jak Akka HTTP 10.2, Guice 6.0.0 i Jackson 2.14. Warto zaznaczy\u0107, \u017ce Play Framework 3.0 przestaje wspiera\u0107 starsze wersje Javy, a minimalna wymagana wersja to Java 11.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Grails 6.0, najnowsza ods\u0142ona frameworka do tworzenia aplikacji webowych w j\u0119zyku Groovy, wprowadza kilka istotnych usprawnie\u0144. Najwa\u017cniejsz\u0105 nowo\u015bci\u0105 jest Grails Forge UI, kt\u00f3ry umo\u017cliwia programistom bardziej efektywne zarz\u0105dzanie projektami napisanymi w tym frameworku. Nowy interfejs dostarcza uproszczonego procesu inicjowania projekt\u00f3w, intuicyjnej nawigacji, walidacji w czasie rzeczywistym, wizualnego zarz\u0105dzania zale\u017cno\u015bciami oraz responsywnego designu.<\/p>\n\n\n\n Grails 6.0 r\u00f3wnie\u017c wzmocni\u0142 integracj\u0119 z Micronaut, u\u0142atwiaj\u0105c korzystanie z bean\u00f3w Micronauta w komponentach Grails oraz wykorzystuj\u0105c klienta HTTP Micronaut do bardziej p\u0142ynnej interakcji z REST API. Warto zaznaczy\u0107, \u017ce r\u00f3wnie\u017c Grails 6.0 podnosi minimalne wymagania dotycz\u0105ce JDK do wersji 11.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Swoj\u0105 premier\u0119 mia\u0142 te\u017c okr\u0105g\u0142y WildFly 30. Mimo \u017ce oficjalna rekomendacja to nadal JDK 17 lub 11, znacz\u0105ca cz\u0119\u015b\u0107 tego wydania zosta\u0142a po\u015bwi\u0119cona integracji z Java SE 21. Najnowsza wersja przechodzi na tej wersji testy certyfikacyjne zar\u00f3wno Jakarta EE 10 Core Profile, jak i Microprofile. Wraz z coraz wi\u0119kszym naciskiem na JDK 21 przewiduje si\u0119, \u017ce WildFly 30 mo\u017ce by\u0107 ostatnim, kt\u00f3re wspiera JDK 11.<\/p>\n\n\n\n Dodatkowo, wraz z przyj\u015bciem WildFly 30 nast\u0105pi\u0142a zmiana licencji z Lesser General Public License 2.1 na Apache Software License 2.0, podsumowuj\u0105c w ten spos\u00f3b d\u0142ugoletni\u0105 \u015bcie\u017ck\u0119. Przej\u015bcie z Lesser General Public License 2.1 (LGPL 2.1) na Apache Software License 2.0 (ASL 2.0) oznacza przej\u015bcie z licencji \u201es\u0142abej\u201d copyleft na bardziej liberaln\u0105.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Oko\u0142o rok temu Vaadin zaprezentowa\u0142 Hille, nowy framework webowy dla programist\u00f3w Java, kt\u00f3ry umo\u017cliwia tworzenie kompletnych aplikacji z backendem opartym na Spring Boot i frontendem napisanym w TypeScript. Wcze\u015bniej znany jako Vaadin Fusion, Hille oferuje sp\u00f3jn\u0105 konfiguracj\u0119 dla Java i TypeScript, bogaty zestaw komponent\u00f3w interfejsu u\u017cytkownika oraz konkuruj\u0105cy z JHipsterem stos technologiczny.<\/p>\n\n\n\n W najnowszej wersji 2.0 dodano ulepszony generator TypeScript, wsparcie dla WebSocket\u00f3w, kompatybilno\u015b\u0107 z GraalVM Native Image, uproszczon\u0105 tworzenie motyw\u00f3w graficznych i narz\u0119dzie SSO Kit do szybkiego wdro\u017cenia logowania jednokrotnego (SSO). Ta wersja korzysta z Spring Boot 3, Java 17 i Jakarta EE 10.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Wydanie IntelliJ IDEA 2023.3 przynios\u0142o dost\u0119pnego dla wszystkich zainteresowanych Asystent AI, kt\u00f3ry opu\u015bci\u0142 faz\u0119 testow\u0105. Oferuje on ulepszon\u0105 generacj\u0119 kodu bezpo\u015brednio w edytorze, kontekstow\u0105 czat AI do zapyta\u0144 zwi\u0105zanych z projektem oraz akcje AI \u015bwiadome projektu, wykorzystuj\u0105ce rozszerzony kontekst do uzyskania bardziej kompleksowych wynik\u00f3w. Wyobra\u017acie sobie taki ChatGPT wbudowany w Wasze IDE, z kilkoma dodatkowymi usprawniaczami dzi\u0119ki byciu mocno zintegrowanym z samym IDE \u2013 tak zwanymi AI Actions.<\/p>\n\n\n\n Ga\u0142\u0105\u017a Gradle 8.x to przede wszystkim prace nad Kotlin DSL, alternatywn\u0105 sk\u0142adni\u0105 do tradycyjnego Groovy DSL, zapewniaj\u0105c lepsze podpowiadania sk\u0142adni przy edycji, kt\u00f3re sta\u0142o si\u0119 od tego wydania wariantem domy\u015blnym. Wraz z Gradle 8.0 poprawiona zostala kompilacji skrypt\u00f3w poprzez wprowadzenie interpretera dla deklaratywnych blok\u00f3w plugin\u00f3w {} w skryptach .gradle.kts, co daje zysk rz\u0119du 20%, zbli\u017caj\u0105c czas procesowania Kotlin DSL do Gradle DSL.<\/p>\n\n\n\n Ale je\u015bli chodzi o Gradle, to jeszcze ciekawsze rzeczy pokaza\u0142o JetBrains.<\/p>\n\n\n\n Programi\u015bci do\u015bwiadczaj\u0105 zmieniaj\u0105cych si\u0119 trend\u00f3w w zarz\u0105dzaniu procesami budowania i integracji ci\u0105g\u0142ej. W ostatnich latach (a mo\u017ce nawet dekadzie), popularne sta\u0142y si\u0119 rozwi\u0105zania CI\/CD jak Github Actions czy TravisCI, oparte na deklaratywnych konfiguracjach w YAML. W ekosystemie Javy, mimo dost\u0119pno\u015bci Mavena z jego XML-em, wielu deweloper\u00f3w przenios\u0142o si\u0119 na Gradle ze wzgl\u0119du na jego wi\u0119ksz\u0105 elastyczno\u015b\u0107, cho\u0107 czasami prowadzi to do skomplikowanych skrypt\u00f3w.<\/p>\n\n\n\n Ten trend wskazuje na ci\u0105g\u0142e wyzwania w zarz\u0105dzaniu z\u0142o\u017conymi projektami, szczeg\u00f3lnie w JetBrains, gdzie Kotlin Multiplatform uwidoczni\u0142 problematyk\u0119 Gradle. W odpowiedzi na te wyzwania, JetBrains rozpocz\u0105\u0142o Project Amper, maj\u0105cym na celu uproszczenie konfiguracji konfiguracji Gradle przez u\u017cycie YAML. Amper obecnie wspiera Kotlin i Kotlin Multiplatform, a tak\u017ce Jav\u0119 i Swifta. Ta inicjatywa ma na celu uczynienie Gradle bardziej dost\u0119pnym i mniej skomplikowanym.<\/p>\n\n\n Oracle opublikowa\u0142o oficjalne rozszerzenie Javy dla \u015brodowiska Visual Studio Code, co stanowi stanowi z ich strony znaczny krok w uznaniu VSCode jako alternatywy dla tradycyjnych \u015brodowisk programistycznych. Pomimo istnienia wyspecjalizowanych narz\u0119dzi dla Javy, jak Intellij, coraz wi\u0119cej programist\u00f3w, w tym studenci i ci pracuj\u0105cy z r\u00f3\u017cnymi j\u0119zykami, preferuje u\u017cywanie tego toola. Rozszerzenie dostarcza funkcje takie jak auto-uzupe\u0142nianie, pod\u015bwietlanie b\u0142\u0119d\u00f3w, wsparcie dla debugowania oraz integracj\u0119 z projektami Gradle i Maven. Wa\u017cn\u0105 cech\u0105 jest wykorzystanie serwera j\u0119zyka opartego na protokole Language Server Protocol, pochodz\u0105cego z NetBeans (o samym LSP mo\u017cecie poczyta\u0107 troch\u0119 ni\u017cej).<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Azul wyda\u0142 wersje swojego OpenJDK 17 – Zulu – z wbudowanym wsparciem dla CRaC API. Jak ju\u017c wspomnia\u0142em przy Springu, CRaC API umo\u017cliwia tworzenie „checkpoint\u00f3w” w trakcie pracy aplikacji, co pozwala na zapisanie pe\u0142nego stanu \u015brodowiska uruchomieniowego. Dzia\u0142a to podobnie do funkcji Save State w emulatorach, gdzie zapisywany jest ca\u0142y stan pami\u0119ci na dysk i mo\u017ce by\u0107 p\u00f3\u017aniej odtwarzany. Azul jest pierwszym dostawc\u0105, kt\u00f3ry oferuje komercyjne wsparcie dla tej technologii, co mo\u017ce by\u0107 interesuj\u0105ce w\u0142a\u015bnie dla early adopter\u00f3w nowych featur\u00f3w Spring Framework 6.1.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n BellSoft wprowadzi\u0142 na rynek Liberica JDK Performance Edition, zmodyfikowan\u0105 wersj\u0119 JDK 11, w kt\u00f3rej zintegrowano poprawki wydajno\u015bciowe z JDK 17. To rozwi\u0105zanie umo\u017cliwia firmom korzystaj\u0105cym z JDK 11 zwi\u0119kszenie wydajno\u015bci aplikacji o 10-15% bez konieczno\u015bci zmian w kodzie. Liberica JDK Performance Edition jest dost\u0119pna dla subskrybent\u00f3w Liberica JDK od 1 sierpnia bez dodatkowych op\u0142at i jest dostarczana wraz z innymi narz\u0119dziami od BellSoft.<\/p>\n\n\n\n Wi\u0119cej szczeg\u00f3\u0142\u00f3w znajdziecie w poni\u017cszych edycjach:<\/strong><\/p>\n\n\n\n Fury, stworzony przez Ant Group, to nowa biblioteka do serializacji, \u0141\u0105czy ona wydajno\u015b\u0107 serializacji statycznej z elastyczno\u015bci\u0105 dynamicznej serializacji, co mo\u017ce znale\u017a\u0107 zastosowanie w przypadku, gdy potrzebna jest du\u017ca przepustowo\u015b\u0107 w masowej transmisji danych. Oferuje ona pe\u0142n\u0105 kompatybilno\u015b\u0107 z rozwi\u0105zaniami ju\u017c istniej\u0105cymi w Javie i wykorzystuje nie tylko zaawansowane techniki serializacji, ale te\u017c operacje SIMD z Vector API oraz podej\u015bcie Zero-Copy, minimalizuj\u0105c op\u00f3\u017anienia podczas transferu danych. Fury wykorzystuje tak\u017ce kompilator JIT, kt\u00f3ry generuje zoptymalizowany kod serializacji w czasie rzeczywistym.<\/p>\n\n\n\n\n
Rok, w kt\u00f3rym MicroProfile po\u0142\u0105czy\u0142 si\u0142y z Core Profile<\/h2>\n\n\n\n
<\/figure>\n\n\n\n\n
\n
\n
Rok, w kt\u00f3rym Testcontainers sta\u0142y si\u0119 cz\u0119\u015bci\u0105 Docker<\/h2>\n\n\n\n
<\/figure>\n\n\n\n\n
Rok, w kt\u00f3rym Spring po\u015brednio sta\u0142 si\u0119 cz\u0119\u015bci\u0105 Broadcom<\/h2>\n\n\n\n
<\/figure>\n\n\n\n<\/figure><\/div>\n\n\n\n
Rok, w kt\u00f3rym Oracle wywraca do g\u00f3ry nogami pricing ich wersji JDK<\/h2>\n\n\n\n
<\/figure>\n\n\n\n<\/figure><\/div>\n\n\n\n
Rok pocz\u0105tku ko\u0144ca problemu nulli w Javie dzi\u0119ki projektowi Valhalla<\/h2>\n\n\n\n
<\/figure>\n\n\n\n.val<\/code> i .ref<\/code>. Mia\u0142y one informowa\u0107, czy chcemy u\u017cywa\u0107 danego obiektu jako warto\u015bci, czy jako referencji. To by\u0142o dla mnie najbardziej problematyczne spo\u015br\u00f3d proponowanych zmian, obawia\u0142em si\u0119 bowiem komplikacji sk\u0142adni. Na razie wygl\u0105da na to, \u017ce uda si\u0119 z nich zrezygnowa\u0107. Prace nad rozwojem ca\u0142ego projektu pozwoli\u0142y zredukowa\u0107 r\u00f3\u017cnice mi\u0119dzy typami prymitywnymi a obiektami do dw\u00f3ch fundamentalnych r\u00f3\u017cnic \u2013 posiadania warto\u015bci domy\u015blnej (jak 0 w przypadku int) oraz wsparcia dla nullowalno\u015bci.<\/p>\n\n\n\nFoo?<\/code> oznacza ten typ zawiera w swoim zbiorze warto\u015bci nullFoo!<\/code> oznacza ten typ nie zawiera w swoim zbiorze warto\u015bci nullFoo<\/code> oznacza \ud83e\udd37\u200d\u2642\ufe0f \u2013 inaczej m\u00f3wi\u0105c, nie okre\u015blony stan nullowalno\u015bci<\/p>\n\n\n<\/figure><\/div>\n\n\n\n
Rok, w kt\u00f3rym z wypiekami na twarzy ogl\u0105da\u0142em JVM Language Summit<\/h2>\n\n\n\n
<\/figure>\n\n\n\nApplicationModel<\/code>, bazowy interfejs modelu, a tak\u017ce patterny implmentacyjne.<\/p>\n\n\n\n\n
Rok, w kt\u00f3rym zapowiedziano Kotlin 2.0<\/h2>\n\n\n\n
<\/figure>\n\n\n\n\n
Rok, w kt\u00f3rym Roman Elizarov odszed\u0142 z Kotlina<\/h2>\n\n\n\n
<\/figure>\n\n\n\n\n
Rok, w kt\u00f3rym doczekali\u015bmy si\u0119 wysypu ciekawych nowych wyda\u0144<\/h2>\n\n\n\n
Frameworki<\/h3>\n\n\n\n
<\/figure>\n\n\n\nSpring Framework 6.1 I Spring Boot 3.2<\/h4>\n\n\n\n
JdbcClient<\/code> oraz automatyczne logowanie Correlation Id podczas korzystania z Micrometera. Spring Boot 3.2.0 u\u0142atwia tak\u017ce budowanie obraz\u00f3w Docker z u\u017cyciem standardu Cloud-Native Buildpacks.<\/p>\n\n\n\n\n
Quarkus 3.0<\/h4>\n\n\n\n
java.util.concurrent.Flow<\/code>.<\/p>\n\n\n\n\n
Micronaut 4.0<\/h4>\n\n\n\n
VirtualThreads<\/code>. Dodatkowo, Micronaut Serialization sta\u0142 si\u0119 domy\u015blnym modu\u0142em oferuj\u0105cym wydajne i bezpieczne interfejsy API serializacji\/deserializacji JSON.<\/p>\n\n\n\n\n
Helidon 4.0<\/h4>\n\n\n\n
\n
Dropwizard 3.0 i 4.0<\/h4>\n\n\n\n
javax.<\/code>, dzi\u0119ki czemu migracja z Dropwizard 2.x do wersji 3.0 powinna by\u0107 minimalna dla wielu projekt\u00f3w. Natomiast Dropwizard 4.0 opiera si\u0119 na zale\u017cno\u015bciach Jakarta EE oraz przestrzeni nazw jakarta.<\/code>, co mo\u017ce wi\u0105za\u0107 si\u0119 z wi\u0119kszym nak\u0142adem pracy przy migracji z Dropwizard 2.x do wersji 4.x.<\/p>\n\n\n\njakarta.<\/code><\/p>\n\n\n\n\n
Play Framework 2.9 i 3.0<\/h3>\n\n\n\n
\n
Grails 6<\/h4>\n\n\n\n
\n
WildFly 30<\/h4>\n\n\n\n
\n
Vaadin Hilla 2.0<\/h4>\n\n\n\n
\n
Tooling<\/h3>\n\n\n\n
<\/figure>\n\n\n\nAI Assistant w IntelliJ Idea<\/h4>\n\n\n\n
\n
Gradle 8.0<\/h4>\n\n\n\n
\n
Amper od JetBrains<\/h4>\n\n\n\n
\n
Oficjalne Java Extension for Visual Studio Code od Oracle<\/h4>\n\n\n\n
\n
Azul Zulu JDK 17 with CRaC support<\/h4>\n\n\n\n
\n
Liberica JDK Performance Edition<\/h4>\n\n\n\n
\n
Nowi ciekawi gracze<\/h3>\n\n\n\n
<\/figure>\n\n\n\nFury<\/h4>\n\n\n\n
![\"\"\/](\"https:\/\/vived.io\/wp-content\/uploads\/2024\/01\/77yQv5n.jpg\")
<\/figure>\n\n\n\n