JVM Tuesday vol. 63 - Przyszłość Lightbendu, Microsoft dołącza do JCP, TestContainers SaaS

1. Jak wygląda przyszłość Lagoma, Akki i Lightbendu 🔮

Dwa tygodnie temu pisaliśmy Wam o tym, że Lightbend rezygnuje z dalszego wspierania Play Framework. Pozwoliłem sobie wtedy na drobną złośliwość w kontekście Lagoma, twierdząc, że komunikatów o jego śmierci nie ma tylko dlatego, że w odróżnieniu od Play nigdy nie “żył”.

Okazuje się jednak, że Jeremy Pollock (VP of Product w Lightbend) oraz James Roper ( jeden z oryginalnych twórców frameworka) postanowili się trochę uzewnętrznić na temat jego przyszłości. W dyskusji na forum Lightbendu postanowili przekazać, że o ile Lagom nie jest oficjalnie martwy i ma dostawać w przyszłości np. poprawki bezpieczeństwa, to jego rozwój realnie został wstrzymany i nie należy spodziewać się już dalszych funkcji rozwojowych.

Powód? Taki sam jak ostatnio – inwestycja w Akka Platform i Akka Serverless. Jednak tutaj jest to umotywowane nieco inaczej niż w wypadku Play. Wtedy bowiem wspominano o skupieniu się na bardziej rozwojowym projekcie, jakim jest Akka. Wypowiedzi wyżej wymienionych panów sugerują zaś, że Lagom po prostu stał się zupełnie… nadmiarowy.

James Roper dość sprawnie argumentuje, że w zasadzie Lagom powstał, żeby poradzić sobie z pewnymi ograniczeniami Akki, a także całego ekosystemu programistycznego. Rozwój samej Akki (min. jej silne typowanie), zupełna dominacja rynku przez Kubernetesa, a także zdobycie popularności przez gRPC sprawiły, że Lagom niczym szczególnym się już nie wyróżnia. Dlatego też nikt nie będzie w niego szczególnie inwestował.

Kończąc – po tych wszystkich ogłoszeniach o “porzuceniu”, społeczność zaczęła zastanawiać się, jak to wszystko wpływa na samą Akkę. Czy w świecie tych wszystkich “Platform” i “Serverlessów” jest jeszcze miejsce na “zwykłą” Akkę? Tutaj na szczęście James Boner wprowadził nieco więcej optymizmu. Akka pozostaje głównym “budulcem” wszystkich rozwijanych przez Lightbend produktów – dlatego o jej los możemy być raczej spokojni. Jeżeli jesteście ciekawi szczegółów – James przedstawił coś w rodzaju roadmapy/planów przyszłego rozwoju.

Źródła

2. Microsoft dołącza do Java Community Process 🥁

Jeśli ktoś jest z nami regularnie, to chyba nie muszę przypominać, że Microsoft dzisiaj jest bardzo mocno “zainwestowany” w Javę. Z każdym kolejnym ogłoszeniem jednak sam nie przestaje się zadziwiać, jak szybko to idzie.

W zeszłym tygodniu bowiem Microsoft ogłosił, że podpisał z Oracle Java Specification Participation Agreement (JSPA) i dołącza do Java Community Process (JCP) – programu, którego celem jest tworzenie specyfikacji Javy i nadzorowanie współpracy nad jej rozwojem.

Ok, wygląda “newsworthy”, ale zacząłem się zastanawiać, do czego się to w praktyce sprowadza? Chyba do niczego. Członków JCP jest mnóstwo, lista jest bardzo długa i znajdziemy na niej również np. Google czy Apple (co ciekawe, nie ma na niej jeszcze Microsoftu). Znaczenie jest jest tutaj więc w zasadzie symboliczne – mamy do czynienia ze swoistym “przyklepaniem” wszystkich działań, jakie Microsoft dokonał, aby stać się ważnym graczem Javowego ekosystemu. Sama firma nie omieszkała się zresztą tym pochwalić w poście z ogłoszeniem podpisania umowy wszystkimi działaniami, jakie poczyniła dla społeczności.

PS: Microsoft nie przestaje działać wielotorowo: dziś w nocy ukazał się C# 10 i .NET 6. Ciekawe jakie featury z języka Java i Kotlin ukradną tym razem 😜

Źródła

3. TestContainers udostępnia usługę chmurową 🌩

A na koniec drobiazg, ale myślę, że dla wielu będzie interesujący.

Kojarzycie TestContainers? Jest to biblioteka wspierająca dla JUnita, zapewniająca lekkie, jednorazowe instancje popularnych baz danych, przeglądarek internetowych dla Selenium i ogólnie wszystkiego, co można łatwo uruchomić w kontenerze Dockera. Wprawdzie wiele osób pewnie będzie zżymać się na uruchamianie kontenerów w testach jednostkowych, ale popularność TestContainers udowadnia, jak bardzo częsty jest to przypadek użycia.

Po prostu nazwiemy nasze testy integracyjnymi.

Teraz idziemy jednak krok dalej. Twórcy biblioteki stworzyli własne rozwiązanie Software-as-a-Service. TestContainers Cloud, bo o nim tu mówimy, pozwala na uruchamianie rzeczonych kontenerów nie na lokalnej maszynie, a w chmurze. Twórcy twierdzą, że takie rozwiązanie uwalnia maszyny programistów od zasobożernych procesów na lokalnych maszynach, a także jest agnostyczne w stosunku do architektury (całość projektu zainspirował podobno początkowy brak wsparcia dla ARM przez Dockera). I o ile ten drugi argument wydaje mi się trochę naciągany, o tyle pierwszy nawet do mnie przemawia.dpalenie cięższej suity testów na komputerze z 16GB RAMu (a w niektórych przypadkach 32GB) w dzisiejszych czasach to obowiązkowa przerwa kawowa… I tak, wiem, że pewnie w Waszych firmach testy odpalają się szybko i piramidka jest zawsze dobrze odzwierciedlona, ale ja jakoś zwykle miałem okazję pracować z projektami pisanymi przez ludzi, nie aniołów.