Patrząc na popularność mojego artykułu Low-code i No-code – czy generatory kodu źródłowego zastąpią programistów?, gdzie cofam się w czasie i opisuję „stare” technologie, które miały zrewolucjonizować sposób wytwarzania oprogramowania. Dziś postanowiłem odświeżyć mój artykuł sprzed ponad roku, który napisałem dla https://bulldogjob.pl, w którym opisałem nierówną „walkę” pomiędzy Java EE (Enterprise Edition), a Spring Framework – Dawid kontra Goliat. Cytuję fragmenty artykułu poprawiając daty oraz dodając moje komentarze.
Obecnie obydwa narzędzia trochę się zestarzały. Spring Framework jest już „pełnoletni” – w tym roku skończył 20 lat. Natomiast Java EE kończy 23 lat, sama Java ma już 27 lat.
[…] 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).
[…] 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, to obecnie Jakarta EE po „oddelegowaniu projektu” przez firmę Oracle do Eclipse Foundation. Swoją drogą, to oddelegowanie wygenerowało spore zamieszanie w projektach i ich bibliotekach, które korzystają z Java EE. Należało zmienić importy dla Java EE w takich projektach jak Spring Framework i Hibernate, ale to już temat na osobny artykuł.
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.
Wspomniane komponenty EJB na szczęście nie zostały „powielone” w Spring Framework. Ten, kto nie używał komponentów Enterprise JavaBeans „niczego nie stracił”. Spring Framework natomiast dla swojego modułu Spring MVC (aplikacje web, REST) wykorzystuje Java Servlet z Java EE.
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.
Tutaj muszę napisać sprostowanie, uzupełnienie dla samego siebie. Kod pisany w języku Java przy użyciu adnotacji ze Spring Framework jest ściśle związany z samym frameworkiem. Natomiast użycie konfiguracji Spring Framework w plikach XML pozwala uniknąć trwałych połączeń kodu Java z frameworkiem. Pojawia się kolejny problem, co jest lepsze, konfiguracja za pomocą adnotacji, czy może z użyciem plików XML? Odpowiedź na to pytanie pozostawiam samym czytelniczkom i czytelnikom.
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.
WebLogic Integration wspomniane w artykule Low-code i No-code – czy generatory kodu źródłowego zastąpią programistów?, to po prostu serwer aplikacyjny WebLogic plus framework „integracji biznesowych”, stąd w nazwie Integration. WebLogic, to serwer dla aplikacji Java EE, który moim zdaniem przyczynił się do „przegranej” Java EE.
https://en.wikipedia.org/wiki/Oracle_WebLogic_Server
Oracle WebLogic Server is a Java EE application server currently developed by Oracle Corporation. Oracle acquired WebLogic Server when it purchased BEA Systems in 2008.
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.
Poniżej cytuję podsumowanie z wcześniejszego artykułu „Java EE vs. Spring Framework – Dawid kontra Goliat”.
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.
Patrząc na technologie – Oracle Forms, WebLogic Integration, NetBeans – opisane w artykule Low-code i No-code – czy generatory kodu źródłowego zastąpią programistów?, które „umarły śmiercią naturalną” oraz biorąc pod uwagę Spring Framework, który „wciąż żyje” można dojść do wniosku, że Spring Framework przetrwał próbę czasu i jest idealnym rozwiązaniem. Na pewno wspomaga tworzenie aplikacji, np.: web, REST.
Najczęstsze błędy młodszych programistów i jak sobie z nimi radzić
Owszem, Spring jako framework jest bardzo przydatny, obecnie bez niego trudno sobie wyobrazić tworzenie projektów. Nie zwalnia on jednak programistów z myślenia nad tworzonym kodem.
Podsumowując, obecnie większość firm IT wymaga od programistów, programistek Java znajomości Spring Framework. Może, to budować mylny obraz, że, to coś nowego innowacyjnego, a po głębszej analizie okazuje się, że, to coś „starego”, co istnieje bardzo długo na rynku IT.
Zdjęcie autorstwa Elijah O’Donnell z Pexels.
English 
Polski