java 9 co dalej?

Planowana data wydania java 9 to 22 wrzesnia 2016. Czy ta data jest dalej aktualna? Bo w necie można znaleźć jakieś plotki na temat zakończenia rozwijania dalszej javy przez oracle i usunięcie wtyczek z przeglądarek internetowych w celu odejścia od flasha.

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.

Jedyne plotki jakie słyszałem dotyczyły Javy EE, a nie Javy jako takiej.

Co byście w takim razie radzili początkującemu/średnio zaawansowanemu programiście Javy? Może przejście na C++ (xD)?

Java 9 to jak na razie marzec 2017, a nie wrzesień 2016 > http://www.java9countdown.xyz/
22 września to data przyklepania JSRa dla JEE8. Implementacja będzie trochę później. Przy czym trochę to raczej tygodnie/miesiące, a nie lata.

Czy Java EE umiera? Tak. W obecnej formie jest ona nieopłacalna dla Oracle i zostanie zapewne zaorana.
Czy Java jako taka umiera? Prawdopodobne, ale też nie słychać, żeby Oracle chciało zmieniać architekturę i tworzyć Javę 2, która była by zupełnie innym językiem.

Niby umiera, ale trudno znalezc jakas sensowna alternatywe, na razie.

Gdy mowa o Microservices to trochę mówi się, że JEE radzi sobie lepiej niż Spring.
Ale według mnie jeśli nie Spring to Java EE.

• do mniejszych rozwiązań pewnie Node.Js itp.

Należy rozróżniać: Javę jako język, Javę EE jako stack technologiczny i wirtualną maszynę javy (JVM). Ta pierwsza ma już fajnych następców, to drugie niemal też, a trzecie to raczej kombajn, który na emeryturę prędko się nie wybiera.

datdata napisał(a):

Należy rozróżniać: Javę jako język, Javę EE jako stack technologiczny i wirtualną maszynę javy (JVM). Ta pierwsza ma już fajnych następców, to drugie niemal też, a trzecie to raczej kombajn, który na emeryturę prędko się nie wybiera.

Prawda ale ewentualni następcy Javy EE i JVM mogą być bardzo interesujący.

Myślicie, że możliwe jest, aby powstała jakaś nowa VM do nowych języków niedługo?

Java + Spring Mvc + Hibernate to chyba najbezpieczniejszy wybór. Spring Mvc jest popularny, "niskopoziomowy" (blisko HTTP, servletów), więc jest w miarę prosty i niewiele ryzykujesz ucząc się tego, a wiedza będzie uniwersalna. Hibernate(/JPA) to praktycznie standard. Java może i ma swoje wady ale to nie powód żeby ryzykować z nauką nowych wynalazków.
.Net Core jest fajny, ale jeszcze bardzo młody (to zależy od pisanej aplikacji, bo np czemu w tym nie zrobić jakiegoś startupu). Ja na pewno wolałbym .Net Core niż jakikolwiek język skryptowy/interpretowany ze względu na statyczne/silne typowanie.

Burdzi0 napisał(a):

Myślicie, że możliwe jest, aby powstała jakaś nowa VM do nowych języków niedługo?

Powstaje coś takiego jak Graal, chyba nawet będzie w Java9, ale do końca nie wiem jak to działa =P

Programiści VM cały czas coś dostrajają i zmieniają, raczej spodziewałbym się implementacji kolejnego języka na JVM, choć będzie ciężko, bo obecne języki mają silną pozycję na rynku.
Od 9 ma być wprowadzone coś takiego jak value types co jest ciekawą opcją, bo zmniejszy żarłoczność kolekcji.

Ja to czekam na nową odsłonę Nashorn'a, bo obecna jest zgodna z ECMAScript 5.1 a już wyszła wersja 7.0

Powracacie do tej dyskusji http://4programmers.net/Forum/Off-Topic/273260-oracle_nie_docenia_java_ee

Nie wierzę, że pozycja języków Java / C# w korpo jest zagrożona. Równie dobrze można napisać, że SQL umiera, bo teraz modne są bazy nierelacyjne. Będzie jak z COBOLem do usranego końca cywilizacji ktoś w tym będzie dłubał. Można JEE nie znosić, ale nie wierzę w śmierć platformy: za duży biznes na sprzedaży serwerów aplikacyjnych. Nawet gdyby platforma z wersji na wersję była coraz słabsza ma taką pozycję marketingową, że na obecnym etapie nie da się już tego zabić. Tendencja jest odwrotna, z wersji na wersje w JEE pisze się coraz łatwiej. Oracle nie dał rady ubić GlassFisha więc na pewno nie da rady uwalić całej platormy JEE. Zwłaszcza, że potrzebuje WebLogica, aby sprzedawać różne swoje produkty, które znacznie bardziej pasują do biznesu tej firmy niż samo JEE, które jest sobie gdzieś tam z boku.

