Java - szczerze, czy komuś się opłaca jeszcze inwestować w tą platformę?

Swego czasu napisałem taki wątek - i wygląda na to, że przewidziałem rzeczywistość, w PL i na świecie:

Java - największy obecnie standard programowania?

Pod pojęciem Javy nie mam na myśli niczego innego poza samym językiem - tj. JVM dla mnie to zupełnie inna sprawa, podobnie Kotlin itd.

Teraz mam wrażenie, że sytuacja zaczęła się zmieniać.
Java będzie na 100% dalej wykorzystywana. Jednak zakres jej wykorzystywania powoli się konsoliduje: albo Java Spring / Spring boot, albo czyste webowe rzeczy. I chyba już nic innego naprawdę liczączego się, odkąd Google teraz określił Kotlin jako główny język programowania Androida. Podobnie sprawa wygląda z embedded. Nie wiem jak gry na Android w Kotlinie, bo nie pisałem żadnej nigdy - ale podejrzewam, że i tu będzie dominował C# (Xamarin z Monogame i Unity).
Natomiast webowe rzeczy to doprecyzowałbym, że chodzi głównie bardziej zaawansowane i wymagające performance'u aplikacje i systemy - a nie strony, do których wystarczy Ruby on Rails, PHP z Symfony lub Laravel czy Python z Flask lub Django.

Java ma utartą pozycję przy korpo projektach. Mnóstwo programistów, mnóstwo frameworków, mnóstwo tutoriali, do tego bardzo "przystępna" w odbiorze. Wielkie firmy na pewno nie pozwolą sobie na eksperymenty.
Ciekaw jestem do czego doprowadzi zmiana modelu wydawania. Imo troche za szybko, oby nie pododawali gówna którego potem nie będą mogli usunąć D:

A jak się inwestuje w jakąkolwiek platformę? Jest od tego jakaś specjalna giełda?

Ciężko ocenić perspektywę języka jeśli nie widzi się wielu projektów tworzonych na wewnętrzne potrzeby firmy. Z resztą zarządy firm potrafią podjąć decyzję z kosmosu, więc pytanie "czy się opłaca" jest trochę nie na miejscu :D

Dużo zależy od managerów czy dadzą się przekonać programistów do użycia nowych języków. Trochę też zależy od programistów czy będą chcieli używać nowych języków. Bo niektórzy są mistrzami Javy i nie chce im się uczyć nowych języków. Dodatkowo jeśli projekt wystartował w Javie to jest mała szansa na przepisanie go do innego języka. Może tylko do Kotlina/Scali, bo wtedy można przepisywać pojedynczymi klasami. Ale to mało firm jest tak postępowych.

BTW Java może straciła Androida, ale to zawsze dla Javy był dodatek. Od lat główną domeną Javy są aplikacje serwerowe gdzie ma się dobrze. A Graal tylko rozszerzy możliwości użycia Javy

Jak uczyć się Javy 16, mam już OpenJDK 16 EAP ale skąd czerpać kursy? Czy lepiej wybrać Scale i Kotlina?

W tym momencie jak Ty masz wątpliwości, kilku zapaleńców kompiluje swój jedyny słuszny język - następnego króla JVM.

To takie gonienie królika. Jest Java to zmieńmy, niech będzie Kotlin a po nim co ... Dwikozy (jak na starych koncentratach pisało)? Tak samo ze Swingiem, zamiast go zaimplementować na Androna to stwierdzili że musi być "nieblokowalne" GUI co mnie przyprawia o nerwy a jak to odzwierciedla się w apkach wielu widzi.
Na najnowszych JDK oblecisz jeszcze dobrych parę lat (a masz w zanadrzu współbieżne Open JDK ) a co będzie za kilkanaście nikt nie wie bo ja nawet dwadzieścia lat temu nie spodziewałem się że mój język programowania Clipper zniknie.

golesz napisał(a):

To takie gonienie królika. Jest Java to zmieńmy, niech będzie Kotlin a po nim co ... Dwikozy (jak na starych koncentratach pisało)? Tak samo ze Swingiem, zamiast go zaimplementować na Androna to stwierdzili że musi być "nieblokowalne" GUI co mnie przyprawia o nerwy a jak to odzwierciedla się w apkach wielu widzi.
Na najnowszych JDK oblecisz jeszcze dobrych parę lat (a masz w zanadrzu współbieżne Open JDK ) a co będzie za kilkanaście nikt nie wie bo ja nawet dwadzieścia lat temu nie spodziewałem się że mój język programowania Clipper zniknie.

