JAVA EE 6 a 7

Witam.
ucze sie obecnie javy ee6, gdyz tylko mam ksiazki obejmujace wersje 6, sa jakies wielkie roznice miedzy wersja 6 a 7, da rade to pozniej nadrobic dokumetnacja, czy od razu jechac 7

Jak się dopiero uczysz to nie ma znaczenia czy to 6 czy 7. Pytanie dlaczego to sobie robisz? Ktoś Ci za to płaci ?

No to w takim razie czego sie uczyć do programowania webowego, biznesowego itp.? Widze, ze w kazdym temacie krytykujesz enterprise edition, springi i tym podobne twory, pisząć że najlepiej uczyć się javy... więc co polecasz mistrzu?

No przecież sam napisałeś. Javę - java jest OK. Jak idziesz do pracy w perspektywie roku to Spring jeszcze nie umarł i Ci się przyda. Ale JavaEE to już zombie.
A co polecam - to zależy co chcesz robić - prosta webówka REST - Ratpack abo SparkJava. Jesli musisz korzystać z baz SQL to JOOQ.

a jakies materialy moglbys zapodac? cos innego niz dokumentacja

Niestety dopiero pisze :-) Ale mnie tam dokumentacja starczała - to nadal o wiele mniej nauki niż potrzebne do bezpiecznego opanowania JavaEE.

Z tą śmiercią JavyEE to bym uważał bo nadal są tam elementy takie jak CDI, JAX-WS/RS, JMS czy JPA które są bardzo popularne i szeroko stosowane. Uczenie się całego stosu JEE pewnie ma niewielki sens, tak samo zresztą jak próba uczenia się wszystkiego co oferuje Spring, bo klasycznie: 80% aplikacji korzysta z 20% funkcjonalności.
Możesz korzystać z tego co masz do JEE 6, niemniej skupiłbym się na tym co wymieniłem wyżej i nie marnował czasu na czytanie na temat EJB czy JSF, bo pewnie będzie o tym sporo, a użyteczność niska.

Dla mnie główną zaletą Springa nad JEE jest bardziej dojrzałe wsparcie dla testów jednostkowych i integracyjnych: powiedziałbym, że killer feature. Arquillian dla JEE nie działa aż tak dobrze. Spring ma dużo lepsze wsparcie dla WebSocketów (pod spodem jest netty i project reactor). Taka JavaEE oferuje tylko czyste WebSockety, co jest dość marne. Pytanie jak to skalować? Czy ktoś o tym pomyślał? Spring natomiast rozszerza je o bardzo łatwe skalowanie dzięki wykorzystaniu brokera np. RabbitMQ oraz bardziej wysokopoziomowe i przyjazne API dzięki zastosowaniu STOMP. Kolejnym bardzo słabym punktem platformy JEE jest nieintuicyjne i niestandardowe wsparcie dla security. Każdy serwer aplikacyjny robi to inaczej.

Ogólnie pracowałem prawie 4 lata ze stosem JEE i można bardzo przyjemnie dowozić działający soft, pod warunkiem że wystarcza Ci wsparcie dla REST/SOAP, relacyjnej bazy danych, potrzebujesz transakcji itp. JSF też jest super jak chcesz na szybko zrobić GUI: kwadratowe tabelki dla niewymgających. CDI jest całkowicie ok, a za pomocą rozszerzeń z pakietu DeltaSpike można uzyskać wiele kopii funkcjonalności Spinga. Można mieć też fat jar w JEE: ale pewnie zostanie to ustandaryzowane dopiero w JEE 9, czyli jakoś 2018/2019.

Poza tym w Springu często używa się wybranych elementów JEE .Ja np. piszę sobie teraz aplikacje w Spring Boocie z użyciem MongoDB (kiepskie wsparcie w JEE: chcę mieć tylko kolekcje i persistence nie bazę danych), Spring Data, JSF zintegrowanym ze Spring Boot, lombokiem i PrimeFaces, ze springiem jako kontenerem DI. Wiele osób używa JAX-RS wraz ze Springiem i JPA i jest to całkowicie ok.

