🥳 Jesteśmy z Wami od roku! 🥳 Od 52 tygodni (nie zgubiliśmy po drodze ani jednego 🥰) informujemy Was o wszystkim, co dzieje się w świecie technologii. Postanowiliśmy z tej okazji trochę poświętować.
🥳 Jesteśmy z Wami od roku! 🥳
Od 52 tygodni (nie zgubiliśmy po drodze ani jednego 🤘) informujemy Was o wszystkim, co dzieje się w JVMowym ekosystemie. Postanowiliśmy z tej okazji trochę poświętować i podsumować ostatnie 12 miesięcy. Wiemy, że takie podsumowania zwykle ukazują się w grudniu, ale tym bardziej może ktoś będzie chciał sobie zrobić taki przegląd właśnie teraz.
Lista jest bardzo “opinionated” i stanowi przegląd najbardziej interesujących wydarzeń, które dotknęły społeczność od sierpnia 2020. Potraktujcie więc całość jako “The Best Of JVM Tuesday… so far” – niektórzy stali czytelnicy mogą np. pamiętać niektóre memiszcza. Całość postanowiłem przedstawić w formie góry lodowej (jeśli nie wiecie, o co chodzi, odsyłam do knowyourmemes) – zawsze mi się marzył własny “iceberg”. Zatem bez przedłużania…
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!
Nowe wydania poszczególnych projektów
W ciągu ostatniego roku większość najważniejszych graczy w ekosystemie wydała jedną nową wersję swojego oprogramowania. Oto (naszym zdaniem) najważniejsze z nich:
- Java 15 i 16
- Kotlin 1.5
- Scala 3
- Quarkus 2.0
- Spring Boot 2.4 i 2.5
- Vert.x 4.0
- Gradle 7.0
- Maven 4.0
Nie będziemy tutaj opisywać każdego z nich, bo każda premiera dostała duży opis w ramach którejś z naszych wcześniejszych edycji, skrzętnie podlinkowanych powyżej. Szczególnie polecamy zapoznać się z nową Scalą – jest to pierwsze duże wydanie od lat i efekt pracy wielu inżynierów (w tym z naszego zespołu w VirtusLab).
W ciągu ostatnich 12 miesięcy zrobiliśmy też pełne podsumowanie stanu, w którym znajdują się Reaktywne Frameworki. Bardzo polecamy, nie zestarzało się zbyt mocno
Google wygrało w sądzie z Oraclem w procesie o użycie API Javy na Androidzie ⚖️
Po dziesięciu latach, Google wygrało z Oraclem proces o użycie API Javy na popularnym Androidzie. Dla tych, którzy nie wiedzą – “zielony robocik” nie uruchamia aplikacji w ramach maszyny wirtualnej Javy, ale jego API dla programistów jest kopią tego javowego, za co Oracle żądało od Google wysokiego odszkodowania z tytułu łamania praw autorskich.
Wyrok jest zresztą ważny dla całej branży, gdyż osobom chcącym stworzyć alternatywne implementacje danych API, daje do rąk dość dobrą amunicje. Należy pamiętać jednak, że wyrok nie jest “konkluzywny”, co do faktu, że API jako takiego nie można chronić prawem autorskim – sąd orzekł, że kompatybilne API wchodzi w definicje tak zwanego “dozwolonego użycia”. Jednocześnie ze względu na działające w USA prawo kazusu, prawdopodobnie minie trochę zanim ktokolwiek spróbuje wytoczyć podobną sprawę.
Przeczytaj więcej
Kotlin stał się szalenie otwarty na społeczność
Chociaż do masowej świadomości Kotlin przebił się nieco później, to jednak swoją premierę język JetBrains miał dekadę temu. W celu odpowiedniego uczczenia tak znamienitej rocznicy, twórcy Intellij postanowili nakręcić… dokument.
Rozwój Kotlina ogólnie naprawdę interesująco się obserwuje. Roman Elizarov, lead projektu, w fantastyczny sposób dzieli się decyzjami projektowymi stojącymi za poszczególnymi featurami (szczególnie jego talki na temat korutyn i structured concurrency należą do moich ulubionych w temacie języków programowania). Jak bardzo otwarty jest to zespół niech świadczy fakt, że wraz z premierą wersji 1.5 języka, pojawiło się na Redditcie kotlinowe AMA, w którym twórcy języka odpowiedzieli na masę pytań społeczności. To nie jedyne tego typu działanie – zespół dał też użytkownikom możliwość głosowania na nowe featury, nad którymi będą pracować w przyszłości… a także na te, których ludzie sugerują unikać w przyszłych wersjach Kotlina.
W ciągu roku doszło też do wielokrotnych aktualizacji Roadmapy Kotlina, która to pozwala śledzić kierunek, w którym ewoluuje język. Wspominając o ewolucji, warto przypomnieć że Kotlin postanowił nieco skopiować cykl wydań Javy, stawiając na przewidywalność kolejnych edycji. Teraz nowa “major” wersja (w koltinowej nomenklaturze 1.x) będzie wydawana raz na pół roku, nie oglądając się na to, jakie funkcjonalności są gotowe.
W tej beczce miodu jest też łyżka dziegciu. Kotlin stał się ostatnimi czasy wręcz definicją Vendor Lock-Inu. JetBrains postanowiło zerwać wszelkie pozory i wcześniej niezależnie rozwijany plugin do języka, stał się integralną częścią Intellija.
Przeczytaj więcej
- JVM Tuesday vol. 23
- JVM Tuesday vol. 33
- JVM Tuesday vol. 39
- JVM Tuesday vol. 41
- JVM Tuesday vol. 43
- JVM Tuesday vol. 43
Oracle też zaczęło dobrze grać z Community
Oracle bardzo zaczyna dbać o komunikację z programistami. Prowadzą stronę Inside Java, agregującą zmiany w świecie JVMowym. Dodatkowo, wprost uwielbiam towarzyszący blogowi podcast. Mówi się że w dzisiejszych czasach nie da się już publikować podcastu na średnim poziomie technicznym i liczyć na posłuch, ale ten od Oracle udowadnia, że w dalszym ciągu “content is the King”. Jakość nagrań jest hmmm… akceptowalna, jednak całość zawiera najbardziej “mięsne” rozmowy na temat języka, na jakie można natknąć się w sieci. Wynika to w dużej mierze z doboru gości. O ile większość innych tego typu kanałów operuje zwykle na wiedzy z “drugiej ręki”, Inside Java zaprasza do siebie twórców JVM, którzy okazują się być naprawdę interesującymi rozmówcami.
Jakby tego było mało Oracle, ustami Nicolai Parlog, zaczęło prowadzić serię wideo Inside Java Newscast, które możecie traktować jako alternatywę dla naszych postów publikowanych w ramach Weekly (aczkolwiek my sięgamy nieco szerzej – seria Oracle to newsy stricte związane z JVMem). Nowym rozwijanym projektem jest zaś JEP Cafe – opisujących nowopowstałe JEPy.
Przeczytaj więcej
Java trafiła na GitHuba
Można by powiedzieć – nareszcie. Wraz z implementacją JEP 369 (Migrate to GitHub), kod źródłowy Javy stał się znacznie łatwiej dostępny dla rzeszy zainteresowanych nim programistów. Wprawdzie nie obyło się bez kontrowersji (nie każdemu podoba się przejście na platformę, której właścicielem jest Microsoft), to jednak teraz będzie znacznie łatwiej śledzić zmiany w kodzie OpenJDK. Przez lata swojej dominacji, Github stał się ekosystemem różnych narzędzi, a sam Git też jest znacznie popularniejszy niż Mercurial, który był do tej pory jedynym wspieranym przez Javę narzędziem kontroli wersji.
Java rozpycha się w świecie Uczenia Maszynowego
Java jest bardzo uniwersalnym językiem, ale są pewne kategorie problemów, z których została skutecznie wyparta przez “konkurencje”. Weźmy na przykład takie uczenie maszynowe. W ostatnich latach nie miała nawet startu do Pythona. Sytuacja powoli wydaje się zmieniać. Wraz z premierą Javy 15, Oracle (nieco cichaczem) opublikował Tribuo, bibliotekę umożliwiającą tworzenie silnie typowanych modeli MLowych, LinkedIn zaś postanowił wypuścić swoje własne rozwiązanie – Dagli.
Czym różni się Dagli od Tribuo? Rozwiązania w założeniach (zastosowania produkcyjne, wspomniane już typy) są do siebie bardzo podobne. Co wyróżnia rozwiązanie LinkedIn to fakt, że jego twórcy wzięli “na tapet” nieco większą klasę problemów – zamiast skupiać się na samych modelach, udostępniają możliwość zintegrowania pełnego pipeline, opisującego kolejne transformacje danych. Dodatkowo dostarczają też cały zestaw gotowych rozwiązań, które od razu można wykorzystać w swojej aplikacji.
W tym temacie nie próżnował też z resztą team JetBrains, tworząc własną bibliotekę. KotlinDL, bo o niej mowa, jest odpowiednikiem pythonowego Kerasa – biblioteką stanowiącą wrapper nad TensorFlow, udostępniającą API pozwalające na używanie modeli uczenia maszynowego również programistom, którzy nie posiadają typowo Data Science’oweg doświadczenia.
Java zaczęła na poważnie wspierać procesory ARM
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. Procesory ARM stają się coraz bardziej realną alternatywą dla programistów JVM – Amazon oferuje instancje chmurowe z tym typem procesorów, Microsoft opracował wersję OpenJDK na Windows uruchamianym na tej właśnie architekturze, a Oracle postanowiło udostępnić w ramach swojej chmury serwery ARM.
Przeczytaj więcej
Renesans desktopowych frameworków pisanych pod kątem JVM
Zaczynam się powoli zastanawiać, czy 2020 nie jest rokiem, który zapisze się w historii (ze względu na brak innych ważnych dla ludzkości wydarzeń) jako ten, który rozpoczął koniec panowania Electrona. Rozwiązanie to charakteryzuje się tym, że nie lubi go w zasadzie nikt… poza programistami, którzy jednym kodem są w stanie stworzyć “natywną” wersję aplikacji na wszystkie platformy. Jednak nawet my chyba powoli uczymy się, że tego typu aplikacje nie są dobrym rozwiązaniem – bardzo daleko im do uczucia natywności, dodatkowo znany jest fakt, że ile RAMu znajdą, tyle zjedzą. Stąd też rodzą się powoli alternatywy, wśród których przoduje Apple z Catalystem. Łokciami zaczyna przepychać się też ekipa z JetBrains, wypuszczając na początku wakacji nie tylko stabilne Jetpack Compose dla Androida, ale również wersje projektu dla Web oraz Desktopa – od niedawna zwanych jako Kotlin Multiplatform.
Oprócz tego stworzyli oni też Skiję – odpowiednik przeglądarkowego Canvas API, stanowiącym alternatywę dla wysłużonego Graphics2D. Stworzenie tego typu rozwiązania od zera byłoby bardzo trudne, dlatego Skija „buduje na barkach giganta” – biblioteki Skia, która służy m.in. jako silnik interfejsu Chrome.
Cały obraz dopełnia się też w Projekcie Lanai. W ramach prac nad Lanai, Jetbrains współpracował z samym Oracle, a celem projektu było stworzenie nowoczesnej metody renderowania obiektów interfejsu na macOS. OpenGL, używany przez Swinga, nie jest już aktywnie wspierany przez komputery Apple – obecnie obowiązującym tam rozwiązaniem jest Metal, własnościowe API, cechujące się wysoką wydajnością i rozwijaną wraz z kolejnymi wersjami systemu. Lanai wyjść ma już za moment, wraz z Javą 17. Teraz stojący za nim ludzie planują zaś Projekt Wakefield – podobną inicjatywę, tym razem dla Linuxa i serwera wyświetleniowego Wayland.
Przeczytaj więcej
AdoptOpenJDK zmieniło się w Adoptium i trafiło pod skrzydła Eclipse
AdoptOpenJDK to projekt, który powstał jako efekt wysiłków społeczności walczącej o “wolną” implementacje JDK. W ciągu ostatnich 12 miesięcy, ostatecznie trafił on pod skrzydła Eclipse Foundation. Efekt, po ponad rocznych, starań skwitowany został przechrzczeniem projektu na Eclipse Adoptium (JDK jest znakiem towarowym należącym do Oracle) oraz powstanie Adoptium Working Group.
Biorąc pod uwagę fakt, że Oracle obecnie udziela wyłącznie sześciu miesięcy wsparcia, dla każdego nowego wydania, Adoptium jest krytycznym projektem dla całej społeczności, nie tylko Javy, ale również innych JVMowych języków. Cały projekt fundowany jest przez mnogość partnerów – Alibaba Cloud, Huawei, IBM, iJUG (stowarzyszenie niemieckich JUGów), Karakun AG, Microsoft, New Relic oraz Red Hat będą brać udział w rozwoju otwartej wersji Javy. W ramach negocjacji udało się też otrzymać dostęp do javowego Technology Compatibility Kit, “wywalczonego” od Oracle.
Ostatecznie, w wyniku prac grupy stworzone zostało Eclipse Temurin – oficjalny build JDK, który może zostać użyty jako “baza” przez całą społeczność i wszystkich tych, którzy chcą stworzyć własny wariant JDK.
Przeczytaj więcej
Security Manager usuwany z Javy – nie bez kontrowersji
JEP 411: Deprecate the Security Manager for Removal przyniósł to, co programiści lubią najbardziej – usuwanie kodu. No, może niekoniecznie usuwanie, ale deprekracja to w końcu pierwszy krok ku pozbyciu się nadmiarowego balastu. A mówimy tutaj o balaście dosyć wiekowym – Security Manager swoje korzenie ma jeszcze w pierwszym wydaniu Javy.
Jego głównym celem było (i w zasadzie ciągle jest) możliwość granularnego sterowania uprawnieniami aplikacji uruchamianych w ramach JVM. Jest to opcja swoistej piaskownicy, pozwalającej np. ograniczyć dostęp do systemu plików albo zablokować wykonanie komend pokroju System.exit() – do tego używają go np. serwery aplikacyjne. Jego użycie szczególnie istotne było w epoce, gdy aplikacje javowe często były np. pobierane z sieci w formie apletów (które również uległy deprekacji w zeszłym roku)
Na wieść o tych planach, lista mailingowa JDK została wręcz zalana krytyką JEP 411. Twórcom Javy zarzucane było lenistwo, brak wypracowania sensownych alternatyw (innych niż „przykro nam, napisz sobie Agenta do maszyny wirtualnej”) – szczególnie aktywnym dyskutantem jest Reinier Zwitserloot, jeden z twórców Lomboka. Z drugiej strony w rozmowie bierze udział m.in. przywołany w poprzedniej edycji Ron Pressler czy Alex Bateman, którzy odbijają piłeczkę. Zarzucali oni krytykom, że o ile tak naprawdę wiele ich argumentum-at-securitum jest dość trafnych, to w realnym świecie nikt nie zwraca na przywoływane aspekty uwagi – typu sandboxowanie użycia bibliotek zewnętrznych.
Ostatecznie w nieco tylko zmienionej formie JEP 411 trafi do Javy 17.
Przeczytaj więcej
Microsoft ostro zaangażował się w rozwój Javy
Dla osób śledzących działania Microsoftu z pewnością nie będzie tajemnicą, że firma z Redmond dość mocno inwestuje ostatnio w Javę. Po dekadach starań (to jest naprawdę dłuuuga historia), wreszcie wypuściła ona własny wariant OpenJDK. Na razie dostępna jest wersja JDK 11, ale do wczesnego wglądu trafiła też “szesnastka”. Całość oparta jest o Eclipse Adoptium, którego Microsoft jest sponsorem. Staną się one oficjalnym rozwiązaniem używanym w ramach platformy Azure (do tej pory używane były warianty JDK tworzone przez Zulu). Dla twórców oprogramowania o niszowych gustach z pewnością istotnym faktem będzie to, że microsoftowa Java wydana zostanie również na procesory ARM – zarówno AARch64 jak i M1.
Microsoft stworzył także GCToolkit. Jest to zestaw bibliotek służących do analizy logów Garbage Collectora. Umożliwia on “próbkowanie” GC i udostępnia interfejs API do odpowiednio wygenerowanych agregat. Pozwala to użytkownikowi na tworzenie złożonych analiz stanu pamięci JVM.
Nie wiem, czy pamiętacie, ale Microsoft ma też własne “IDE” dla Javy, jeśli tak można nazwać zestaw pluginów do Visual Studio Code. Jego kolejne aktualizacje pojawiają się w regularnych, miesięcznych odstępach i stanowią intrygującą alternatywę dla IntelliJ.
Przeczytaj więcej
Project Loom dalej się rozwija, wzbudzając pewne kontrowersje
O Projekcie Loom, mającym wprowadzić Kontynuacje do maszyny wirtualnej Javy, powiedziano już naprawdę dużo. W ciągu ostatnich dwunastu miesięcy najciekawszą dyskusję wzbudził jednak, moim zdaniem, Greg Wilkins (Project Lead znanego wszystkim Jetty’ego)
Postanowił on przygotować testy Early Access buildu Projektu Loom, w celu zweryfikowania, na ile obietnice jego twórców mają odzwierciedlenie w realiach. Na pierwszy ogień poszła możliwości stworzenia miliona równocześnie istniejących równoległych wątków. Efekt jest hmmm… połowiczny. Pisząc w skrócie, nie ma problemu ze stworzeniem wątków jako takich, ale za wiele to się w nich nie zrobi – nawet średniej wielkości Stacktrace (1000 operacji) per wątek szybko udowadnia, że RAM nie jest z gumy. Także o ile rzeczywiście istnieje możliwość stworzenia miliona wątków, to styl programistyczny w nich użyty musi być drastycznie inny (np. poprzez mocne ograniczenie bibliotek zewnętrznych, które potrafią bardzo stacktrace wydłużać)
Ze względu na mocno krytyczny charakter posta, pojawiła się do niego masa komentarzy, zarówno na Reddicie (gdzie Ron Pressler odpierał zarzuty) jak i na liście mailngowej OpenJDK, gdzie znowu cały temat komentował Alan Bateman. Cała dyskusja jest równie frapująca jak wspomniane artykuły.
Przeczytaj więcej
JFrog zamyka Bintray i JCenter 🐸
Podejrzewam, że każdy, na jakimś etapie swojego życia (a już zwłaszcza, jeśli pisał coś w Androidzie), miał okazję wpisywać do swoich .pom lub .gradle odnośniki do repozytoriów Bintraya lub JCenter. Te alternatywy dla Maven Central stanowiły przystań dla wersji testowych zależności, niezależnych projektów. Sprawdźcie, czy wasze buildy nie mają zależności na JCenter, przed 1 lutego 2022. Inaczej może Was spotkać przykra niespodzianka.
Co ja się łudzę, ta informacja i tak zaskoczy wielu developerów jak zima drogowców (chyba, że będą czytać nasze JVMowe wtorki, bo na pewno o tym przypomnimy).
Przeczytaj więcej
Wydano nową wersję Microprofile
Wprawdzie miało nie być o poszczególnych wydaniach, ale dla niszowych, a istotnych technologii robimy tu wyjątek (takich wyjątków będzie jeszcze parę).
Pewnie większości z Was obiła się o uszy nazwa Microprofile, jednak prawdziwie docenić go będą mieli okazję tylko Ci, którzy w swojej karierze pracowalimieli okazję pracować z Javą EE, zwłaszcza w okresie, gdy branża zaczęła robić maślane oczy od konceptu dziś znanego jako Mikroserwisy. Java EE posiadała już koncept profili, ale były to profile “ciężkie” i “jeszcze cięższe”, na pewno nic co dało określić się słowem “mikro”. Postanowiono więc stworzyć coś, co będzie Javą EE odpowiadającą na potrzeby czasów. Od tamtej pory projekt trafił pod skrzydła fundacji Eclipse, a teraz mamy okazję obserwować jego czwartą edycję.
Wraz z kolegami bardzo chcemy się tym projektem pobawićCo więc przyniósł Microprofile w wersji czwartej? Głównym celem releasu jest wsparcie niedawno wydanej Jakarty EE 8 i związanych z nią nowość, ale i w samym profilu pojawia się masa interesujących rzeczy. Przynosi on nową obsługę konfiguracji, a także ogromny krok do przodu jeśli chodzi o wsparcie dla Observability – nowe wersje modułów OpenTracing, Metrics i Health, a także Fault Tolerance, który jest jednym z najelegantszych rozwiązań tego typu, z jakimi miałem styczność – pod warunkiem, że komuś nie przeszkadza nadmiar anotacji .
Przeczytaj więcej
Java na GraalVM zaczyna kompilować samą siebie
GraalVM 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ę jJavowy fFramework 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 jJavowych w środowisku GraalVM. Pod tym względem 2021 przyniósł małą rewolucję – możliwość uruchomienia aplikacji jJavowych 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 jJavowa 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.
Przeczytaj więcej
Pivotal wypuścił Spring Native 🌿
Kontynuując temat GraalVM – 2021 przyniósł też również wersje Springa przeznaczoną na tą właśnie platformę.
Jak bardzo zelektryzowało to społeczność niech udowodni fakt, ż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.
Ok, ale co konkretnie to oznacza? 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.
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.
Twórcy Springa bardzo aktywnie wsparli również sam rozwój GraalVM, pomagając umożliwić w pełni “natywne” testowanie aplikacji za pomocą JUnita (przed wprowadzonymi przez nich zmianami, 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.
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.
Przeczytaj więcej
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!
Project Valhalla wymusza grube zmiany w modelu danych JVM
Valhalla jest jednym z najważniejszych obecnie rozwijanych projektów odbywających się w ramach JVMa. Johna Rose’a i Briana Goetza opublikowali w zeszłym roku serię pokazującą, 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.
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.
Przeczytaj więcej
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
