java 9 co dalej?

Jak Java jest wypierana przez C#? Gdy C# notuje spadek a Java wzrost?
http://www.tiobe.com/tiobe-index/

A spring boot niby fajny ale swoje wady też ma.

azalut napisał(a):

bo są bdb zintegrowane - bo tworzone "wspólnie"(...)

Taa, wspólnie ;) JEE to zbiór średnio-pointegrowanych niezależnych frameworków sprzedawanych pod wspólną nazwą

@Zimny Lew
chyba nie próbujesz mi powiedzieć, że poszczególne części JEE się ze sobą cieżko integrują?

@vpiotr

C# nie ma szansy zastąpić Javy bo jest jeszcze bardziej produktem jednego producenta...

Ale projekt .NET Core ma szansę bo przynajmniej oficjalnie ma być to rozwiązanie open source nad którym będą "czuwać" różne firmy. Na blogu Microsoftu widziałem ostatnio, że dołączył do nich Samsung więc zapowiada się ciekawie. Ale to dopiero 1.0 więc minie kilka lat zanim będzie można tego użyć do poważnego projektu co nie zmienia faktu że na naszych oczach wyrasta zdecydowana alternatywa dla Javy.

Ile to razy czytałem nawet na tym forum "Gdyby C# nie był tylko Windows-only używałbym go zamiast Javy bo lepiej zaprojektowany, łatwiejszy w użyciu, bo LINQ i w ogóle jakiś taki "fajniejszy"....". Teraz będzie to możliwe.

nie będzie zastepcy
będa systemy zbudowane z mikroserwisów i każdy będzie klepał w czym będzie chciał byleby sie zmiescił w czasie odp 200ms :D

Według mnie musiałoby powstac cos nowego, który będzie alternatywą zarówno dla Javy EE i C#.

W którymś z postów pojawiła się teza, że Java EE przestaje być opłacalna dla Oracle. Dlaczego? Czy ktoś może to tutaj uzasadnić?

@Desu @azalut
Obecnie pracuję właśnie w banku i nasz system mikroserwisów jest oparty na różnych bibliotekach i komponentach. Są w nim na przykład:

• Akka jako podstawa,
• Lift framework, którego chciałbym się pozbyć i wstawić coś co trzyma stan klienta po stronie klienta,
• Lift mapper/ Slick - tutaj pasuje zmigrować na Slicka w całości zwłaszcza, że Slick w wersji 3.2 ma sterowniki do Oracle oficjalnie za darmo,
• Scalaz - goście z początkowego zespołu lubili sobie poprogramować mocno funkcyjnie (efektem jest np https://github.com/lancewalton/treelog ),
• Bootstrap i jQuery z poziomu Lifta (czyli kodu Scalowego),
• Apache Kafka,
• Apache ActiveMQ,
• Selenium w testach akceptacyjnych,
• Oracle na serwerach, H2 w testach,
• itd

kolo625 napisał(a):

W którymś z postów pojawiła się teza, że Java EE przestaje być opłacalna dla Oracle. Dlaczego? Czy ktoś może to tutaj uzasadnić?

Może Weblogic słabo się sprzedaje :p

Vendors have a conflict of interest when it comes to standardization. For vendors, standardization is a two-edged sword. On the one hand, standardization is attractive because it makes it easier to sell the technology. On the other hand, too much standardization is seen as detrimental because vendors want to keep control over the features that distinguish their product from the competition.

http://queue.acm.org/detail.cfm?id=1142044

krzysiek050 napisał(a):

Java to nie tylko applety. Właściwie to była pomyłka, nikt tego nie używa, no chyba że do stworzenia artykułów z statystykiami jaka to Java jest dziurawa.
Java na razie nie przestanie być rozwijana, bo jest zbyt silnym graczem na rynku. Jak usuną applety to większość nawet nie zauważy.

Przepraszam, czat wp ciągłe używa i ciągle to jest jedyny sposób na dostanie się do ich czata. Nawet aplikacji na Androida nie mają

@kolo625, JavaEE to nie tylko WebLogic, ale po stronie Oracle przede wszystkim ludzie, którzy pracują nad standardami, robią badania, opracowują specki. To są koszty i to poważne. http://arstechnica.com/information-technology/2016/07/how-oracles-business-as-usual-is-threatening-to-kill-java/ Co prawda było sprostowanie od Oracle, gdzie spółka zapowiedziała kontynuację prac nad JEE, ale zapewne zmieni się forma procesu.

Warto tu wspomnieć, że JavaEE od samego początku miała dużego pecha, bo poza potwornie zj#@$@# architekturą pierwszych wersji, był też problem ze sprzedażą tego rozwiązania. Sytuacja uległa zmianie, gdy całkowicie otworzono JEE na potrzeby tworzenia własnych implementacji przez firmy inne niż Sun.

@Koziołek,

to co się stanie jak Oracla przestanie rozwijać jave ee? czy jak przestanie rozwijać jave ee to również przestanie rozwijać jave se? Wszyscy będziemy musieli przeżucić się na C# :(?

Javy SE, a dokładniej platformy JVM to tak szybko nie przestanie rozwijać. To co zrobi z JEE jest wielką tajemnicą, ale można spróbować zgadnąć:

• Java EE 8 będzie ostatnią Javą EE. Późniejsze wersje już nie powstaną.
• Jako że Java 9 ma wspierać moduły to Java EE 9 będzie "lekką" specyfikacją opisującą tylko zasady modularyzacji specyficzne dla platformy EE (minimalne wymagania). Coś w rodzaju profili, ale na bazie mechanizmu modułów.
• Java EE 9 będzie "kiedyś w przyszłości", bez jakiś konkretnych dat i deklaracji.

@Koziołek,

a myślisz, że jak przestaną rozwijać jave EE to java z tymi jej frameworkami takimi jak spring da sobie radę?

W ogóle to dlaczego ta technologia się tak słabo sprzedaje? Rozumiem, że Microsoft ze swoim C# nie narzeka, bo nadal kładą $ w rozwijanie tego framworka asp.net To w czym to jest lepsze?

Java EE w ogóle się nie sprzedaje. Specyfikacja jest otwarta. Jednak jej utrzymanie kosztuje. Sprzedają się rozwiązania w rodzaju WebLogica, ale tu jest silna konkurencja.

Co do frameworków to nie one są problemem. JEE to też tylko ulepek specyfikacji :) Problematyczne może być standaryzowanie pewnych rozwiązań. Jak by nie patrzeć Spring korzysta ze standardowych elementów JEE (przynajmniej kiedyś ostro i jawnie korzystał).

