1. Co w 2023 ciekawego można się dowiedzieć z State of Developer Ecosystem oraz Jakarta EE Developer Survey
Zaczniemy sobie od liczb i wykresów, ponieważ ukazały się nam dwa branżowe raporty, z fokusem na części ekosystemu będące punktem zainteresowania również tego newslettera – a więc State of Developer Ecosystem 2023 (który będąc wydanym przez JetBrains, posiada wiele interesujących danych kotlinowo/javowych) oraz Jakarta EE Developers Survey 2023 (a tu to już nazwa chyba mówi sama za siebie). Nie będzie to jakaś mocno wnikliwa analiza – jako że same raporty są dostępne publicznie dla każdego zainteresowanego – ale wybiorę ze swojej strony smaczki, które mi się rzuciły w oczy.
Najpierw na warsztat weźmiemy ten pierwszy i zanim zobaczymy jeszcze szczegóły poszczególnych języków, zobaczmy sobie jak według zebranej przez JetBrains próbki 27-tys developerów wyglądają obecnie migracje między językami.
Programiści zdecydowanie okopali się na swoich pozycjach i ciężko zauważyć jakieś wielkie kierunki migracji (może poza Rust i Go, te dwa języki wydają się być nieco bardziej przyciągać developerów). Szczerze mówiąc, to spodziewałem się znacznie większych liczb przy Pythonie. Ogólnie wojny języków powoli wydają się być coraz mniej interesujące, przynajmniej w porównaniu do szału sprzed kilku lat. Ciężko szukać jakichś potencjalnie wielkich success stories na następne lata, takich pokroju Rusta czy Go.
Z ciekawych obserwacji raportu – trzeba też przyznać, że Scalowcy są swojemu językowi bardzo wierni…
… ale patrząc na kolejny wykres – trochę ciężko im się dziwić 😉.
A języki pewnie stają się coraz mniej istotne, bo z ankiety wychodzi, że językiem wszystkich programistów staje się język angielski (czy też inne języki naturalne), i raczej panuje w ankiecie w tym temacie konsensus:
Ogólnie sekcja poświęcona generatywnemu AI jest ciekawa i posiada sporo insightu na temat adopcji konkretnych narzędzia czy modeli. Nie będę całości rozbijał na czynniki pierwsze, bo ani tu miejsce ani czas, ale polecam chociaż zerknąć – może znajdziecie dla siebie jakąś inspirację.
Teraz przejdźmy sobie do Javy
Okazuje się bowiem, że według danych zebranych przez JetBrains, mamy obecnie Jave dwóch prędkości. Z jednej strony bowiem projekty ciągle tkwią na stareńkiej Javie 8, mimo faktu że już w zasadzie nic w ekosystemie jej nie wspiera i cały czas dostajemy ogłoszenia o jej porzucaniu przez głównych graczy. Z drugiej zaś mamy olbrzymią adopcję JDK 17. W praktyce – a przynajmniej w mojej głowie – oznacza to, że w wypadku Javy firmy już zostaną na JDK 8 do końca świata (i jeden dzień dłużej). Z drugiej strony jeżeli już ktoś przejdzie przez proces migracji, to jest spora szansa, że już zostanie na szybkiej ścieżce aktualizacji na kolejne LTSy.
Tutaj też jest bardzo ciekawie – pierwsze miejsce Dockera nie dziwi, za to zaskakujące jest to, że jednak serwery aplikacyjne biorą wciąż górę nad samodzielnymi *.jar – choć to akurat może trochę korelować z Javą 8 z poprzedniej sekcji. Smuci mnie mała popularność GraalVM, za to śmieszy homeopatyczne użycie jlink – w ramach jednej z moich prezentacji konferencyjnych jak ostatni troll pytam ludzi o fazę linkowania w Javie, i jeśli choć jedna osoba skojarzy, to już wiem że mocna grupa się trafiła.
Tutaj dałem 2022 do porównania, żeby uświadomić Wam, jak chorym sukcesem jest Spring i jak mimo całej konkurencji nie traci on trakcji.
Podobnych ciekawych statystyk, dotyczących bibliotek, serwerów itd jest jeszcze więcej, ale ekipa z JetBrains i zaproszeni goście zrobili tam już własną analizę, więc odsyłam Was do oryginalnego dokumentu.
To teraz pora na Kotlina
Rewolucji nie stwierdzono. Serwerowe użycie powróciło do procentowego udziału z 2021, rośnie Multiplatform. Nothing to see there…
… za to tutaj jak porównamy do wyników w przypadku Javy, to totalna dominacja Gradle robi wrażenie nie mniejsze, niż dominacja Springa w domenie javowych frameworków.
Ten wykresie zostawiam tylko, żeby podzielić się obserwacją, że „Which JetBrains Kotlin libraries and tools do you currently use?” jest prawdopodobnie tożsame z „Which Kotlin libraries and tools do you currently use?”. Istnieje totalna dominacja JetBrains w tej kwestii.
No i pełny raport tutaj.
No to jeszcze krótko o Scali
Te liczby pewnie łatwo skomentować „Scala 3.0 dalej w tyle”, ale nie pokazują one trendu. Dla porównania, dane z zeszłego roku 👇
Scala 3.0 bowiem rośnie, i to bardzo elegancko. Choć zastanawiający jest też wzrost Scali 2.13 – i to co ciekawe nawet w porównaniu do 2021. Możliwe, że istnieją po prostu dwie ścieżki kanibalizacji Scali 2.12 i 2.11 – część projektów decyduje się na przejście do najnowszej wersji gałęzi 2.x
Jeśli chodzi o Akke – to jestem zaskoczony, jak wszystko stabilnie się trzyma w statystykach, mimo kontrowersji z nowym modelem licencyjnym. Ale pewnie trudno pozbyć się trzonu istniejących systemów i powodu, dla którego projekty w ogóle w Scale inwestowały.
No i pełny raport ponownie tutaj.
I jeszcze kilka wniosków z Jakarta EE Developer Survey 2023 – aczkolwiek sam raport jest tutaj nieco mniej rozbudowany, bo dotyczy jednej tylko technologii, i też mamy dostęp do samego „Executive Summary”.
O ile popularność Jakarty EE 10 jest logiczna, biorąc pod uwagę jak cały ekosystem się na nią przepina, to dla mnie największym zaskoczeniem był procentowy wzrost… Jakarty EE 8. Po dłuższym zastanowieniu jest to jednak logiczne – prawdopodobnie są to migracje z Java EE 8. Z punktu widzenia modernizacji jest to naturalny pierwszy krok.
Ciekawie prezentują się też priorytety społeczności – widać, że chęć konteneryzacji dalej jest w ludziach silna, co samo w sobie będzie promowało rozwiązania związane z szybkim startem aplikacji. Myślę, że dobrze to koreluje z punktem numer 2, czyli mikroserwisami (choć z mojej perspektywy, po wdrożeniu Core Profile już jest naprawdę dobrze) oraz czwartym, czyli server. No i ja też bardzo czkam na to, w jaki sposób rozwiązana będzie kwestia standaryzacji Virtual Threadów i w których częściach specyfikacji się one znajdą.
Przyznam, że trochę brakowało mi w raporcie cząstkowych danych – czuć, że jednak pracujemy tutaj na typowym Executive Summary. Przykładowo, mamy zobrazowane pewne trendy:
ale osobiście jestem ciekawy pełnego rozłożenia nie tylko LTS-ów JDK, a też wersji starszych niż JDK 9 czy użyć konkretnych serwerów aplikacyjnych. Pełne dane są niestety dostępne tylko dla członków Jakarta EE Working Group… ale aktywnie nad tym też już pracuje, może już niedługo będę miał dla Was jakieś ogłoszenia 🤞
Wspomniany raport dostaniecie zostawiając e-mail oraz duszę tutaj.
Zainstaluj teraz i czytaj tylko dobre teksty!
2. Właściciele Springa przejęci przez Broadcom
To teraz ogłoszenie na styku biznesu i świata technologii. Dla nikogo zaskoczeniem nie będzie, że duże projekty Open-Source w dzisiejszych czasach zwykle posiadają swoich korporacyjnych sponsorów, a wielu ludzi rozwijających je robią to w ramach firmowych etatów. Tydzień temu pisaliśmy o wysypie nowości i dużych premier w ekosystemie Springa, projekt wydaje się więc być w najlepszym miejscu od lat. Przykro słyszeć więc o tym, że od strony backstage dzieją się zawirowania. A aby to wyjaśnić, wybaczcie mi za to, że będę musiał wprowadzić nieco korporacyjnej struktury, w stopniu minimalnym, żeby wyjaśnić co się dzieje.
Pivotal Software (stojący za Springiem) i VMware mają ze sobą silne powiązania historyczne i biznesowe. Pivotal, specjalizujący się w rozwoju platformy chmurowej i narzędzi programistycznych, został pierwotnie założony jako niezależna firma przez EMC Corporation, która posiadała także większościowy udział w VMware, lidera w branży wirtualizacji i infrastruktury chmurowej. W 2012 roku VMware i EMC wspólnie zainwestowały w Pivotal, a w 2013 roku Pivotal został oficjalnie wydzielony jako oddzielna firma. W 2019 VMware przejęło Pivotal, co nie tylko pogłębiło ich związek, ale także wzmocniło pozycję VMware w obszarze rozwoju aplikacji i usług chmurowych, korzystając z ekspertyzy Pivotal w tym zakresie – jak choćby ich rozwiązań Cloud Foundry.
Tu jednak historia się nie kończy. Broadcom, znany głównie z produkcji półprzewodników, podjął decyzję o rozszerzeniu swojej działalności na rynku oprogramowania, co było częścią szerszej strategii dywersyfikacji firmy. Wybór padł na VMware, jako że firma uznawana jest za lidera w dziedzinie wirtualizacji i infrastruktury chmurowej, co stanowiło atrakcyjny kierunek rozwoju dla Broadcom. Przejęcie rozpoczęte w maju 2022, a będące jedną z większych transakcji tego typu opiewającą na 69 miliardów dolarów, domknięto finalnie w zeszłym tygodniu, 22 listopada.
Przechodzimy do stanu dzisiejszego – bardzo szybko po transakcji doszło do serii zwolnień w firmie. Nie wiemy jaki jest ich zakres, ale na pewno zaafektowały one też zespół odpowiadający za najpopularniejszy javowy framework. Oliver Drotbohm, architekt Springa, który od ponad dekady prowadzi projekt Spring Data, podsumował całość wymownie.
Jako, że nie mamy żadnych oficjalnych komunikatów nie będę się tutaj bawił w przypuszczenia. Jedyne co, to wszystkim zaafektowanym życzę odpoczynku i szybkiego znalezienia dla siebie równie dobrego, albo i lepszego nowego miejsca.
3. Release Radar
Micronaut 4.20
W najnowszej wersji Micronaut Framework 4.2.0 wprowadzono kilka istotnych zmian dotyczących Kotlina i Gradle. Po pierwsze, doszło do usprawnień w integracji z Kotlin Symbol Processing (KSP). Wprowadzono także wsparcie dla Kotlin 1.9.20 i KSP 1.9.20-1.0.13, a także Ktor 2.3.5. Co więcej, dla Gradle, nowe aplikacje domyślnie używają Gradle z Kotlin DSL, który zapewnia lepszą integrację z IDE, a także Kotlin DSL stał się domyślnym dla Gradle. Micronaut Data wprowadzono korutynowe warianty operacji połączeniowych i transakcyjnych – odpowiednio CoroutineConnectionOperation oraz CoroutineTransactionOperatio.
Nowe Micronaut Data to też wywołania procedur w repozytoriach czy wsparcie dla asocjacji w DTOsach, czy Pozostałe aktualizacje obejmują wsparcie dla GraalVM z flagą --strict-image-heap, które stanie się domyślne w następnej wersji GraalVM Native Image. Dodano także możliwość wyboru Java 21 w Micronaut Launch lub CLI. W . Aktualizacje objęły również wiele innych modułów, takich jak Micronaut Test, Micronaut Tracing, Micronaut Micrometer, Micronaut OpenAPI, a także wsparcie dla różnych technologii, w tym GCP, Kafka, RabbitMQ, Redis, i wiele innych
Vert.x 4.5
Pamięta ktoś Vert.x? Projekt ten, będący wielojęzycznym zestaw narzędzi do tworzenia reaktywnych aplikacji na serwerze JVM, zgubił sporo swojej trakcje wraz ze zmniejszeniem się hype na programowanie reaktywne (bardzo chętnie poświęciłbym temu któreś z przyszłych wydań) i musi wymyśleć się trochę na nowo. Nic nie uświadamia tego tak bardzo, jak nowe wydanie.
Vert.x 4.5 zaskakuje wprowadzeniem wirtualnych wątków z Javy 21. Jest to znaczące, ponieważ Vert.x znany jest z asynchronicznego (i reaktywnego) przetwarzania zapytań w ramach łańcuchów kolejnych akcji, a wirtualne wątki pozwalają na pisanie kodu, który wydaje się być synchroniczny. To umożliwia łatwiejsze zarządzanie złożonymi workflowami, jednocześnie zachowując asynchroniczne korzenie – w mojej głowie to wrappowanie zapytań w Future.await wywraca jednak sposób pisania w Vert.x do góry nogami, zwłaszcza, że akurat mam sporo komercyjnego doświadczenia z rozwiązaniem.
Verticle verticle = new AbstractVerticle() {
@Override
public void start() {
HttpClient client = vertx.createHttpClient();
HttpClientRequest req = Future.await(client.request(
HttpMethod.GET,
8080,
"localhost",
"/"));
HttpClientResponse resp = Future.await(req.send());
int status = resp.statusCode();
Buffer body = Future.await(resp.body());
}
};
Choć to pewnie po prostu ja, i dla kogoś startującego z projektem będzie to coś zupełnie naturalnego.
W tej wersji dodano także dynamiczne tworzenie połączeń SQL, co umożliwia elastyczne łączenie się z różnymi bazami danych. Wprowadzono również wsparcie dla transakcyjnych trybów pulowania połączeń dla proxy na 7 poziomie sieci, takich jak PgBouncer.
Nowością jest też możliwość aktualizacji konfiguracji SSL TCP w czasie rzeczywistym, co jest przydatne przy rotacji certyfikatów. Ponadto, Vert.x 4.5 wprowadza oddzielny klient WebSocket, co pozwala na lepsze rozgraniczenie interakcji HTTP od tych na WebSocket. Wreszcie, dodano builder dla zaawansowanego tworzenia Vert.x-owych klientów, co ułatwia ich konfigurację.
EclipseStore 1.0
Tu mamy naprawdę ciekawe wydanie. Ale zanim będziemy mogli opowiedzieć o Eclipse Storę, najpierw musimy powiedzieć sobie o MicroStream.
MicroStream natywna dla Javy, stworzona z myślą o mikroserwisach oraz i serverlessie warstwa trwałości „databaseless” (mamy serverless, to zdzierżymy też ten skrót). Jest to bardzo ciekawe rozwiązanie, umożliwiające na zapisywanie w pamięci grafu obiektów Java bez względu na jego wielkość i złożoność, zapewniając przy tym pełną spójność transakcji. Dane są ładowane i przywracane z pamięci automatycznie, a mechanizm Lazy-Loading pozwala na optymalizacji jej zużycia.
Niedawno stała się oficjalnym projektem Eclipse Foundation pod nazwą EclipseStore 1.0, który powstał na bazie kodu MicroStream wersji 8. Rozwój MicroStream został w związku z tym zakończony, a wszystkie nowe funkcje będą wydawane tylko w ramach projektu EclipseStore. Zespół MicroStream będzie kontynuował intensywną pracę nad projektem, rozwijając nowe funkcje i prezentując je na nadchodzącym EclipseStore Summit 2023 – mają rozmach.
Co ciekawe, nie mamy do czynienia z typowym „death by open sourcing”. EclipseStore pozostaje dla MicroStream kluczowym projektem, stanowiąc bazę dla jego komercyjnej oferty, jaką są MicroStream Cluster oraz MicroStream Enterprise.
Hibernate 6.4
W najnowszej wersji Hibernate ORM 6.4.0 wprowadzono kilka kluczowych zmian. Jedną z nich jest wsparcie dla „miękkiego usuwania” poprzez nową adnotację @SoftDelete. Umożliwia ona oznaczenie wartości jako usuniętych/nieusuniętych (pokroju kolumny deleted typu boolean, myślę że rozumiecie o co chodzi). Dodano również nowy moduł hibernate-vector, który oferuje wsparcie dla typów wektorowych i funkcji matematycznych użytecznych w obszarze AI/ML, umożliwiających wyszukiwanie podobieństwa wektorowego. Na ten moment wspiera on jednak tylko PostgreSQL z włączonym rozszerzeniem pgvector.
Ponadto, Hibernate ORM 6.4.0 dodaje nowe funkcje do obsługi tablic w zapytaniach HQL i Criteria. Zaktualizowano także wsparcie dla zdarzeń Java Flight Recorder (JFR) – ze względu na różnice w implementacji JFR stworzono oddzielny moduł hibernate-jfr, zapewnieniający kompatybilność miedzy nimi. Ciekawą nowością jest też wsparcie dla używania tenant-id z typami innymi niż String, popularnej funkcji dla aplikacji ze wsparciem MutliTenancy. Użycie tenant-id pozwala na efektywne zarządzanie dostępem i segregację danych, zapewniając, że dane jednego klienta nie są dostępne dla innego.
PS: Pojawiła się też wersja 2.2 Hibernate Reactive, ale jest w zasadzie wrapperem nad Hibernate ORM 6.4.0.
AWS SDK for Kotlin
Aktualnie w Las Vegas odbywa się re:Invent – coroczna konferencja Amazon Web Services. W zeszłym roku jedną z zapowiedzi które otrzymaliśmy był AWS Lambda SnapStart, integrujący CRaC z AWS Lambda. W tym roku (jak na razie) ogłoszeń JVM-owych jest mniej, ale udało mi się wyłuskać ciekawe – wydano bowiem AWS SDK dla Kotlina!
API biblioteki zostało stworzone w idiomatycznym Kotlinie, i zawiera typowe dla języka DSL-e oraz wsparcie dla asynchronicznych wywołań usług AWS przy użyciu coroutines. Obecna wersja pozwala deweloperom na pracę na platformach JVM lub Android API Poziom 24+, z planowanym wsparciem dla dodatkowych platform takich jak Kotlin/Native w przyszłych wydaniach.
Micrometer 1.12
Micrometer powoli staje się standardem jeśli chodzi o monitoring aplikacji Javowych. Do najważniejszych nowości wersji 1.12 należy wsparcie dla Jetty 12 w JettyConnectionMetrics, wsparcie świeżutkiego generacyjnego ZGC, usunięcie native-image.properties z micrometer-core, a także dodanie instrumentacji obserwacji dla Jakarta JMS. Dodano również skrót do przypisywania dynamicznych tagów do metryk.
Załatano też sporo bugów m.in. naprawę błędów w serializacji metadanych w Dynatrace v2, poprawki w liczeniu asynchronicznych zdarzeń log4j2, czy naprawę zależności na Guavę w module Stackdriver. Ponadto, w tej wersji zaktualizowano wiele zależności, w tym archunit-junit5, mockito-core, junit czy mongodb-driver-sync.
Sieroty po release Springa – nowe wersje Modulith i Vault
A na koniec, dwa wydania towarzyszące Springowi, które nie zdążyły się załapać na poprzednią edycję:
W najnowszej wersji Spring Vault 3.1 wprowadzono aktualizację do Spring Framework 6.1, wsparcie dla uwierzytelniania JWT dzięki JwtAuthentication, nowy interfejs AuthenticationEventMulticaster, umożliwiający odnowienia Leases, gdy token logowania wygasł. Pojawiło się również lepsze wsparcie dla reaktywności.
Spring Modulith 1.1 przynosi zaś szczególnie wsparcie dla eksternalizacji zdarzeń do AMQP, Kafka, JMS, AWS SNS i SQS, API do obsługi zakończonych i niezakończonych publikacji zdarzeń. Wzmocniono też ograniczenia relacji dla kodu w głównym katalogu aplikacji – w praktyce oznacza to, że Spring Modulith sprawdza i egzekwuje zasady dotyczące tego, jak moduły mogą się ze sobą komunikować i współdziałać, ograniczając możliwość tworzenia niepożądanych zależności między nimi. Dodano też wsparcie dla aktuatorów w obrazach natywnych czy implementację Neo4j Event Publication Repository. Osobiście bardzo zaś doceniam warianty Kotlina i Gradle Kotlin DSL zarówno dla przykładów kodu, jak i konfiguracji.
Zainstaluj teraz i czytaj tylko dobre teksty!
Bonus – Advent of Code 2023 with Kotlin! 🎄
To jeszcze na koniec – kto ma PTSD widząc ten obrazek?
Jako że zbliża nam się sezon świąteczny – już niedługo zaczyna się Advent of Code. Jest to coroczny konkurs programistyczny, w którym śmiałkowie ścigają się w rozwiązywaniu zadań programistycznych o coraz większym poziomie złożoności… późniejsze tygodnie są już naprawdę wymagające. Uwierzcie mi, będę się w to bawił czwarty rok.
Jak w zeszłym roku, JetBrains zaprosiło społeczność do rozwiązywania kolejnych zadań w Kotlinie, tworząc min. własne leaderboardy czy obiecując nagrody każdemu, kto wykona przynajmniej trzy zadania (i nie będzie używał do tego LLM). Przygotowali też gotowe repo do sklonowania dla każdego, kto chciałby dostać jakąś bazową strukturę do rozwiązywania zadań. Jeśli gdzieś się zatniecie, będą też publikowali lifestreamy z rozwiązywania zadań w idiomatycznym Kotlinie.
A jeśli chcecie dołączyć do jakiegoś lokalnego LeaderBoardu, zapraszam do jednego, w którym sam sam się ścigał – aczkolwiek podejrzewam, że choćby pisanie tego newslettera, jak i inne obowiązki (jeden z nich ma 2.5 roku) sprawią, że nie będę trudnym przeciwnikiem 🥴
Kod znajdziecie tutaj 3230435-45a28415 (a podać go trzeba tutaj), a naszą aktywną grupę wsparcia tutaj.
Aczkolwiek ostatnie lata nauczyły mnie, że w Advent of Code ważniejsza jest systematyczność i upór, nie maszynowe wypluwanie kodu. To zostawmy GPT-4.
PS: Ja w tym roku zdecydowanie nie kombinuje i też piszę w Kotlinie. Miłego wstawania o 6:00!
