Jak uargumentowalibyście żeby przejść z JEE na Spring

:)

Java EE już nie istnieje. Teraz jest https://jakarta.ee/

Java EE robi herbatę z wody po pierogach. A serio, to zależy komu argumentujesz. Przejście nie koniecznie ma w każdym przypadku sens.

wait, pytanie newbie: Jeszcze nie doszedłem w nauce do aplikacji webowych ale przez ten cały czas rozumiałem że apki webowe to JEE a Spring jedynie ułatwienie pisania ich, rozumiem że to jakby dwie różne sprawy i mogę pominąć naukę JEE i od razu brać się za Springa gdy przyjdzie na to czas, tak?

Jakbyś chciał poznać argumentację przeciwną, zobacz na YT -> Adam Bien
Spring nie jest żadną religią, żeby za niewiarę ścinali głowy (np mi)

Pewnie się w wątku odezwie @jarekr000000 z jeszcze trzecim zdaniem

Aplikacje o małej złożoności (o wąskiej funkcjonalności, wąskie "poziomo") być może bym robił w jednym z lekkich frameworków sieciowych / httpowych. Moja głowa przypomniała sobie ratpack, ale są i inne

Na pewno łatwiej testować i można budować jary zamiast warów :)

scibi92 napisał(a):

Na pewno łatwiej testować i można budować jary zamiast warów :)

Java EE też już ma jary od jakiegoś czasu (nawet długo) - Wildlfy Swarm, Websphere Liberty :-).
To samo co w Springu.

W sumie te potworki się niewiele różnią, oprócz tego, że Jakarta EE jest bardziej odjechana w adnotacje. Z Jakarta EE nie da sie beanów i aspektów już w zasadzie wyciać (a w Springu się udaje). Sam rdzeń springa jest Spring free.
W jakarta ee przez to jeszcze trudniej testować cokolwiek niż w Springu.

To ogólnie zawsze był najsłabszy punkt tego podejścia.
Spytaj o testy z bazą danych i zobacz jak się Java EE architekci wiją. (da się - ale to jest męczące).
Tak samo testy kontrollerów Rest.
(To w springu niedawno też było słabe (powolne), ale już jest znośnie).

W Springu jest więcej gotowych modułów do różnych integracji, np. (różnych usług z chmury itp). - takie same rzeczy w Jakarta są trudne do zdobycia, specyficzne dla serwerów.
Ale jak nie jesteś w chmurce to na grzyba.

Jak dla mnie zmiana ma sens jak przesiadka ze Stara 660 na Star 266. Niewątpliwie czuć postęp.

To wszystko zależy od kontekstu.
Tak ogólnie, porównując oba frameworki (pisząc o Springu, mam namyśli też autokonfiguracje i cały zasobnik Spring Boot), mogę powiedzieć, że:

1. TESTY - w JEE to istna mordęga (ostatnich kilka lat pracowałem głównie z JEE). Testy np. DB w JEE wymagają ogromnego nakładu pracy, gdy w Springu to kwestia dodania 1-2 adnotacji... (Spring Boot Testing). Polecam także ciekawy wpis Antonio Goncalvesa (m.in. Java EE Expert) odnośnie testów JavaEE vs. Spring Boot
2. Integracja z chmurą - Spring dostarcza wiele gotowych modułów, które ułatwiają integrację z chmurą - Spring Cloud
3. Jeśli korzystacie / zamierzacie korzystać z JPA - świetna integracja Spring Data - repozytoria, gotowe convertery, entity listenery, konfiguracje itp. Ja osobiście polecam JOOQ, którego udało mi się przeforsować w jednym projekcie i jego podejście (DB first) podoba mi się o wiele bardziej od JPA (Java first) - jedna z fajnych, przystępnych prelekcji Java vs. SQL twórcy JOOQ - How Modern SQL Databases Come up with Algorithms that You Would Have Never Dreamed Of by Lukas Eder
4. Moduł do tworzenia reaktywnych serwisów/resource'ów - Spring WebFux, oraz podejście nieco bardziej zbliżone do funkcyjnego New in Spring 5: Functional Web Framework
5. Moduł Spring Security, ułtawiający nieco integrację z np. OAuth
6. Springfox - integracja Swagger2 ze Springiem - dość wygodny framework do tworzenia dokumentacji Swagger/OpenAPI.
7. Spring Boot Devtools z m.in. live reloadem czy wbudowanym supportem do pracy z H2 na środowisku developerskim.
8. Ja osobiście doceniam jeszcze ConfigurationProperties w Spring Boot - Spring Boot Externalized Configuration
9. Całkiem niezły Spring Initializr, pozwalający na utworzenie projektów wraz z niezbędnymi zależnościami nawet komuś bardzo niedoświadczonemu w pracy ze Springiem.

To nie jest tak, że na JEE tych wszystkich rzeczy się nie da zrobić, ale jest to po prostu nieco bardziej czasochłonne lub skomplikowane.
Często zdarzało się, że w JEE trzeba było stworzyć coś,co w Springu jest gotowym modułem, który tylko nieco trzeba skonfigurować.

Oczywiście, to wszystko nadal zależy od tego, w czym pracujecie, co robicie na co dzień, z jakimi problemami borykacie się w JEE, jakie Wasze problemy rozwiąże Spring, a jakich problemów Wam przysporzy. Niestety, nic tutaj nie jest jednoznaczne i na pewno prędzej czy później, możecie trafić na coś, przez co będziecie kląć na Springa. :)

