Rozszerzenie JDK dla Javy EE 7

0

Chciałbym przejść (a raczej poznać możliwości) z Javy SE na Javę EE i zacząć korzystać z dobrodziejstw Javy EE. Jako, że do tej pory nie napisałem jeszcze nawet jednego programu w Javie EE mam kilka pytań. Ze strony oficjalnej Java Platform, Enterprise Edition (Java EE) | Oracle Technology Network | Oracle można ściągnąć Java EE 7 Whitepaper, w którym czytamy:

For developers that are coming up to speed on Java EE, or simply want to quickly get started on new Java EE 7 features, the Java EE 7 SDK (SDK) is an all-in-one bundle for doing just that. The SDK includes the First Cup Java EE 7 introduction, the full Java EE 7 tutorial, sample applications that can be built with Maven, Java EE 7 javadocs, GlassFish Server Open Source Edition 4.0, and (optionally) JDK 7.

Chodzi mi o ostatnie wyrazy (podkreślone). 1) Czyli żeby przenieść swój kod, który wcześniej napisało się w Javie SE (przy pomocy JDK oczywiście) na Javę EE 7 SDK, trzeba doinstalować JDK z Javy SE? Wiem, że na stronie można ściągnąć paczkę Javy EE 7 SDK with JDK 7 Update 45 (w chwili pisania tego posta). Ale co jeśli napisało się program z wykorzystaniem dobrodziejstw Javy w wersji 8? Czyli w takiej sytuacji muszę zainstalować zarówno Javę EE 7 SDK (bez JDK) i dodatkowo Javę SE 8 JDK, czy tak (bo przecież ze strony Javy EE nie można ściągnąć samego pakietu JDK 8, ten znajduje się tylko na stronie Javy SE)?

Koziołek napisał(a):

Java SE - skrzynka z narzędziami.
Java EE - skrzynka z narzędziami + wykwalifikowani robotnicy + "podręcznik do budowy wszystkiego".

Java SE to podstawowy zestaw klas. Java EE to już różne wyspecjalizowane narzędzia, specyfikacje itp. które pozwalają na łatwe pisanie aplikacji.

Ten post mnie trochę zmylił. Bo jeśli podstawowa (**bez **opcjonalnego JDK) Java EE nie zawiera klas właśnie z Javy SE JDK, to w takim razie:
Java SE = skrzynka z narzędziami
Java EE = skrzynka z narzędziami + wykwalifikowani robotnicy + "podręcznik do budowy wszystkiego”.
Chyba że skrzynka z narzędziami, skrzynce z narzędziami nierówna. Hmm…

Drugie pytanie. Zatem skoro można (i Oracle to oferuje) ściągnąć Javę EE SDK bez JDK, to znaczy, że nawet bez klas wchodzących w skład JDK można coś konkretnego napisać. A moje pytanie (może kuriozalne) brzmi 2) co takiego? Oczywiście chodzi mi o główne idee a nie konkretne programy. Przeczytałem, że może służyć do wyświetlania stron. Ale przecież już w Javie SE można pisać aplety i umieszczać je w kodzie HTML, a do wyświetlenia ich wystarczy po stronie klienta aby miał zainstalowane jedynie JRE. Do tej pory jeśli chciałem coś napisać w Javie SE to bez JDK ani rusz. Po to jest właśnie JDK, zestaw klas programistycznych. W takim razie trudno jest stwierdzić, żeby Java EE była nakładką czy rozszerzeniem Javy SE. W Javie EE (podstawowej) zrobimy to czego nie zrobimy w Javie SE i odwrotnie (jedno służy do czegoś innego i drugie do czegoś innego, tak?).

Na początek tyle. I tak jest to długi post.
Pozdrawiam wszystkich i dziękuję z góry za odpowiedzi.

0

