Java EE i Spring Framework, czyli Dawid kontra Goliat

W tym artykule wytłumaczę, dlaczego moim zdaniem Java EE przegrała w "walce" ze Spring Framework. Walka ta mogłaby się wydawać z góry przegrana z perspektywy Springa. Był on niewielkim graczem w porównaniu z "gigantem", jakim była Java EE w dawnych czasach, gdyż stał za nią Oracle, a Spring Framework inicjalnie został stworzony przez jedną osobę (Roda Johnsona).

Obecnie obydwa narzędzia trochę się zestarzały i Spring Framework jest już "pełnoletni" - w tym roku skończył 19 lat. Natomiast Java EE w grudniu kończy 22 lat, a sama Java ma już 26 lat.

Podczas mojej pracy jako programista Java korzystałem z dwóch wyżej wymienionych, najbardziej popularnych rozwiązań typu enterprise. Pierwszym rozwiązaniem była Java EE (Enterprise Edition), drugim Spring Framework. 

Java EE

Co takiego stało się, że Java EE, która jest dzieckiem twórców języka Java, przegrała ze Spring Frameworkiem? Bardzo obrazowo porównuję to na przykładzie PKP i PolskiegoBusa. PKP przespało swój czas na polskim rynku, nie rozwijało się, posiadało stare pociągi, bez udogodnień. Natomiast PolskiBus (obecnie FlixBus) wykorzystał pojawiającą się szansę i stworzył bardzo dobre połączenia, oferuje nowoczesne i wygodne autobusy z wieloma udogodnieniami.

Podobnie stało się z Java EE — przespała swój czas, oferowała przestarzałe technologie i rozwiązania. Wymaga "ciężkiego" serwera aplikacyjnego zgodnego ze specyfikacją Java EE. Użycie EJB (Enterprise Java Beans) nie wspierało dobrych zasad programowania obiektowego. Zmieniło się to trochę za sprawą DI (Dependency Injection), ale było już za późno. Moim zdaniem największym problemem był praktycznie brak możliwości testowania komponentów EJB.

Spring Framework

Natomiast Spring Framework nie wymaga "ciężkiego" serwera aplikacyjnego — DI jest jego głównym elementem, razem z Inversion of Control (IoC). Kod, który piszemy w Spring, nie jest ściśle związany z samym frameworkiem, co automatycznie pozwala na łatwe testowanie aplikacji. Dodatkowo Spring wspiera pisanie testów na każdym etapie i dla każdej warstwy aplikacji.

Skąd porównanie do Dawida i Goliata?

Tak jak pisałem na wstępie, Spring Framework inicjalnie został stworzony przez jedną osobę, a za powstaniem Java EE stała ogromna firma. W czasie, kiedy pojawił się Spring Framework, większość miał dość Java EE i wyczekiwał jakiejś alternatywy. Zdawano sobie sprawę, że firma stojąca za Javą, nie odda tak łatwo palmy pierwszeństwa, natomiast Spring Framework zdobywał coraz to nowych zwolenników i współtwórców.

Spring Framework zaczynał od zera, musiał zebrać i zatrzymać przy sobie grono odbiorców. Natomiast Java EE była już mocno promowana w świecie korporacyjnym. Na szczęście programiści zaczęli dostrzegać zalety korzystania ze Spring Framework i rozpowszechniali użycie tego frameworka we własnych firmach.

Idea przyświecająca Java EE była naprawdę bardzo obiecująca i szlachetna. W zamyśle było to odciążenie programisty od powtarzających się i podatnych na błędy elementów kodu, takich jak np. tworzeniem obiektów i zarządzaniem cyklem ich życia. Celem było również udostępnienie jednego wspólnego interfejsu, który będzie implementowany przez różnych dostawców serwerów dla Java EE. Serwery aplikacyjne dla Java EE, to np. WildFly (dawniej JBoss), WebLogic, BEA. Miało, to ujednolicić konfigurację aplikacji Java EE. Skutek był odwrotny do zamierzonego, gdyż każdy dostawca serwera aplikacyjnego miał możliwość konfiguracji aplikacji i samego serwera w różny sposób.

Przegrana Java EE

Główne problemy, które moim zdaniem przyczyniły się do "przegranej" Java EE ze Spring Framework:

• Bardzo słaba oficjalna dokumentacja do specyfikacji Java EE.
• Niewielka liczba przydatnych tutoriali.
• Konieczność używania "ciężkich" serwerów aplikacyjnych implementujących całą Java EE.
• Serwery aplikacyjne, które rzadko działały stabilnie w trakcie developmentu.
• Programista musiał zajmować się konfiguracją i administrowaniem serwerów Java EE.

Na początku mojej pracy jako programisty, konkretnie jako Junior Java Developer, dużo pracowałem z technologią EJB w wersji 2.1, która wchodzi w skład Java EE. Konfiguracja EJB była bardzo niewygodna, co opóźniało development (przykład konfiguracji EJB 2.1 za pomocą XML). Nawet po latach nie mam odwagi patrzeć ponownie na konfigurację EJB za pomocą XML-a. 

Ten przykład nie jest jedynym, jeśli chodzi o uciążliwość w korzystaniu z Java EE. Dodatkowo dochodziły nieudokumentowane i efemeryczne błędy związane z serwerem aplikacyjnym, na którym uruchamiałem aplikacje. Szukałem nieistniejących błędów, np. serwer aplikacyjny zapamiętywał stare dane, a ja już umieściłem nową wersję aplikacji na serwerze. 

Zmarnowałem niezliczone godziny podczas pracy z Java EE. To wszystko sprawiało, że walczyłem z frameworkiem, zamiast pisać kod kolejnych funkcji oprogramowania i dostarczać działające rozwiązania.

Wygrana Spring Framework

Co moim zdaniem przyczyniło się do "wygranej" Spring z Java EE?

• Bardzo dobra oficjalna dokumentacja techniczna.
• Wsparcie społeczności związanej ze Spring Framework.
• Brak konieczności używania "ciężkich" serwerów dla całej Java EE.
• Wystarczy "lekki" kontener servletów, serwer HTTP np.: Tomcat, Jetty.
• Wsparcie ze strony IDE, np.: Eclipse, IntelliJ.

Obecnie tworząc projekty oparte na Spring Framework, skupiam się głównie na logice biznesowej, którą muszę zaimplementować, a nie na technicznych problemach, tak jak było to w przypadku Java EE. Przez logikę biznesową rozumiem m.in. wykonanie przelewu bankowego z konta na konto.

Jeżeli tworzę w Spring Framework aplikację web, to po prostu dołączam moduł Spring MVC, korzystając z zależności. To samo dotyczy dostępu do bazy danych. Wtedy dodaję zależność dla modułu Spring Data. Utworzenie szablonu nowego projektu opartego na Spring Framework jest równie łatwe — wystarczy skorzystać ze Spring Initializr, gdzie ww. moduły można dodać po prostu — wpisując ich nazwy.

Moduły Spring Framework i korzyści z ich zastosowania:

• Core, Beans i Context— dostarczają Dependency Injection oraz Inversion of Control.
• Spring Boot— dostarcza domyślnie skonfigurowaną aplikację Spring.
• Spring Web— wsparcie dla warstwy web, np.: HTML i/lub REST.
• Spring Data— wsparcie dla warstwy dostępu do danych, np.: JDBC, JPA, Hibernate.
• Spring Security— autentykacja i autoryzacja użytkowników, np.: HTTP Basic Auth, OAuth.
• Spring Test— wsparcie dla testów aplikacji stworzonej w oparciu o Spring Framework.

Należy pamiętać, że Spring Framework nie jest jedynym dostępnym frameworkiem opartym na DI i IoC. Java EE miała i ma swoje wady. Tak samo po wielu latach również Spring Framework je ma. Nie należy ograniczać się tylko do niego, ani zamykać na inne rozwiązania takie, jak np.:

• Google Guice,
• PicoContainer.

Warto zapoznać się z Comparison between Guice, PicoContainer and Spring oraz dostępnymi alternatywami dla Spring Framework:

- https://stackshare.io/spring-framework/alternatives
- https://alternativeto.net/software/spring/

Podsumowanie

Podsumowując, konkurencja powoduje, że powstają nowe alternatywne rozwiązania, które zaspokajają zapotrzebowanie rynku. W tym przypadku był to nowszy framework dla aplikacji typu enterprise, który rozwiązał problemy Javy EE. Praca ze Spring Framework od samego początku była przyjemniejsza w porównaniu do Java EE i napędzana entuzjazmem związanym z czymś nowym. Obecnie ciężko sobie wyobrazić projekt javowy, który nie korzysta ze Spring Framework i jego modułów, które usprawniają pracę programisty.