Co „State of Developer Ecosystem 2022” mówi nam o Javie i JVM ? – JVM Weekly vol. 123

1. Oracle wywraca do góry nogami pricing Javy

Java bardzo rzadko trafia na języki społeczności programistycznej. O ile nas interesować mogą nowe wersje JDK, zmiany w maszynie wirtualnej i inne wiadomości z ekosystemu, to jednak ktoś „niezainwestowany” w ekosystem o Javie słyszy głównie w momencie internetowych „dram”. I takowa wydarzyła się właśnie w zeszłym tygodniu. A wszystko przez to, że Oracle zdecydował się zmienić sposób naliczania opłat za swoje JDK.

Zacznijmy od faktów: 23 stycznia Oracle poinformował, że zmienia model licencyjny Oracle JDK na Java SE Universal Subscription. Nowy cennik, zamiast bazować na stanowiskach roboczych i procesorach, będzie opierał się na ilości pracowników zatrudnianych przez firmę: w tych do 1000 pracowników opłaty wynosić będą 15$/mc, dla większych będzie to 5,25$/mc. Dla wielu (większości?) firm korzystających z Oracle JDK oznaczać to będzie olbrzymi wzrost kosztów, ponieważ w obliczeniach brani są pod uwagę nie tylko programiści, ale wszyscy pracownicy firmy – także ci spoza działu IT, a także np. kontraktorzy.

Próbowałem oszacować, jak wygląda obecnie użycie poszczególnych JDK, i udało mi się dogrzebać do raportu State of the Java Ecosystem opublikowanego przez New Relic. Z niego wynika, że popularności Oracle JDK mocno przedostatnie lata spadała (75% w 2020 do 35% w 2022), więc jeśli trend się utrzymał, początkiem 2023 będziemy mówić o jeszcze mniejszych liczbach. Podejrzewam zresztą, że ostatnie zmiany pricingu tylko ten odpływ przyspieszą.

Niestety, mam wrażenie, że jesteśmy tutaj w samonapędzającej się spirali – pobawmy się więc najpierw w adwokata diabła. Skoro spada ilość firm używających rozwiązania Oracle, a koszty rozwoju Javy pozostają stałe, oczywistym (choć bolesnym) rozwiązaniem okazuje się być podniesienie cen, aby cały biznes się spinał. Należy też pamiętać, że to nie jest tak, że do tej pory Oracle JDK było za darmo. Model licencyjny zakładał bowiem opłatę za każdy procesor i każde stanowisko robocze, na którym zainstalowany był JDK. Istniejący model, który uważany był za korzystniejszy i za którym będziemy tęsknić, był dość zbliżony do mocno krytykowanej w zeszłym roku zmiany licencji Akki, również wprowadzającej opłaty per procesor.

Zmiany nie będą dotyczyć też już płacących klientów, którzy będą mogli się rozliczać na współczesnych warunkach (aczkolwiek nie udało mi się dogrzebać, w jaki sposób rozwiązane zostanie np. rozszerzenie licencji). Kończąc na pozytywnej nucie, zapisy mogą być teoretycznie korzystne dla niektórych firm, zwłaszcza małych startupów stricte technologicznych, posiadających małą ilość pracowników. Enterprise tracą chyba w każdej konfiguracji, ale mali, szybko skalujący się mogą zyskać – aczkolwiek wbrew tej teorii może być fakt wysokich opłat per pracownik (15$/mc) w firmach poniżej 1000 zatrudnionych osób.

W dalszym ciągu jednak zapis:

Employee for Java SE Universal Subscription: is defined as (i) all of Your full-time, part-time, temporary employees, and (ii) all of the full-time employees, part-time employees and temporary employees of Your agents, contractors, outsourcers, and consultants that support Your internal business operations. The quantity of the licenses required is determined by the number of Employees and not just the actual number of employees that use the Programs

jest dość przerażający. Oracle JDK jest często używana przez firmy, których technologia nie jest core, a po prostu napędza istniejący biznes. Przypominam, że licencja bowiem bierze pod uwagę WSZYSTKICH pracowników, nie tylko tych bezpośrednio zaangażowanych w technologię. Tego typu firmy, jeśli Oracle nie wprowadzi jakiejś formy ryczałtu, potencjalnie mogą spodziewać się najwyższego rachunku. Nathan Biggs z House of Bricks dokonał pierwszych wyliczeń i jego syntetyczne (ale nie jakoś mocno nierealistyczne) przykłady pokazują olbrzymi wzrost kosztów.