Javs SE to zestaw klas i runtime i narzedzia do tworzenia aplikacji. JRE to tylko klasy + runtime.
Java EE to zestaw specyfikacji - sam w sobie nic nie potrafi, to tylko definicja co kiedy i jak ma sie zachowac, wymaga konkretnej implementacji.
Taka implementacja jest np. JBoss AS, Glassfish (od Oracla), WebSphere itp. (mozliwe ze niektore z tych serwerow juz nie istnieja albo sa przestarzale, dawno nie robilem nic w EE). Te implementacje maja ogolnie nazwe 'serwer aplikacji' - pewnie sie spotkales.
Istnieja rowniez 'kontenery serwletow' - implementuja tylko fragment pelnej specyfikacji Javy EE, mianowicie servlety i JSP; naleza do nich np. Jetty oraz Tomcat. Nie oferuja pelnej funkcjonalnosci serwera aplikacji, ale mozna rozbudowac dolaczajac biblioteki, np. TomEE to tomcat plus Open EJB itp. (a przynajmniej kiedys takie cos bylo).
Nie ma czegos takiego (z tego co pamietam) jak Java EE bez Java SE. W sensie - kazda wersja specyfikacji Java EE ma pewne wymagania co do wersji Java SE. Z tego co pamietam, Java EE 5 wymagala Java SE 5 poniewaz uzywala adnotacji, EE 6 wymagala SE 6, a EE 7 wymaga SE 7. Najczesciej sciagasz albo pakiet serwer aplikacji plus bundled JRE/SDK, albo sam serwer aplikacji i zanim go uruchomisz musisz podac sciezke do JRE/SDK.
Jesli korzystasz z tego co oferuje Java 8 i chcesz tak skompilowany kod uzywac w Java EE, musisz serwerowi aplikacji podac sciezke do JRE/SDK 8. Zauwaz ze jest to zalezne od serwera, teoretycznie moze to byc nawet niemozliwe.
Standardowe aplikacje Java SE (takie z metoda main()) nie da sie uruchomic na EE - ta metode main() implementuje serwer aplikacji, a zasada pisania aplikacji jest inna - piszesz komponenty ktorymi zarzadzaja 'kontenery', i serwer aplikacji wola ich metody w odpowiednim momencie. 'Kontenery' (np. kontener serwletow, EJB, ...) to takie jakby moduly serwera aplikacji ktore maja konkretne zadania (web, komponenty server-side itp.).

0

Strasznie pogmatwałeś i to tylko dlatego że zamiast spróbować to zacząłeś niepotrzebnie czytać bzdety. Oracle nazwał sobie szumnie tą paczkę Java EE SDK, a w rzeczywistości to jest po prostu trochę tutoriali i Glassfish. Nic z tego nie jest ci koniecznie potrzebne. W swoim JDK masz już interfejsy javy EE, nic nie musisz dociągać ani kombinować. Nie masz za to żadnych implementacji bo JEE to jest tylko standard. Żeby uruchomić aplikację JEE potrzebujesz implementacje ;] W związku z tym potrzebujesz serwer aplikacyjny - może to być glassfish, ale możesz równie dobrze wziąć JBossa na przykład.

Moja rada: nie kombinuj tyle! Ściągnij sobie IntelliJ Enterprise (trial albo EAP 14). Ściągnij Glassfisha albo JBossa. Zacznij pisać ;)

0

Nie wiem czy piszesz do mnie czy autora, ale wydaje mi sie ze napisalem dosc duzo prawdy ;d
Mozesz powiedziec co rozumiesz przez to:

Shalom napisał(a):

W swoim JDK masz już interfejsy javy EE, nic nie musisz dociągać ani kombinować.

Jakie interfejsy Javy EE sa w JDK? JDK to tak na marginesie caly pakiet (JRE + narzedzia + kupa jarow). Moze chodzilo ci o Java SE? Tam z tego co wiem jest faktycznie pare pakietow ktore sa rowniez w EE (jakiestam parsery XML, JAXB itp. ale nie wszystko co jest potrzebne zeby skompilowac aplikacje EE (runtime to juz w ogole co innego. Mozesz wyjasnic?

0

Pisałem do autora ;)
Chodziło mi o to że jak masz JDK i jakiś serwer aplikacyjny to masz już wszystko co jest potrzebne do kompilacji i uruchamiania. Nie wymaga to żadnych specjalnych SDK i cudów na kiju od Oracle.
Poza tym biorąc pod uwagę wsteczną kompatybilność javy nie wiem czemu miałby być problem z używaniem Javy 8 gdzieś :)