Spodziewam się wzrostu popularności języków spoza JVM jak Go, Rust, ale w startupach. Co ciekawe, znam startupy preferują JEE nad Springiem, aby klepnąć coś "na szybko" na froncie jest Angular.

Ogólnie jak wiadomo co nas najbardziej irytuje to pauzy garbage collectora. C# i Java mają to rozwiązanie, więc naturalne wydaje się powstanie języka kompilowanego (nie jakiś tam intepretowany byte-code i JIT) w którym się szybko pisze znacznie łatwiejszego niż C++: omijamy problem pauz przez nie korzystanie z GC. Język ten powinien być prosty i elegancki jak C# lub Kotlin. Java jest brzydka, ale właściwie kogo to obchodzi.

Ktoś tu chyba ma nieaktualne dane:

• aplety Javy wymarły razem z dinozaurami - wycięcie obsługi apletów Javy jest jak zerwanie kompatybilności z ZX Spectrum,
• JDK 9 ma ustalony harmonogram http://openjdk.java.net/projects/jdk9/ i można sobie ściągać kolejne buildy na bieżąco: https://jdk9.java.net/
• Oracle ma plany wobec JavyEE 8 i nie jest to jej zakopanie:

http://www.infoworld.com/article/3098007/java/oracle-to-reboot-java-ee-for-the-cloud.html

While Oracle plans to publicly introduce its updated Java EE strategy at the JavaOne conference in San Francisco in late September, Kurian offered several significant details about where Java EE is headed.

“Oracle has a very clear plan for Java EE 8,” Kurian said. This plan, Kurian explained, will move Java EE into modern computing realms, specifically the cloud.

We wrześniu ma być zaprezentowane oficjalne stanowisko Oracle'a, więc nie ma co robić sraczki już teraz.

margor90 napisał(a):

Ogólnie jak wiadomo co nas najbardziej irytuje to pauzy garbage collectora. C# i Java mają to rozwiązanie, więc naturalne wydaje się powstanie języka kompilowanego (nie jakiś tam intepretowany byte-code i JIT) w którym się szybko pisze znacznie łatwiejszego niż C++: omijamy problem pauz przez nie korzystanie z GC. Język ten powinien być prosty i elegancki jak C# lub Kotlin. Java jest brzydka, ale właściwie kogo to obchodzi.

Dziwne mam odczucia do tego co napisałeś.
Java to jest właśnie rozwiązanie, żeby pisać łatwiej niż w C++, nie martwić się memory leakami, ani przypisywaniem pamięci i związanym z tym debugowaniem. Te 4 sprawy są załatwione za jednym zamachem i tym Java zaskarbiła sobie całe zastępy programistów, bo średnio zwiększyła wydajność pracy o 50%. Mam tu na myśli samą pracochłonność, a nie wydajność danej aplikacji.
Przy obecnych rozwiązaniach hardware'owych jakiekolwiek pauzy wynikające z GC to jest czas marginalny. Chyba, że jest jakaś specyficzna architektura aplikacji o bardzo wyśrubowanych warunkach pracy, to wtedy może to być kłopot.

@Duży Terrorysta: Nie twierdze, że C++ to narzędzie godne XXI wieku i gdzie mogę preferuję Jave (bo za dużo kompilatorów i każdy ze sobą niezgodny). Nie przeczę też sukcesowi Javy, w której klepie zarabiając na chleb. Małe sterty to małe pauzy. Bardziej chodzi mi o to, że naturalną potrzebą do pisania wydajnych softów prościej może być po prostu nie używać GC niż na siłę go stroić.

Może racja i prościej klepać dalej Jave i używać jakiś HeapOff w rzadkich fragmentach, gdzie nie chcemy GC czy coś w tym stylu pytanie czy ktoś to standaryzuje. I tak uważam, że jest potrzebny następca C++.

margor90 napisał(a):

(...)
Spodziewam się wzrostu popularności języków spoza JVM jak Go, Rust, ale w startupach. Co ciekawe, znam startupy preferują JEE nad Springiem, aby klepnąć coś "na szybko" na froncie jest Angular.
(...)

To by było piękne móc porzucić wirtualne maszyny, interpretery, garbage collectory i wrócić do pisania natywnych aplikacji. Przyznaję, że jestem podatny na hype Rusta :p

Może racja i prościej klepać dalej Jave i używać jakiś HeapOff w rzadkich fragmentach, gdzie nie chcemy GC czy coś w tym stylu pytanie czy ktoś to standaryzuje

OpenHFT? ;)

a co wg was ma być tym zastępującym JEE? bo rozumiem, że nie spring, a nic podobnego mi nie przychodzi do głowy z ekosystemu np scali
bo jesli JEE ma "umrzec" to Java podupadnie, zostają inne jezyki
C#? ale chcemy linuxy bez żadnych mono.. to python z.. czymś?

no ja powiem ze do JEE to nie widze zamiennika na tę chwilę