Należy pamiętać, że Oracle nie jest jedynym dostawcą JDK, więc każdy chcący używać Javy za darmo, może użyć np. Adoptium. W najgorszej sytuacji znajdują się firmy, które ciągle nie zmigrowały się na najnowsze edycji JDK, przez co np. muszą płacić dodatkowo za wsparcie takiego JDK 1.8. Jeśli jednak firma ma w miarę aktualny stack technologiczny, ale potrzebuje opcji płatnego supportu, to istnieje grono alternatywnych vendorów.

Co jest smutne – wiedzą to co prawda ludzie znający ekosystem Javy, ale dla szerokiego odbiorcy jest to stan mocno nieintuicyjny. W końcu nie ma alternatywnych dystrybucji Go czy Rusta (albo są statystycznie pomijalne). Dlatego mam obawy, że całość bardzo mocno wpłynie na reputację Javy jako języka, widać, że temat jest bardzo nośny i odbija się szerokim echem.

A żeby zakończyć czymś akcjonowalnym – jeżeli aktualnie właśnie stoicie przed decyzją, jakie kroki powziąć po wspomnianej zmianie pricingu, to najlepsze opracowanie dostępnych alternatyw znajdziecie na whichjdk.com

Źródła

• Oracle Java SE Universal Subscription FAQ
• House of Bricks dokonał pierwszych wyliczeń
• 2022 State of the Java Ecosystem Report
• Oracle changing Java licensing from per-processor to a multiplier of employee headcount – costs could go up singificantly
• whichjdk.com

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. AtomicJar zgarnia 25 milionów finansowania i odpala TestContainers Cloud

O ile w wypadku JavaScriptowych infrastrukturalnych projektów dość często (a przynajmniej 2021 i 2022 nas w tym temacie dosyć rozpieściły) mamy do czynienia z ogłoszeniami nowych rund zewnętrznego finansowania (Vercel, Deno), o tyle relatywnie rzadko słyszy się, aby jakaś javowa biblioteka zakładała własną chmurę (chyba, że bierzemy tutaj pod uwagę takiego Confluence i Kafkę). Dlatego też ze sporym uśmiechem przywitałem zeszłotygodniowe ogłoszenie od AtomicJar, w którym to firma chwaliła się rundą finansowania na 25 milionów dolarów.

Żeby przedstawić, na co mają iść dane środki, warto przypomnieć sobie czym AtomicJar się zajmuje. 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.

Pieniądze od inwestora mają iść na dalszy rozwój własnego rozwiązanie Software-as-a-Service firmy – TestContainers Cloud. Pozwala ono 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, 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. Odpalenie cięższej suity testów na komputerze z 16GB RAMu (a w niektórych przypadkach 32GB) w dzisiejszych czasach to obowiązkowa przerwa kawowa…

Ogłoszeniu finansowania towarzyszy też uruchomienie otwartej wersji Beta usługi TestContainers Cloud. Nie pozostaje nic innego jak AtomicJar pogratulować i życzyć sukcesów 🎉. Bardzo chciałbym, aby takie produkty jak ich nie były potrzebne, ale niestety, bardzo są.

Źródła

• AtomicJar Secures $25 Million in Series A Funding and Launches Public Beta of Testcontainers Cloud
• A letter to the Testcontainers community
• testcontainers.cloud

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!

3. Co „State of Developer Ecosystem 2022” mówi nam o Javie i JVM ?

A że już w pierwszej sekcji udowodniliśmy sobie, że statystyki użycia są przydatne na sam koniec mam dla Was raport

Coś ostatnio JetBrains ma mocno przesunięty cykl publikacyjny. Najpierw końcówką musieliśmy bardzo długo czekać na to, aby firma wreszcie oficjalnie przyznała się do wydanego końcówką roku Kotlina 1.8, a teraz w styczniu 2023 dostaliśmy ichniejszy State of The Developer Ecosystem 2022. Niby nic nie ma w tym dziwnego – w końcu jak przy okazji AtomicJar porównywaliśmy już do JavaScriptów, to duże raporty z tego ekosystemu też pojawiły się dopiero w styczniu tego roku, to jednak State of Developer Ecosystem co roku publikowany był jesienią. Przyznam, że czekałem na ten raport – o ile bowiem dotyka on szerszej grupy języków niż tylko te JVM-owe, to stanowi bardzo dobre źródło statystyk, którymi będę mógł szafować przez resztę roku.

