JVM Tuesday vol. 22

1. Java na GraalVM zyskuje potężne nowe możliwości

GraalVM (nazwa kodowa – Project Metropolis) to jedna z najciekawszych inicjatyw Oracle. Jest to zestaw narzędzi, dostarczający uniwersalną maszynę wirtualną dla różnych języków programowania. Projekt ten rozwijany jest od lat, a jego adopcja przekroczyła chyba oczekiwania samych twórców (właściwie każdy liczący się Javowy Framework chwali się obecnie wsparciem dla GraalVM).

Najbardziej znanym wykorzystaniem kompilatora Graal jest z pewnością możliwość generowania niezwykle wydajnych, binarnych wersji programów przez niego skompilowanych. Do tej pory był to jedyny (a przynajmniej jedyny niewymagający pełnego JVMa) sposób uruchamiania aplikacji Javowych w środowisku GraalVM. Wraz z wydaną w zeszłym tygodniu wersją 21 (ciekawostka: jej premiera streamowana była na… Twitchu) przynosi małą rewolucję – możliwość uruchomienia aplikacji Javowych w środowisku Truffle.

Truffle jest warstwą pośrednią, określaną czasem jako kompilator kompilatorów. Jest to hmmm… narzędzie do generowania interpretatorów poszczególnych języków, generujący ich Abstract Syntax Tree w formacie kompatybilnym do uruchomienia w ramach maszyny wirtualnej Graala. Do tej Truffle działał tylko i wyłącznie dla języków implementowanych. Możliwość jego użycia również w wypadku Javy ma dwie ogromne zalety. Po pierwsze Truffle jest szybki… diabelnie szybki – w połączeniu z GraalVM generuje on bardzo wydajny kod maszynowy. Po drugie zaś, Truffle jest napisany w Javie, co oznacza że może być dołączony jako… zależność do projektu. Prowadzi to do sytuacji, kiedy aplikacja Javowa może sama skompilować swój własny kod. Jest to tak zwane Metacircularity – cecha, którą twórcy określają jako (nomen omen) święty Graal maszyn wirtualnych. W praktyce oznacza to możliwość użycia zarówno kompilacji Ahead-of-Time, jak i Just-in-Time w tym samym projekcie.

Ukradzione z oryginalnego postu, ale nie mogłem się powstrzymać

Jeżeli chcecie się dowiedzieć więcej o samym GraalVM – polecam wprowadzenie w formie wideo po polsku.

Źródła:

2. Java na ARM – co musisz wiedzieć

Schodząc z tematów internali, przechodzimy na hardware.

Praktycznie na każdej liście najważniejszych wydarzeń technologicznych 2020 roku musiał znaleźć się niesamowity wręcz sukces procesorów ARM. Głównie dzięki Apple i ich niesamowitym procesorem M1 (dlaczego są takie szybkie? Tutaj znajdziecie bardzo fajny artykuł na ten temat), ale na podobny ruch zdecydowały się też inne firmy. Jedną z nich jest Oracle, który postanowił udostępnić w ramach swojej chmury serwery ARM. Decyzja ta nie pozostała bez efektu na Javę, której to wersja, na tą właśnie architekturę, stała się nagle ważnym elementem biznesu Oracle.

Linkowany artykuł jest najlepszym, jak do tej pory źródłem informacji o wydajności, możliwościach, lecz również potencjalnych problemach, na jakie możemy natknąć się podczas portowania naszej aplikacji na nowy typ procesora. Znajdziemy w nim też wiele interesujących detali, takich jak np. sugerowane flagi maszyny wirtualnej lub unikalne metody diagnozowania problemów.

Źródła:

3. Wysyp multiplatformowych edycji Kotlina i Scali

Końcówka roku była bardzo spokojna i powolna, a ilość ciekawych ogłoszeń można było policzyć na palcach jednej ręki – wydaje się, że była to jednak cisza przed burzą. Początek roku to wysyp wiadomości atakujących nas z różnych stron. Zaczęliśmy od informacji o nowym wydaniu GraalVM, a edycje zakończymy zaś podsumowaniem tego, jak radzą sobie różne podejścia do tak zwanego “multiplatformowego JVM”.

Zacznijmy od Kotlina. Język ten od samego początku celował w możliwość kompilacji na środowiska uruchomieniowe różnych platform. Kotlin umościł się głównie na Androidzie, powolutku promując się również na język serwerowy. Nie wolno jednak zapominać, że istnieją też jego edycje na choćby JavaScript, iOS, czy również raczkująca edycja Native, uruchamiana w ramach LLVM. Zastanawialiście się kiedyś, na ile te niszowe edycje Kotlina mają powodzenie? Załoga JetBrains to zrobiła, i dzięki temu mamy teraz ciekawe wyniki ankiety dotyczącej tego zagadnienia. Zaskoczeniem nie będzie na pewno, że najczęstszym przypadkiem użycia są wspólne buildy aplikacyjne dla Androida i iOSa, ale np. aż 15% ankietowanych stwierdziło, że dzielą kod między frontendem a backendem.

Tym stwierdzeniem szybko możemy przejść do drugiego bohatera tej części (o którym mogliście już zresztą przeczytać w naszej edycji frontendowej, jest to dość unikalny “crossover”), czyli ScaliJS. Mam osobistą słabość do tego języka (min. przez mój jedyny talk ever na Krakow Scala User Group), ale przyznam, że nigdy nie dawałem mu wielkich szans na dynamiczny rozwój. O ile jednak ciężko nazwać go czymś więcej niż “niszą w niszy”, to jednak nowe edycje ukazują się w miarę regularnie. Ostatnia z nich, Scala.js 1.4.0, nie przynosi co prawda wielu zmian, podsumowuje jednak zapoczątkowaną przez Scala.js 1.3 modularyzację, podbijając przy okazji używaną przez Scala.js bazową wersję Scali z 2.13 na 2.14.

Podsumowując ten dział dziwnych wydań języków JVMowych, wrócimy w tej chwili do Scali, tym razem w wydaniu Native. Podobnie jak natywny Kotlin, Scala Native uruchamiana jest na LLVM, podobnie jak Scala.js, wersja 0.4.0 przynosi upgrade Scalowej bazy, nieco mniej śmiało niż ma to przypadek w wersji JavaScriptowej,
bo zaledwie do Scali 2.13. Zakres zmian nie kończy się jednak na tym – nowa edycja to znacznie rozwinięta współpraca z kodem napisanym w C, zupełnie nowy Garbage Collector, a także spore zmiany w formacie pośrednim NIR.

1. Java na GraalVM zyskuje potężne nowe możliwości

Źródła:

2. Java na ARM – co musisz wiedzieć

Źródła:

3. Wysyp multiplatformowych edycji Kotlina i Scali

Źródła:

Odkryj więcej świetnych treści!