Helidon Nima – Pierwszy Framework zbudowanych od podstaw dla Project Loom – JVM Weekly 101

1. Helidon Nima – Pierwszy Framework zbudowanych od podstaw dla Project Loom

Czy kojarzycie EclipseCon? Jest to coroczna, odbywająca się co rok w Niemczech konferencja, która zajmuje się nie tyle Eclipse IDE (jak można by na pierwszy rzut oka podejrzewać), ale wszystkimi projektami znajdującymi się pod „parasolką” Eclipse Foundation. A że ta zagarnia ostatnimi laty pod siebie masę projektów, to z roku na rok robi się z tego coraz ciekawsze wydarzenie. Z masy naprawdę interesujących talków wybija się jednak jeden, o dość znamiennej nazwie: Helidon Nima – Loom based microservices framework.

Okazuje się bowiem, że szykuje nam się pierwszy(?) framework, w którym Loom nie będzie doklejonym dodatkiem, a „First-Class Citizen”. Na razie samych szczegółów z jednej strony nie mamy za wiele (abstrakt z ElipseCon to jedyne oficjalne wspomnienie o Nimie), z drugiej strony… początkiem tygodnia w ramach repozytorium Helidona ukazał się jej kod źródłowy. Także jeśli ktoś ma ochotę, może sobie zobaczyć jakie API chcą zaproponować nam jego twórcy.

Ogólnie ciekawy będzie ten październik. Najpierw JavaOne (17-20.10 – impreza doczekała się już zapowiedzi video w Inside Java Newscast zawierającej przegląd agendy), a potem EclipseCon (24-27.10). Czy ktokolwiek z naszych czytelników się na którąś wybiera? Dajcie proszę znać na naszej stronie Facebookowej.

Źródła

• Helidon Nima – Loom based microservices framework
• Nima Source Code
• String Templates, JavaFX 19, Deserialization, and more at JavaOne – Inside Java Newscast #32

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. Release Radar: slf4j 2.0

Porozmawialiśmy trochę o przyszłości Javy, teraz czas trochę spojrzeć na jej teraźniejszość.

Podejrzewam, że praktycznie każdy z czytających ten newsletter (przynajmniej z tych będących w branży już parę lat) choć raz miał przyjemność dokładania do projektu slf4j. Nazwę tą rozwija się jako The Simple Logging Facade for Java i taką właśnie jest jej rola – tak, jak np. Hibernate stanowi abstrakcje nad bazami danych, tak slf4j ukrywa przed użytkownikiem detale implementacyjne frameworków. Dekadę temu, log4j w swojej pierwszej wersji był frameworkiem mocno skomplikowanym, o niskopoziomowym API. Jego głównym konkurentem pozostawał dość ograniczony w konfiguracji java.util.logging, a slf4j stanowił bardzo wygodną w użyciu abstrakcję, dającą programiście np. wygodną kontrolę nad poziomami logowania.

Od czasu świetności slf4j branża jednak trochę wyewoluowała. Najpierw pojawił się Logback, który zachwycił programistów błyskawiczną inicjalizacją (przez co łatwiej używało się go bezpośrednio, bez dodatkowej abstrakcji), a następnie pojawił się log4j2, który przyniósł API kompatybilne z slf4j, ale już bez dodatkowego narzutu abstrakcji. W międzyczasie pojawił się też java.lang.system.Logger, czyli drugie podejście twórców JDK do tematu logowania – dużo bardziej udane. Coraz więcej ludzi skłania się ku temu, że w dobie dojrzałych rozwiązań do logowania, nie ma wiele sensu używanie dodatkowej uspójniającej abstrakcji – nawet log4shell nie przekonał raczej ludzi, że warto zmienić ot tak sobie logger. To wszystko składa się na fakt, że lata świetności slf4j ma chyba za sobą.

Nie znaczy to jednak, że projekt stoi w miejscu, pojawiła się bowiem początkiem tygodnia jego edycja 2.0.0. Pewnym zmianom uległo API (mocno przemodelowane zostały niektóre buildery oraz dołożono Fluent Logging API), ale z pewnością największa rewolucja wydarzyła się pod maską. Wraz z nową wersją, slf4j pozbył się wsparcia dla JDK mniejszych niż JDK 8 – nie są więc tak „ambitni” jak twórcy np. Springa, ale też ze względu na swoje mocne zakorzenienie w przeszłości jest to dość rozsądny krok. Jednak również Ci używający nowszych JDK 9+ dużo zyskają na migracji – slf4j doczekał się bowiem wsparcia dla modułów JPMS, dzięki czemu łatwiej będzie się go używało w zmodularyzowanych projektach.

Jeśli chcecie więcej, bardzo ciekawą dyskusje o log4j2 vs slf4j znajdziecie w wątku na StackOverflow

Źródła

• Is it worth to use slf4j with log4j2
• slf4j 2.0.0