To jest naturalny postęp a nie gonienie królika. Jest koń to zmieńmy, niech bedzie samochod, a po nim co... Wedlug mnie pomiedzy kotlinem (nie liczac corutines) a java jest wieksza przepasc niz pomiedzy java 7 a 8 i ciut mniejsza niz java 4 a 5. Cieko w ogole kogokolwiek namowic, zeby zaczal projekt w Javie, jesli pisal cos w Kotlinie (wczesniej piszac w Javie) - przynajmniej tak to wyglada wsrod moich znajomych, ja jestem odludkiem bo z jakiegos powodu nadal bardzo lubie Jave : D

Nie rozumiem tego ostatniego punktu, przeciez jak rozumiesz co sie dzieje pod spodem to level-master kazdego nowego jezyka to bedzie ze 2 lata, a tak zeby dostac sie do pracy po przebranzowieniu sie na inny jezyk to pewnie w miesiac by sie wyrobil, moze w dwa. To tak jakby powiedziec, ze nie kupuj teraz peceta bo za 10 lat beda nowsze - no jak beda to sie zmieni i fajnie, zreszta jakos nie widze osoby w tej branzy ktora klepie w jednym jezyku tylko przez 10 lat i niczego sie wiecej nie uczy wiec to jakas abstrakcja i tak i tak

Aventus napisał(a):

A jak się inwestuje w jakąkolwiek platformę? Jest od tego jakaś specjalna giełda?

https://openjdk.java.net/sponsor/

Zmiana technologii kosztuje, obecnie to raczej tnie się koszty i korzysta z pewnych i najtańszych rozwiązań.

Dla nudnego biznesu sama technologia ma drugo jak nie trzeciorzędne znaczenie. Tak naprawdę ważniejszy jest sam biznes i ludzie, którzy go prowadzą niż to w jakim narzędziu programista robi program, a grafik grafikę, a księgowa księgowość itd. Tam gdzie technologia nie ma szczególnego znaczenia ludzie będą wybierać domyślne narzędzia z największym wsparciem, z najmniejszym progiem wejścia w daną dziedzinę.

Dla zwykłego programisty - bez znaczenia jest język, ważniejsze jest doświadczenie jakie posiada, oraz to jak je wykorzystuje i z kim współpracuje. Sama znajomość języka i umiejętność programowania w nim to raptem 10% tego co w rzeczywistości potrzeba przy zaawansowanych projektach.

Oba powyższe akapity można potraktować jako bulllshit o ile biznes wraz programistami zamierza wypracować technologiczną przewagę nad konkurencją. To samo tyczy się oprogramowania dla księgowych, grafików itp Wiele zależy od tego co jest priorytetem i ile jesteśmy w stanie wycierpiać dla niedomyślnych zmian, a nie od tego jak bardzo nudna/fajna jest java.

Wydaje mi się, że przez 10 lat dużo się zmieniło. Java powoli zaczyna być postrzegana tak, jak C był postrzegany 20 lat temu: jako język zbyt niskopoziomowy (wymagający zajmowania się wieloma szczegółowymi kwestiami).

Jeśli miałbym wyrokować mniej więcej analizując co się działo przez ostatnie dekady, to projekty przez najbliższe 10 lat na pewno będą ciągle w dużej mierze oparte na Javie, a wiele z nich zostanie i przez 20 lat. Inna sprawa to nowe projekty. Myślę, że powoli Java będzie kierować się do tego, czym jest C dzisiaj, z tym, że w obszarze serwerów.

Wydaje mi się, że przez 10 lat dużo się zmieniło. Java powoli zaczyna być postrzegana tak, jak C był postrzegany 20 lat temu: jako język zbyt niskopoziomowy (wymagający zajmowania się wieloma szczegółowymi kwestiami).

To ciekawe, a podasz jakiś przykład języka wyższego poziomu?

Charles_Ray napisał(a):