Bump. Czy po 2.5 roku coś się zmieniło, nadal Spring jest bardziej postępowy, czy może Jakarta nadgoniła?

Nowe projekty są tworzone w Springu. Spring ma większe community, łatwiej znajedziesz rozwiązanie problemu. Jakościowo nie sądze żeby była wielka różnica, a jeśli już to raczej na korzyść Springa ;)

BluzaWczolg napisał(a):

Bump. Czy po 2.5 roku coś się zmieniło, nadal Spring jest bardziej postępowy, czy może Jakarta nadgoniła?

Literalnie porównujesz konkretny projekt (rodzinę projektów) ze specyfikacją.

Dużo dobrego się dzieje w java EE8 -> jakarta EE. Czy na tyle aby w "obiektywnym" porównaniu przebić Springa, i przebić jego pozycję rynkową? Otwarte pytanie.
Na EJB2 i wszystko, co przyniosły, w zasadzie spuszcza się wstydliwą zasłonę milczenia (a część jest deprecated / wycięta). Nie znam szczegółów, nigdy nie siedziałem w EJB2

Ciekawe specyfikacje z grupy micorserwisowej, wszelkie monitorowania, konfigurowania itd....

Akurat jak się wczytywałem w konfigurację, idzie to inaczej, niż bym sobie wymarzył, skupia się na atomowych danych konfiguracyjnych, a nie obiektowym podejściu. Nie wiem, może generałowie widzą szerszy horyzont, i to ma zalety większe, niż mi szeregowemu programiście by się widziało (type-safe klasy konfiguracyjne)

Sporo dobrego.

Minusy są. Zmiana namespace, to będzie czkawka na tzw "okres przejściowy", a ten nie będzie trwał przecież kwartał.
Nadal jestem związany z frameworkiem webowym Apache Wicket (i nadal widzę w tym zalety). Nie jest to zaniedbany projekt, nowa wersje nie tylko wymaga Javy 11, ale jest w jej stylu. Ciągle zmiana namespace przede mną (jako użytkownikiem fw - pewnie dwie wersje ??? hgw )

Java EE MVC (bosch, jak fajnie zrobiony) - tylko spóźniony o 15 lat

Jakarta EE pozwala na mniejszy "horror zależności" niż Spring. Można użyć ich "punktowo", w pełni / o wiele, wiele lepiej rozumiejąc co działa pod maską. bez magicznego spojrzenia / cargo kultu w sraniu przypadkowymi adnotacjami "wszystkomającymi"

Mniejszy fat-jar

Aleksander32 napisał(a):

Nowe projekty są tworzone w Springu. Spring ma większe community, łatwiej znajedziesz rozwiązanie problemu. Jakościowo nie sądze żeby była wielka różnica, a jeśli już to raczej na korzyść Springa ;)

"łatwiej znajedziesz rozwiązanie problemu"
również łątwiej wprowadzą cię na krowi placek

Uargumetował bym milionami słabiutkich programistów springowych, a raczej stawiaczy andotacji + vendor locking

Bump. Czy po 2.5 roku coś się zmieniło, nadal Spring jest bardziej postępowy, czy może Jakarta nadgoniła?

Moim zdaniem to źle zadane pytanie. Bardzo wiele projektów ma model hybrydowy, bo np. korzysta z CDI czy JPA, ale jednocześnie stoi na Spring Boocie. To w takim razie to jest projekt Springowy czy jednak JEE? Jak to mierzyć? Idąc dalej, ja generalnie nie rozumiem za bardzo takiego nakręcania się na framework, bo w nie-CRUDowej aplikacji 95% kodu to będzie logika domenowa która jest niezależna od frameworka.

Tak samo jak podwyżkę. Wypowiedzeniem

Wracając do tematu - tak jak każda decyzje :)

1. Parametry decyzji, na co wpływa w krótkim terminie i najważniejsze na co w długim (2-3 lata), np. niższe koszty rozwoju, utrzymania, łatwiejszy dostęp do specjalistów na rynku, bezpieczeństwo, inne…
2. Ewaluujesz kilka opcji, w tym baseline, wykazujesz jak dana opcja na wybrane parametry. Powinny być na stole 2-3 opcje
3. Przedstawiasz różne warianty dojścia do Ew. zmiany technologii i jakie są trade offy.

Biznesowo taka zmiana musi poparta liczbami, tj. danymi. Biznes/management zapyta na pewno o trade offy, wpływ na cele, na kiedy będzie zrobione i jakie inne opcje były w ogóle rozważane.

Żeby zacząć brać się do takiej dyskusji, trzeba mieć argumenty sensowniejsze niż "Spring jest fajny". Trzeba mieć też plan przejścia. I trzeba mieć jakieś liczby, albo chociaż szacunki, które skłonią klienta do wyłożenia grubej kasy na napisanie tego samego, ale "fajniej".

Bardzo racjonalne podejście @Charles_Ray. Ja bym jeszcze drążył temat kontekstu, tzn. jakiego rodzaju problem rozwiązujemy i dlaczego zmiana technologii ma być lekarstwem.

Często nie chodzi o zmianę technologii w istniejącym projekcie, to faktycznie zwykle kanał. Natomiast istotne jest w czym robimy nowe projekty. Niestety dużo nowych projektów robi się w durnych, przestarzałych technologiach - bo przecież w starszych projektach działa. To, że jest problem z testowaniem, konfiguracją i development jest dużo wolniejszy - zwykle już jest przez seniorów jednej technologii pomijane.