0

Nie chcę nowego wątku robić, więc dołączę się tutaj.

Chcę zacząć uczyć się JavaEE. Czy poniższe JDK jest tym co potrzebuje? Bo w nazwie ma niby SE.

http://www.oracle.com/technetwork/java/javase/downloads/jdk8-downloads-2133151.html

0

@toburz: olej JEE jako takie tylko ucz się Springa :)

0

Ok, ale można brać się od razu za Springa, bez ogarnięcia orientacyjnie tematyki serwletów, JSP, JSF?

Kupiłem książki:
-"Java EE6 Programowanie aplikacji WWW". Krzysztof Rychlicki-Kicior
-"Spring w praktyce". Willie Wheeler, Joshua White.

Miałem zamiar przerobić najpierw tę pierwszą, aby jako tako ogarnąć Java EE, a potem wziąć się za tę drugą o Springu.

Sugerujesz, że mam wziąć się od razu za tę drugą?

Zmarnowałem kilka miesięcy na zagłębianie się w Swinga i JavaFX, aby potem się dowiedzieć, że to nie jest w ogóle używane, więc byłbym wdzięczny za nakreślenie, za co nie ma sensu się brać, aby nie marnować więcej czasu :)

Pozdro.

0

Dlaczego mnie nikt nie wezwał ? ;-)
Zapomnij o Java EE. Java EE to zemsta lat 90tych na programistach. Służy do zanudzania programistów Javy na śmierć (przez zmusznie ich do pisania geterów i seterów i maperów tych seterów do geterów... )
Wszystko to co możesz napisać w JavaEE - możesz napisać lepiej w czystej javie z bibliotekami - mniej uczenia - lepszy kod:
poczytaj o Ratpack, SparkJava, Lagom, Vert.x, Spring 5 Reactive (to kilka lepszych alternatyw dla technologii serwerowych w Javie).
Btw. powinno się nazywać ZombiEE. Bo niby martwe, a się rusza.

0

@margor90: jesli uważasz ze architekt powinien byc doscwiadczonym programistom to ze złej pozycji startujesz, ale pewnie mamy różne postrzeganie roli architekta . Kolejna sprawa - czy naprawdę wplecenie kotlina w projekt to problem i czy każdego to interesuje- niestety rozumiem ze są tematy w stylu micromanagemnetu ? I Jesli zastanawiasz sie nad test builderami to pewnie spock tez ci obcy

0

Tak patrzę ile byków walnąłem w poprzednim komentarzu :)

0

@kemot: Nie pisałem w Spocku, tylko JUnit i TestNG. Wiem, że Spock bazuje na Groovym i być może język ten ma ciekawe właściwości, które rozwiązują ten problem: nie znam Grooviego. Czy w Spocku używa się Mockito, czy raczej używa się Groovy (ma własny mechanizm mockowania)? Powiem szczerze, że bym chciał spróbować, ale nie zawsze jest czas wszystko samemu przetestować, a wiadomo trzeba trafić na zespół programistów, który takich technologii używa. W przypadku JUnit builder lomboka działa super. Mam świadomość, że to może nie być najlepsze możliwe rozwiązanie: ale nie sposób znać wszystkie możliwe frameworki. :-)

Uważam, że wrzucanie kolejnego języka do testów np. Groovy zamiast Javy ma taką wadę, że ludziom może nie chcieć się tego uczyć. Wielu programistów ma problem z testami jednostkowymi i integracyjnymi w czystej Javie. Groovy to jednak kolejny język do nauczenia. Pod tym względem Lombok jest przyjazny. Co innego jak ma się dream team ambitnych programistów, którzy sami sobie dobierają narzędzia.

0

