JVM Tuesday vol. 45

Widać, że świat IT jest bardzo mocno amerykanocentryczny. Dzień Niepodległości – czyli jedno z najważniejszych świąt w USA – sprawia, że tak naprawdę ilość newsów jest znikoma. Dlatego też dzisiejsza edycja będzie dość… skromna. W dalszym ciągu jednak zapraszamy do lektury – mamy dla Was dwie ciekawe wiadomości.

1. Quarkus 2.0 wydany. Co przynosi nowa wersja ?

Quarkus, framework od Red Hata, coraz mocniej przebija się do programistów Java jako czołowy reprezentant frameworkowej “nowej fali”. Dlatego też jego kolejna duża edycja, wersja 2.0, z pewnością przyciągnie uwagę niejednego znudzonego Springiem deva. Przyglądnijmy się zatem, co kryje się za nowym “majorem” i czy rzeczywiście jest to tak duży przeskok dla użytkowników.

Na pewno odważnym krokiem ze strony twórców jest porzucenie JDK 8. Quarkus 2.0 wymaga minimum JDK 11, a więc najnowszego LTSa. Jest to chyba pierwszy duży framework, w którym zdecydowano się na ten krok, co samo w sobie stawia go w awangardzie JVMowego programowania. Ciekawe, czy konkurencja zdecyduje się w niedalekiej przyszłości na taki krok.

Zaktualizowane zostały również główne komponenty używane przez Quarkusa. Wersja 2.0 przynosi ze sobą GraalVM w jego najnowszej wersji 21.1, aktualizacje Vert.x do 4.0 (będącej w dalszym ciągu w mojej topce najgorszych release notes) oraz wsparcie dla MicroProfile 4.0, co odbyło się poprzez aktualizację wszystkich komponentów SmallRye.

Poza nowościami wynikającymi ze wspomnianego podbicia zależności, Quarkus wprowadza jedną dodatkową, dużą funkcjonalność. Otóż umożliwi on tak zwane “ciągłe testowanie”, czyli uruchomienie rozwijanej aplikacji w trybie pozwalającym na odpalanie suite testowych w tle podczas pisania kodu. Twórcy chwalą się, że dzięki temu znacząco wzrośnie tak zwany “development experience” podczas używania ich narzędzia. Ciągłe testowanie jest mi znane zarówno z build tooli JSowych, jak i rozszerzeń do Intellij pozwalających na taki tryb pracy. Twórcy Quarkusa chwalą się jednak, że ich rozwiązanie jest lżejsze, szybsze i znacznie bardziej bezobsługowe w porównaniu do dostępnych na JVMie alternatyw. Chętnie zweryfikuje ich twierdzenia.

 

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. Zespół Kotlina pyta społeczność, nad czym powinien pracować

Dwa tygodnie temu pisaliśmy Wam o AMA z Kotlin Teamem, rozpływając się nad tym, jak bardzo otwarci są na głos społeczności. W zeszłym tygodniu udowodnili to po raz kolejny, ogłaszając możliwość głosowania na nowe featury języka, 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.

Każdego chcącego mieć wpływ na przyszłość języka serdecznie zapraszamy do wypełnienia dokumentu. Propozycji jest aż piętnaście, dlatego z naszej zaś strony, w tej krótkiej sekcji wskażemy te funkcjonalności, które wydają się być nam najbardziej interesujące.

Ze względu na kompatybilność z Javą i jej systemem modułów, z pewnością na czele funkcjonalności, które moim zdaniem powinny zostać wzięte pod uwagę jest scope “packaged-private”. Interoperacyjność Kotlina jest jedną z jego największych zalet, kluczową dla osób krok po kroku migrujących na niego swoje javowe projekty. Brak dostępu package-private, domyślnego javowego poziomu, prowadził zaś wielokrotnie do trudności w przestawieniu się na rozwiązanie JetBrainsów przez posiadających już swoje nawyki, bardziej doświadczonych programistów. Dodanie tego poziomu dostępu mogłoby być pragmatycznym ukłonem w ich stronę.

Powyższa sugestia kierowana była bardziej rozumem niż sercem. Jeżeli chodzi o moje prywatne marzenie – bardzo chciałbym zobaczyć kiedyś w Kotlinie Unie (choć przytuliłbym też powiązanego z nimi Multicache wyjątków). Im bardziej funkcyjnie staram się pisać, tym więcej zaciemniających logikę biznesową wrapperów muszę dokładać do swojego kodu. Unie wydają się być eleganckim rozwiązaniem tego problemu – aczkolwiek sugerowana alternatywa, czyli wygodniejsza składania dla sealed class może być dobrym kompromisowym rozwiązaniem. Może ono pozwolić zminimalizować konieczność dokładania kolejnego bytu do i tak coraz bardziej skomplikowanego języka, pozwalając mu uniknąć losu Scali.

fun String.parseData(): Data | Failure

Choć podtrzymuje, że Unie w powyższej postaci bym przytulił.

Z drugiej strony – czy jest zatem coś na tej liście, co wydaje mi się zbędne? Będę tutaj pewnie dość kontrowersyjny, ale jednym z takich dodatków będą raczej popularne “collection literals”:

val list = [1, 2, 3]
val map = ["one": 1, "two": 2, "three": 3]

Kotlin posiada już wystarczająco wygodne funkcje do tworzenia podstawowych typów kolekcji, więc taka dodatkowa składnia wydaje mi się być czymś nadmiarowym (tak, powiedziałem to ja, przed chwilą upominający się dokładania do języka dużo bardziej rewolucyjnych Unii).

Jestem też lekko nieprzekonany w związku z dalszym grzebaniem z lateinit i rozszerzaniem jego przypadków użycia. Jest to już w tym momencie jeden z bardziej problematycznych konceptów Kotlina – z jednej strony będący potężnym narzędziem, kluczowym dla jego odpornego na nulle języka typów, ale również trudny do zrozumienia, zwłaszcza na początku. Możliwe, iż proponowana sugestia, czyli umożliwienie użycia go również w przypadku prymitywów i typów “nullable” jest krokiem w prawidłowym kierunku. Jednocześnie, wczytując się w oryginalny KIP i jego komentarze, zmiana ta może mieć dość szerokie reperkusje (ogólnie polecam wspomnianego KIPa, mnie dużo nauczył, jak naprawdę lazyinit działa w “bebechach”).

 

I pamiętajcie, żeby spróbować Vived, jeśli chcesz otrzymywać tego typu treści spersonalizowane pod Ciebie!

• App Store
• Play Store
• Wersja PWA