Zimny Młot napisał(a):

W ogóle to dlaczego ta technologia się tak słabo sprzedaje? Rozumiem, że Microsoft ze swoim C# nie narzeka, bo nadal kładą $ w rozwijanie tego framworka asp.net To w czym to jest lepsze?

Bo niektóre implementacje Javy EE to jest pain in the ass. Porównaj choćby "surowy" kod Javy i Hibernate, żeby wyciągnąć coś z DB. W Hibernate to zajmie 5x mniej kodu niż w Javie.
Mi się wydaje, że tylko niektóre paczki z Javy EE przestaną być rozwijane, a nie że całą technologię porzucą. Strzeliliby sobie w kolano takim zagraniem.

Biały Mleczarz napisał(a):

Bo niektóre implementacje Javy EE to jest pain in the ass. Porównaj choćby "surowy" kod Javy i Hibernate, żeby wyciągnąć coś z DB.

A jak to wygląda w surowym C#?

Bo niektóre implementacje Javy EE to jest pain in the ass. Porównaj choćby "surowy" kod Javy i Hibernate, żeby wyciągnąć coś z DB. W Hibernate to zajmie 5x mniej kodu niż w Javie.

Jestem daleki od tego typu ocen... szczególnie, że w Javie możesz użyć "normy" w rodzaju JPA, której jedną z implementacji jest Hibernate.

Specyfikacja JEE na pewno nie padnie. Inne firmy wezmą się za standaryzację. Im mniej Oracle tym lepiej. Koszty standaryzacji nie są tak wysokie, ponieważ to nie R&D, Tu nie ma nic innowacyjnego. Wystarczy zebrać dobre, powszechnie używane praktyki. Gdy specyfikacja padnie powstanie wieża babel. Będzie trudniej programować na różne serwery aplikacyjne. Taki JBoss będzie wtedy kolejnym Springiem. Albo Red Hat stworzy własną specyfikację JEE2 i wypną się na Oracle. Ja totalnie nie widzę po co do tworzenia JEE potrzebny jest jakiś Oracle skoro Springa daje radę pisać 1 firma.

Poza tym wielkim beneficjentem istnienia JEE jest sam Spring.

Co innego koszt rozwijania serwerów aplikacyjnych. To jest konkretna kasa. Tyle, że GlassFisha wzięła Payara. I prawde mówiąc efekty są niezłe.

@Wibowit
w banku? taki stack? banku krwi? spermy? :D scala? bank? coś mi sie ostro nie zgadza, ale szczerze gratuluje ;)
duży w tym projekt jest? czy to jakiś mniejszy microservice?

btw fajnie sie slicka uzywa?

odnosnie tematu: wierzyc mi sie nie chce ze JEE mogłoby przestać być rozwijane a jedynie utrzymywane, a po latach zapomniane i utrzymywane jak COBOL
ok wspominacie o C# i .NETcie ale co oprócz tego? microsoft nie wygrał świata telefonów to wygra świat webapplikacji? eee