Wydaje mi się, że przez 10 lat dużo się zmieniło. Java powoli zaczyna być postrzegana tak, jak C był postrzegany 20 lat temu: jako język zbyt niskopoziomowy (wymagający zajmowania się wieloma szczegółowymi kwestiami).

To ciekawe, a podasz jakiś przykład języka wyższego poziomu?

Dowolny język, na którym ludzie nie potykają się, bo nie potrafili zaimplementować poprawnego hashCode albo equals ;)

Z punktu widzenia wysokopoziomowego języka rzeczy takie, jak equality check, obliczanie hasha powinny być OOTB. To są dwie rzeczy potrzebne praktycznie zawsze, a które w Javie trzeba sobie dzielnie naklecić samemu (i zrobić to w jeden określony sposób, albo narobić błędów) lub oblepić kod papą dla procesora adnotacji, który to wygeneruje. Pisząc wysokopoziomowy kod nie powinienem musieć się tym martwić, dopóki z jakiegoś powodu nie zechcę zrobić czegoś po swojemu - na własne ryzyko.

Inne szczegółowe kwestie, z którymi w Javie trzeba albo dzielnie walczyć, albo wspomagać się generatorami / procesorami adnotacji:

• gettery / settery - w bardziej wysokopoziomowych językach mają domyślne naiwne implementacji i/lub cukier składniowy, dzięki któremu przez 90% czasu nie trzeba o nich myśleć, mają property access syntax dzięki któremu czyta się to bardziej intuicyjnie itd.
• wielowątkowe naleciałości z czasów zamierzchłych - jak choćby await / notify do zawołania na praktycznie wszystkim. Można przyjąć, że się tego nie będzie używać i tyle, ale to jak mówić, że w C można nie używać void* - prawda, ale to nie znaczy że nie trafię na istniejący już kod, który tego jednak używa.
• nieistniejące null safety - albo raczej istniejące na tyle, na ile się smaruje wszędzie null-checkami. I znowu - można nie używać samemu nulla, zamiast tego mieć null objects i/lub optionale, ale to rozwiązuje problem nawet rzadziej niż nieużywanie await / notify, bo nulle mogą też lecieć do/z kodu third party, jak biblioteki.

Też uważam, że czas żeby java odeszła do lamusa (w mainstreamie)
Jest zbyt niskopoziomowa (nie wspiera wielu abstrakcji) i błędogęnna względem wielu nowszych języków.