azalut napisał(a):

a co wg was ma być tym zastępującym JEE? bo rozumiem, że nie spring, a nic podobnego mi nie przychodzi do głowy z ekosystemu np scali
bo jesli JEE ma "umrzec" to Java podupadnie, zostają inne jezyki
C#? python z.. czymś?

no ja powiem ze do JEE to nie widze zamiennika na tę chwilę

Też na chwilę obecną nie widzę.
Ja bym w ogole traktowal Spring/JEE jako jedno. Wtedy to jest gigant.
dot.net to ostatnio stracił, ale czy to jest rozwiązanie tak różne od JEE? Czy to znowu nie jest trochę to samo?

Jest Play Framework i Akka ze Scali ale śmiem twierdzić, ze to co jest obecnie w javie jest wygodniejsze i bardziej kompatybilne wstecz.

.NET różny od JEE nie jest, choć ja sie tam nie znam na nim, ale nie widze .NETu na tych klastrach linuxowych

co do akki i playa - same w sobie sa świetne, ale nie jest to tak spójne jak w przypadku JEE czy springa.. gdzie tego drugiego ztcw można uzywac swobodnie za pomocą scali tak jak i javy - ale przydałoby sie wyciagnac max z danego jezyka, a nie tylko podmienić

JEE i Spring to po prostu gotowe środowiska, a AKKA czy play to tylko urywki, tu jakies aktory, niby na wielu klastrach, skalowalne, ale z playem to nie "jednosc", a jedynie "dobra integracja"

Nie no co to w ogóle za porównanie. Play to framework webowy, akka to framework do współbieżności, ale jak sie to ma do Springa czy JEE? Jasne, i jedno i drugie ma też swoje frameworki webowe na przykład, ale to jest mały fragment funkcjonalności. To trochę tak jakby porównywać samochód osobowy z fotelem i zastanawiać się czy ten fotel może zastąpić samochód, bo jest wygodniejszy niż fotele w samochodzie :D

Shalom napisał(a):

Nie no co to w ogóle za porównanie. Play to framework webowy, akka to framework do współbieżności, ale jak sie to ma do Springa czy JEE? Jasne, i jedno i drugie ma też swoje frameworki webowe na przykład, ale to jest mały fragment funkcjonalności. To trochę tak jakby porównywać samochód osobowy z fotelem i zastanawiać się czy ten fotel może zastąpić samochód, bo jest wygodniejszy niż fotele w samochodzie :D

Prawda. Ale to tylko potwierdza, że brak odpowiednika w takiej Scali.

A musi być? W Scali powstało wiele aplikacji webowych, które nie stoją na JavieEE czy Springu. Po co koniecznie pakować się w te kobyły?

Ze springiem mozesz zaciagnac jakie chcesz moduly.

@Wibowit
bo są bdb zintegrowane - bo tworzone "wspólnie"
a z doswiadczenia wiem i ty pewnie też, że integracja zupełnie niezależnych bibliotek często potrafi byc problematyczna nawet w prostym hello worldzie, a co dopiero w systemie bankowym itd

@margor90
tylko czy .Net to jest faktyczna alternatywa czy raczej to samo ale od innej firmy...

Ogólnie jak wiadomo co nas najbardziej irytuje to pauzy garbage collectora. C# i Java mają to rozwiązanie, więc naturalne wydaje się powstanie języka kompilowanego (nie jakiś tam intepretowany byte-code i JIT) w którym się szybko pisze znacznie łatwiejszego niż C++: omijamy problem pauz przez nie korzystanie z GC. Język ten powinien być prosty i elegancki jak C# lub Kotlin. Java jest brzydka, ale właściwie kogo to obchodzi.

Bez świętej wojny ale czy aby gc nie jest w nowym C++ ładnie zastąpiony przez inteligentne wskaźniki? W tej chwili w nowym kodzie C++ już nigdzie nie uświadczysz ( według dobrego stylu od C++11 ) słowa delete. Koniec "gołych" wskaźników". A jeżeli chodzi o wygodę podobną do tej w C# radzę zerknąć na Qt, ja pisząc w pracy w jednym i drugim nie widzę między nimi żadnej różnicy a nawet lepiej pisze mi się w Qt.

Poza tym czy jest sens rozdzierać zasoby czy to finansowe czy ludzkie na tworzenie kolejnych 50 języków? Według mnie to bezsens. Istnieje już pewna baza a te nowe twory nie wnoszą rewolucyjnych zmian. Czy język D był nam potrzebny? Według mnie nie. Rust wygląda fajnie ale czy jest rewolucyjny?

Java na naszych oczach jest pomalutku wypierana przez C# np takimi projektami jak .NET Core.
Stawiam na to że z każdym rokiem coraz więcej osób mając do wyboru Jave i .NET Core będzie wybierało to drugie jako pewniejszą technologię która posiada znacznie większe zaplecze.