W dniu dzisiejszym duża bomba od Spring Teamu, plany na Jakarta EE 10 oraz kilka mniejszych wydań (Quarkus, JavaFX, Scala).
Zapraszamy do lektury dzisiejszej, ciut spóźnionej edycji.
W dniu dzisiejszym duża bomba od Spring Teamu, plany na Jakarta EE 10 oraz kilka mniejszych wydań (Quarkus, JavaFX, Scala).
Zapraszamy do lektury dzisiejszej, ciut spóźnionej edycji.
Cześć, dzisiaj wyjątkowo w środę – początek tygodnia spędziłem na Segfault Unconference w Krakowie. Mega odświeżające jest uczestnictwo w offlinowej konferencji, ale przez to złapaliśmy jednodniowy poślizg, za co przepraszamy 😅
Cały świat javowy czeka już na premierę Javy 17 (to już następny wtorek!), ale to nie znaczy że wszystko dookoła stanęło. Mam wrażenie, że wręcz przeciwnie – ważni gracze uchylają rąbka tajemnicy i zdradzają, co już niedługo czeka ekosystem.
Szczególnie jest to widoczne w świecie Springa. Podczas odbywającego się w zeszłym tygodniu SpringOne, dorocznej konferencji poświęconej temu frameworkowi, mieliśmy okazję poznać szczegóły zarówno Springa 6.0, jak i Spring Boota 3.0 – kolejnych dużych wydań produktów z pivotalowej stajni.
Nie oznacza to jednak, że doczekamy się ich szybko – przyjdzie nam bowiem wykazać się cierpliwością jeszcze przynajmniej przez rok, do czwartego kwartału 2022 roku (czuje nosem oficjalną premierę na kolejnym SpringOne). Pierwszą rzeczą, która przykuwa uwagę, to fakt bardzo mocnego kroku w przód. Spring odcina się bowiem od starych wersji Javy, a za taką uznając m.in. Javę 8! Tak, dobrze widzicie – zarówno Spring Framework, jak i Boot do działania będą wymagały JDK 17 (która ukaże się w przyszłym tygodniu jako pierwsza po 11 LTS). Twórcy nie zdecydowali się na JDK 11, ponieważ wsparcie dla tej kończy się już w 2023 roku. Obiecują równocześnie, że Spring Framework 6.x będzie wspierał minimalnie zakres wydań JDK 17-29. To jednak nie wszystko, bo Spring odcina się również od Javy EE. Kolejne wydania będą wymagać już linii Jakarta, w wersji od 9. w górę.
Co stoi za tym odważnym ruchem? Twórcy chcą przygotować rozwiązanie na przyszłość, a stare API mocno im ciążyły. Lata temu czytałem świetny tekst, ile effortu wymagało przykładowo utrzymanie wsparcia dla starych wersji po wyjściu JDK 8 – z ogłoszenia dotyczącego nowych wersji przebija, że aktualnie też masa pomysłów na posprzątanie codebase jest blokowana przez potrzebę zachowania kompatybilności. Jest to jednak jedna z agresywniejszych zapowiedzi, jakie widziałem u ważnych graczy – do tej pory chyba tylko Jetty odciął się tak gwałtownie, wymuszając m.in. wersję 11. Jeżeli zaś chodzi o przejście na Jakartę, jest to według mnie bardzo zrozumiałe – zmiana namespace wymagała od twórców rozwiązań albo radykalnych działań, albo “bujania się” z skomplikowanym procesem transpilacji jeszcze przez długi czas.
Mam wrażenie, że ten jeden ruch Springa ma szansę zrobić dla adopcji nowych wersji Javy więcej, niż wszystkie działania Oracle razem wzięte. Na razie nie za wiele wiemy o tym, jakie nowe funkcjonalności będą miały być marchewką zachęcającą do przejścia na nowe wersje oprogramowania, ale spodziewam się, że w kolejnych miesiącach twórcy będą stopniowo dzielić się kolejnymi zapowiedziami.
Ale nie tylko Spring pokazał swoje plany dotyczące kolejnych wydań. Jakarta 10 też podzieliła się swoim planem wydawniczym. Ukazać się ma w pierwszym kwartale następnego roku, przynosząc szereg zmian.
Jakarta EE 10 to pierwsze duże wydanie Jakarta EE od czasu aktualizacji do namespace jakarta (o czym wspomnieliśmy przy okazji zapowiedzi Springa). Z tego względu bardzo dużo sprzątania odbyło się pod maską. Masa elementów wcześniej wymaganych przez potrzebę zachowania kompatybilności, mogła zostać wyczyszczona. Porządkom sprzyjać może również fakt, że Jakarta zdecydowała się na ostateczne pożegnanie JDK 8 – jej twórcy nie zdecydowali się jednak na aż tak radykalny ruch jak zespół Springa, pozostając przy wsparciu dla JDK 11. Decyzja ta pozwoli jednak na “prawdziwe” wsparcie JPMSa, pcha więc cały projekt mocno do przodu. Oczywiście, w Jakarta 10 zapowiedziano też parę nowych zmian funkcjonalnych. Moją uwagę najbardziej przykuła informacja o tzw. “Core Profile”, ale myślę, że jest to temat, którym lepiej będzie zająć się przy okazji pierwszych RC – na razie wszelkie informacje o tej alternatywie (?) dla MicroProfile są strasznie niekonkretne.
A jak już o MicroProfile mowa, to jeszcze w tym roku powinniśmy się spodziewać jego wydania 5.0. Większość istotnych API doczekała się już kilku wydań Release Candidate, w których społeczność znajduje tylko drobne problemy. Nowa wersja standardu wydaje się być więc niezagrożona.
Ostatnio ukazało się też kilka małych releasów, które postanowiliśmy zebrać w zbiorczym akapicie.
Ukazała się JavaFX 17. Jest to pierwszy LTS od czasu wydania JavyFX 11 (twórcy rozwiązania zdecydowali się “syncować” cykl wydawniczy z tym oryginalnej Javy). Lista zmian nie jest jakaś imponująca (jeżeli zmiana struktury katalogowej jest twoją główną zapowiedzią, ciężko dobrze “sprzedać” wydanie), ale przez sam fakt bycia LTS powinni się zainteresować nią wszyscy użytkownicy tego rozwiązania.
W świecie Scali doszło zaś do premiery Scali 3.0.2 – nowego minora, ale przynoszącego kilka ciekawych nowości. Są to m.in. kroki w kierunku lepszej odporności na nulle, ulepszenia w dokumentacji, a także poprawki kilku znalezionych bugów.
W ciągu tygodnia ukazały się też aż dwa wydania Quarkusa. Wersja 2.2.1 (2.2.0 nie ukazała się nigdy, ze względu na znalezione bugi) przynosi wsparcie dla GraalVM 21.2, ulepszenia dla reaktywnego RestEasy oraz lepsze wsparcie dla długożyjących akcji, które doczekało się własnego blogposta. Wersja 2.2.2, która ukazała się tydzień później, załatała zaś pewne bugi, które przemknęły twórcom oryginalnego rozwiązania.