22.09.20225 min
Józef Tokarski
Sii Polska

Józef TokarskiSoftware ArchitectSii Polska

Krajobraz frameworków Javy w 2022 roku

Sprawdź, jakie frameworki stworzyła społeczność Javy, jaki jest próg ich wejścia na rynek oraz co ze Springiem w 2022 roku.

Krajobraz frameworków Javy w 2022 roku

Są różne powody, którymi kierują się początkujący programiści, gdy zaczynają swoją karierę i dokonują wyboru technologii. Starsi programiści Javy mogą pamiętać czasy, gdy mówiło się, że Java jest dobrym wyborem dla tych, którzy chcą pracować w stabilnym środowisku.

Mówiło się, że co prawda próg wejścia jest wysoki, ale po dobrym opanowaniu najważniejszych umiejętności: Javy, Springa i Hibernate’a właściwie jest się „ustawionym” do emerytury. Jako kontrast podawało się świat Front-Endu, w którym rzekomo co tydzień powstaje nowy JavaScript’owy framework.

Z pewnością wielu Java developerów może odczuwać swego rodzaju stabilizację. Pośród mnogości zagadnień, z jakimi na co dzień mamy do czynienia, wiele jest takich, które od lat się nie zdezaktualizowały. Dzięki temu w niektórych obszarach możliwe jest bezpośrednie wykorzystanie wiedzy sprzed 5 czy nawet 10 lat.

Frameworki Javy 2022

Czy jednak takie postrzeganie ekosystemu Javy jest nadal słuszne w 2022 roku?

Wiele obserwacji świadczy, że nie. Jeśli spojrzymy na tylko niektóre z nich, uświadomimy sobie, jak dużo się dzieje:

  • Duży postęp w dziedzinie Cloud-Computinguprzyczynił się do rozwoju kultury DevOps, gdzie programista staje się współodpowiedzialny za strukturę deploymentu i w ogóle za infrastrukturę. Wymaga to uzupełnienia umiejętności w obszarze usług cloude’owych. Usługi te różnią się pomiędzy dostawcami, a nawet w ramach jednego dostawcy – stopniowo ewoluują.  
  • Konteneryzacja aplikacji stała się bardzo popularna, a w wielu organizacjach stała się standardem. Rozwiązuje ona różne problemy serwerów aplikacyjnych, ale jednocześnie zmusza do istotnej zmiany myślenia o deploy’owaniu aplikacji. A zatem również do uzupełnienia umiejętności.
  • Rozwiązania NoSQL co prawda nie uśmierciły (jak niektórzy przewidywali) tradycyjnych relacyjnych baz danych, ale i tak mają dziś znaczącą pozycję. Nie można być dzisiaj dobrym architektem skalowalnych rozwiązań, jeśli się nie zna przynajmniej ogólnych zasad działania poszczególnych rodzajów rozwiązań NoSQL. 
  • Coraz częściej backendowcy, przyzwyczajeni do programowania imperatywnego i synchronicznego, muszą przestawiać swój sposób myślenia na programowanie reaktywne. Na przykład, jeśli mają do czynienia z mikroserwisami komunikującymi się przez kolejki.
  • W końcu również sielankowy spokój javowego backendowca mącą frameworki alternatywne dla Springa.

Spring Framework

Od lat trzyma pozycję lidera, jeśli chodzi o backendowe frameworki w świecie Javy. Zdołał tę pozycję obronić przed różnymi alternatywami, jakie pojawiły się w międzyczasie. Wiele z nich, choć zyskało sporą popularność, to pozostało niszowe:

  • Grails(pisanie na JVM w dynamicznie typowanym języku).
  • Vaadin(tworzenie web UI w Javie).
  • Play Framework(reaktywne aplikacje pisane w bardzo popularnej swego czasu Scali).
  • Odświeżona Java EE(nowoczesne i lekkie aplikacje na tradycyjnych serwerach aplikacyjnych opartych o otwarte standardy).


Dzisiaj istnieją jednak nieco mniej oczywiste czynniki, które mogą determinować wybór frameworka. Czynniki, które ujawniły się, gdy popularne stały się architektury mikroserwisowe.

Architektury mikroserwisowe

Jednym z kluczowych argumentów, by przejść na architekturę mikroserwisową, jest potrzeba auto-skalowalności. Można ją zrealizować poprzez skalowanie wertykalne (scale up) albo horyzontalne (scale out). Można też stosować kombinację obydwu.

