JVM Tuesday vol. 88 – Spring Boot, Leyden, Structured Concurrency

1. Spring Boot 2.7 wydany

Zgodnie ze springowym kalendarzem, w zeszłym tygodniu mieliśmy premierę nowego Spring Boota w wersji 2.7, któremu towarzyszyło wydanie też nowych wersji kilku innych springowych projektów. Dlatego też dzisiejsze wydanie zaczniemy właśnie od przyglądania się, co nowego przynosi ostatnie przed Spring Boot 3.0 wydanie linii 2.x.

W środku jest zaś i dużo, i niedużo. Pewnie, takie rzeczy jak wsparcie zdobywającego coraz większą popularność Cache2k czy łatwiejsza rejestracja Jacksonowych Mixinów to całkiem interesujące dodatki, podobnie jak natywne wsparcie Podmana, alternatywy dla Dockera (tej lepszej alternatywy – w końcu z 🦭 zamiast 🐳  w logu). Nie da się jednak ukryć, że wyraźnie jest to cisza przed burzą i większe zmiany dostaniemy dopiero na jesieni, wraz z premierą “trójeczki”. Tego wrażenia nie zmyje raczej ostatnia z dużych nowości w wersji 2.7, czyli AutoConfiguracja i metryki dla Spring for GraphQL.

Z tym ostatnim związana jest też największa z towarzyszących nowemu Spring Bootowi premier – Spring for GraphQL w stabilnej wersji 1.0. W tym dzieje się znacznie więcej niż w “głównym” wydaniu. 

• Znaczenie rozszerzono ilość dostępnych dla użytkownika anotacji 
• ulepszono walidacje parametrów
• wprowadzono wsparcie batchowych zapytań i interceptorów
• obsługa QueryDSL 
• Klient HTTP, WebSocketów i RSocketów

a to i tak nie wszystko. Spring for GraphQL 1.0 to według mnie najciekawsza nowinka od czasu ukazania się pierwszego preview Spring Native. 

Co poza tym towarzyszy nowemu Springowi? 

• Spring Security w wersji 5.7 wprowadza kilka nowości do obsługi mechanizmów OAuth i SAML, udostępnia też RequestAttributeSecurityContextRepository i SecurityContextHolderFilter, ułatwiające prace z SecurityContext. Wprowadzono też specjalny DSL do obsługi nagłówków CORS
• Spring Data w wersji 2021.2 przynosi jeszcze większe możliwości zdefiniowania ClassLoadera, którego chemy używać, wsparcie dla konwerterów wartości opartych o konkretne pola w klasie, nowe możliwości dla projekcji encji, a także większe i mniejsze zmiany w zasadzie w każdym z providerów do konkretnych baz danych.
• Spring LDAP w wersji 2.4.0 doczekał się repakietyzacji, która ułatwia stosowanie go wraz z systemem modułów

Drobiazgi w postaciu podbicia zależności i korekcji błędów otrzymało też Spring Session, Spring Batch, Spring Hateoas.

Źródła

• Spring Boot 2.7.0 available now
• Spring for GraphQL 1.0 Release
• Spring LDAP 2.40
• Spring Security 5.7.1

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!

2. Zaproszenie do dyskusji nad Projektem Leyden

Ale się wszyscy wzięli za wydajność JVMa. Dopiero co w kwietniu duży update dostał Project CRaC, tydzień temu opisywaliśmy Project Liliput, a teraz na warsztat wrócił Project Leyden, o którym nie słyszałem chyba od dobrego roku.