Co do OOTB hashCode i equals - uważam, że tych metod w ogóle nie powinno być.
w java.lang.Object jest 11 metod, wszystkie javowe obiekty z tego dziedziczą - z tych metod 10 (no dobra 9) to raczej poważny błąd projektowy :-( Oczywiście kiedyś nie było to oczywiste - eksperyment nie wyszedł.

Nowe wersje Javy są git.
Używam kotlina ogólnie, trochę ułatwia ale jak projekt ma springa to narzut javowy jest duży. Na springa można psioczyc ale trudno uciec. Ale już wolę tego springa niż wymysły hipsterów do których trudno znaleźć kogokolwiek kto to zna.

Sam język? Nie porywa. Ale ecosystem jvm jest przebogaty dlatego według mnie to bardzo dobra platforma, głównie dla web backend.

Java umiera ale raczej będzie umierać kolejne 30 lat.

Chociaż siedząc na tym backendzie tyle lat, obecnie wolałbym się trzymać od tego jak najdalej.

Java nie wyszła i jeszcze dlugo nie wyjdzie z mainstreamu, głównie przez wielkie korporacje piszące systemu dla 'ludu'. Wiecie w czym jest pisany ZUS czy Epuap? w Javie

Java ma bogaty ecosystem, aczkolwiek bywa on toporny.

Kiedyś musiałem pewną rzecz zaimplementować w Pythonie. Dosyć szybko zaciągnąłem potrzebną bibliotekę i naklepałem początkowy kawałek kodu, który w miarę działał. Jednak mój przypadek był dosyć specyficzny, ale szybko znalazłem, że po prostu muszę odpalić ten kawałek kodu w innym trybie i dalej to już poszło z górki, jedynie od czasu do czasu musiałem coś sprawdzić w dokumentacji.

Jakiś czas później zdarzyło mi się, że musiałem zrobić coś podobnego w Javie. Zaciągnąłem najpopularniejszą bibliotekę i musiałem najpierw całkiem sporo kodu naklepać, żeby najprostsze przypadki w ogóle działały (po co mieć jakieś proste defaulty, które wystarczą w 90% zastosowań?). Jak przyszło do tych trudniejszych to było znacznie gorzej, bo okazało się, że klocki, co prawda są, ale cały klej musiałem sam zaimplementować (albo przekleić kupę kodu z SO, czego nie lubię). I tak często jest w Javie. Poniekąd powiew świeżego powietrza to był Spring Boot, ale i tam pod spodem jest dalej wiele dziwnych i nieco archaicznych zachowań.

Ale rzecz jasna Java w mainstreamie jeszcze pewnie będzie długo istnieć. Jest kupa firm pełnych programistów Java i jak trzeba zbudować nowy projekt to lepiej jest to robić w technologiach, które ludzie na pokładzie ogarniają.

Java to język dla korporacji, a wy na niego patrzycie jak na język dla prostych greenfieldów i hello worldów. Typowa sytuacja dla Javowego programisty jest taka, że wchodzi do projektu, który ma już kilka lat, kilkunastu albo kilkudziesięciu ojców (większość z nich już dawno opuściła pokład), jest napisany w wielu różnych stylach, ma świeże kawałki kodu obok mocno nieświeżych, a nowy programista ma dorzucać funkcjonalności, pokrywać testami oraz refaktorować kod na bieżąco by się nie zakopać. Do tego najwięcej korporacyjnych systemów to monolity, a więc nie da się przepisywać serwis po serwisie. Trzeba orać kod systematycznie po kawałku i tutaj bardzo dużą zaletą jest wysoka kompatybilność wsteczna. Genericsy można było dodawać stopniowo (dzięki raw types), lambdy też można dodawać stopniowo nawet w starym kodzie (bo są w pewnym sensie cukrem na klasy anonimowe). Klasy wartościowe / value classes / inline classes / zwał jak zwał mają być kompatybilne ze starymi genericsami, więc znów nie trzeba będzie orać całego kodu tylko będzie można modernizować go stopniowo. Project Loom dostarczy virtual threads (wcześniej zwane jako fibers), dzięki którym będzie można programować współbieżnie tak ja w Golangu (czyli bez kolorowania funkcji), a API będzie oparte na starych Threadach i Executorach, więc na tym samym co cały obecny Javowy kod.

Niedostatki w API są powoli zmniejszane, np:

• w Javie 11 doszedł nowy HTTP client: http://openjdk.java.net/jeps/321 Teraz kod jest dość prosty:

import java.net.URI;
import java.net.http.HttpClient;
import java.net.http.HttpRequest;
import java.net.http.HttpResponse;
//
public class HelloHttp {
    public static void main(String[] args) throws Exception {
        String url = "http://openjdk.java.net/jeps/321";
        var client = HttpClient.newHttpClient();
        var response = client.send(
                HttpRequest.newBuilder(URI.create(url)).build(),
                HttpResponse.BodyHandlers.ofString());
        System.out.println(response.body());
    }
}

• dopiero w Javie 7 doszła metoda java.nio.files.Files.readAllBytes. Dzięki niej można wczytać cały plik od razu (bo i tak w 99%+ przypadków tak się robi) i nie musieć bawić się w przepychanie danych przez strumienie czy w pamiętanie o zamykaniu zasobów. To pokazuje, że API w Javie jest mocno w tyle za konkurencją, ale i tak się rozwija. Za 10 lat dalej pewnie będzie w tyle za konkurencją, ale względem dzisiejszego stanu będzie dużo lepiej.

Java obrywa zarówno za składnię czy API, które dodano zbyt szybko (jak java.util.Calendar) jak i te, które dodano zbyt późno (jak np lambdy). Biorąc pod uwagę nacisk na kompatybilność wsteczną autorzy Javy teraz raczej wolą opóźnić wprowadzenie nowych bajerów i upewnić się co jest dokładnie potrzebne, a nie ryzykować dodawaniem bajerów, które za kilka lat będą deprecated.

Trochę wyższy poziom będzie w Javie 14 dzięki record data class:
https://dzone.com/articles/a-first-look-at-records-in-java-14
https://mkyong.com/java/java-14-record-data-class/

ja tam najbardziej czekam na prymitywne generyki, w drugiej kolejności na operatory.

Miałem ciekawy incydent raz związany z Javą.

Niecałe 3 lata temu, gdy w startupie pracowałem nad projektem JS i PHP, wpadł do nas nieoczekiwanie jakiś student. Wtedy w prasie była silna nagonka na Javę, i każdy, kto znał ten język, mógł zgodnie z powszechnym mniemaniem dumą się obnosić wobec wszystkich innych programistów. ;)

