JVM Tuesday vol. 29

1. Premiera JDK 16

Mamy to !

W dniu dzisiejszym, premierę ma (a raczej będzie mieć w godzinach wieczornych) Java 16. Co prawda od czasu, gdy opisywaliśmy jej Release Candidate nie zmieniło się za wiele, ale mamy dla Was niespodziankę. Otóż postanowiliśmy z tej okazji przygotować dla Was pierwszy… podcast

Wraz Piotrkiem Janczykiem z zespołu Vived porozmawialiśmy o nowym wydaniu – czego się można po nim spodziewać oraz na jakie featury najbardziej czekamy. Zapraszamy do odsłuchu!

Jeżeli preferujecie formę tekstową, zapraszamy do jednej ze starych edycji, gdzie przeszliśmy przez wszystkie JEPy. Dodatkowo, jako że w odcinku obiecaliśmy też podzielić się informacjami o planowanych zmianach w Kotlinie, częstujcie się linkiem o planowanej adopcji rekordów w tym języku.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

2. Opublikowano betę Spring Native

Przyznam szczerze, że była to jedna z tych informacji, których z jednej strony się nieco spodziewałem (w końcu wsparcie w inkubacji było od dłuższego czasu) , z drugiej zaś wzięła mnie mocno z zaskoczenia, gdyż oczekiwałem od Pivotala raczej wypuszczenia Spring Boot 2.5. Otóż w połowie zeszłego tygodnia twórcy najpopularniejszego Javowego frameworku ogłosili, że wsparcie ich rozwiązania dla GraalVM, osiągnęło właśnie status bety.

Ok, ale co konkretnie to oznacza? W dość długim, bardzo interesującym poście, twórcy zdradzają szczegóły rozwiązania.

Po pierwsze, Spring Native będzie mógł być releasowany jako pojedynczy plik wykonywalny, bez potrzeby posiadania zaembedowanego JVMa. Po drugie, jego czas startu robi wrażenie – według tego, co podają twórcy, dla typowej aplikacji nie powinien on przekraczać magicznej granicy < 100ms (aczkolwiek liczby jak to liczby, będzie trzeba je zweryfikować w praktyce). Nieodmiennie w wypadku rozwiązań opartych na GraalVM, jako docelowy sposób użycia wskazywane są kontenery, a także rozwiązania chmurowe takie jak choćby Spring Cloud Functions.

Oczywiście, w wypadku tak mocno opartego na adnotacjach rozwiązania jak Spring, niezbędne było automatyczne wykrywanie zależności wstrzykiwanych przez refleksje. Zapewni to specjalny tooling stworzony na potrzeby edycji natywnej, który wykrywa wszystkie “beany” i wrzuca je do paczuszki. W sytuacjach podbramkowych, gdy potrzebujemy dodać do projektu klasy niezarządzane bezpośrednio przez Springa (jak np. drivery do baz danych wcześniej znajdujące się po prostu na classpath), możemy użyć adnotacji @NativeHint. Muszę przyznać, że to właśnie ona budzi moje największe obawy. Mam jednak nadzieje, że rozwiązanie dostarczone przez Pivotala będzie na tyle sprytne, że jej użycie ograniczone będzie do minimum

Jednocześnie nie ma róży bez kolców i chcąc korzystać z nowej zabawki trzeba iść na pewne kompromisy. Korzystając ze Spring Native, będziemy musieli pogodzić się z dłuższymi czasami kompilacji oraz brakiem bardziej zaawansowanych optymalizacji, jakie daje JIT – musi nam wystarczyć kompilacja Ahead-of-Time.

Na koniec metody wersjonowania – cykl życia Spring Native będzie ściśle spięty z releasami Spring Boota, a nowe wydania wersji natywnej będą pojawiać się wraz z każdym update’em do klasyka.

Odkryj więcej treści IT dopasowanych do Ciebie

W aplikacji Vived znajdziesz artykuły moderowane przez developerów.
Zainstaluj teraz i czytaj tylko dobre teksty!

3. Project Liliput – JVMowe nagłówki na diecie ‍♂️

Widać, że po okresie stabilizacji Javy 16, prace nad dalszymi rozwinięciami języka ruszyły pełną parą, ostatnio bowiem mamy wręcz zatrzęsienie nowych proposali. Przeglądem co ciekawszych zajmiemy się pewnie w przyszłym tygodniu, a w międzyczasie zaś mamy dla Was bardzo wstępny zarys projektu Liliput.

Czym projekt Liliput jest, czy raczej “ma być”? Otóż ma on za zadanie zmienić jedną z najbardziej “internalowych” części JVMa – nagłówek obiektów. Skąd taka chęć zmiany? Liczby mówią same za siebie – otóż w 64-bitowej Javie, nagłówek obecnie zajmuje aż 128 bitów. Jest to jedna trzecia “wagi” przeciętnego obiektu. Od razu więc widać, że każda optymalizacja w tym zakresie może doprowadzić do znaczącej poprawy zużycia pamięci przez aplikacje JVMowe, a także zmniejszyć presję na Garbage Collectory.

Oczywiście, jakby zmiana była prosta, już dawno by się odbyła. Nagłówek jest używany do różnych celów, między innymi do przechowywania informacji o statusie synchronizacji obiektu – zawiera on m.in. dane nałożonego na obiekt “locka”. W tym stwierdzeniu objawia się właśnie potencjalna szansa dla zaangażowanych w projekt inżynierów – jako pierwszy cel planują oni wziąć wprowadzone dopiero co Rekordy. Ich pola są “efektywnie-finalne”, dzięki czemu jeśli uda się wprowadzić planowany dynamiczny rozmiar nagłówka, będzie można ograniczyć jego długość.

Ogólnie muszę przyznać, że im bardziej wgryzam się w to co dzieje się w JVMie, tym więcej we mnie Mechanical Sympathy do maszyny wirtualnej Będę z pewnością informować Was o dalszym rozwoju prac – przy czym należy pamiętać, że Liliput jest na razie jedynie propozycją i nic z niego może nie wyrosnąć.