Wielu architektów rozwiązań, jako sposób na bezbolesne przetrwanie spike’ów obciążenia, preferuje skalowanie horyzontalne. To znaczy – jeśli wystąpi drastyczny wzrost natężenia ruchu w naszym systemie, to dynamicznie dodajemy nowe efemeryczne instancje najbardziej dotkniętych mikroserwisów. Gdy ruch spadnie – usuwamy je. A zatem w danej chwili mikroserwis może mieć od kilku do kilkunastu instancji, ich liczba zmienia się w czasie.


Wskutek tego rolę zaczyna odgrywać:

  • Narzut zużycia zasobów na uruchomienie kolejnej instancji (przede wszystkim – pamięci operacyjnej).
  • Czas startu instancji.


Okazuje się, że framework aplikacyjny ma dominujący wpływ na obie te wielkości. I właśnie na tym polu odbywa się dzisiaj rywalizacja pomiędzy javowymi frameworkami.

Gdyby bliżej prześledzić jak pod spodem działa Spring to można zauważyć pewien paradoks. Z jednej strony: aplikacja napisana w Javie, statycznie typowanym, kompilowanym języku.

Statyczna analiza kodu

Jest ważnym narzędziem panowania nad naszą logiką biznesową. Z drugiej strony Spring – mocno oparty na refleksji, skanowaniu classpatha, bardzo intensywnie używający dynamicznych możliwości JVM.

Wszystko to, zrobione przede wszystkim dla wygody developera, powoduje dodatkowy narzut zużycia pamięci na cache refleksji oraz wydłuża start aplikacji.

Frameworki od społeczności Javy

W odpowiedzi na te problemy, społeczność Javy stworzyła nowe frameworki nastawione na rozwiązanie tych konkretnych problemów. Najważniejsze z nich to Micronaut i Quarkus.

Wyróżnia je to, że od początku zostały stworzone z myślą o możliwości budowania natywnych obrazów opartych na GraalVM. Daje to możliwość zastosowania technik optymalizacji niedostępnych wcześniej dla programistów Javy:

  • Ahead-of-time compilation.
  • Compile-time dependency injection.
  • Static linking.


Sprawia to, że osiągalny staje się czas startu aplikacji rzędu dziesiątek milisekund.

Odbywa się to kosztem zwiększonej złożoności i wydłużonego czasu budowania artefaktów. Należy jednak zauważyć, że twórcy Micronauta i Quarkusa wkładają ciągle intensywne wysiłki w optymalizację tych procesów.

Jeśli więc naszym celem są ultraskalowalne rozwiązania mikroserwisowe, to – jako Javowcy – mamy dziś do tego wszelkie narzędzia.

Próg wejścia frameworka

Rzeczą bardzo subiektywną będzie oczywiście próg wejścia w nowy framework. Warto tu zaznaczyć, że model programowania Micronauta oraz Quarkusa opiera się na dependency injection będącym adaptacją standardu CDI. Dlatego nie powinien być więc obcy dla developerów Javy.

Wybierając framework, na którym opieramy nasze rozwiązanie, trzeba wyważyć nasze priorytety. Jeśli z góry wiemy, że nie mamy wymagania ultrawysokiej skalowalności, to Spring nadal jest dobrym i bezpiecznym wyborem.

Z jednej strony, ekosystem Springa jest prawdziwą kopalnią dojrzałych, gotowych rozwiązań. Z drugiej strony, dla wnikliwego programisty jest świetną szkołą stosowania najlepszych praktyk programistycznych.

Zarówno jeśli chodzi o taktyczne wzorce projektowe, jak i bardziej strategiczne koncepcje (jak inversion of control), jak i wreszcie wzorce architektoniczne w obszarze infrastruktury mikroserwisowej (warto przypomnieć, że Spring Boot jest modelowym przykładem 12-factor app).

Podsumowanie

Podsumowując, świat Javy jest ogromny i pełen możliwości. Pojawienie się każdego nowego frameworka jest okazją do ponownego przemyślenia swoich wyrobionych przekonań.

Każde alternatywne rozwiązanie stymuluje społeczność do nieustannego doskonalenia swoich rozwiązań. Warto się więc przyglądać różnym rozwiązaniom choćby po to, żeby wiedzieć, dlaczego zostajemy przy swoim.

W końcu świat Javy jest na tyle duży, że odnajdą się w nim zarówno eksperymentujący pionierzy, jak i zwolennicy rozwiązań, które już przetrwały próbę czasu.

<p>Loading...</p>