java ee, czy warto?

Czy muszę uczyć się javy EE, czy wysatrczy znajomość samego springa mvc?

Polecicie jakiś tutorial, książkę do Javy ee, gdzie buduje się jakiś projekt step by step... są takie fajne książki do asp.net, springa. Mam wrażenie, że ta literatura dla javy ee jest bardzo uboga i ta technologia staje się coraz mniej popularna.

Czy waszym zdaniem java ee to przeżytek?

Czy muszę uczyć sie jazdy na nartach, czy wstarczy sama jazda na rowerze?

Java EE i Spring MVC to technologie konkurujące ze sobą, realizujące mniej więcej te same potrzeby. Historycznie Java EE była bardziej toporna niż Spring, aczkolwiek ostatnio jest całkiem dobrze. Zdecydowanie nie jest przeżytkiem i jeszcze sporo projektów w tym powstaje i powstanie.

Warto. A jeżeli masz jeszcze jakieś obiekcje czy warto to sobie możesz posłuchać:

Warto znać Spring i JEE są bardzo podobne, ale najpierw skup się na samym Springu lub JEE (nie wszystko na raz).

w JEE 8 też będzie ustandaryzowane MVC wzorowane na JAX-RS: Ozark.
https://ozark.java.net/

Dużo ostatnio mówi się o tej nowej wersji javy ee. Weźmy np. taki artykuł https://www.infoq.com/news/2016/07/Java-EE-8-Stagnating. Nie wiem czy to działania konkurencji, czy faktycznie oracle nie chce już tak rozwijać javy ee, kiedy do gry zaczęły wchodzić inne technologie jak np: asp.net

kiedy do gry zaczęły wchodzić inne technologie jak np: asp.net

A asp.net to jakaś świeżynka?

Jeżeli znasz podstawy Java SE to polecam http://javastart.pl/enrol/index.php?id=10

kolo625 napisał(a):

Dużo ostatnio mówi się o tej nowej wersji javy ee. Weźmy np. taki artykuł https://www.infoq.com/news/2016/07/Java-EE-8-Stagnating. Nie wiem czy to działania konkurencji, czy faktycznie oracle nie chce już tak rozwijać javy ee, kiedy do gry zaczęły wchodzić inne technologie jak np: asp.net

Java EE poradzi sobie bez Oracle. Ale milczenie ze strony Oracle zostało przerwane i będą mieli swój komentarz w JCP: wezmą udział w tworzeniu następnego standardu. Szczegóły zostaną przedstawione na konfie JavaOne na jesień.

Poza tym powstają ciekawostki jak standaryzacja takich rzeczy jak UberJar czy micro profile na potrzeby cloud.

Tylko nie siedź za długo nad EJB, bo to długa i skomplikowana specyfikacja, a w praktyce wykorzystuje się może 10% z tego i ze względu na rozwój CDI i tak średnio ma rację bytu.

...albo odpowiadając stricte na pytanie- żeby programować w Spring Mvc, to z JavyEE powinieneś znać Servlety

Pijany Zając napisał(a):

Tylko nie siedź za długo nad EJB, bo to długa i skomplikowana specyfikacja, a w praktyce wykorzystuje się może 10% z tego i ze względu na rozwój CDI i tak średnio ma rację bytu.

EJB ma znacznie więcej opcji niż trzeba. Pisze się w tym prosto, ale trzeba wiedzieć czego używać czego nie.

Co do EJB moje przemyślenia są takie:

1. Używać adnotacji @stateless (POJO na logikę biznesową transakcyjne domyślnie). Może się też przydać @Singleton (np. na schedulery). Raczej nie będziesz zbyt często chciał używać komponentów @Statelful, ale warto wiedzieć, że jest taka opcja.
2. Zamiast @ejb używaj @Inject (CDI). Do prostych case'ów wystarcza.
3. Nie używaj interfejsów przy pojedynczej implementacji (od JEE7 wystarcza samo @stateless na POJO). @LocalBean w JEE7 jest redundantne.
4. Sporadycznie możesz chcieć używać metod asynchronicznych @Asynchronous.
5. Timer service dość często się używa i warto poznać (scheduler / cron).
6. Jak będziesz potrzebował JMS możesz zainteresować się MDB. Uważaj na toksyczne komunikaty i pilnuj zasięgu transakcji (transaction attribute RequiresNew w MDB).
7. Jeśli chodzi o interceptory i dekoratory nie używaj tych z EJB tylko tych z CDI.
8. Zapomnij o zdalnych interfejsach: szkoda czasu. Lepsze są WebServices.
9. Warto wiedzieć, że masz 2 rodzaje transakcji:
   a) zarządzane przez kontener CMT, domyślne, (nic nie musisz z nimi robić), ale nie masz kontroli nad zasięgiem transakcji
   b) zarządzanie ręcznie BMT, przydają się bardzo rzadko, gdy potrzebujesz bardziej precyzyjny zasięg transakcji jak metoda (wiele transakcji w 1 metodzie)

Z punktu widzenia kodera nie ma większej różnicy czy pisze się POJO w EJB/CDI czy Springu. Bardziej wewnętrzna specyfikacja serwera aplikacyjnego jest różna (Spring go nie wymaga).

Moim zdaniem znacznie mniej przyjazną specyfikacją niż EJB jest JPA (Hibernate itp.). Problem w tym, że jest bardzo rozpowszechniona, również w Springu. EJB to zwykłe POJO.

margor90 napisał(a):

EJB ma znacznie więcej opcji niż trzeba. Pisze się w tym prosto, ale trzeba wiedzieć czego używać czego nie.

No właśnie, tylko skąd nowe osoby mają to wiedzieć. Lista którą podałeś wygląda jak lista haków i świadczy o braku spójności platformy. Dlatego uważam, że lepiej gdyby EJB wywalono z JEE. W EJB jest może kilka ficzerów, ale one nie usprawiedliwiają 450 stron specyfikacji. Powinien być jeden model klas zarządzanych przez kontener.

450 stron specyfikacji na pewno nie jest istotne dla programisty aplikacji biznesowych. Co najwyżej dla programisty serwera aplikacyjnego (im bardziej dokładna specyfikacja przy tej liczbie serwerów aplikacyjnych tym lepiej). To co potrzebne z EJB dla małego-średniego projektu spokojnie można zamknąć na kilkugodzinnym szkoleniu (z praktyczną wiedzą jak ktoś kuma SOLID i DI). Podejrzewam, że pełna specyfikacja (dokumentacja) Springa jest większa (np. różne podejścia do obsługi transakcji).

Czy potrzebujemy serwerów aplikacyjnych? To już inna sprawa. Często nie, ale w tej chwili serwery aplikacyjne są już używalne (kiedyś to był mordor).

Z tego co widać JEE ewoluuje w tą stronę, aby serwery aplikacyjne były opcjonalne (rozwój CDI).

np. Mały, średni projekt, microservices = JAX-RS, CDI, JPA, Spring Data/Apache DeltaSpike... czego chcieć więcej? Pisze się w tym dobrze.
Z dobrym mentoringiem albo mając dobry przykład i można lecieć z CRUDami niemal na ślepo ;)

Aczkolwiek jak każda technologia ma to swoje niuanse, które pewnie można poznawać latami.
np. sprawy związane z transakcjami i lazy initialziation exception itp. pewnie na początek mogą spędzać sen z powiek.
Albo czemu używać Setów w encjach zamiast List itp. ;)

Ja jestem przyzwyczajony do Spring Boota. Ostatnio zacząłem trochę interesować sie Wildfly to stwierdziłem, że można napisać aplikację łudząco podobnie do Springa. A taki Wildfly praktycznie dostarcza wszystkie potrzebne jary by napisać fajną aplikację.

Według mnie fajne i przyjazne technologie.

PS. Jak macie propozycje to chętnie poznam jak można to fajniej napisać w innym języku.