Jak w temacie, od razu jechaliście dokumentacje, czy może jakieś książki czy kursy wam pomogły wejść w enterprise edition?
0
0
Jeżeli jesteś na takim etapie jak myślę, to lepiej zabrać się za naukę Springa i Hibernate'a.
0
Nigdy nie uczyłem się JEE jako takiej. Najpierw Hibernate a później Spring :)
1
Uczyłem się z draftu Mastering EJB ... rok 2000 chyba. Do tego testy na Jboss 1.0 oraz jserv (chyba pierwszy servlet container - katastrofa) , potem catalina .
Od tego czasu multum sie zmieniło.
Zasadniczo tylko mam pytanie na kiego grzyba chciałbyś się tego uczyć ? muzeum technologii?
Jeśli potrzebujesz w pracy i Ci dobrze płacą to polecam Adama Biena prezentacje online. Książki też ok http://press.adam-bien.com/
Jeśli po prostu chcesz znaleźć pracę w Javie to olej JavaEE jako takie i ucz się Springa.
Jeśli natomiast chcesz coś pisać sensownego dla siebie lub z myśla o pracy za kilka lat to olej też Springa i ucz się javy po prostu, albo kotlina.
0
Bardzo możliwe, że to co napisałem poniżej nie ma potwierdzenia w rzeczywistości, nie mogę dotrzeć do źródła
Gdzieś na SO spotkałem się z odpowiedzią na temat JEE, że to zbiór... cholera znaleźć nie mogę... takich zasad (?), wytycznych (?) i pisząc aplikacje webowe powinniśmy korzystać z nich, aby aplikacje mogły być używane na różnych serwerach (?) jak glassfish, wildfly, itp.
Taki moje pytania, aby usystematyzować temat:
- Czy JEE dotyczy tylko rozwiązań sieciowych? (Jeżeli nie to jakich?)
- Jak często się korzysta z JEE (i dlaczego? co jest na plus/minus?)
- Co zastępuje/zastąpi lub nie JEE i dlaczego?
2
- Nie, w skład JEE wchodzą też rzeczy typu messaging (JMS), persystencja (JPA). tranzakcje (JTA), wstrzykiwanie zależności (CDI)
- To zależy od aplikacji którą tworzysz. JEE dostarcza pewne gotowe "komponenty" które możesz wykorzystać w swojej aplikacji.
- Konkurencyjnym stosem technologicznym jest Spring, ale alternatywnie można sobie też poskładać odpowiedni stos z niepowiązanych bibliotek odpowiedzialnych za różne elementy.
0
jarekr000000 napisał(a):
Uczyłem się z draftu Mastering EJB ... rok 2000 chyba.
Aż mi się łezka od tego zakręciła - zakochałem się wtedy w tej książce i wszystkim z nią związanym. ;) W sumie fajne to tam było może porządne potraktowanie transakcji, MOM i ciut nacisku na interfejsy, a reszta to - jak się potem okazało - mega-g..., w reakcji na które powstały właśnie Spring i Hibernate, a potem zrobiono przemeblowanie samej Javy EE.
0
Okej, dzięki @Shalom ;)
Jak to zwykle bywa jedno pytanie generuje kolejne :D
- Czy znając JEE jest łatwiej przerzucić na inne frameworki (bo chyba tym jest Spring, Hibernate, Play...)?
- Czy można się spodziewać całkowitego zniknięcia JEE z rynku/obecnie rozwijanych projektów?
- Jaka jest pozycja Springa?
I ostatnie, najważniejsze. Rozumiem, że rynek raczej nie stawia na JEE. Czy warto uczyć się tego w ogóle? Na pewno będę, chociażby w celach hobbystycznych, ale jak jest to odbierane przez innych? Jak znajomość czegoś raczej nieprzydatnego/przydatnego, ale sporadycznie (przeszukanie SO wystarczy)/czegoś ważnego, decydującego?
2
Pijany Kura napisał(a):
Jak w temacie, od razu jechaliście dokumentacje, czy może jakieś książki czy kursy wam pomogły wejść w enterprise edition?
To zależy o który fragment pytasz.
Z grubsza można wymienić takie obszary:
- Java client-side: JavaFX, aplety
- Java server-side:
2.1) Web tier: JSP, JSF, JSTL, Servlety (czytaj wystarczy Tomcat)
2.2) Beans różnej maści (EJB, JMS)
2.3) serwer aplikacyjny: JPA, JTA, CDI
2.4) API backendowe: JavaMail, JSON-P, JAXB, JAX-RS, JAX-WS itd.
Nazwy mogą być różne w zależności od źródła:
https://docs.oracle.com/javaee/7/tutorial/overview007.htm
https://dzone.com/articles/java-ee-basics
I teraz różnie te warstwy wyglądają różnie zależnie od wieku aplikacji.
Z grubsza masz takie etapy historyczne:
- (archeologia)
- J2EE 1.4, czyli EJB 2.1
- EJB 3
- EJB 3.1
- EJB 3.2
Więcej: https://en.wikipedia.org/wiki/Java_EE_version_history
Oczywiście fajnie jest znać najnowsze trendy, ale np. w moim wypadku kupowanie książek o JEE 7 było bez sensu ponieważ cała firma do której aplikowałem stoi na J2EE i związanymi z tym starociami. A niestety JEE 7 a JEE 2 bardzo się różnią.
Pewne rzeczy są niezmienne, albo niewiele się zmieniają, natomiast patterny architektoniczne, wstrzykiwanie, podejście do beanów trzeba się uczyć pod konkretną platformę (chyba że chcesz poznać całą historię JEE).
Do J2EE książek nie będę polecał, bo to chyba bez sensu, ew. daj znać to dołącze listę.
Niezależnie od tego którego JEE będziesz się uczył, warto znać Hibernate, JPA i JDBC.
No i oczywiście narzędzia - IDE, maven/gradle, svn/git itd.
1
- Czy znając JEE jest łatwiej przerzucić na inne frameworki (bo chyba tym jest Spring, Hibernate, Play...)?
Hmm no to zależy. Jeśli dany komponent jest podobny to pewnie tak. Np. JPA powstało na bazie Hibernate więc siłą rzeczy znajomość jednego oznacza że dość szybko załapiesz jak używać drugiego, bo są do siebie bardzo podobne (pomijam fakt że można używać Hibernate przez JPA, bo to szczegół). Podobnie jest częściowo ze Spring DI i CDI, znów jeśli rozumiesz jak działa jedno to szybko załapiesz jak używać drugiego.
- Czy można się spodziewać całkowitego zniknięcia JEE z rynku/obecnie rozwijanych projektów?
Bardzo wątpie.
- Jaka jest pozycja Springa?
Raczej dobra, szczególnie że Spring jest modułowy i nie wymaga serwera aplikacyjnego. W efekcie możesz sobie wrzucić do projektu jakiś jeden czy dwa komponenty jeśli ci potrzebne.
I ostatnie, najważniejsze. Rozumiem, że rynek raczej nie stawia na JEE. Czy warto uczyć się tego w ogóle? Na pewno będę, chociażby w celach hobbystycznych, ale jak jest to odbierane przez innych? Jak znajomość czegoś raczej nieprzydatnego/przydatnego, ale sporadycznie (przeszukanie SO wystarczy)/czegoś ważnego, decydującego?
To nie jest prawda że rynek nie stawia na JEE. Tak to tylko w marzeniach @jarekr000000 ;)
0
U mnie cała firma stoi na JavaEE (głównie, bo wiadomo, że technologii jest mnóstwo). Ale to nie jest tak, że to jest nasza przyszłościowa technologia. Raczej spadkowa.
Btw serwer aplikacyjny klasyczny czy embedded to jeden pies ( embedded zmniejsza minimalnie poziom komplikacji związany np. z classloaderami, i czasy restartow sobie można zoptymalizować, ale pod względem produkowanego/wyaganego syfnego kodu - to samo).
0
Shalom napisał(a):
Np. JPA powstało na bazie Hibernate
Możesz to wyjaśnić? Jeśli Hibernate jest implementacją JPA, to w jaki sposób JPA powstało na bazie Hibernate? Z góry dzięki. :)
2
Najpierw był hibernate, potem stwierdzono , że to jest dobre i sie sprawdza, więc na bazie Hibernate opracowano specyfikację- którą nazwano JPA (podzbior hibernate). Potem kolejna wersja Hibernate (3) było naturalnie zgodna z tym standardem, a reszta twróców ORMów sie dopasowała.
Btw. hibernate to kastastrofa oczywiście :-)
0
@Wielki Kaczor jak wyżej -> w javie często jest taki oddolny proces. Ktoś zrobi dobrą bibliotekę która staje się popularna, a potem włącza się to do standardu języka. W przypadku JPA, jako że to część JEE, opisano jedynie specyfikacje bazując na tym co oferowało Hibernate (a także kilka innych rozwiązań) a następnie Hibernate dostosowało sie do tej specyfikacji. Inaczej np. było z klasami do obsługi dat i czasu w javie 8. Bazowano na Joda-Time, ale że weszło to w skład JSE to do standardu języka wprowadzono konkretną implementacje.
0
jarekr000000 napisał(a):
Najpierw był hibernate, potem stwierdzono , że to jest dobre i sie sprawdza, więc na bazie Hibernate opracowano specyfikację- którą nazwano JPA (podzbior hibernate). Potem kolejna wersja Hibernate (3) było naturalnie zgodna z tym standardem, a reszta twróców ORMów sie dopasowała.
Btw. hibernate to kastastrofa oczywiście :-)
@jarekr000000 dlaczego uważasz, że hibernate to katastrofa ? Lepiej używać JPA zamiast Hibernate ?
0
Obejrzyj linkowany wykład. JPA/Hibernate dramatycznie rozwala się już w średnich projektach. Płaczę ile razy widze jak ktoś savuje encje przy pomocy merge albo nie radzi sobie z onetomany. Szkoda na to czasu. Jak już ktoś się w bagno SQL pakuje to niech używa narzędzia prostego czyli np. JOOQ albo MyBatis. Przynajmniej wiadomo co się dzieje i używa się tego intuicyjnie.
Inaczej strata czasu pod tytułem - cholera wiem jak to zrobić w SQL, ale nijak nie umiem zamapować w JPA albo zrobić zapytania w JPA QL jest zbyt męcząca.
Kiedyś myślałem, że jest jeden dobry case na hibernate / jpa - kiedy po prostu piszesz klasy na pałę i olewasz co tam się wygeneruje w bazie danych -automat.Wyciąganie prosto po findById i żadnych zabaw z JPA QL Takie podejście nawet działa i wydajność nie jest wcale takim problemem. Natomiast jest inny numer - bo jak po prostu olewasz SQL i potrzebujesz tylko perzystować jakieś obiekty to na nic Ci ta baza SQL nie jest potrzebna, a tylko przeszkadza. Wywal i będzie jeszcze lepiej.