Odpisałeś w sobotę o tej godzinie, powiedz mi czy czekasz na kolejny dzień pracy, chcesz podyskutować czy sie czegoś nauczyć ? Rozumiem ze nie miałeś okazji poznać spocka, ja tez nie , zanim nie poświęciłem kilku godzin żeby ogarnąć temat. Który ma znikomy próg wejścia, w ciągu 2lat wdrożyłem go w 3 projektach w żadnym wypadku nie pytając nikogo poza zespołem dev o zdanie ! Dlaczego ? Bo reszta nie powinna sie tym interesować - tu można dyskutować ze byc moze Management bedzie sie w przyszłości martwił ze braknie im ludzi znających to cos, ale nikt normalny nie wciska businessowi spcka tak jak i nie wciska scruma nazywając go w ten sposób.

0

prxeczytem twój dream team edit. Jesli rzeczywiście pracujesz w miejscach gdzie opisane tematy są problem to zmień prace, albo zastanów sie co zrobić żeby ułatwić prace sobie i reszcie. Nadal problemem nie są testy które dla mnie są podstawa oprogramowania, problemem jest podejście do ...wszystkiego wokoło tego tematu

0

Technologia ma znaczenie trzeciarzedne ? Są sytuacje w których można przeznac ci racje, ale "nowinki" nie sa po to żeby sobie były, po co używasz Lomboka, i kolejne pytanie czym wg ciebie różni sie lombok od kotlina ,
dziwne pytanie ale pewnie niektórzy zrozumieją co mam na myśli.

0

Dla mnie Lombok i Kotlin rozwiązują ten sam problem: ograniczają bolier-plate w stosunku do czystej Javy. Ostatnio zmieniałem pracę i od kilku miesięcy piszę w Lomboku i dostrzegam wartość dodaną (bardzo się ciesze, że trafiłem do takiego projektu, wcześniej pisałem w JEE). Na przykład bardzo podoba mi się, że zniknęło @Inject/@Autowired. Zostało zastąpione @RequiredArgsConstructor (prawie jak zwykłe new tylko mniej kodu, ale lepsze bo można łatwiej zmockować zależności lub testować integracyjnie: obydwa podejścia mają swoje zalety, przy czystym new pozostają testy integracyjne: jak jest dużo logiki / algorytmów warto też mieć jednostkowe). Jest to oczywiście obchodzenie ograniczeń Javy. Jak wiadomo konstuktor i DI wciąż są, ale są niewidoczne (podobnie jak akcesory). Pewną wartością dodaną z JUnit jest, że jest to oficjalny tool dołączony do Spring Boot wraz z Mockito, działa to sprawnie w testach integracyjnych (np. z MongoDB jako wbudowaną bazą). Można szybko i sprawnie pisać testy integracyjne z bazą testową taką samą jak produkcyjna.

Oczywiście zamierzam wypróbować Kotlina jako kolejny logiczny krok rozwoju zawodowego: może kiedyś będę mógł zaprponować takie rozwiązanie w nowym projekcie. Po prostu lepszy język. Przyjdzie na to czas. Wolałbym to jednak robić początkowo z JUnit, aby zachować kompatybilność z pakietem testowym dla Spring Boot. I tutaj chciałbym mieć dokładnie takiego samego buildera jak Lombokowy albo odpowiednik Kotlina.

Znalazłem coś takiego i póki co wydaje mi się znacznie lepszy lombokowy builder (może kiedyś zmienię zdanie):
https://kotlin.link/articles/DSL-builder-in-Kotlin.html

Myślę, że zaletą Kotlina jest zupełnie nowy design od podstaw po wielu latach obserwacji tego co jest słabe w Javie. Z drugiej strony uważam, że Lombokowy @Builder i @Value są świetne i nadają Javie drugą młodość. Logika funkcji to wciąż stara, dobra Java, znika tylko bolierplate.

Dodam, że nie używamy Lomboka w ciele metod. Kod funkcji to wciąż czysta Java, nie licząc buildera.

1 użytkowników online, w tym zalogowanych: 0, gości: 1