Zaglądnijmy zatem do środka, co też ciekawego dzieje się w językach JVM, a przynajmniej tych trzech zawartych w raporcie – swoje miejsce znalazły w nim bowiem Java, Kotlin oraz Scala. Wybrałem dla Was te, które z mojej perspektywy były najbardziej interesujące.

Zacznijmy od statystyk użycia konkretnych wersji JDK. Mimo, że w momencie publikacji nie posiadała już dużego wsparcia, to jednak w dalszym ciągu JDK 8 jest królem, jeśli chodzi o adopcje. Zauważyć trzeba jednak powolne odchodzenie od tego wydania – zaliczyło ono bowiem spadek z 72% do 60%, a więc o 12 punktów procentowych. Nie zmienia to faktu, że to właśnie starusieńka „ósemka” pozostaje królem jeśli chodzi o adopcje, i goniona jest przez JDK 11 (48%) oraz JDK 17 (30%). Użycie wersji nie-LTS jest (pewnie zgodnie z planem) są raczej homeopatyczne. Przypominam, że dane są zbierane na pierwszą połowę 2022, więc sytuacja mogła się jeszcze trochę zmienić

Niepodzielnie rządzi też Spring Boot i Spring MVC, cała reszta stawki nie była w stanie dobić do 5% użycia. Dziwnym wyborem jest też umieszczenie w stawce JSF – trochę takie porównywanie jabłek do pomarańczy. Ciekawe, czy biorąc pod uwagę totalną dominacje Springa, jego rezygnacja z JDK starszych niż JDK 17 wpłynie na State of The Developer Ecosystem 2023.

Powyższy wykres pokazuje, dlaczego lubię tego typu statystyki. Bazując tylko na obecności w dyskusji, wydawać by się mogło, że Gradle już przejął ekosystem narzędzi do budowania projektów javowych. Okazuje się jednak, że choć Gradle rzeczywiście przebił granicę 50% adopcji, to do starego, cichszego ostatnio Mavena jeszcze sporo mu brakuje.

Jeśli chodzi o Kotlina, to najciekawszą statystyką jest chyba użycie języka w poszczególnych środowiskach. Procentowo, adopcja mobilna (zarówno Android, jak i MultiPlatform) rośnie bowiem w stosunku do tej serwerowej, która to jako jedyna zaliczyła spadki w punktach procentowych. Zastanawiałem się, czy nie jest to efekt większej bazy użytkowników, ale akurat ta mniej więcej pokrywa się z tą z zeszłego roku (bazując na danych o ilości użytkowników jak i procencie z nich używających Kotlina, według moich zgrubnych wyliczeń, zarówno w 2021, jak i 2022 wzięło udział około ~4500 kotlinowców). Ciekawe, na ile jest to jednorazowa sytuacja czy bardziej regularny trend.

Na koniec spójrzmy sobie na Scalę. W wypadku tego języka wyraźnie widać, że mamy do czynienia z raczej już ustabilizowanymi przypadkami użycia, aczkolwiek nie aż tak dominującymi jak Spring w wypadku Javy. Bazując na raporcie, jeżeli ktoś ma w projekcie Scalę, to z dużym prawdopodobieństwem możecie założyć, że używa jej do Akki lub Sparka, a dodatkowo posiada w projekcie jakaś bibliotekę wspierającą programowanie funkcyjne. Przynajmniej ja tak odczytuje powyższe dane.

Na końcu zaś spójrzmy na adopcje poszczególnych wersji Scali. Tutaj mam dobrą nowinę dla języka – wersja 3.0 zdecydowanie rośnie, wszystkie pozostałe wydania maleją. Wyraźnie jednak widać, że wszystkie wersje od 2.11 w górę mają ciągle sporą adopcję, proces będzie jeszcze raczej trwać.

Danych jest znacznie więcej, pełny raport znajdziecie na stronie The State of Developer Ecosystem 2022.

Źródła

• The State of Developer Ecosystem 2022
• The State of Developer Ecosystem 2022 – Java
• The State of Developer Ecosystem 2022 – Kotlin
• The State of Developer Ecosystem 2022 – Scala