Student szukał możliwości odbycia praktyk w programowaniu. Kiedy szef powiedział, w jakich technologiach jest ów projekt, student - wcześniej skromny i z pochyloną głową, nagle wyprostował pierś i stwierdził, że on w takich językach nie będzie programował i zapytał, czy są u nas jakieś inne firmy tego typu. :) Spojrzał na mnie z góry, nie wiedząc, że mam lata doświadczenia w Javie.. cóż mogłem zrobić, jak się tylko nie uśmiechnąć na ten widok :D

Piszę o tym, bo mam wrażenie, że jest obecnie boom na Javę i ew. C# na studiach (chyba z Pythonem nadal słabo? ale mogę się mylić) po medialnej nagonce, i część innych języków programowania po prostu straciła na zainteresowaniu. Tych innych, co straciły, chyba jeszcze nie obejmuje C/C++, bo na studiach jest to podstawa, a większość ludzi, którzy chcą robić gry, się go uczą.

Zauważyłem jedno: tak, jak jest ciężko znaleźć dobrego programistę Java, tak samo jest z każdym innym językiem: C#, PHP, Python itd.

Prasa podkreśla znajomość języka tak, jakby to było meritum sprawy. Tymczasem programowanie to nie znajomość języka, tak jak pisanie powieści to nie znajomość zasad polskiego ;)

forsberg napisał(a):

Niecałe 3 lata temu, gdy w startupie pracowałem nad projektem JS i PHP, wpadł do nas nieoczekiwanie jakiś student. Wtedy w prasie była silna nagonka na Javę, i każdy, kto znał ten język, mógł zgodnie z powszechnym mniemaniem dumą się obnosić wobec wszystkich innych programistów. ;)

Student szukał możliwości odbycia praktyk w programowaniu. Kiedy szef powiedział, w jakich technologiach jest ów projekt, student - wcześniej skromny i z pochyloną głową, nagle wyprostował pierś i stwierdził, że on w takich językach nie będzie programował i zapytał, czy są u nas jakieś inne firmy tego typu. :)

Też bym nie pracował w JS i PHP (chyba ze bym głodem przymierał) bo mam teorię że języki dynamicznie typowane powodują choroby psychiczne, a ja mam predyspozycje :(

Ja mam trochę ograniczających przekonań w stosunku do javy i staram się jej nie używać(jak już to bardziej JVM), ale w tym roku w firmie zrobiłem jeden wyjątek. Dałem opcje do pisania testów w javie, bo osoby, które się uczą się pisać testy mają prościej gdy kompilator i InteliJ podpowiada. O pisaniu testów w Selenium jest dużo jest książek, ale głównie w java, no i też warto podkreślić, że wtedy osoba, która pisze testy ma wtedy większy wpływ na swoją przyszłość. Świadomość, że za 1-3 lata będą mogli pracować jako QA w większej firmie lub korpo za większy hajs wpływa na morale, a mnie zostawia z czymś co potencjalnie łatwo będę mógl przekazać kolejnej osobie.

Dopóki programy nie wymagają skomplikowanego podejścia to ta java nie jest zła. Wierzę, że programować w java można łatwo i przyjemnie, ale jeśli to podejście opiera się na pisaniu konkretnego kodu, a nie kodu, w którym przeważnie rządzą ogólne byty. Niestety dla programisty, java to mniej więcej jest pierwszy język, gdzie idzie docenić ogólny sposób myślenia (bo separacja), i przez to projekty są bardziej wymóżdżone niż wynika to z realnych potrzeb.

W sumie z tego wątku wynika, że w 90% firm projekty to szambo, a Java dev to praca szambonurka

Pecunia non olet :]