Hejt hejtem ale skoro Spring/Java EE to taki badziew to poproszę o informację na co warto zwrócić uwagę. Chętnie się dowiem.
- 1
- 2
0
Wielki Mleczarz napisał(a):
Hejt hejtem ale skoro Spring/Java EE to taki badziew to poproszę o informację na co warto zwrócić uwagę. Chętnie się dowiem.
Nikt nie hejtuje Javy, tylko wymienione zostały jej wady. Żadna technologia nie jest pozbawiona wad.
0
JavaFan napisał(a):
Wielki Mleczarz napisał(a):
Hejt hejtem ale skoro Spring/Java EE to taki badziew to poproszę o informację na co warto zwrócić uwagę. Chętnie się dowiem.
Nikt nie hejtuje Javy, tylko wymienione zostały jej wady. Żadna technologia nie jest pozbawiona wad.
Ale pare osob wymienia jak to w 2017 juz bedzie inaczej a Spring i Java EE to nowy Cobol.
To się pytam co jest 'normalne' teraz?
- Rejestracja:ponad 8 lat
- Ostatnio:około 3 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
1
Wielki Mleczarz napisał(a):
Ale pare osob wymienia jak to w 2017 juz bedzie inaczej a Spring i Java EE to nowy Cobol.
To się pytam co jest 'normalne' teraz?
Przelećmy po kolei:
| Aspekt | Niemodne | Modne w 2017 |
|---|---|---|
| baza danych SQL | JPA | JOOQ |
| trwałośc | bazy danych SQL | ES na Cassandra |
| rest/websocket | JAX-RS | SparkJava, Ratpack |
| transakcje | JTA /Spring-tx | całkiem niemodne |
| DI | CDI 2.0 | Java (słówko kluczowe new ) |
| Frontend | JSF | na pewno nie w Javie: (React + Redux) lub Angular 2 |
| messaging | JMS | kafka, rabbitmq, (formalnie passuje akka-actors - ale w javie się nie przyjmie) |
I mała uwaga - to tylko modne technologie i to nie wszystkie. Warto znać -co nie znaczy, że zasze warto stosować.
Będą jeszcze długo istniały nisze gdzie warto zastosować nawet JavaEE lub Spring i rózne inne dziwa (typu Vaadin na front).
Ale to raczej w takich sytuacjach:
- wasz team zna tylko tą technologię, a projekt krytyczny i nie można sobie pozwolić na uczenie sie,
- robicie obsługe garażu dla pana Stefana - i wtedy wiadomo, że JavaEE lub Spring starczy i nie będzie wam ciążył za kilka lat,
a za to jest dużo przykładów dokumentacji. Te nowe "modne" technologie nadal maja braki w dokumentacji i przykładach użycia.
Na pewno warto przemyśleć pchanie się w klasyczne JavaEE lub Spring jak:
robisz serwer dla dużej ilości klientów mobilnych ( tu naprawdę pojawiają się straszne problemy z wydajnością klasycznej architektury - zwłaszcza jak klienci mają być fancy i permamentnie bombardują serwer zapytaniami),
korzystasz z wielu zewnętrznych serwisow HTTP ( a nie tylko z jednej/twojej bazy danych),
edytowany 5x, ostatnio: jarekr000000
- Rejestracja:ponad 10 lat
- Ostatnio:5 miesięcy
- Lokalizacja:Warszawa
- Postów:3573
0
Spring to żaden cobol. To że ktoś tak napisal to nie znaczy że tak jest...
0
JOOQ ok, może być. Ale nie uważam by JPA było jakieś bardzo złe. Według mnie jedna z lepszych rzeczy w Java.
SparkJava, Ratpack - fajne, ale nie wygląda mi to na pełną odpowiedz dla Spring lub Java EE.
transakcje/DI - niech będzie
Frontend - oczywiście, że nie w Java
messaging - w sumie jest tego mnóstwo do wyboru
A czy mając np. spring boot... zyskujemy coś łącząc go z Ratpack ?
Java mimo wszystko patrzy bardziej na np. Microprofile czy coś w stylu KumuluzEE albo Netflix stack.
- Rejestracja:ponad 8 lat
- Ostatnio:około 3 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
0
Wielki Mleczarz napisał(a):
JOOQ ok, może być. Ale nie uważam by JPA było jakieś bardzo złe. Według mnie jedna z lepszych rzeczy w Java.
JPA jest OK jak się na nim znasz i programujesz SAM. W projektach zespołowych to strata czasu i nerwów. (Architektura typu pole minowe - jeden fałszywy ruch i nie masz nóg).
SparkJava, Ratpack - fajne, ale nie wygląda mi to na pełną odpowiedz dla Spring lub Java EE.
Dokładnie! I o to chodzi - mają tylko zastąpić budowanie REST i nie narzucać Ci frameworku.
A czy mając np. spring boot... zyskujemy coś łącząc go z Ratpack ?
Zysjkujemy? - nic. Tracimy natomiast możliwość robienia non blocking serwisów (jeśli Ci to akurat potrzebne (rzadko)).
edytowany 3x, ostatnio: jarekr000000
0
Znaczy sie uwazam, ze Ratpack czy SparkJava zalatwi mi jakies 80% tego co caly spring. Prawda a Bogiem... To wcale nie potrzebuje wielu tych ficzerow spring a idac w modularyzacje to moge sobie miec springowa appke po srodku a wokol np. Sparkjavy czy cokolwiek innego...
Oczywiscie wszystko z glowa. Ale by zrobic prostego CRUD nie widze sensu sie bawic w springa.
Ogolnie co by nie mowic ale JAX-RS i JPA sa calkiem udane ale i wysluzone.
Pytalem o Ratpack + Spring boot bo jak googlamy o ratpacku to zaraz mozna natrafic na integracje ze spring.
JOOQ - mialbys moze jakis wpis blogowy opisujacy to nieco +zalety tego rozwiazania? Ja sie chwile bawilem ale chetnie bym innym pokazal ;)
0
Teraz zaczął się hejt Cobola ;)
Tu: https://www.infoq.com/news/2016/09/java-ee-delayed-2017 piszą, że EE 8 wyjdzie nieco później niż zakładano.
Fajnie, że pociągnęliście wątek dalej - sporo ciekawych rzeczy się człowiek dowie.
- Rejestracja:ponad 8 lat
- Ostatnio:około 3 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
0
Wielki Mleczarz napisał(a):
JOOQ - mialbys moze jakis wpis blogowy opisujacy to nieco +zalety tego rozwiazania? Ja sie chwile bawilem ale chetnie bym innym pokazal ;)
Polecam wykłady (youtube) i blog Lukasa Edera (to autor JOOQ :-) ).
Mam małe doświadczenia z JOOQ (nawet mi się pare rzeczy nie spodobało :-) ). Ale ostatnio spotykam coraz więcej zadowolonych, a osobiście wiem, że JPA to droga do piekła.
Sam bawię się zupełnie innymi alternatywami, których czas jeszcze nie nadszedł (w IT idzie wszystko powoli :-) ).
edytowany 1x, ostatnio: jarekr000000
- Rejestracja:prawie 9 lat
- Ostatnio:5 miesięcy
- Lokalizacja:Futurama
- Postów:887
0
Tutaj takie pytanie trochę wyrwane z kontekstu: czy JEE i Springa można użyc do desktopu (i jeżeli tak to do czego można by to wykorzystać) ? Wiem, co się mówi o desktopie dżawie (chociażby dzięki założonemu przeze mnie wątkowi), jednakże ciekawi mnie to.
- Rejestracja:ponad 8 lat
- Ostatnio:około 3 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
0
Burdzi0 napisał(a):
Tutaj takie pytanie trochę wyrwane z kontekstu: czy JEE i Springa można użyc do desktopu (i jeżeli tak to do czego można by to wykorzystać) ? Wiem, co się mówi o desktopie dżawie (chociażby dzięki założonemu przeze mnie wątkowi), jednakże ciekawi mnie to.
Dawno temu używałem EJB do remotingu client (Swing) i server. Całkiem nawet OK (może dlatego, że to akurat jedna z tych rzeczy do których EJB stworzono...).
- Rejestracja:ponad 13 lat
- Ostatnio:prawie 3 lata
0
Burdzi0 napisał(a):
Tutaj takie pytanie trochę wyrwane z kontekstu: czy JEE i Springa można użyc do desktopu (i jeżeli tak to do czego można by to wykorzystać) ? Wiem, co się mówi o desktopie dżawie (chociażby dzięki założonemu przeze mnie wątkowi), jednakże ciekawi mnie to.
Tak do końca nie wierz temu co się mówi o desktopowej Javie.
Jakiś czas temu robiłem statystyki w czym są robione aplikacje na portalach typu Softpedia i co ciekawe było parę aplikacji zrobionych w Javie:
- BuzzBundle
- Visual Paradigm for UML, DBVisualizer, Netbeans, ArgoUML, SeqMonk, InfoScope, Seneca, Cytoscape,
- CLC Sequence Viewer, Gitools, DanCalculator, Open Source Physics, EJS Neuro Launcher,
- Fibanacci Sphere
- IntelliJ IDEA? (*)
Ogólnie to raczej cały rynek aplikacji desktopowych leży, bo 100 razy wygodniej dla firmy używać aplikacji webowej niż desktopowej, zwłaszcza jeśli masz więcej niż 4 pracowników.
Ale to nie znaczy że takie aplikacje nie powstają.
Tyle że aplikacje desktop w Javie to raczej specyficzny rynek - wziąwszy pod uwagę, że można je łatwo zdekompilować.
Z aplikacjami desktopowymi widziałem przykłady dla interfejsów bazodanowych (Hibernate, JPA, JDBC).
Można też użyć jakiegoś DI (np. CDI): https://blog.frankel.ch/lessons-learned-from-cdi-in-swing/
(*) Aktualnie się zapoznaję z tym IDE. Działa tak szybko że mam wątpliwości czy to Java ;-)
edytowany 1x, ostatnio: vpiotr
- Rejestracja:ponad 8 lat
- Ostatnio:około 3 godziny
- Lokalizacja:U krasnoludów - pod górą
- Postów:4707
0
vpiotr napisał(a):
(*) Aktualnie się zapoznaję z tym IDE. Działa tak szybko że mam wątpliwości czy to Java ;-)
Swing. Działa szybko i jest to normalne. Tylko trzeba poczytac jak działa i się nauczyć (wątek UI!) - a potem jeszcze poprofilować pod kątem GC.
Niestety prawie nikomu się nie chce.
0
Ale Swing to staroć, zastąpiła go przecież JavaFX... Chociaż spotkałem się z wypowiedziami, że JavaFX zdycha powoli...
( tu jest dość ciekawy wątek na temat Swinga, Javy FX i HTML5 - https://jaxenter.com/javafx-compared-to-other-ui-toolkits-like-swing-html5-and-swt-a-resume-124484.html )
Co do appek desktopowych jest trochę tego w Javie, aczkolwiek chyba najwięcej jest w C++ zrobionych, ew. C#.
Z punktu widzenia dev-a aplikacje www są lepsze, ale jeśli chodzi o użytkownika to nie za bardzo.
0
jarekr000000 napisał(a):
Sam bawię się zupełnie innymi alternatywami, których czas jeszcze nie nadszedł (w IT idzie wszystko powoli :-) ).
querydsl? mybatis? jdbi?
jarekr000000
#NoDB
0
Probowal ktos https://github.com/spotify/apollo ?
- Rejestracja:prawie 10 lat
- Ostatnio:prawie 6 lat
0
jarekr000000 napisał(a):
Dawno temu używałem EJB do remotingu client (Swing) i server. Całkiem nawet OK (może dlatego, że to akurat jedna z tych rzeczy do których EJB stworzono...).
Hmm.. dla mnie remoting binarny to się wydaje jednak przekombinowany. W końcu web services są prostsze, jedyna wada to brak obsługi transakcji których w 98% przypadków nie potrzebujemy (2PC). Nawet mega entuzjasta JEE Adam Bien twierdzi, że w nowoczesnych aplikacjach (w tym nieblokujących) w JEE REST rozwiązuje remoting, a zdalne EJB są deprecated.
Od servlet 3.1 mamy nieblokujące we-wy (za sprawą NIO2 w JDK, które używa chociażby Vert.x), czyli są zabawki jak np. EventSource: będzie w JEE 8, już jest od dawna jako dodatek od Jersey. Jestem skłonny dalej bronić platformy JEE jako good enough. Wydaje mi się, że wszystkie frameworki mają generalnie podobne możliwości.
Co mnie martwi w nowych zabawkach (nie Spring i nie JEE) to kwestia zagrożenia finansowania. Może się zdarzyć, że opierając swój soft na czymś nowoczesnym za 5-8 lat zostaniemy bez supportu i będziemy musieli forkować framework: komu się chce. A stary dobry COBOL będzie dawał radę.
Poza tym super modna ostatnio (za sprawą Node.JS) komunikacja nieblokująca nie wszędzie się sprawdza np. przy streamingu lepiej działać blokująco. Chyba wszystko zależy od wymagań aplikacji.
Problemem JEE jest powolność w adaptacji rozwiązań. Ale pojawiła się nadzieja za sprawą firmy C2B2 Consulting: fork GlassFisha payara, który dodatkowo wprowadza innowacje, których nie ma w standardzie. Oracle nie dał zabić JEE, a było bardzo blisko. Poza tym nic nie przeszkadza na serwerze aplikacyjnym używać np. jOOQ zamiast JPA. Jak komercyjnie wspierana Payara od premiery będzie oferować płatny support do JEE 8 i 9 (zaraz po sobie wydadzą) to będzie dobrze.
edytowany 4x, ostatnio: margor90
@margor90 podsumowując - remoting na HTTP, transakcji (zwłaszcza 2PC) nie używamy, wywal jeszcze bazę danych SQL i zostajesz z platformą, która owszem działa, ale wporównaniu z gołą Javą tylko Ci przeszkadza i której większość kodu wspiera rzeczy Ci niepotrzebne (a stacktrace to widzi :-)). Pare lat temu się pomiarkowałem, że tak mam i po prostu zacząłem wyłączać te JBOSSy i Glassfishe (a w pracy mam nadal Webświra, który jest najgorszy z bandy i nie daje się tak łatwo ubić (powiedzcie chociaż zdalnie - "współczujemy")).
@jarekr000000 a dlaczego Twoim zdaniem warto odejść od SQL i bez relacyjnych? IMO SQL i RDBMS to jeden z najelegantszych i efektywnych wynalazków. Czy robiliście takie rzeczy produkcyjnie i było lepiej? Widziałem Twoją prezentację: używać jak najwięcej RAM i CPU i functional programming. Ale w aplikacjach biznesowych to ma chyba umiarkowane zastosowanie? Od WebSphere jest jeszcze jeden gorszy wynalazek: SAP NetWeaver od lat niezmienny na EJB 3.0 mimo zgodności z JDK 1.8. Ale takie AS służą chyba bardziej jako middleware (ESB/integracja) niż AS.
Wiem, że niektórzy używają np. MongoDB bo nie potrzebują transakcji. I mają minimalnie szybszy odczyt. Ale nie jest to żaden hype.
Pisząc wyże (post)j miałem na myśli, ze nie potrzebujemy zbyt często transakcji rozproszonych (wystarczyła kolejka do komunikacji HTTP). Ale jak pisałem aplikację na potrzeby księgowości to używałem i @stateless było super rozwiązaniem.
@margor90 w jednym się zgadzam SQL i RDBMS to bardzo elegecnkie wynalazki. Jak potrzebujesz ad hoc raporty z dużej ilości danych super. Są za to zupełnie durne jako persistence do aplikacji biznesowych - po prostu bezsensowna kopanina z koniem. Jak piszesz aplikację tabelkową, która ma być biedna od początku do końca - to owszew to i stateless i JPA się sprawdza.
Ok, ale abstrahując od raportowania. Jak nie RDBMS i SQL/ORM (inny niż JPA bo to paskudztwo) jako persistence do aplikacji biznesowych to co Twoim zdaniem warto użyć w roku 2016? Chyba jeszcze za wcześnie na trzymanie całej aplikacji i danych w RAM: chyba serializacja byłaby niewygodna (ale mogę nie rozumieć).
@margor90 - ta zabawa z ram (a tak naprawdę z ES na dysku) jest całkiem fajna (ale raczej na start i rapid development). Potem (jak się projekt rozrośnie) można się przesiąśc na full CQRS oparty o akka persistence albo Lagom. Serializacja binarna jest jest tylko nieco bardziej niewygodna niż do tabelek. (Przy wiekszej migracji ta sama kupa i bez stop the world - jest ciężko duży update zrobić).
Lagom raczej ląduje na mojej liście technologii do opanowania obok Vert.X i Kotlina.
ja mam wrażenie, że ludzie się wycofują z Vert.x ale może mi się wydaje ;)
Znam osobiście jedno korpo, które używa vert.x i jedną małą firmę. Nie słyszałem, aby ktoś używał Lagoma. Inne produkty od Typesafe bazujące na Scali już prędzej.
- 1
- 2