JVM Tuesday vol. 42

1. Czy słyszeliście o Oracle Cloud Infrastructure? Platforma interesująco się rozwija ‍♀️

Że wszyscy inwestują w chmurową Javę to nie jest jakaś wielka nowość. Świadczyć mogą o tym takie projekty jak AWS Cornetto czy buildy OpenJDK rozwijane przez Microsoft. Po prostu to się opłaca – platforma jest niezwykle popularna, więc każdy duży dostawca chmury chce mieć w swojej ofercie jak najlepsze wsparcie dla niej. Nie codziennie słyszy się jednak o nowej usłudze chmurowej dla Javy od… twórców Javy.

Oracle ogłosiło w zeszłym tygodniu, że w ramach swojej Oracle Cloud Infrastructure, udostępni Java Management Service – usługę, którą można uruchomić zarówno w ramach chmury obliczeniowej, jak i serwerów on-premise. Całość jest supervisorem dbającym o aktualizacje, bezpieczeństwo oraz inny szeroko rozumiany „compliance” usług.

Wszystko fajnie, tylko czemu całość musi posiadać akronim JMS. Ja wiem, że jeśli stosujemy Smurf-Naming i każda nazwa musi zaczynać się od słówka “Java”, to liczba potencjalnych kombinacji jest ograniczona… no ale Java Message Service jest już tak mocno zakorzeniony w społeczności, że po prostu całość będzie się myliła.

JMS zresztą to nie jedyne wzbogacenie użyteczności Oracle Cloud Infrastructure. Niedawno ukazał się Helidon 2.3.0 (o czym nie omieszkaliśmy Was poinformować dwa tygodnie temu). Ta wersja rozwijanego przez Oracle frameworku posiada bezpośrednią integrację właśnie z Oracle Cloud Infrastructure. Widać, że firma mocno inwestuje w zapewnienie programistom ciekawych rozwiązań (szkoda tylko, że ciekawych głównie dla wielkich korporacji, ale to te pozostają klientami firmy Larry’ego Ellisona). Ostatnimi czasy na ich blogu ukazał się zaskakująco interesujący wywiad z dwójką liderów Helidoma, prezentujący filozofię Oracle jeśli chodzi o rozwiązania chmurowe.

Źródła

2. Spring Native 0.10.0 przynosi ciekawe zmiany w samym GraalVM

Informacja o wydaniu bety Spring Native walnęła jak grom z jasnego nieba na niczego niespodziewających się developerów. Z naszej strony powiem, że ogłoszenie to jest jak do tej pory najlepiej “czytającym się” newsem dotyczącym JVMa jakiego opublikowaliśmy w Keep Upie, przebijając nawet wydanie Javy 16. Niech choćby to świadczy o zainteresowaniu, jakim społeczność zareagowała na nową edycje Springa.

Aczkolwiek może to po prostu ta informacja jest niezwykle clickbaitowa.

Teraz, wraz z premierą wersji 0.10.0, nie spodziewamy się ani krztyny takiego zainteresowania (mam wrażenie, że pierwsza wersja testowa traktowana była jako coś w rodzaju “eventu”), co nie oznacza, że nie stanowi ona ciekawego kolejnego kroku dla projektu. Nowa wersja przynosi sporo interesujących zmian – poza standardowymi aktualizacjami zależności (tutaj akurat jest to Spring Boot 2.5 oraz GraalVM 21.1) przynosi też sporo innych nowości. Jak to przy Springu bywa, ich nieoceniony Developer Advocate, Josh Long, przygotował wideo prezentujące wszystkie nowe funkcjonalności.

Dla tych, którzy nie chcą oglądać prawie półtoragodzinnego materiału, wspomnę że kluczową rzeczą przynoszącą przez wydanie jest zupełnie zaktualizowany sposób budowania paczek aplikacyjnych. Poprzednie edycje pozwalały tylko i wyłącznie na budowanie za pomocą Mavena, 0.11 przynosi oczekiwany plugin dla Gradle służący do budowania aplikacji. Jest to wynik współpracy teamu springowego z inżynierami pracującymi nad samym GraalVM.

Drugą niezwykle istotną nowością (również powstałą przy współpracy z zespołem GraalVM) jest w pełni “natywne” testowanie aplikacji za pomocą JUnita. Do tej pory wszystkie testy uruchamiane były w ramach standardowej maszyny Javy. Aby to osiągnąć, niezbędna była implementacja funkcjonalności junit-platform-native, która wykrywa testy podczas uruchomienia w ramach “zwykłego” JVM i zapisuje je na boku na potrzeby również natywnej kompilacji. Tak znalezione testy są pakowane do osobnego pliku wykonywalnego, który może być uruchomiony już w ramach środowiska GraalVM.

