Witam w 2024 roku! Ale zanim pójdziemy dalej, przypomnijmy sobie z kronikarską sumiennością to, co wydarzyło się w 20231
Rok, w którym dostaliśmy JDK 21
2023 to z pewnością rok, który zapamiętamy dzięki JDK 21. To właśnie ona sprawiła, że Java wróciła na języki świata programowania, a to wszystko dzięki niezwykle bogatemu zbiorowi nowych, oczekiwanych od lat funkcji, gdzie frontrunnerem były z pewnością wirtualne wątki. Te odmieniane były przez wszystkie przypadki, frameworki prześcigały się z ich adopcją (i do tego tematu sobie jeszcze wrócimy), ale ilość innych praktycznych nowości też robiła wrażenie. Tych było tak wiele, że nie zamierzam tutaj przechodzić przez wszystkie, i zapraszam Was do tekstu, który opublikowałem przy okazji premiery, a który całość podsumowuje w sposób co najmniej zwięzły: A one-sentence summary of each new JEP from JDK 21 . Oprócz tytułowych jedno-zdaniowców, każdy nowy JEP dostał też zbiór dodatkowych linków, które pomogą Wam poczuć atmosferę dyskusji odbywającej się w koło nowego wydania.
No dobra, to skoro oczywistości mamy za sobą, czas przejść do rzeczy, które RZECZYWIŚCIE mieliście okazje przegapić 😇.
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!
Rok, w którym umarł GraalVM EE, a narodził się GraalOS
Rok 2023 zapamiętamy też jako ten, podczas którego GraalVM przeszedł sporą transformację. Pierwszą kluczową zmianą były kwestie licencyjne, które to rozpoczęły się jeszcze w końcówce 2022. GraalVM, tradycyjnie oferował dwie edycje – Community (CE) i Enterprise (EE). Na JavaOne 2022 zapowiedziano włączenie GraalVM CE pod skrzydła OpenJDK (w ramach projektu Galahad). W połowie 2023 zdecydowano się na równie duży krok, jeśli chodzi Enterprise Edition. Ta została zastąpiona przez Oracle GraalVM, nową dystrybucję z modelem licencyjnym, znanym jako GraalVM Free Terms and Conditions (GFTC). Ta zmiana licencyjna uławia darmowe użycie najnowszej wersji Oracle GraalVM zarówno w środowiskach deweloperskich, jak i komercyjnych, co stanowi znaczący krok naprzód w porównaniu do poprzednich ograniczeń licencyjnych.
Kolejną istotną nowością jest wprowadzenie Graal Cloud Native (GCN). To specjalna wersja zestawu modułów frameworka Micronaut (o Micronaucie jeszcze będzie trochę później), zaprojektowana do tworzenia mikroserwisów w sposób pełni kompatybilna z kompilacją GraalVM Native Image. Można je de facto uznać za pierwszy pełnoprawny framework GraalVM-First.
Również w 2023 opublikowany został GraalOS, nowe środowisko uruchomieniowe dla aplikacji chmurowych, skoncentrowane na optymalizacji funkcji serverless poprzez możliwość odpalenia ich (dzięki GraalVM) na serwerach bare metal. GraalOS wykorzystuje kompilację ahead-of-time (AOT) do konwersji aplikacji w samodzielne natywne pliki wykonywalne, co pozwala na eliminację „cold startów” i zwiększa wydajność aplikacji serverless. GraalOS w teorii ma być dostępny dla każdego środowiska, ale jest zaprojektowany do integracji z Oracle Cloud Infrastructure Functions i stanowić ma przewagę konkurencyjną tego środowiska. Zobaczymy, czy stanie się odpowiednim argumentem dla rozwiązania Oracle.
Warto zauważyć, że AWS Lambda umożliwia już obsługę GraalVM w ramach tak zwanego niestandardowego środowiska wykonawczego. Jednakże zasadniczo wiąże się to z uruchomieniem kontenera z aplikacją GraalVM. GraalOS umożliwia obejście tej warstwy, eliminując potrzebę uruchamiania kontenera i inicjowania maszyny JVM.
Oprócz powyższych zmian, ewolucje przeszedł również Truffle. Ten metaframework umożliwiający tworzenie interpreterów języków programowania na potrzeby ich uruchomienia w ramach GraalVM, został oddzielony od głównej platformy. Same interpretery dla Pythona czy JavaScripta dostępne są teraz jako osobne pakiety, które możemy zaczytać jako zwykła dependencja projektu, pomijając wcześniej wymagany customowy tooling.
Więcej szczegółów znajdziecie w poniższych edycjach:
- GraalVM EE is Dead, Long Live Oracle GraalVM – JVM Weekly vol. 47
- What does GraalVM for JDK 21 have in common with the Rabbit of Caerbannog? Both surprise with their power – JVM Weekly vol. 58
Rok, w którym MicroProfile połączył siły z Core Profile
Teraz cofniemy się o całe 12 miesięcy – MicroProfile 6.0 był bowiem pierwszą dużą premierą roku 2023. Poza standaryzacją nowego zestawu API, przyniósł on zaś oczekiwane uporządkowanie tego, jak wygląda obecnie relacja projektu z Jakarta EE.
Wraz z Jakarta EE 10 pojawił się tak zwany Core Profile – zestaw API, które zgodnie z planami twórców mają stanowić minimum niezbędne do tworzenia mikrousług w Javie. Brzmi to bardzo podobnie do celu, jaki postawili sobie twórcy MicroProfile, dlatego od początku zastanawialiśmy się, w jaki sposób pojawienie się Core Profile na niego wpłynie. Jakaś forma synergii wydawała się tutaj być bardzo naturalna, ale równocześnie od początku pojawiały się jasne komunikaty, że nie należy spodziewać się dwóch inicjatyw w jedną. Ich twórcy jednak zapewniali, że pozostają ze sobą w stałym kontakcie i w przyjacielskich stosunkach.
Przed premierą MicroProfile 6.0, strategią standardu było wybieranie sobie z Jakarta EE tych API, które według twórców projektu miały być najbardziej przydatne dla użytkownika MP. W wypadku MicroProfile 5.0 było to więc:
- Jakarta Contexts and Dependency Injection (CDI)
- Jakarta Annotations (JPA)
- Jakarta RESTful Web Services (JAX-RS)
- Jakarta JSON Binding (JSON-B)
- Jakarta JSON Processing (JSON-P)
Od wydania MicroProfile 6.0 projekt dokonał alignementu z Jakarta Core Profile. Oznacza to, że zamiast na pojedynczych API będzie on posiadał zależność na pełnym Profilu, a tranzytywne trafią do niego również następujące API:
- Jakarta RESTful Web Services
- Jakarta Interceptors
Ze zrozumiałych powodów, minimalna wersja Jakarta EE wspierana przez MicroProfile to teraz Jakarta EE 10.
Więcej szczegółów znajdziecie w poniższej edycji:
Rok, w którym Testcontainers stały się częścią Docker
O ile w wypadku JavaScriptowych infrastrukturalnych projektów dość często (a przynajmniej 2021 i 2022 nas w tym temacie dosyć rozpieściły) mamy do czynienia z ogłoszeniami nowych rund zewnętrznego finansowania (Vercel, Deno), o tyle relatywnie rzadko słyszy się, aby jakaś javowa biblioteka zakładała własną chmurę (chyba, że bierzemy tutaj pod uwagę takiego Confluence i Kafkę). Dlatego też ze sporym uśmiechem śledziłem tegoroczne ogłoszenia od AtomicJar.
Żeby przedstawić, na co mają iść dane środki, warto przypomnieć sobie czym AtomicJar się zajmuje. Kojarzycie TestContainers? Jest to biblioteka wspierająca dla JUnita, zapewniająca lekkie, jednorazowe instancje popularnych baz danych, przeglądarek internetowych dla Selenium i ogólnie wszystkiego, co można łatwo uruchomić w kontenerze Dockera. Wprawdzie wiele osób pewnie będzie zżymać się na uruchamianie kontenerów w testach jednostkowych, ale popularność TestContainers udowadnia, jak bardzo częsty jest to przypadek użycia.
W lutym AtomicJar pozyskało 25 milionów dolarów finansowania. Środki te miały na celu rozwój TestContainers Cloud – rozwiązania Software-as-a-Service, które umożliwia uruchamianie kontenerów nie lokalnie, ale w chmurze. Miało to na celu ułatwienie pracy programistom, zwłaszcza w kontekście cięższych testów i ograniczeń sprzętowych.
Następnym krokiem była premiera Testcontainers Desktop, aplikację mającą na celu przyspieszenie startu testów poprzez funkcje takie jak stałe porty czy możliwość zamrażania kontenerów dla celów debugowania. Testcontainers Desktop stanowił ułatwienie dla tych, którzy wciąż preferują lokalne środowisko testowe, jednocześnie dając dostęp do wersji próbnej Testcontainers Cloud.
Kulminacyjnym wydarzeniem roku było przejęcie AtomicJar przez Docker w grudniu. Tranzakcja miała strategiczne znaczenie zarówno dla samego Dockera (który z przytupem wkroczył w ten sposób w rynek Cloud DevEnvironments), jak i dla Tescontiners, potencjalnie rozszerzając bazę użytkowników ich rozwiązania, które dzięki współpracy z Dockerem ma szanse wyjść poza świat Javy i stać się rynkowym standardem.
Oby więcej takich historii w 2024.
Więcej szczegółów znajdziecie w poniższej edycji:
- What does the „State of Developer Ecosystem 2022” tell us about Java and the JVM ? – JVM Weekly #32
- Java, Kotlin, Scala: Insights from State of Developer Ecosystem 2023 – JVM Weekly vol. 62
- Docker acquires AtomicJar, company behind Testcontainers – JVM Weekly vol. 64
Rok, w którym Spring pośrednio stał się częścią Broadcom
O ile powyższe przejęcie witam bardzo optymistycznie, to jednak nie każde ogłoszenie tego typu to powód do radości. Dla nikogo zaskoczeniem nie będzie, że duże projekty Open-Source w dzisiejszych czasach zwykle posiadają swoich korporacyjnych sponsorów, a wielu ludzi rozwijających je robią to w ramach firmowych etatów. Dlatego też ruchy spółek giełdowych potrafią mieć na ich rozwój olbrzymi wpływ.
Pivotal Software (stojący za Springiem) i VMware mają ze sobą silne powiązania historyczne i biznesowe, czego kulimancją w 2019 było przejęcie Pivotala przez tą drugą firmę. W 2023 doszło do kolejnych akwizycji samego VMWare – Broadcom, znany głównie z produkcji półprzewodników, podjął decyzję o rozszerzeniu swojej działalności na rynku oprogramowania. Wybór padł na VMware, jako że firma uznawana jest za lidera w dziedzinie wirtualizacji i infrastruktury chmurowej, co stanowiło atrakcyjny kierunek rozwoju dla Broadcom. Przejęcie rozpoczęte w maju 2022, a będące jedną z większych transakcji tego typu opiewającą na 69 miliardów dolarów, domknięto finalnie w zeszłym tygodniu, 22 listopada.
Bardzo szybko po transakcji doszło do serii zwolnień w firmie. Nie wiemy jaki jest ich zakres, ale na pewno zaafektowały one też zespół odpowiadający za najpopularniejszy javowy framework. Oliver Drotbohm, architekt Springa, który od ponad dekady prowadzi projekt Spring Data, podsumował całość wymownie.
Więcej szczegółów znajdziecie w poniższej edycji:
Rok, w którym Oracle wywraca do góry nogami pricing ich wersji JDK
Jak już wspomniałem na samym początku, poza wyjątkowymi okazjami jak JDK 21, Java bardzo rzadko trafia na języki społeczności programistycznej. O ile nas interesować mogą zmiany w maszynie wirtualnej i inne wiadomości z ekosystemu, to jednak ktoś „niezainwestowany” w ekosystem o Javie słyszy głównie w momencie internetowych „dram”. A z taką mieliśmy do czynienia początkiem lutego, a wszystko przez to, że Oracle zdecydował się zmienić sposób naliczania opłat za swoje JDK. Nie mogę więc nie poświęcić miejsca temu faktowi w podsumowaniu roku.
23 stycznia Oracle poinformował, że zmienia model licencyjny Oracle JDK na Java SE Universal Subscription. Nowy cennik, zamiast bazować na stanowiskach roboczych i procesorach, opiera się na ilości pracowników zatrudnianych przez firmę: w tych do 1000 pracowników opłaty wynoszą 15$/mc, dla większych 5,25$/mc. Dla wielu (większości?) firm korzystających z Oracle JDK oznacza to będzie wzrost kosztów, ponieważ w obliczeniach brani są pod uwagę nie tylko programiści, ale wszyscy pracownicy firmy – także ci spoza działu IT, a także np. kontraktorzy.
Zmiany nie dotyczy już płacących klientów, którzy będą mogli się rozliczać na współczesnych warunkach (aczkolwiek nie udało mi się dogrzebać, w jaki sposób rozwiązane zostanie np. rozszerzenie licencji). Kończąc na pozytywnej nucie, zapisy mogą być teoretycznie korzystne dla niektórych firm, zwłaszcza małych startupów stricte technologicznych, posiadających małą ilość pracowników. Enterprise tracą chyba w każdej konfiguracji, ale mali, szybko skalujący się mogą zyskać – aczkolwiek wbrew tej teorii może być fakt wysokich opłat per pracownik (15$/mc) w firmach poniżej 1000 zatrudnionych osób.
Należy pamiętać, że Oracle nie jest jedynym dostawcą JDK, więc każdy chcący używać Javy za darmo, może użyć np. Adoptium. Co jest smutne – świetnie wiedzą to ludzie znający ekosystem Javy, ale dla szerokiego odbiorcy jest to stan mocno nieintuicyjny. W końcu nie ma alternatywnych dystrybucji Go czy Rusta (albo są statystycznie pomijalne).
Więcej szczegółów znajdziecie w poniższej edycji:
Rok początku końca problemu nulli w Javie dzięki projektowi Valhalla
2023 to też kolejny rok iteracji nad Valhallą. Projekt ulega dalszej rewolucji i z każdą kolejną iteracją staje się coraz ciekawszy i ma szanse (trochę przypadkiem) dać nam usprawnienia, na które programiści czekali… no w zasadzie od zawsze. Jedną z funkcji języka, które dostarczyć ma Valhalla są Value Type (czy jak one się tam teraz po kolejnych iteracjach mają nazywać). Głównym rozróżnieniem między „typem referencyjnym” (czyli obecnie istniejącymi w języku) a „typem wartości” jest fakt, że te drugie nie mogą przyjmować wartości null. W odróżnieniu od takiego Kotlina, własność ta nie jest łatwo wyrażalna w samym języku. Dlatego też projektanci do Valhalli rozważają wprowadzenie nowego znacznika „nullness” dla obiektów.
Jeśli nie śledzicie na bieżąco rozwoju Valhalli, możliwe, że umknął Wam fakt, że w pewnym momencie twórcy zaproponowali sufiksy .val i .ref. Miały one informować, czy chcemy używać danego obiektu jako wartości, czy jako referencji. To było dla mnie najbardziej problematyczne spośród proponowanych zmian, obawiałem się bowiem komplikacji składni. Na razie wygląda na to, że uda się z nich zrezygnować. Prace nad rozwojem całego projektu pozwoliły zredukować różnice między typami prymitywnymi a obiektami do dwóch fundamentalnych różnic – posiadania wartości domyślnej (jak 0 w przypadku int) oraz wsparcia dla nullowalności.
W odróżnieniu od takiego Kotlina, własność ta nie jest łatwo wyrażalna w samym języku. Dlatego też projektanci do Valhalli rozważają wprowadzenie nowego znacznika „nullness” dla obiektów. Pojawiła się propozycja wprowadzenia dwóch dodatkowych oznaczeń przy definiowaniu typu – ! oznaczający nie dopuszczamy nulla oraz ? oznaczający ten obiekt jest nullowalny. W skrócie:
Foo? oznacza ten typ zawiera w swoim zbiorze wartości nullFoo! oznacza ten typ nie zawiera w swoim zbiorze wartości nullFoo oznacza 🤷♂️ – inaczej mówiąc, nie określony stan nullowalności
Z czasem, twórcy będą dążyć do tego, aby wersja bez odpowiedniej adnotacji przyjmowała cechy wariantów anotowanych – na ten moment wydaje się, że nieoznaczone Foo będzie w większości przypadków traktowane jako nienulowalne.
Więcej szczegółów znajdziecie w poniższej edycji:
- Will Valhalla bring better nulls to Java? – JVM Weekly #33
- Exploring the Newest Updates of Project Leyden, Valhalla & Hermes: JVM Weekly vol. 54
Rok, w którym z wypiekami na twarzy oglądałem JVM Language Summit
JVMLS to roczne wydarzenie, które gromadzi ekspertów i inżynierów związanymi z rozwojem JVM, aby omawiać aktualne udoskonalenia i przyszłość tej platformy. W tym roku mamy dostęp do masy materiałów z eventu, co pozwoliło nam zerknąć pod maskę wielu projektów, które zwykle pozostają w cieniu.
Podczas JVMLS, sporo miejsca poświęcono Projektowi Leyden, który wprowadza nową technikę optymalizacji kodu Javy, opartą na „przesuwaniu i ograniczaniu” obliczeń . Projekt ten umożliwić ma tworzeniu „kondensatorów”, które analizują zachowanie aplikacji w czasie rzeczywistym i dostosowują ją do efektywnego działania. Dzięki temu, aplikacje Java mogą być zoptymalizowane już przed uruchomieniem, co skraca czas „rozgrzewania” i zapewnia dłuższe okresy szczytowej wydajności. Na JVMLS po raz pierwszy mogliśmy przyglądnąć się wynikom prac, zaprezentowany został ApplicationModel, bazowy interfejs modelu, a także patterny implmentacyjne.
Kolejnym interesującym projektem jest Projekt Babylon, który ma na celu dostarczenie bardziej zaawansowanych możliwości niż istniejące mechanizmy refleksji w Javie, poprzez wprowadzenie tak zwanej „refleksji kodu”. W odróżnieniu od standardowej refleksji, działającej w runtime, ta ma pozwolić programistom na analizę i manipulację kodem źródłowym również w czasie kompilacji, umożliwiając dynamiczne generowanie kodu dla różnych środowisk uruchomieniowych, podobnie jak LINQ w języku C#.
Projekt Panama też nie zwalnia, i po ogarnięciu tematy Foreign Memory i usprawnieniu pracy z programami napisanymi w językach „natywnych”, ma teraz na celu ułatwienie integracji Javy z nietypowymi środowiskami uruchomieniowymi, takimi jak np. GPU. Dzięki Panama, programiści będą mieli lepszą kontrolę nad transferem danych między różnymi rodzajami pamięci oraz nad działaniem Garbage Collectora, co ułatwi pracę z frameworkami związanymi z uczeniem maszynowym i sztuczną inteligencją. Jego twórcy mocno współpracują i wymieniają doświadczenia z TornadoVM, platformą pozwalającą na wykonywanie aplikacji Java na różnych platformach sprzętowych, w tym na GPU, FPGA i systemach wielordzeniowych.
TornadoVM wykorzystuje kompilator JIT GraalVM, co pozwala na przekształcanie kodu Java w natywny kod maszynowy, co w wielu przypadkach znacząco przyspieszyć wydajność aplikacji. Tworzą oni też użyteczne abstrakcje, ułatwiającą tworzenie portowalnego kodu. W tym roku (rzutem na taśmę, w grudniu) wreszcie ukazała się jego wersja 1.0, więc można myśleć o szerszej adopcji 😉
Zdecydowanie nie mogę się doczekać JVMLS 2024.
Więcej szczegółów znajdziecie w poniższej edycji:
- Panama, OpenCL and TornadoVM: Java’s entry into the GPU world – JVM Weekly vol. 55
- Exploring the Newest Updates of Project Leyden, Valhalla & Hermes: JVM Weekly vol. 54
- Project Babylon: Chance for LINQ (and more) in Java – JVM Weekly vol. 56
Rok, w którym zapowiedziano Kotlin 2.0
W świecie Kotlina szykują się spore zmiany – przynajmniej jeśli chodzi o numeracje, aczkolwiek na niej się nie skończy.
Twórcy ogłosili bowiem, że wydanie 1.9 będzie ostatnim z linii 1.x. Wersja 1.10 się nie pokaże, zamiast niej przeskoczymy od razu do wydania 2.0. Wynikać ma to z faktu, że to właśnie na tą wersje planowane jest wydanie długo oczekiwanego kompilatora K2 – „jednego, by wszystkimi rządzić” i mającego zapewnić wspólną infrastrukturę dla wszystkich potencjalnych targetów języka. Dzięki temu jego twórcy nie będą musieli każdorazowo implementować tych samych funkcjonalności na potrzeby JVM, WebAssembly czy Androida, co ma znacznie przyspieszyć ewolucje Kotlina. Zmiana jest więc na tyle duża, że uznano za zasadne odpowiednie ukoronowanie jej podbiciem numeracji.
Zmiana „dużej” wersji języka potrafiła mocno zamieszać w ekosystemie danego języka, jednak w wypadku Kotlina JetBrains obiecuje bardzo stabilny proces migracji. Ma być to możliwe do osiągnięcia dzięki dwóm składowym. Po pierwsze, zmiany motywujące podbicie numeracji odbywają się pod maską, a twórcy celowo nie planują wprowadzać w nowym wydaniu żadnych nowych nowości w samym syntaksie języka – te zostawiają sobie na wydania 2.x, które przyjdą po udanym przejściu na K2 (a już kilka kąsków zapowiedziano). Dodatkowo jednak JetBrains zyskuje na tym, że kontroluje zarówno Kotlina, jak i jest głównym dostawcą narzędzi do niego. Pozwala to bowiem na znacznie sprawniejsze przeprowadzenie całej operacji, gdy większość najważniejszego toolingu może być rozwijana równolegle z językiem.
Więcej szczegółów znajdziecie w poniższych edycjach:
- Will Valhalla bring better nulls to Java? – JVM Weekly #33
- Play Framework is reborn like a phoenix from the ashes…. and gets rid of Akka – JVM Weekly vol. 60
- TLDW: Opinionated Wrap-up of KotlinConf 2023 Keynote – JVM Weekly vol. 40
Rok, w którym Roman Elizarov odszedł z Kotlina
Zostając w świecie Kotlina końcówką roku gruchnęła duża informacja. Roman Elizarov, lead projektu, ogłosił swoje odejście z JetBrains z powodów osobistych, kończąc w ten sposób również swoją pracę nad językiem. Pożegnanie odbyło się serią tweetów, w których wyrażając wdzięczność za możliwość pracy nad Kotlinem i podkreślając swoje wielkie uznanie dla społeczności Kotlina.
Dowiedzieliśmy się też kto w przyszłości stanie za sterami języka – Mikhail Zarechenskiy, wcześniej pracujący za kulisami w JetBrains, zostanie głównym projektantem Kotlina. Kluczowe zmiany w zespole obejmują też Hadi Hariri, którego możecie znać jako Co-hosta podcastu Talking Kotlin – przejmie on teraz więcej obowiązków poza działaniami promocyjnymi i jego zaangażowaniem w KotlinConf. Również drugi prowadzący Talking Kotlin, Sebastian Aigner, będzie odgrywać teraz ważniejszą rolę w Kotlin Foundation, szczególnie w wsparciu inicjatyw szerszego ekosystemu Kotlin. Egor Tolstoy dalej zaś będzie kierować zespołem od strony Product Managementu.
Więcej szczegółów znajdziecie w poniższych edycjach:
Rok, w którym doczekaliśmy się wysypu ciekawych nowych wydań
Frameworki
Spring Framework 6.1 I Spring Boot 3.2
W Spring Framework 6.1 pojawiło się wsparcie dla dwóch kluczowych nowości: Wirtualnych Wątków oraz Projektu CRAC. Dla przypomnienia: Wirtualne Wątki to nowy koncept w Javie, wprowadzony w JDK 21 w ramach Projektu Loom, który zmienia podejście do współbieżności. W przeciwieństwie do tradycyjnych wątków, które są zarządzane przez system operacyjny, wątki wirtualne są zarządzane przez JVM, co pozwala na tworzenie dużej liczby wątków bez narzutu związanego z tradycyjnymi wątkami.
Projekt CRAC (Checkpoint/Restore in Application Continuation) pozwala zaś na zapisanie stanu działającej JVM i jego przywrócenie, skracając czas rozruchu aplikacji. To rozwiązanie redukuje problem „zimnego startu” aplikacji Javowych, co jest szczególnie istotne dla aplikacji serwerowych i serverless. Spring integruje się z CRAC, umożliwiając kontrolowane checkpointy i przywracanie stanu JVM.
Dodatkowo, w Spring Boot 3.2.0 wprowadzono rozszerzone wsparcie dla Apache Pulsara oraz interfejs RestClient z Spring Framework 6.1, który dostarcza prekonfigurowany klient HTTP do obsługi zapytań REST. Dodano także wsparcie dla JdbcClient oraz automatyczne logowanie Correlation Id podczas korzystania z Micrometera. Spring Boot 3.2.0 ułatwia także budowanie obrazów Docker z użyciem standardu Cloud-Native Buildpacks.
Więcej szczegółów znajdziecie w poniższych edycjach:
Quarkus 3.0
Quarkus 3.0 wprowadza rozbudowane Dev UI, które ułatwia zarządzanie i konfigurację aplikacji. Dzięki funkcji Dev Mode, Quarkus umożliwia Continuous Testing, co przyczynia się do wydajności i komfortu pracy deweloperów.
Niezwykle ciekawą nowością jest też Mutiny2, biblioteka stworzona przez zespół Quarkusa do programowania reaktywnego i asynchronicznego. Mutiny2 ma na celu uproszczenie kodu reaktywnego, oferując podejście bardziej intuicyjne od innych bibliotek, jak RxJava i Project Reactor. Jest to także symboliczne zamknięcie pewnej epoki, ponieważ Mutiny w nowej wersji przechodzi z własnej implementacji Reactive Streams API na standardowe java.util.concurrent.Flow.
Jednak choć Quarkus 3.0 przynosi wiele cennych zmian, brakuje pełnego wsparcia dla wirtualnych wątków, które było wspominane jako jedna z obiecujących funkcji.
Więcej szczegółów znajdziecie w poniższych edycjach:
Micronaut 4.0
Micronaut Framework 4.0 porzuca wsparcia dla wersji Java starszych niż JDK 17, co umożliwiło dostosowanie API do nowych składni języka, takich jak Java Records, Sealed Classes, Switch Expressions, Text Blocks czy Pattern Matching dla instanceof. Klient HTTP Micronaut został zaktualizowany do wersji opartej na kliencie HTTP Java wprowadzonym w JDK 11, co poprawiło wydajność. Micronaut 4.0 został też zoptymalizowany pod kątem wykorzystania GraalVM, dzięki czemu kompilowanie aplikacji Micronaut zależnych od innych bibliotek stało się łatwiejsze.
Ponadto, nowe wydanie wprowadza lepsze wsparcie dla chmur, modułową architekturę oraz wstępne wsparcie dla VirtualThreads. Dodatkowo, Micronaut Serialization stał się domyślnym modułem oferującym wydajne i bezpieczne interfejsy API serializacji/deserializacji JSON.
Więcej szczegółów znajdziecie w poniższych edycjach:
Helidon 4.0
Helidon 4 został pierwszym na świecie frameworkiem do mikroserwisów opartym o wirtualne wątki. Główną zmianą przychodzącą z wydaniem było bowiem zastąpienie Netty nową implementacją serwera o nazwie Níma. Níma został zaprojektowany tak, aby w pełni wykorzystywać wirtualne wątki Java 21, umożliwiając każdemu requestowi działanie na dedykowanym wirtualnym wątku. Upraszcza to proces wykonywania blokujących operacji i zapewnia wysoki poziom współbieżności, eliminując w ten sposób potrzebę skomplikowanego kodu asynchronicznego, co zwiększa wydajność, zwłaszcza (według doniesień samych twórców) w Helidon MP. Oznacza to również, że doczekaliśmy się pierwszego framework wymagającego do działania… Java 21.
Helidon SE, stanowiący podstawowy zestaw API dla Helidon, również przeszedł sporą transformację. Adopcja wirtualnych wątków umożliwiła przejście od asynchronicznych API do blokujących (aż się sam dziwie pisząc to zdanie). Ta zmiana upraszcza kod, czyniąc go łatwiejszym w pisaniu, utrzymaniu i zrozumieniu – daje nam to przedsmak tego, co czeka pewnie w przyszłości cały ekosystem. Osoby korzystające z Helidon 3 SE będą musiały niestety znacznie dostosować swój kod do zaktualizowanych API. Chociaż może to wymagać pewnego początkowego wysiłku, korzyści w postaci zwiększonej wydajności i prostoty kodu wydają się tego warte.
Więcej szczegółów znajdziecie w poniższych edycjach:
Dropwizard 3.0 i 4.0
Pamiętam czasy, gdy używałem Dropwizarda, kiedy ten szumnie obiecujący framework znajdował się na samym szczycie popularności. Mimo pierwotnego entuzjazmu, DropWizard zaczął tracić na znaczeniu i premiera wersji 3.0 i 4.0 przeszła bez echa w świecie technologii.
Powód dwóch wersji na raz jest prosty: Dropwizard 3.0 opiera się na Java EE i przestrzeni nazw javax., dzięki czemu migracja z Dropwizard 2.x do wersji 3.0 powinna być minimalna dla wielu projektów. Natomiast Dropwizard 4.0 opiera się na zależnościach Jakarta EE oraz przestrzeni nazw jakarta., co może wiązać się z większym nakładem pracy przy migracji z Dropwizard 2.x do wersji 4.x.
Obie wersje łączy też trochę wspólnych zmian – podniesienie wymaganej wersji Javy do 11, wprowadzenie struktury pakietów opartej o JPMS (mam wrażenie, że to jedno z pierwszych narzędzi biorących ten standard na poważnie), aktualizację Jetty do wersji 10.0.x (która też wymaga minimum Javy 11), aktualizację Apache HttpClient do wersji 5.x oraz usunięcie wsparcia dla JUnit 4.x (przeniesione do dropwizard-testing-junit4). Dodatkowo, tylko Dropwizard 4.0 dostał wsparcie dla Hibernate 6.0, wymagającego przejścia na jakarta.
Więcej szczegółów znajdziecie w poniższych edycjach:
Play Framework 2.9 i 3.0
Kolejne podwójne wydanie. Play Framework powrócił bowiem z nowymi wydaniami 2.9 i 3.0. Kiedyś uważany za głównego konkurenta Springa, Play wrócił do życia po tym jak został przekazany społeczności po pewnym okresie stagnacji i kontrowersji związanych z toksyczną nową licencją Akka, którego to rozwiązania wykorzystywał wewnętrznie.
Dlatego wydanie 3.0 przynosi migrację z Akki do Apache Pekko, forka Akka 2.6.x. Play 3.0 korzysta teraz z Pekko i jego komponentów HTTP. Jednakże, dla aplikacji silnie zintegrowanych z Akką, ta zmiana może wymagać pewnych wysiłków migracyjnych. Dlatego równocześnie wydano również Play 2.9, które kontynuuje wykorzystanie Akki i Akka HTTP.
Poza powyższym Play 2.9 i 3.0 skupiają się na wsparciu dla zaktualizowanych języków programowania, kompatybilności z Scala 3, a także na dostosowaniu do nowszych wersji bibliotek, takich jak Akka HTTP 10.2, Guice 6.0.0 i Jackson 2.14. Warto zaznaczyć, że Play Framework 3.0 przestaje wspierać starsze wersje Javy, a minimalna wymagana wersja to Java 11.
Więcej szczegółów znajdziecie w poniższych edycjach:
Grails 6
Grails 6.0, najnowsza odsłona frameworka do tworzenia aplikacji webowych w języku Groovy, wprowadza kilka istotnych usprawnień. Najważniejszą nowością jest Grails Forge UI, który umożliwia programistom bardziej efektywne zarządzanie projektami napisanymi w tym frameworku. Nowy interfejs dostarcza uproszczonego procesu inicjowania projektów, intuicyjnej nawigacji, walidacji w czasie rzeczywistym, wizualnego zarządzania zależnościami oraz responsywnego designu.
Grails 6.0 również wzmocnił integrację z Micronaut, ułatwiając korzystanie z beanów Micronauta w komponentach Grails oraz wykorzystując klienta HTTP Micronaut do bardziej płynnej interakcji z REST API. Warto zaznaczyć, że również Grails 6.0 podnosi minimalne wymagania dotyczące JDK do wersji 11.
Więcej szczegółów znajdziecie w poniższych edycjach:
WildFly 30
Swoją premierę miał też okrągły WildFly 30. Mimo że oficjalna rekomendacja to nadal JDK 17 lub 11, znacząca część tego wydania została poświęcona integracji z Java SE 21. Najnowsza wersja przechodzi na tej wersji testy certyfikacyjne zarówno Jakarta EE 10 Core Profile, jak i Microprofile. Wraz z coraz większym naciskiem na JDK 21 przewiduje się, że WildFly 30 może być ostatnim, które wspiera JDK 11.
Dodatkowo, wraz z przyjściem WildFly 30 nastąpiła zmiana licencji z Lesser General Public License 2.1 na Apache Software License 2.0, podsumowując w ten sposób długoletnią ścieżkę. Przejście z Lesser General Public License 2.1 (LGPL 2.1) na Apache Software License 2.0 (ASL 2.0) oznacza przejście z licencji „słabej” copyleft na bardziej liberalną.
Więcej szczegółów znajdziecie w poniższych edycjach:
Vaadin Hilla 2.0
Około rok temu Vaadin zaprezentował Hille, nowy framework webowy dla programistów Java, który umożliwia tworzenie kompletnych aplikacji z backendem opartym na Spring Boot i frontendem napisanym w TypeScript. Wcześniej znany jako Vaadin Fusion, Hille oferuje spójną konfigurację dla Java i TypeScript, bogaty zestaw komponentów interfejsu użytkownika oraz konkurujący z JHipsterem stos technologiczny.
W najnowszej wersji 2.0 dodano ulepszony generator TypeScript, wsparcie dla WebSocketów, kompatybilność z GraalVM Native Image, uproszczoną tworzenie motywów graficznych i narzędzie SSO Kit do szybkiego wdrożenia logowania jednokrotnego (SSO). Ta wersja korzysta z Spring Boot 3, Java 17 i Jakarta EE 10.
Więcej szczegółów znajdziecie w poniższych edycjach:
Tooling
AI Assistant w IntelliJ Idea
Wydanie IntelliJ IDEA 2023.3 przyniosło dostępnego dla wszystkich zainteresowanych Asystent AI, który opuścił fazę testową. Oferuje on ulepszoną generację kodu bezpośrednio w edytorze, kontekstową czat AI do zapytań związanych z projektem oraz akcje AI świadome projektu, wykorzystujące rozszerzony kontekst do uzyskania bardziej kompleksowych wyników. Wyobraźcie sobie taki ChatGPT wbudowany w Wasze IDE, z kilkoma dodatkowymi usprawniaczami dzięki byciu mocno zintegrowanym z samym IDE – tak zwanymi AI Actions.
Gradle 8.0
Gałąź Gradle 8.x to przede wszystkim prace nad Kotlin DSL, alternatywną składnią do tradycyjnego Groovy DSL, zapewniając lepsze podpowiadania składni przy edycji, które stało się od tego wydania wariantem domyślnym. Wraz z Gradle 8.0 poprawiona zostala kompilacji skryptów poprzez wprowadzenie interpretera dla deklaratywnych bloków pluginów {} w skryptach .gradle.kts, co daje zysk rzędu 20%, zbliżając czas procesowania Kotlin DSL do Gradle DSL.
Ale jeśli chodzi o Gradle, to jeszcze ciekawsze rzeczy pokazało JetBrains.
Amper od JetBrains
Programiści doświadczają zmieniających się trendów w zarządzaniu procesami budowania i integracji ciągłej. W ostatnich latach (a może nawet dekadzie), popularne stały się rozwiązania CI/CD jak Github Actions czy TravisCI, oparte na deklaratywnych konfiguracjach w YAML. W ekosystemie Javy, mimo dostępności Mavena z jego XML-em, wielu deweloperów przeniosło się na Gradle ze względu na jego większą elastyczność, choć czasami prowadzi to do skomplikowanych skryptów.
Ten trend wskazuje na ciągłe wyzwania w zarządzaniu złożonymi projektami, szczególnie w JetBrains, gdzie Kotlin Multiplatform uwidocznił problematykę Gradle. W odpowiedzi na te wyzwania, JetBrains rozpocząło Project Amper, mającym na celu uproszczenie konfiguracji konfiguracji Gradle przez użycie YAML. Amper obecnie wspiera Kotlin i Kotlin Multiplatform, a także Javę i Swifta. Ta inicjatywa ma na celu uczynienie Gradle bardziej dostępnym i mniej skomplikowanym.
Oficjalne Java Extension for Visual Studio Code od Oracle
Oracle opublikowało oficjalne rozszerzenie Javy dla środowiska Visual Studio Code, co stanowi stanowi z ich strony znaczny krok w uznaniu VSCode jako alternatywy dla tradycyjnych środowisk programistycznych. Pomimo istnienia wyspecjalizowanych narzędzi dla Javy, jak Intellij, coraz więcej programistów, w tym studenci i ci pracujący z różnymi językami, preferuje używanie tego toola. Rozszerzenie dostarcza funkcje takie jak auto-uzupełnianie, podświetlanie błędów, wsparcie dla debugowania oraz integrację z projektami Gradle i Maven. Ważną cechą jest wykorzystanie serwera języka opartego na protokole Language Server Protocol, pochodzącego z NetBeans (o samym LSP możecie poczytać trochę niżej).
Więcej szczegółów znajdziecie w poniższych edycjach:
Azul Zulu JDK 17 with CRaC support
Azul wydał wersje swojego OpenJDK 17 – Zulu – z wbudowanym wsparciem dla CRaC API. Jak już wspomniałem przy Springu, CRaC API umożliwia tworzenie „checkpointów” w trakcie pracy aplikacji, co pozwala na zapisanie pełnego stanu środowiska uruchomieniowego. Działa to podobnie do funkcji Save State w emulatorach, gdzie zapisywany jest cały stan pamięci na dysk i może być później odtwarzany. Azul jest pierwszym dostawcą, który oferuje komercyjne wsparcie dla tej technologii, co może być interesujące właśnie dla early adopterów nowych featurów Spring Framework 6.1.
Więcej szczegółów znajdziecie w poniższych edycjach:
Liberica JDK Performance Edition
BellSoft wprowadził na rynek Liberica JDK Performance Edition, zmodyfikowaną wersję JDK 11, w której zintegrowano poprawki wydajnościowe z JDK 17. To rozwiązanie umożliwia firmom korzystającym z JDK 11 zwiększenie wydajności aplikacji o 10-15% bez konieczności zmian w kodzie. Liberica JDK Performance Edition jest dostępna dla subskrybentów Liberica JDK od 1 sierpnia bez dodatkowych opłat i jest dostarczana wraz z innymi narzędziami od BellSoft.
Więcej szczegółów znajdziecie w poniższych edycjach:
Nowi ciekawi gracze
Fury
Fury, stworzony przez Ant Group, to nowa biblioteka do serializacji, Łączy ona wydajność serializacji statycznej z elastycznością dynamicznej serializacji, co może znaleźć zastosowanie w przypadku, gdy potrzebna jest duża przepustowość w masowej transmisji danych. Oferuje ona pełną kompatybilność z rozwiązaniami już istniejącymi w Javie i wykorzystuje nie tylko zaawansowane techniki serializacji, ale też operacje SIMD z Vector API oraz podejście Zero-Copy, minimalizując opóźnienia podczas transferu danych. Fury wykorzystuje także kompilator JIT, który generuje zoptymalizowany kod serializacji w czasie rzeczywistym.
Więcej szczegółów znajdziecie w poniższych edycjach:
EclipseStore 1.0
MicroStream rozwiązanie, które zapewnia trwałość danych w sposób „databaseless” natywne dla Javy, skrojone dla mikroserwisów i środowisk serverless. Pozwala na zapisywanie grafów obiektów Java w pamięci bez ograniczeń dotyczących ich wielkości czy złożoności, zapewniając jednocześnie pełną spójność transakcji. MicroStream w 2023 został przekształcony w oficjalny projekt Eclipse Foundation o nazwie EclipseStore 1.0, a wszystkie nowe funkcje będą teraz wydawane w jego ramach. To nie oznacza jednak końca rozwoju, a wręcz przeciwnie – zespół MicroStream nadal będzie aktywnie pracować nad projektem. Co istotne, EclipseStore ma pozostać kluczowym elementem strategii komercyjnej MicroStream, stanowiąc bazę dla oferty MicroStream Cluster i MicroStream Enterprise.
Więcej szczegółów znajdziecie w poniższych edycjach:
JoularJX 2.0
JoularJX 2.0 to narzędzie, którego celem jest umożliwienie programistom dokładnego monitorowania i analizy zużycia energii na różnych urządzeniach i systemach operacyjnych. Używa do tego zaawansowanych modeli pomagających w oszacowaniu zużycia energii przez kluczowe komponenty sprzętowe, takie jak procesor i pamięć, oraz dostarcza szczegółowe raporty i wizualizacje zużycia. Narzędzie to wpisuje się w rosnące zapotrzebowanie na zrównoważone praktyki programistyczne i efektywność energetyczną w branży IT.
Kluczową nowością w wersji 2.0 jest możliwość śledzenia zużycia mocy i energii na poziomie poszczególnych metod w kodzie. Dzięki temu programiści mogą uzyskać bardziej szczegółowy wgląd w to, które części ich aplikacji są najbardziej energochłonne
Więcej szczegółów znajdziecie w poniższych edycjach:
Nowości w świecie Kotlina i Scali
No to jeszcze zerknijmy co u kuzynów Javy, którzy zawsze smają się za nieco lepszych niż ona sama 😉
Kotlin Mulitplatform Stable
Kotlin Multiplatform (KMP) osiągnął stabilność i gotowość do użytku produkcyjnego, co jest znaczącym krokiem dla deweloperów mobilnych. Technologia umożliwia współdzielenie kodu między różnymi platformami, zacierając granice między rozwojem cross-platformowym a natywnym. Pozwala na integracje różnych środowisk, jak Android, iOS, a także aplikacje serwerowe, choć w tym ostatnim przypadku synergii jest nieco mniej. Siłę KMP pokazują biblioteki takie jak choćby Compose Multiplatform.
Więcej szczegółów znajdziecie w poniższych edycjach:
AWS SDK for Kotlin
Podczas tegorocznej edycji konferencji Amazon Web Services re:Invent w Las Vegas, ogłoszono wydanie AWS SDK dla Kotlina. SDK zostało zaprojektowane z uwzględnieniem idiomatycznych cech języka, włączając w to specjalistyczne DSL-e oraz wsparcie dla asynchronicznych wywołań usług AWS za pomocą coroutines. Aktualna wersja SDK umożliwia użycie w aplikacjach serwerowych oraz Android API w wersji 24+, jednak w planach są dodatkowe wsparcia dla innych platform, w tym Kotlin/Native.
Więcej szczegółów znajdziecie w poniższych edycjach:
Scala Metals 1.0
Language Server Protocol (LSP) to otwarty protokół oparty na JSON-RPC, umożliwiający interakcję między edytorami IDE a serwerami językowymi, które oferują funkcje specyficzne dla języka, takie jak autouzupełnianie czy przejście do definicji. Dzięki LSP, serwer języka raz stworzony może być wykorzystywany w wielu narzędziach, co eliminuje konieczność wielokrotnego wykonywania tej samej pracy.
Ważnym osiągnięciem w tym obszarze jest wydanie Metals 1.0, dojrzałego serwera językowego dla Scali. Jego rozwój to efekt współpracy wielu członków społeczności Scala. Metals 1.0, nazwany kodowo Silver, oprócz standardowych funkcji LSP, oferuje dodatkowe funkcje jak wsparcie dla projektów z wieloma rootami, uruchamianie reguł Scalafix i lepsze wsparcie dla Scala CLI. Obsługuje najnowsze wersje Scali (Scala 3.3.0, Scala 2.12.18, Scala 2.13.11).
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!
No i na końcu – rok, w którym ekosystem Java wskoczył na wagonik Hype związany z AI
No bo takiej ilości nowości to się chyba absolutnie nikt nie spodziewał. A to i tak tylko te ciekawsze.
langchain4j
langchain4j to zaś javowy wrapper do LangChain – stworzonego przez Harrisona Chase’a frameworku skoncentrowanego na Dużych Modelach Językowych (LLMach), takich jak GPT-3, GPT-3.5 i GPT-4 od OpenAI. Został zaprezentowany pod koniec października 2022 i zaprojektowany z myślą o tworzeniu nie tyle eksperymentów, co produkcyjnych aplikacji opartych o LLMy. LangChain umożliwia tworzenie łanchów różnych komponentów, takich jak szablony dla różnych typów promptów, integrację z różnymi modelami LLM, czy agentów korzystających z LLM do podejmowania decyzji, Wprowadza też koncepcje krótko- i długoterminową pamięć.
Semantic Kernel for Java
Microsoft również ma swoje SDK podobne do LangChainie o nazwie Semantic Kernel (SK), które umożliwia integrację dużych modeli językowych AI (LLM) z konwencjonalnymi językami programowania, w tym Javą. SDK to łączy język naturalny, tradycyjny kod i pamięć opartą o embeddingi, tworząc rozszerzalny model programowania. W praktyce, Semantic Kernel for Java pozwala programistom na płynną integrację usług AI, takich jak Azure OpenAI, z ich aplikacjami, wykorzystując model oparty o tak zwane skillach. Programiści mogą też tworzyć inteligentne plany przy użyciu Plannerów, łącząc umiejętności wykonywania złożonych działań z generatywną sztuczną inteligencją.
Rust-written JVM and Bytecode Transpiler: A Masterclass in Learning-by-Doing – JVM Weekly vol. 51
Spring AI
Spring AI, zainicjowany przez Marka Pollacka, to nowy projekt mający na celu stworzenie mostu między zaawansowanymi modelami AI (szczególnie z wariantami GPT), a typowymi wzorcami Springa w tworzeniu aplikacji. Projekt Spring AI czerpie inspirację z LangChain, LlamaIndex i Semantic Kernel, dążąc do oferowania programistom Spring podobnego doświadczenia AI. Wprowadza on wspólny interfejs API do interakcji z modelami, rozwija „prompty” kluczowe dla komunikacji z AI, a także oferuje parsery do konwersji ich odpowiedziami na zwykłe POJO. Ponadto, zdając sobie sprawę z ryzyk związanych z zarządzaniem wrażliwymi danymi w LLM-ach, umożliwia integrację z bazami wektorowymi, ułatwiając ich wykorzystanie bez konieczności re-treningu modeli.
quarkus-langchain4j
Rozszerzenie quarkus-langchain4j 0.1 stanowiło istotny krok w kierunku bardziej intuicyjnego i efektywnego wykorzystania sztucznej inteligencji w tworzeniu oprogramowania. Współpracując z Dmytro Liubarskyi i zespołem LangChain4j, Quarkus skupił się w rozszerzeniu na integracji LLM-ów z aplikacjami napisanymi w tym właśnie frameworków.
JVector
Bazy Wektorowe odgrywają istotną rolę w nowoczesnych aplikacjach AI, ułatwiając rozbudowę bazy wiedzy modeli i dostarczanie precyzyjnych odpowiedzi, minimalizując ryzyko błędów czy „halucynacji” AI. JVector, napisany w czystej Javie, to embeddowalny silnik wyszukiwania wektorowego, który napędza DataStax Astra i integruje się z Apache Cassandra. Oferuje on znaczące ulepszenia w stosunku do wyszukiwania wektorowego w Apache Lucene, używając zaawansowanego algorytmu DiskANN, który jest ponad 10 razy szybszy niż Lucene dla dużych zbiorów danych. Jest przeznaczony do prostej integracji, zachowując wysoką wydajność, korzystając przy tym z Vector API i instrukcji SIMD z projektu Panama.
Jlama
Jlama to silnik przetwarzania dla LLM, kompatybilny z modelami takimi jak Llama, Llama2 czy GPT-2 (który także został udostępniony), a także z formatem modelu Huggingface SafeTensors. Aby działać, wymaga on Javy 20, gdyż korzysta ze wspomnianego już Vector API, dzięki czemu umożliwia szybkie obliczenia wektorowe niezbędne podczas wnioskowania z modeli.
llama2.java
llama2.java jest bezpośrednim portem llama2.scala, który z kolei bazuje na llama2.c stworzonym przez Andreja Karpathy’ego. Projekt ma na celu służyć jako pole do testowania nowych funkcji językowych, ale także porównywać wydajność GraalVM w stosunku do wersji w C. W repozytorium znajdują się odpowiednie testy wydajnościowe. Aby skorzystać z tej biblioteki, potrzebujesz Javy w wersji 20+, wraz ze wsparciem dla MemorySegment i Vector API.
Amazon Q Code Transformation
Amazon Q, asystent AI dostępny dla Visual Studio Code oraz IntelliJ dla użytkowników z licencją CodeWhisperer Professional, wprowadza nową funkcję zwaną Code Transformation. Ta funkcja pozwala na inteligentny, masowy refaktoring, automatyzując powtarzalne zadania programistyczne. Obecnie Amazon Q koncentruje się na modernizacji aplikacji Java, umożliwiając przekształcenie kodu z Java 8 lub Java 11 na najnowszy LTS, czyli Java 17. Amazon Q jest obecnie w wersji Preview, co oznacza pewne ograniczenia – na przykład wspiera tylko projekty oparte na Mavenie.
SD4J (Stable Diffusion in Java)
Oracle Open Source wypuściło projekt SD4J, będący implementacją inferencji Stable Diffusion działająca na bazie ONNX Runtime, napisana w języku Java. Jest to zmodyfikowana wersja implementacji w C#, wyposażona w GUI dla powtarzalnej generacji obrazów oraz wsparcie dla negatywnych wejść tekstowych. Celem projektu jest demonstracja wykorzystania ONNX Runtime w Javie oraz najlepszych praktyk związanych z wydajnością w ONNX Runtime.
Mam nadzieje, że pod kątem ekosystemu JVM 2024 będzie przynajmniej tak ciekawy jak 2023.
PS: Jeśli dotarliście aż tutaj, to znaczy że się chyba podobało 🥂 Dlatego jeśli znacie kogoś, komu JVM Weekly mogłoby się przydać – podrzućcie mu ten newsletter na początku 2024!
Odkryj więcej świetnych treści!
- Rozsądna ilość treści
- Tylko wysoka jakość
- Pełne dopasowanie do Twoich potrzeb!