Java EE ma się dobrze i standaryzują kolejne elementy np. security. To jest bardzo dobry stos technologiczny. Jego główną zaletą jest moim zdaniem znacznie większa prostota i łatwość ogarnięcia niż Springa. Jednak scope wspieranych funkcjonalności jest po prostu mniejszy. Jak patrzę na scope JEE 8 i JEE 9 dochodzę do wniosku, że chyba trzeba się zaangażować w proces tworzenia specyfikacji by przepychać dobre pomysły, które się przyjęły np. w Springu (po co wymagać bezargumentowch konstruktorów w EJB albo @Inject jak można mieć implicit DI przez konstruktor jak w Springu i pozbyć się adnotacji przez Lomboka).

Oczywiście serwery aplikacyjne mają feature'y jakich nie ma Spring np. taki WebLogic ma płatne rozwiązania GIS np. MapViewer zintegrowany z bazą Oracle, fushion apps itp. Ale JEE to tylko lekka specyfikacja i taka ma być. Jak coś się sprawdza np. w Springu to za kilka lat trafia do JEE.

Nie ucz się JEE z książek. Weź najnowszą wersję, ale na backendzie od JEE 5 programuje się dość podobnie, ale z każdą wersją coraz łatwiej. Wiele aplikacji po prostu nie wymaga nic więcej jak JEE i nie ma problemu. Wszystko zależy od wymagań aplikacji.

JEE8 na koniec tego roku ma być... zatem pogłoski o śmierci JEE są mocno przesadzone.

1. Ucz się Javy jako takiej. Jak znasz język JEE staje się po prostu kolejną specyfikacją.
2. Dokumentacja, tutoriale Oracle i blog Adama Biena, to chyba najważniejsze źródła.
3. Książki Beginning JEE 7 i seria Java EE7 development with Netbeans 8, Wildfly, Glassfish 4 AS oraz JEE7 Essentials

Z listy książek wybierz jedną. Książka ma tą przewagę nad tutorialem, że treść jest odpowiednio ułożona, ktoś ją zrecenzował i zredagował.

Ten raport Gartnera zdenerwował wielu JavaEE guardianów:
https://www.gartner.com/doc/3522917/market-guide-application-platforms

Jakkolwiek faktycznie JavaEE będzie ciężko ubić - bo trudno ubić martwiaki : ZombiEE :-)

Btw. Gartner to marketing -> można olać - czekam aż chłopaki z Thoughtworks umieszczą to na swojej liście HOLD.
Application serwery są tam już od jakiegoś czasu (https://www.thoughtworks.com/radar/platforms/application-servers) (a taki JSF od dawna - mają nosa).

@margor90: no jak dla mnie stos Springowy jest o wiele łatwiejszy do nauki bo jest to po prostu implementancja i standard

@scibi92: Spring nie jest standardem i dlatego wiele rzeczy jest tam "prostsze". Standard ma swój cykl życia. Wprowadzenie nowej wersji, która będzie zawierać nowe funkcjonalności trwa znacznie dłużej niż w przypadku projektu, który nie jest standardem. Z drugiej strony standard daje gwarancję stabilności, a wdrożenie poprawki w implementacji nie spowoduje wybuchu, bo złamano jakieś, niepisane, reguły.

No co do tego standardu... właśnie projekty przenoszę z WAS 8.5 na WAS 9 (wiem, że to chyba najgorszy z serwerów...).
Jest zabawnie....
Chociaż na koniec działa. To, że po takim przenoszeniu przeklinam tak, że zawstydziłbym starych marynarzy to inna historia.

@Koziołek: tak wiem, to był trochę taki skrót myślowy - chodziło mi o to że JEE to standard niby ale jest to tylko taki "interface". A Spring od razu zawiera wszystko co potrzeba więc nie trzeba pitolić się z serwerami różnymi, no i mam wrażenie że dokumentacja jest o wiele łatwiejsza do ogarnięcia, np. security -> masz po prostu Spring Security a szukanie jak into jee + security to tak średnio bym powiedział ;)