Czym jest Leyden? Jako koncept mówimy tutaj o inicjatywie dość zbliżonej do GraalVM i zawiera z nią masę punktów wspólnych. Ma za zadanie stworzenie specyfikacji Statycznych Obrazów. Obraz statyczny jest samodzielnym programem, który nie może ładować żadnych zewnętrznych bytów na classpath, ani generować nowego bajtkodu w runtime. Jest to bardzo duże ograniczenie w stosunku do zwykłych aplikacji javowych, co dostajemy więc w zamian? Te dwa ograniczenia, których wynikiem jest “zamrożenie” zbioru klas w docelowej aplikacji przez cały jej cykl życia, sprawiają, że już na poziomie kompilacji (w ramach procesu tak zwanej kompilacji AoT (Ahead-of-Time)  można wywalić wszystko co niepotrzebne, zmniejszając w ten sposób zarówno rozmiar obrazu, jak i czas jego uruchamiania.

Teraz, prawie dwa lata od oryginalnego Call-For-Discussion i zebrania feedbacku, twórcy biorą się za pracę nad inicjatywą w oparciu o wygenerowane przez społeczność przypadki użycia. Już teraz jednak mówi się, że jednym z implementatorów specyfikacji mógłby być właśnie wspomniany już w tej sekcji GraalVM. 

Źródła

• Project Leyden: Beginnings

3. Structured Concurrency w Inkubacji

A na sam koniec feature, który właśnie trafił do inkubacji, a będący częścią Looma i stanowiący naturalne uzupełnienie Wirtualnych Wątków… długo oczekiwana Strukturalna Współbieżność.

Czym jest strukturalna współbieżność? Jeśli ktoś nie chce próbować dokopywać się do jakichś zakurzonych papierów z lat 60-tych (bo tam można znaleźć wszystko) jej korzeni należy doszukiwać się poście blogowym “Structured Concurrency” z 2016 roku, napisanym przez Martina Sústrika – twórcy ZeroMQ. To właśnie w nim zaprezentował on koncepcje enkapsulowania współbieżnych wątków wykonawczych za pomocą bloków kodu o jasnych miejscach startu i zakończenia, które gwarantowałyby, że wszystkie wątki kończą pracę przed wyjściem z danego bloku. Tego typu podejście w znacznym stopniu ułatwia rozumowanie na temat kodu, a również obsługę błędów.

Idea pewnie nigdy nie zdobyłaby aż takiej popularności gdyby nie Roman Elizarov, architekt kotlinowych korutyn, który postanowił wykorzystać ją w praktyce przy projektowaniu mechanizmu. Efekty okazały się być na tyle dobre, że w całym JVM-ie nastąpiła spora zmiana w myśleniu i – przykładowo – oryginalna wersja projektu Loom poszła w zasadzie do kosza, a ostateczny wariant, o którym pisaliśmy dwa tygodnie temu, to już rozwiązanie w pełni ze Strukturalną Współbieżnością kompatybilne.

Jeżeli to, o czym pisałem kojarzy Wam się z wprowadzonym w Javie 1.7 try-with-resources to macie bardzo dobre skojarzenia. Właśnie na tej znajomej programistom Javy konstrukcji projektanci Looma zdecydowali się oprzeć swoją wersję strukturalnej współbieżności:

Response handle() throws ExecutionException, InterruptedException {
    try (var scope = new StructuredTaskScope.ShutdownOnFailure()) {
        Future<String>  user  = scope.fork(() -> findUser()); 
        Future<Integer> order = scope.fork(() -> fetchOrder());

        scope.join();          // Join both forks
        scope.throwIfFailed(); // ... and propagate errors

        // Here, both forks have succeeded, so compose their results
        return new Response(user.resultNow(), order.resultNow());
    }
}

W powyższym przykładzie blok try automatycznie “posprząta” wszystkie stworzone w nim wątki w wypadku jakiegokolwiek problemu. Jasno sprecyzowany jest też cykl życia całości, wygodnie zbiera się też rezultaty, ponieważ całość zachowuje się w zasadzie jak kod synchroniczny. 

W odróżnieniu od samych wirtualnych wątków, będących obecnie jako Preview, JEP 428: Structured Concurrency znajduje się w inkubacji i raczej nie trafi do JDK 19, a tym bardziej w wersji stabilnej do JDK 21, kolejnego LTSa. To co twórcy chcą teraz osiągnąć, to zdobycie opinii społeczności w celu doprecyzowania docelowe API. 

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!

Bonus: Nowy wygląd Intellij Idea

A na koniec drobnica z kategorii “plotki i ploteczki”.

Na backlog Intellij Idea trafił naprawdę spory redesign, wiążący się z odświeżeniem całego edytora

Wiem, że to jest news pokroju “nowy design facebooka”, ale jako, że zmian jest sporo, postanowiłem się z Wami podzielić. Więcej szczegółów i wygląd konkretnych komponentów znajdziecie tutaj.