Zostałem przywołany (z piekła) - więc przybywam.
Te wątki o Java EE to są tak częste, że aż się nie zawsze chce.
Sens uczenia - pewnie znajdziesz moje odpowiedzi, że jeśli potrzebujesz do pracy to owszem Java EE, ma sens, bo praca w tym jest i pewnie długo będzie.
Jakkolwiek moim zdaniem w COBOLu też długo będzie, a ujma na honorze (za COBOL) mniejsza.
Stanowczo odradzam uczenie sie Java EE dla początkujacych, bo ten framework po prostu ogłupia (początkujacych). Ludzie po Java EE mają tony głupich przesądów :
- nie można używać wątków,
- nie można używać
new
,
- nie można
nie pisać interfejsów
do serwisów (btw. java ee od dawna tych interfejsów nie wymaga...).
Albo jeszcze myślą, że adnotacje to programowanie deklaratywne( .... wtf? https://en.wikipedia.org/wiki/Declarative_programming)
(Zresztą w Springu to samo....)
Czyli jak już poznasz Javę/programowanie w stopniu niezłym to możesz brać się za Java EE pod kątem pracy. Ale IMO, żeby nie dostać trwałego uszczerbku na stylu kodowania, to trzeba umieć zrobić serwis bez Java EE i bez Springa. Wtedy można sie za nie zabrać i też ocenić na ile przeszkadzają, czy pomagają. Miałem kilka projektów, gdzie Spring / JavaEE były wykorzystane w stopniu marginalnym (fasada do REST, JPA), cała reszta kodu była pisana normalnie (żadnych beanów i wstrzykiwania) - takie projekty są całkiem rozsądne w utrzymaniu i testowaniu.
Jak już pracujesz w Java EE lub Springu i nie masz za bardzo wyjścia, bo masz taki projekt, narzuconą architekturę to powinieneś się Java EE/Springa nauczyć. Przeczytać KILKA książek, w tym najnowsze (oba frameworki mocno ewoluują). Poćwiczyć/ poeksperymentować na własnych projektach. Niestety, w trakcie mojej kariery ludzi, którzy faktycznie czytają te książki, do poziomu gwarantującego nie rzucanie sobie kłód pod nogi, poznałem mało. Mógłbym policzyć na palcach jednej ręki. I większości palców z tej ręki bym nie użył :-(.