JVM Tuesday vol. 44

1. Kotlin 1.5.20 – zaskakująco ciekawe wydanie (again)

Minory Kotlina to jedne z najciekawszych Minorów – zwłaszcza wersje *.*.20.

Nie wiem, czy to jakaś kwestia nomenklatury, czy jakiejś przyjętej konwencji, ale Kotlin 1.4.20 był prawdziwą petardą, a tutaj pojawia się wersja 1.5.20. Co prawda nie jest ona aż tak bogata jak jej odpowiednik , ale tak naprawdę jest tam całkiem sporo nowego i interesującego.

Dobra, to co interesującego przynosi wspomniana wersja? Otóż nareszcie mamy dostać lepiej działającą integracje Kotlina z Lombokiem. Jest to dla mnie prywatnie dość istotna informacja, ponieważ moja pierwsza duża w życiu migracja Java->Kotlin bardzo przedłużyła się właśnie z powodu konieczności “wychodzenia” z Lomboka. Niestety, zakres adnotacji kompatybilnych z Kotlinem jest ciągle dość ograniczony – żeby pokryć nasz (historyczny już na szczęście) case, niezbędne byłoby wspieranie również Builderów generowanych z poziomu Lomboka. Cóż, może w następnych edycjach.

Z punktu widzenia programistów Java, interesującym może być też fakt natywnego wsparcia przez Kotlina projektu JSpecify, zestawu adnotacji udostępniających szersze możliwości analizy statycznej w javowych projektach. Do tej pory rozpoznawany był istniejący już zbiór dostarczony przez samo JetBrains, widać jednak, że twórcy języka otwierają się również na alternatywy.

Twórcy explicite piszą w dokumentacji “We have seen the xkcd comic. Please do not send us the xkcd comic. We know about the xkcd comic.” Ja jednak nie mogę się powstrzymać

Kotlin 1.5.20 to także trochę nowych możliwości dla Kotlin/Native, a także lepsze wsparcie nowego Gradle. Dla osób, które używają Kotlin/JS (są tu tacy eksperymentatorzy?) udostępniono również nowy przewodnik migracyjny dla, mającej ukazać się wraz z kolejną dużą wersją języka, zmodernizowanej reprezentacji pośredniej.

BTW: Wiedzieliście, że Kotlin 1.6 ukaże się już w listopadzie 2021 . Nowy cykl releasowy zupełnie wypadł mi z głowy

Źródło

2. Dlaczego nie powinniśmy używać GlassFisha na produkcji

Co pewien czas informujemy Was o tym, jak rozwija się standard Jakarta EE. Regularnie też, trochę kąśliwie odnosimy się do dość powolnej adopcji standardów. Dopiero co cieszyliśmy się też, choć nie bez nutki ironii, że pierwsze projekty już teraz wspierają Jakartę EE 9.1 – wśród nich dzisiejszy bohater, GlassFish.

Może jednak nie warto się za bardzo spieszyć.

Na blogu Payary ukazał się dość długi post, dlaczego nie warto iść w rozwiązanie konkurencji i frywolnie wrzucać je na produkcje. W większości przypadków przeszlibyśmy nad takowym do porządku dziennego – podgryzanie konkurencji to w końcu absolutnie nic niezwykłego. Post zwraca jednak uwagę również na kilka aspektów, które warto wziąć pod uwagę przy potencjalnej migracji.

Dlaczego GlassFish mógł tak szybko stworzyć swoją wersję referencyjną? Odpowiedzią niech będzie tutaj sposób powstawania tego serwera. Okazuje się, z czego nie zdawałem sobie sprawy, że GlassFish nie ma w zwyczaju aktualizować swoich własnych zależności. W celu weryfikacji tej informacji udało mi się przebić przez stare wątki redditowe, gdzie ludzie dość mocno płaczą nad tym faktem. Próbowałem obalić to twierdzenie, szukając jakiekolwiek “minorowej” edycji, ale niestety, jedyne co znalazłem to potwierdzenie tego, o czym pisał internet – GlassFish posiada tylko duże edycje.

Nie podejrzewam, żeby ktokolwiek używał GlassFisha na produkcji (nie spotkałem się z tym od bardzo, bardzo dawna). Jest to jednak bardzo dobre przypomnienie, że serwery aplikacyjne, mimo iż implementują dokładnie ten sam interfejs, nie zostały stworzone równymi. GlassFish ląduje w mojej głowie w szufladce “zabawka”.

Mamy nadzieję, że ten tekst nie będzie działał jako straszak dla wszystkich tych, którzy chcą być na bieżąco z nowymi wersjami Jakarty EE. My naprawdę mamy nadzieje, że ten ekosystem w przyszłości nieco przyspieszy – osobiście bardzo lubię zarówno Jakartę, jak i MicroProfile, a powolny cykl wydawniczy fatalnie działa na ich PR.

Źródło

3. Nowa seria wideo o JEPach od Oracle

Oracle bardzo zaczyna dbać o komunikację z programistami. Prowadzą stronę Inside Java, agregującą zmiany w świecie JVMowym. Dodatkowo, już kilkukrotnie w różnych edycjach wspominałem o ichniejszym podcaście. Niedawno zaczęli prowadzić też serię wideo Inside Java Newscast, które możecie traktować jako alternatywę dla postów, które regularnie czytacie (aczkolwiek my sięgamy nieco szerzej – seria Oracle to newsy stricte związane z JVMem).

Kolejną serią tego typu jest teraz JEP Cafe. Regularnie piszemy o JEPach, trochę nie biorąc pod uwagę, że ten termin może być obcy dla wielu osób piszących w tym języku (choć podejrzewam, że chociażby przy premierach kolejnych “dużych” wersji Javy, niejednej osobie obił się o oczka). Dlatego też cieszę się, że powstała tego typu seria, będąca de facto wprowadzeniem do tematu – można dowiedzieć się, jak cały proces wygląda od kuchni, jaką drogę musi przeżyć proposal, oraz z jakich części się składa. Całość przedstawiona jest na bazie JEP 395 – Records, który został rozłożony na czynniki pierwsze przez (nieco flegmatycznego) prowadzącego.

Korzystając z okazji, chcieliśmy się podzielić dwoma innymi ciekawymi rozmowami, przeprowadzonymi przez prowadzącego Inside Java Newscast, Nicolai Parlog. Otóż spotkał się on ostatnio z architektami stojącymi za dwoma dużymi projektami Loom i Panama, przeprowadzając z nimi długie, około godzinne rozmowy. Jako że oba projekty są relatywnie szybko zmienne, wywiady Nicolaia można stosować jako chyba najświeższy materiał dotyczący obu.

Źródło

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

1. Kotlin 1.5.20 – zaskakująco ciekawe wydanie (again)

Źródło

2. Dlaczego nie powinniśmy używać GlassFisha na produkcji

Źródło

3. Nowa seria wideo o JEPach od Oracle

Źródło

Odkryj więcej świetnych treści!