Z takich ważniejszych zmian w istniejących specyfikacjach to API JMS zostało uproszczone, a do JSFa doszło coś takiego jak "html5 friendly markup" co daje trochę większą kontrolę nad HTMLem:

<html xmlns="http://www.w3.org/1999/xhtml"
      xmlns:jsf="http://xmlns.jcp.org/jsf">
<head>
  <title>JSF 2.2</title>
</head>
<body>
  <form jsf:id="myform">
    <input type="text" jsf:id="username" jsf:value="#{bean.username}"/>
    <button jsf:action="#{bean.save}">Save</button>
  </form>
</body>
</html>

Jak dla mnie to z JavyEE EJB mogłoby być wyrzucone (ew. kilka ich ficzerów przeniesionych do CDI), JSF jest jeszcze znośne chociaż upierdliwe w debugowaniu

@Koziołek: "Jak znasz język JEE staje się po prostu kolejną specyfikacją." - dla mnie JEE to jak nauka drugiego języka, przykrywa składnię Javy i wprowadza własną- głównie ze względu na EJB/CDI

@student pro: jeżeli mowa o JSF, to się zgodzę. Kolejny język. Jednak EJB czy CDI, to nadal stara dobra Java, która tutaj spełniać musi kilka regułek.

Co mnie irytuje to fakt, że w JEE wciąż nie doczekaliśmy się fajnej rzeczy jaką jest Spring JDBC template. Po prostu możnaby to ustandaryzować i zintegrować z CDI. Zamiast tego dodają jakieś MVC pytam się po co skoro teraz wszyscy robią REST API ewentualnie JSF. Jeszcze JSP jako technologię widoku dla MVC sorry ale kto tego będzie chciał używać?

Czego nie potrafię zrozumieć ze strony Springa to braku implementacji dla javax.enterprise.context.* oraz dodawnia wsparcia dla @ViewScoped z CDI (to w sumie nowość dla JSF 2.2). Zamiast tego spotkałem się ze straszliwym i paskudnym polecaniem Spring WebFlow dla integracji z JSF co jest masakrycznie paskudne.

@Koziołek: co do tego, że CDI/EB to standardowa java... to mam wątpliwości:

• nie możesz używać normalnie wątków,
• nie możesz używać normalnie exceptionów (to może akurat plus :-) ),
• dzieją się cuda jak zrobisz return this, (to akurat głupie, ale fajnie pokazuje różnicę )
• wpierniczają Ci się w wywołania "aspekty", które jeszcze nie działają czasami (np. nie działają dobrze jak robisz call metody z tego samego beana),
• musisz dość dużo rzeczy robić publicznych, a już konieczność wpierniczania co najmniej protected domyslnego konsturktora w JPA jest naprawdę kuriozalna,
• nie możesz używać 'new' na beanach, (czyli masz klasy drugiego sortu),
• kuriozalne naruszenia enkapsulacji (szczególnie jak korzystasz z Request lub Session scope ),

@jarekr000000: ale nadal jest to Java, a nie jakiś nowy dziwny język. Narzucone są pewne reguły i koniec. O ich zasadności, bądź nie już rozmawialiśmy przy okazji dyskusji o Springu.

@margor90 patrząc na sukces SpringMVC to "standaryzacja" MVC jest uzasadniona. Tak czy inaczej ostatnie stanowisko Oracla jest takie że JSR371(MVC) ma pozostać poza standardem JavyEE, chociaż jest to malutka biblioteczka bazująca na JAX-RS i jej dodanie to żaden problem. Silnik widoku można zmieniać, nie musi być JSP i można ustawić Thymeleaf