W dzisiejszej edycji sporo internali. Project Valhalla przyniesie duże zmiany w JVMie, a nowa wersja GraalVM dodaje wielopoziomową kompilacje. Nieco na przełamanie, mamy też nową edycje JHipstera dla wszystkich tych którzy czują się FullStackami 🧔. Zapraszamy do lektury!
1. GraalVM 21.1: Szybszy rozruch aplikacji dzięki wielopoziomowej kompilacji
Opisując z tygodnia na tydzień zmiany w ekosystemie języka/platformy (a robimy to dla Was już ponad pół roku, a prawie kwartał w formie blogowej ), siłą rzeczy niektóre tematy po prostu muszą w miarę regularnie wracać. Z perspektywy redaktora (jak to dumnie brzmi!) wydaje mi się, że dopiero co dotykaliśmy tematu nowości w GraalVM, aczkolwiek po sprawdzeniu okazuje się, że ostatni raz robiliśmy to w… styczniu. Projekty JVMowe rozwijają się jednak bardzo dynamicznie, w związku z czym, ostatni tydzień stał pod znakiem dalszego rozwoju tego meta-frameworku. Na rynek trafiła bowiem wersja 21.1, która mimo niepozornej numeracji przynosi masę interesujących zmian.
Zacznijmy od “ciepłej wody w kranie”. O ile GraalVM zawsze targetuje bieżącą Javę w wersji LTS, to jego nowa odsłona wprowadza bonusowo eksperymentalne wsparcie dla JDK 16. Twórcy z góry zastrzegają, że jest to rozwiązanie dalekie od produkcyjnego, a biorąc pod uwagę rychłą premierę Javy 17, która będzie kolejną wersją o długim wsparciu, potencjalnie nigdy się nie uprodukcyjni. Jest to bardzo interesująca sytuacja, w której wersje pośrednie JDK bardziej pomagają twórcom narzędzi – możliwość poeksperymentowania z Javą 16 na tym etapie uprości proces przechodzenia GraalVM na nowego LTSa. Nowe wydanie to też okazja do pożegnania się ze wsparciem dla JDK 8 – od wersji 21.1, ta wciąż najpopularniejsza, a jednak dziś już mocno przestarzała wersja Javy, będzie mogła być wspierana tylko w wersji Enterprise.
Wsparcie dla Node.js’a również zostało zaktualizowane, jednocześnie w ramach odchudzania bazowej wersji GraalVM, zostało wsparcie tej platformy wydzielone z głównego wydania do zewnętrznego modułu, który należy doinstalować w ramach. Co ciekawe, ten sam los nie spotkał wsparcia dla JavaScriptu, które pozostaje integralną częścią GraalVM.
Nowe wydanie to również kilka interesujących zmian w samym procesie kompilacji. Generowany natywny kod znacznie agresywniej teraz podchodzi do tematu współbieżności, w mniej asekuracyjny sposób podchodząc do tego, jakie operacje mogą być wykonane równolegle. Twórcy chwalą się, że zmiany są szczególnie widoczne np. podczas używania ConcurrentHashMap.
Jednak chyba najbardziej interesującym dodatkiem, który przynosi nowa edycja jest tak zwana wielopoziomowa kompilacja (Multi-Tier Compilation), działająca na zasadach zbliżonych do tych znanych z kompilatora JIT. Jest ona dostępna dla programistów, którzy zdecydują się na użycie wbudowanego w GraalVM narzędzia Truffle, o którym nieco więcej pisaliśmy przy okazji jednej z poprzednich edycji (kiedy to początkiem roku dostał wsparcie również dla Javy). W praktyce sprowadza się to do tego, że zaraz po uruchomieniu, początkowe optymalizacje są nieco mniej agresywne, co pozwala jednak na szybszy rozruch. Dopiero, gdy aplikacja jest już w pełni gotowa do działania, następuje druga faza optymalizacji. Całość ma za zadanie przyspieszyć początkowy rozruch aplikacji.onkretne benchmarki zostały opisane zaś w tym artykule. W nim też znajdziecie dokładny opis całego procesu.
Ogólnie GraalVM idzie ostro do przodu i wszystko wskazuje na to, że jeszcze nie raz o nim od nas usłyszycie.
PS: Jeżeli lubicie wersje wideo, wczoraj ukazało się bardzo fajnie przejście przez opisywane przez nas zmiany
Źródła:
- Faster warmup, smaller downloads, JDK 16 — GraalVM 21.1 is here!
- Multi-Tier Compilation in GraalVM
- Java on Truffle — Going Fully Metacircular
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!
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Project Valhalla wymusza grube zmiany w modelu danych JVM
Dzisiejszą edycję można ogólnie uznać za dosyć “internalową”. Po zmianach w dość niszowym, jednak wciąż, GraalVM, dzielimy się z Wami również dokumentem opisujący rozwój prac nad Valhallą – jednym z najważniejszych obecnie rozwijanych projektów odbywających się w ramach JVMa. Dzięki pracy Johna Rose’a i Briana Goetza mamy okazję dowiedzieć się, jak w swoim bieżącym kształcie wpłynie on na bytecode samego JVMa.
I choć zdajemy sobie sprawę, że ciężko o bardziej hermetyczny temat (rozkminy, jak na poziomie bajtkodu będzie zachowywać się funkcjonalność języka, której jeszcze nie ma), to jednak publikacja zapewnia sporo ciekawych informacji o decyzjach projektowych i ich reperkusjach. Tekst nie należy do najprostszych (mimo, że napisany jest w jak najbardziej przystępny sposób, po prostu ta tematyka jest z założenia mocno złożona), ale dla nas, śmiertelnych klepaczy kodu, wnosi tyle że bogowie JVMa zdecydowali się dość mocno maszynę wirtualną, przeorać na potrzeby zmian wprowadzonych w Valhalli. Największą różnicą w stosunku do oryginalnych założeń jest fakt, że projektanci Valhalli zdecydowali się na porzucenie początkowego konceptu “wtłoczenia” klas prymitywnych w już istniejące JVMowe typy typ L – oznacza to, że mamy do czynienia z referencją do obiektu.
Ciekawostka – nikt nie ma pojęcia, dlaczego wybrane zostało L. Artykuł sugeruje, że C mogło być po prostu już zajęte przez Char, wybrano więc drugą literkę słowa Class.
Zamiast tego twórcy zdecydowali się rozszerzyć hierarchię o dodatkowy typ Q, mający opisywać “klasy egzotyczne”, których jedynym reprezentantem na ten moment są właśnie “klasy prymitywne”. Mają one bazować na wspomnianym już typie L. Główna różnica między tymi dwoma ma sprowadzać się do tego, że obiekty “L” są leniwe – mogą zostać zaczytane przez JVM dopiero przy pierwszym użyciu. Obiekty typu Q muszą zostać od samego początku w pełni “zrozumiałe” przez JVM,dzięki temu możliwa jest znacznie bardziej agresywna optymalizacja pamięci.
Oczywiście, to o czym piszę dla Was, to wierzchołek góry lodowej – chętnych zapraszam do pełnej publikacji. Moja obawa po lekturze jest taka, że biorąc pod uwagę zakres planowanych zmian, ja Valhalli chyba nigdy nie dożyje.
Źródła:
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!
Zainstaluj teraz i czytaj tylko dobre teksty!
3. Coś dla fullstacków – JHipster 7 wydany
Dobra, na koniec zostawiliśmy sobie projekt, który nosi chociaż znamiona czegoś, co w roku 2021, ktoś z nas może użyć w realnym projekcie.
Otóż niedawno – końcem marca, sami ten fakt przegapiliśmy – ukazała się wersja siódma generatora fullstackowych aplikacji Javowych o wdzięcznej nazwie JHipster. Projekt ten od dłuższego czasu żyje sobie na marginesie społeczności, zapewniając możliwość szybkiego wygenerowania w pełni skonfigurowanej aplikacji posiadającej Javowy backend oraz funkcjonalny frontend. W mojej głowie, JHipster zawsze kojarzył się z idealnym rozwiązaniem na potrzeby hackathonów. Niemal natychmiastowo pozwala on bowiem zbootstrapować działający szkielet, który następnie łatwo i szybko można rozwijać. Jednocześnie jednak, dość sceptycznie podchodziłem do wszelkich potencjalnych wdrożeń komercyjnych – powiedzmy sobie szczerze, jak często zdarza się Wam w pracy setupować od podstaw całe projekty, zwłaszcza takie posiadające zarówno frontend, jak i backend? No właśnie . Jednocześnie jednak, twórcy chwalą się całkiem sporą listą klientów, możliwe więc, że to moje patrzenie jest tutaj dość tunelowe.
JHipster od kilku edycji rozwija się “wszerz”. Początkowo będąc w pełni “wyopiowanym” rozwiązaniem Spring Boot + Angular, przez lata zaczął pozwalać na dużo bardziej elastyczny dobór technologii frontowym. Nowe wydanie idzie jednak o krok dalej, pozwalając na dopasowanie pod siebie również backendu – wśród dostępnych rozwiązań oprócz Spring Boota pojawił się m.in. Quarkus i Micronaut. Ewolucję przeszło też podejście do testowania frontendu. Protractor został zastąpiony przez rozpychającego się łokciami ostatnio Cypressa.
Jeżeli z wcześniejszych akapitów nie wyczytaliście zbytniego entuzjazmu, pamiętajcie że wynika to z moich wcześniejszych doświadczeń m.in. niespełnionym obietnicom podobnego projektu ze środowiska Node.js, yeomana, z którym zawsze było więcej aktualizacji i walki niż realnego pożytku. Jak to jednak mówią, “your mileage may vary”, więc jeśli macie w głowie jakiś przypadek użycia, możliwe że warto się JHipsterem zainteresować.
Przepraszam za feeling youtubowej karty “Na Czasie”, ale ten filmik to moje guilty pleasure i nie mogłem się powstrzymać.
Źródła:
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