A jak już mowa o Gradle, to pojawiła się jego wersja 7.1. To co przynosi, to głównie masa deprekacji funkcjonalności, które za jakiś czas (sporo z nich już w Gradle 8.0) znikną z tego najdynamiczniej rozwijającego się javowego build toola.

Źródła

3. Generyki w Javie nareszcie mają stać się prawdziwie uniwersalne ‍♀️

A na koniec, jak to u nas zwykle bywa, kiedy akurat nie pojawiają się bardziej “bieżące” tematy, JEPik. I jak zwykle z gatunku tych bardzo interesujących, ponieważ jest to dalsza praca nad Valhallą.

Parę tygodni temu przybliżyliśmy Wam temat obiektów prymitywnych (Primitive Objects), do pewnego momentu znanych pod nazwą value types (co będzie istotną wskazówką, o czym mówimy dla tych, którzy nie są na bieżąco z każdym nowym proposalem – ten ekosystem naprawdę porusza się mocno do przodu). JEP 401 i 402, bo o nich mowa, nie są jeszcze gotowe, czy nawet zapowiedziane na konkretną wersję Javy. Żeby jednak nie musieć czekać z pracami koncepcyjnymi na realizację, która ze względu na ogrom planowanych zmian (czytelnicy naszych Weekly z pewnością zdają sobie sprawę, jak prace nad “passion projectem” Briana Goetza lubią eksplodować w nieoczekiwanych kierunkach) pewnie trochę zajmie, już dzisiaj rozważane są kolejne kroki.

Idąc za ciosem, po zbliżeniu do siebie typów prymitywnych i obiektów, najwyższy czas przyszedł na zajęcie się generykami. Pewnie każdy zdaje sobie sprawę, że w Javie typami parametryzującymi (psss… to te rzeczy w <>) mogą być tylko i wyłącznie typy referencyjne – czyli (w uproszczeniu) klasy. Żeby umożliwić tworzenie np. ArrayList zawierających prymitywy (czyli te wszystkie inty, chary i reszta rodzinki) jako parametry, niezbędne było stworzenie klas im odpowiadającym (odpowiednio Integer.class, Char.class). JEP 402 ma to trochę posprzątać, migrując wspomniane klasy towarzyszące na odpowiednie typy prymitywne.

Świeżo opublikowany draft jest kolejnym krokiem, niezbędnym żeby w pełni wykorzystać wprowadzone zmiany – i jak tak na to patrzę, bez jego implementacji nie ma za bardzo możliwości “wmergowania” wspominanych 401 i 402 do upstreamu, gdyż posypałby się nam cały system generyków. To właśnie nowy proposal przynieść ma oczekiwane możliwe użycie typów prymitywnych w generykach poprzez “uelastycznieniu” wspomnianego ograniczenia, wymuszającego, aby parametrami były wyłącznie typy referencyjne. Twórcy widzą również pewne możliwości na usprawnienia ze strony wydajności, ale na razie zdecydowali się odłożyć je na później, kreatywnie tnąc zakres działań – Valhalla i tak się rozrosła.

Na razie całość opierać się ma na standardowych mechanizmach JVM – nie ominie ich “usuwanie” informacji o typach parametrycznych w runtime. Zobaczymy jednak, co pokaże przyszłość. Może już w ramach któregoś kolejnego JEPa? Już w tej chwili twórcy zapowiadają, że wprowadzenie opisywanego draftu pociągnie za sobą kolejne zmiany w całej bibliotece standardowej.

Polecam lekturę całości każdemu, kogo ciekawią zawiłości javowego polimorfizmu – można w nim znaleźć sporo smaczków.

Źródła

I pamiętajcie, żeby spróbować Vived, jeśli chcesz otrzymywać tego typu treści spersonalizowane pod Ciebie!

1. Czy słyszeliście o Oracle Cloud Infrastructure? Platforma interesująco się rozwija ‍♀️

Źródła

2. Spring Native 0.10.0 przynosi ciekawe zmiany w samym GraalVM

Źródła

3. Generyki w Javie nareszcie mają stać się prawdziwie uniwersalne ‍♀️

Źródła

Odkryj więcej świetnych treści!