trudno się nie zgodzić, że mamy bardzo wiele ciekawych języków, każdy z nich ma równie wiele fajnych frameworków: Akki, Playe, Slicki, Squeryl, Spark - ale to jednak nie jest to samo co JEE jako pełen zestaw narzędzi. te frameworki klada nacisk na konkretny temat, wspolbieżnosc, front-end, data-processing itp
powoli zaczynam wierzyć w to co napisałem wcześniej jako pół żarcik - teamy będą komponowane w różnych technologiach a cały system bedzie gadał w czyms technology-independent, a nad wszystkim bedzie czuwał jeden, dobry orchestrator naklepany jeszcze w JEE albo C# :D

Normalny duży bank. Trochę szczegółów jest tutaj: https://www.linkedin.com/in/channingwalton (OTC Client Clearing) A tutaj: https://skillsmatter.com/skillscasts/5836-fun-and-profit-within-the-evil-empire-scala-in-finance jest filmik innych ziomków (których zdążyłem poznać w przeciwieństwie do Waltona). Projekt zaczynał w Londynie, więc obecność Scali powinna być mniej zaskakująca - rynek programistów Scali w Londynie jest dość spory, więc tam pracodawcy nie mają obaw, że im się zespół rozsypie i nie będą mieli kogo zatrudnić.

Slicka jest niewiele w obecnym projekcie, niestety znacznie więcej jest Lift mappera. Ze Slickiem miałem więcej doświadczenia w VirtusLabie i było spoko. Na pewno nie chciałbym babrać się z żadnym ORMem.

trudno się nie zgodzić, że mamy bardzo wiele ciekawych języków, każdy z nich ma równie wiele fajnych frameworków: Akki, Playe, Slicki, Squeryl, Spark - ale to jednak nie jest to samo co JEE jako pełen zestaw narzędzi. te frameworki klada nacisk na konkretny temat, wspolbieżnosc, front-end, data-processing itp
powoli zaczynam wierzyć w to co napisałem wcześniej jako pół żarcik - teamy będą komponowane w różnych technologiach a cały system bedzie gadał w czyms technology-independent, a nad wszystkim bedzie czuwał jeden, dobry orchestrator naklepany jeszcze w JEE albo C#

W IT świętym Graalem jest właśnie komponowalność, a nie wielkie i silnie wewnętrznie powiązane kobyły. Przez to, że mamy wielkie kobyły to ciężko projekty integrować z innymi i stopniowo unowocześniać. Idealnie byłoby mieć całkowicie niezależne biblioteki służące do różnych celów i prosto je integrować. Scalowy ekosystem idzie właśnie w tym kierunku.

Scala i banki to wlasnie idealne polaczenie.

Moim zdaniem jakby nie mili zamiaru rozwijać Javy EE to by nie wypuszczali kolejnej wersji. Muszą mieć w tym interes, bo przy tak grubej inwestycji nie ma sentymentów. Po drugie jakby to wyglądało? Mają system i nagle przestają go wspierać? To by inne firmy zaczęły się bać coś kupować od nich, bo mogłoby się okazać, że nagle zniknie wsparcie dla jakiegoś produktu. Wydaje mi się, że raczej będą dążyć do tego aby ta Java EE z wersji na wersję była coraz lepsza...

Nastąpi wielka era w JS.
Wszystko będziemy pisać w JS.

Drżyjcie!

W takim razie chyba logicznym pytaniem jest czy warto zaczynać naukę JEE? Czy skupić się na czymś bardziej przyszłościowym?

Burdzi0 napisał(a):

W takim razie chyba logicznym pytaniem jest czy warto zaczynać naukę JEE? Czy skupić się na czymś bardziej przyszłościowym?

Obecnie najlepiej umiec elementy JEE i Springa jednoczesnie. Jesli o jave chodzi.

@Burdzi0 to nie "umrze" (jeśli w ogóle) przez długie lata, nawet projektów robionych na JEE7 jest sporo, JEE8 tez bedzie sporo, dalej będzie rozwój + maintanance
wciąz utrzymuje sie hype na jave, wiec jesli chcesz w niej pracowac to się ucz.
nawet jesli to ma zamiar umrzec za x lat to zdarzysz sie o tym pewnie przekonać jeśli śledzisz temat i w domowym zaciszu nauczyć czegoś fancy jak kotlin, scala, node albo inne :P

Burdzi0 napisał(a)

W takim razie chyba logicznym pytaniem jest czy warto zaczynać naukę JEE? Czy skupić się na czymś bardziej przyszłościowym?

Tak warto, ponieważ jeszcze przez wiele lat będziesz miał zajęcie. Pytanie, co jest bardziej przyszłościowe? IMO, trzeba na nowe technologie patrzeć uważnie, ale nie można przepowiedzieć, co będzie przydatne, za dajmy na to 5 lat.

ps. https://www.thoughtworks.com/radar

jak 4fun to tylko node.js