Java, Java i co dalej?

0

Ameryki nie odkryję jak napiszę, że Java jest wszechobecna i to od wielu, wielu lat. Wszechobecna. Niestety.
Zastanawiam się nad tym czy nie dałoby się jakoś zastąpić jej czymś innym? Oczywiście lepszym.
Czy są jakieś sensowne perspektywy na wyeliminowanie jej?
Wiem że wszystko rozbija się o kasę i że Java może pozwalać na stworzenie przenośnej aplikacji w krótszym czasie niż w innych językach. I wiadomo, że podmiot zamawiający stworzenie aplikacji lub samodzielnie ją tworzący chce wprowadzić produkt na rynek w jak najkrótszym czasie i za jak najmniejsze pieniądze.

Ale czy ktokolwiek bierze pod uwagę to, że cały koszt użytkowania aplikacji javowych jest przeniesiony finalnie na
użytkownika końcowego? Bo to on przecież korzysta z aplikacji i to on musi ponosić koszty takie jak:

  • konieczność posiadania wypasionego sprzętu do uruchomienia aplikacji
  • bycia zmuszanym do dokonywania kolejnych upgrade'ów sprzętu bo nowe wersje aplikacji będą miały większe wymagania
  • straty czasu na lagowanie aplikacji javowych
  • straty nerwów

Czy są jakiekolwiek zyski po stronie użytkownika końcowego poza ładnie prezentującą się na obrazku stroną wizualną aplikacji w javie?

Czy to już przesądzone, że w przyszłości nadal będziemy zmuszani do używania aplikacji javowych?

11

@userek_jakis: to jest jakiś remake postu z wczesnych lat dwutysięcznych? Czy też zapytałeś ChatGPT do czego używa się obecnie Javy, a następnie poprosiłeś o napisanie tekstu o znaczeniu przeciwnym?

Od bardzo długiego czasu 95% aplikacji pisanych w Javie nie docierają do użytkownika końcowego. Zamiast tego są odpalane na serwerach, a użytkownicy jedynie doświadczają efektów ich działania.

0
wartek01 napisał(a):

@userek_jakis: to jest jakiś remake postu z wczesnych lat dwutysięcznych? Czy też zapytałeś ChatGPT do czego używa się obecnie Javy, a następnie poprosiłeś o napisanie tekstu o znaczeniu przeciwnym?

Jak mu wrzuciłem "napisz artykuł z najgłupszymi powodami dla których nie powinienem używać javy" to nawet ChatGPT nie wpadł na to, żeby zarzucać Javie, że wymaga wypasionego sprzętu albo że laguje. Chyba, że chodzi o jakieś gierki na telefon w Javie ME, ale to dawno było, nawet one chyba nie lagowały.

userek_jakis napisał(a):

Zastanawiam się nad tym czy nie dałoby się jakoś zastąpić jej czymś innym? Oczywiście lepszym.

Czy to takie oczywiste? W IT wygrywają nie języki i technologie najlepsze (cokolwiek to znaczy), ale te ze wsparciem dużych firm. Dobrym przykładem jest Golang.

1

A'propos lagowania - weźmy jako przykład IDE Eclipse.

Kiedyś kiedy próbowałem używać Eclipse - włączyłem sobie indexowanie źródeł pewnego dużego projektu. Trwało to indexowanie chyba z 2 godziny przy 100% zajętości procka i eclipse całkowicie przestał odpowiadać na jakiekolwiek eventy. Przeprowadziłem podobny test na Eclipse kilka razy, po czym stwierdziłem że to nie ma sensu
i użyłem zwykłego narzędzia do indexowania, które uporało się z tym zadaniem chyba w kilkadziesiąt sekund.

Obecnie już nie za bardzo mam wybór i muszę korzystać z czegoś w rodzaju debuggera napisanego w javie. Uruchamiam go zdalnie.
Jak zmierzyłem czas od momentu zatwierdzenia uruchomienia aplikacji do sensownego stanu używalności tej aplikacji to mi wyszło dokładnie 2 minuty. Sprawdziłem inne aplikacje uruchamiane z tego samego systemu zdalnie to uruchamiają się w kilkadziesiat sekund.

A popatrzmy może na pamięciożerność tej aplikacji zaraz po uruchomieniu:
VSZ: 122.8 GB
RSS: 1.1GB

Inny przykład. Używanie aplikacji w javie do przeparsowania iluśtam plików tekstowych i wyrzucenie na wyjściu jednej linijki. Czas trwania parsowania to kilkadziesiąt sekund. Akurat ta aplikacja jest używana w ramach pewnej infrastruktury testującej i tutaj czas wykonania ma istotne znaczenie a biorąc dodatkowo pod uwagę, że testy są wykonywane na okrągło i korzysta z nich mnóstwo ludzi to to już całkiem jakaś niepoważna sytuacja.

1

Większość aplikacji napisanych w Javie to aplikacje serwerowe. Java jest dobra do takich zastosowań, bo koszt pracy programisty to duży udział w koszcie utrzymania a przez wiele lat tak na prawdę nie było sensownych alternatyw.

Jeśli chodzi o aplikacje desktopowe to faktycznie jest słabo ale zauważ, że tych aplikacji wcale nie ma tak dużo. Eclipse to przypadek szczególny, bo jest przeinżynierowany. Warto wspomnieć samą platformę, która używa jakiegoś tam OSGI.

0
slsy napisał(a):

Większość aplikacji napisanych w Javie to aplikacje serwerowe. Java jest dobra do takich zastosowań, bo koszt pracy programisty to duży udział w koszcie utrzymania a przez wiele lat tak na prawdę nie było sensownych alternatyw.

Ok, przyjmuję do wiadomości, że i na serwerach java sobie chodzi.

Jeśli chodzi o aplikacje desktopowe to faktycznie jest słabo ale zauważ, że tych aplikacji wcale nie ma tak dużo. Eclipse to przypadek szczególny, bo jest przeinżynierowany. Warto wspomnieć samą platformę, która używa jakiegoś tam OSGI.

Ok, a powiedz w czym aktualnie tworzy się apki dla Androida? Czy to też Java czy coś innego tak zamula? Ja tego kompletnie nie rozumiem - jak np. taka appka do podglądu stanu konta dla T-Mobile potrafi uruchamiać się chyba z 5 lub więcej minut? Co tam takiego skomplikowanego jest w tej appce że się tak długo uruchamia? Jakieś wysoce skomplikowane metody autoryzacji są tam używane czy jak?

0

Nic z tego postu nie wynika. Śmieszy mnie to.
Chcesz zastąpić Javę, bo?

1
userek_jakis napisał(a):

Kiedyś kiedy próbowałem używać Eclipse - włączyłem sobie indexowanie źródeł pewnego dużego projektu. Trwało to indexowanie chyba z 2 godziny przy 100% zajętości procka i eclipse całkowicie przestał odpowiadać na jakiekolwiek eventy. Przeprowadziłem podobny test na Eclipse kilka razy, po czym stwierdziłem że to nie ma sensu

Czy jeśli napiszę ci narzędzie indeksujące w np. C, które będzie jeszcze wolniejsze od Eclipse'a to będzie to oznaczało, że C jest wolniejsze od Javy?
Na wydajność indeksowania składa się sporo czynników, bardzo mocno podejrzewam, że owa narzędzia indeksują różne rzeczy i w różny sposób.

Inny przykład. Używanie aplikacji w javie do przeparsowania iluśtam plików tekstowych i wyrzucenie na wyjściu jednej linijki. Czas trwania parsowania to kilkadziesiąt sekund. Akurat ta aplikacja jest używana w ramach pewnej infrastruktury testującej i tutaj czas wykonania ma istotne znaczenie a biorąc dodatkowo pod uwagę, że testy są wykonywane na okrągło i korzysta z nich mnóstwo ludzi to to już całkiem jakaś niepoważna sytuacja.

Widzę tutaj pewien wzór. Używasz jakiegoś in-house softu, który jest wolny i uznajesz, że to wina języka. No więc tak, w Javie da się parsować duże pliki szybko.

0
NeutrinoSpinZero napisał(a):

Nic z tego postu nie wynika. Śmieszy mnie to.
Chcesz zastąpić Javę, bo?

Przeczytaj może ponownie to co napisałem do tej pory a dopiero potem proponuję kontynuować czytanie tego posta poniżej.

Z związku chociażby z tymi danymi co do czasu uruchamiania aplikacji o których pisałem powyżej to według mnie stosunek zysku do strat w przypadku aplikacji javowych jest mniej więcej taki jak 1:n.
Gdzie:
1 - zysk jednokrotny dla użytkownika końcowego z racji tego że szybko dostał do ręki gotową aplikację i nie musiał długo czekać na jej powstanie
n - ilość użyć aplikacji przez użytkownika końcowego

Jak widać strata tym większa im więcej użytkownik korzysta z tej aplikacji.

0
wartek01 napisał(a):
userek_jakis napisał(a):

Kiedyś kiedy próbowałem używać Eclipse - włączyłem sobie indexowanie źródeł pewnego dużego projektu. Trwało to indexowanie chyba z 2 godziny przy 100% zajętości procka i eclipse całkowicie przestał odpowiadać na jakiekolwiek eventy. Przeprowadziłem podobny test na Eclipse kilka razy, po czym stwierdziłem że to nie ma sensu

Czy jeśli napiszę ci narzędzie indeksujące w np. C, które będzie jeszcze wolniejsze od Eclipse'a to będzie to oznaczało, że C jest wolniejsze od Javy?

Najprawdopodobniej będzie to oznaczało jakiś wybiórczo znaleziony corner case.

Na wydajność indeksowania składa się sporo czynników, bardzo mocno podejrzewam, że owa narzędzia indeksują różne rzeczy i w różny sposób.

Bardzo możliwe, ale z tego co pamiętam to wtedy eclipse nie dał mi wyboru ograniczenia w jakikolwiek sposób zakresu indexowania.
Ale w sumie może za krótko używałem eclipse i da się jakoś kontrolować to indexowanie, żeby dało się tego sensownie używać?
Jeśli tak - to chętnie się dowiem jak.

Inny przykład. Używanie aplikacji w javie do przeparsowania iluśtam plików tekstowych i wyrzucenie na wyjściu jednej linijki. Czas trwania parsowania to kilkadziesiąt sekund. Akurat ta aplikacja jest używana w ramach pewnej infrastruktury testującej i tutaj czas wykonania ma istotne znaczenie a biorąc dodatkowo pod uwagę, że testy są wykonywane na okrągło i korzysta z nich mnóstwo ludzi to to już całkiem jakaś niepoważna sytuacja.

Widzę tutaj pewien wzór. Używasz jakiegoś in-house softu, który jest wolny i uznajesz, że to wina języka.

Czy z tym "in-house soft" to chodzi ci o taki soft pisany na kolanie? W przypadku pewnej firmy to raczej bardzo mało prawdopodobne.

Jeszcze nie widzialem apki w javie która startuje równie szybko i działa równie szybko jak inne aplikacje.
Appki w javie przynajmniej te które widziałem ZAWSZE zostawały w tyle, ale podkreślam: te które widziałem.
Być może są jakieś appki w javie które potrafią nie wkurzać czy to pamięciożernością czy marnotrawieniem taktów cpu :)

No więc tak, w Javie da się parsować duże pliki szybko.

Ale doliczasz tutaj czas startu od zera za każdym razem takiej appki w javie czy pomijasz ten czas?

0

W IT wszystko jest efektem kompromisów. Jeśli coś jest np. wolne to przeważnie oferuje dodatkowe opcje w innym zakresie. Więc raczej nie chodzi o to, czy narzędzie jest lepsze czy gorsze, lecz w jakim zakresie stanowi odpowiedź na problemy użytkownika. Ty o tym nic nie piszesz więc wątek postrzegam jako czasozabijacz i nic ponadto.

W przypadku javy nie chodzi tylko o problemy użytkownika, ale o zaplecze, zapewnienie ciągłości. Nie wiem, który biznes chciałby utrzymywać własne rozwiązania w zapomnianym języku. Takie projekty niepotrzebnie przepalają środki i stwarzają dodatkowe ryzyka, choćby w zatrudnieniu i douczaniu kolejnej osoby. Jeśli chodzi o kasę to lepiej sztukę dla sztuki sobie darować i mieć jeden etap już za sobą.

Wiem że wszystko rozbija się o kasę i że Java może pozwalać na stworzenie przenośnej aplikacji w krótszym czasie niż w innych językach.

To zależy od typu aplikacji i problemu jaki zamierzasz rozwiązać. Do trywialnych zadań Java jest przerostem formy nad treścią.

3
userek_jakis napisał(a):

Jeszcze nie widzialem apki w javie która startuje równie szybko i działa równie szybko jak inne aplikacje.
Appki w javie przynajmniej te które widziałem ZAWSZE zostawały w tyle, ale podkreślam: te które widziałem.
Być może są jakieś appki w javie które potrafią nie wkurzać czy to pamięciożernością czy marnotrawieniem taktów cpu :)

No to masz:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello world");
    }
}

time szypka

Hello world
real 0m0.004s
user 0m0.000s
sys 0m0.004s

0
userek_jakis napisał(a):

Najprawdopodobniej będzie to oznaczało jakiś wybiórczo znaleziony corner case.

Nie. To będzie oznaczało, że napisałem kiepski program indeksujący w C.

Bardzo możliwe, ale z tego co pamiętam to wtedy eclipse nie dał mi wyboru ograniczenia w jakikolwiek sposób zakresu indexowania.
Ale w sumie może za krótko używałem eclipse i da się jakoś kontrolować to indexowanie, żeby dało się tego sensownie używać?
Jeśli tak - to chętnie się dowiem jak.

Jeszcze raz - Eclipse to słaba aplikacja. Pełna zgoda i nie zamierz jej bronić, a ostatnio to jej używałem z dziesięć lat temu. Nie wiem co zrobić, żeby Eclipse szybko indeksowało.
Natomiast twierdzenie, że jakiś język jest szybki lub słaby na podstawie porównania dwóch aplikacji jest po prostu błędem.

Czy z tym "in-house soft" to chodzi ci o taki soft pisany na kolanie? W przypadku pewnej firmy to raczej bardzo mało prawdopodobne.

Niekoniecznie.
Po prostu in-house soft ma to do siebie, że ktoś napisze rozwiązanie, które jest good enough na ówczesne potrzeby, a później ludzie zaczynają tego rozwiązania używać i zaczyna ono niedomagać.

Jeszcze nie widzialem apki w javie która startuje równie szybko i działa równie szybko jak inne aplikacje.
Appki w javie przynajmniej te które widziałem ZAWSZE zostawały w tyle, ale podkreślam: te które widziałem.

Ogólnie znana i lubiana IntelliJ Idea jest raczej wydajna (a już na pewno o niebo wydajniejsza od Eclipse'a). Z tego co pamiętam to ArgoUML też odpalał się tak, że nie widziałem problemów.

Ale doliczasz tutaj czas startu od zera za każdym razem takiej appki w javie czy pomijasz ten czas?

Ja piszę o parsowaniu plików, a nie o odpalaniu apki. Natomiast tak, da się kompilować bytecode JVMowy do natywnych apek, żeby śmigało szybko.

0
jarekr000000 napisał(a):
userek_jakis napisał(a):

Jeszcze nie widzialem apki w javie która startuje równie szybko i działa równie szybko jak inne aplikacje.
Appki w javie przynajmniej te które widziałem ZAWSZE zostawały w tyle, ale podkreślam: te które widziałem.
Być może są jakieś appki w javie które potrafią nie wkurzać czy to pamięciożernością czy marnotrawieniem taktów cpu :)

No to masz:

public class Main {
    public static void main(String[] args) {
        System.out.println("Hello world");
    }
}

time szypka

Hello world
real 0m0.004s
user 0m0.000s
sys 0m0.004s

O dziękuję. Próbowałem dawno temu coś równie skomplikowanego i użytecznego skompilować w takim IDE dla Javy o nazwie BEA. Czas uruchomienia samego IDE to było coś koło 5-10 minut + mielenie dyskiem na maksa na całkiem aktualnym wtedy kompie. Potem próba kompilacji tak zaawansowanej aplikacji i uruchomienia - kolejne parę minut oczekiwania. W czasie mielenia dyskiem oczywiście komp był bezużyteczny. Stwierdziłem, że niech się tym czymś zajmują "inni".

W sumie fajnie jeszcze byłoby sprawdzić ile to coś zajęło pamięci RAM, ile czasu trwała kompilacja, ile zajmuje binarka na dysku i jakie libki potrzebuje.
Szkoda tylko że wyciągasz taki corner case.

1
userek_jakis napisał(a):

O dziękuję. Próbowałem dawno temu coś równie skomplikowanego i użytecznego skompilować w takim IDE dla Javy o nazwie BEA. Czas uruchomienia samego IDE to było coś koło 5-10 minut +

To chyba musiało być bardzo dawno...
Btw. dziś jakbyś tego BEA coś tam użył też pewnie by to trwało X minut. Bo to nie służyło do pisania aplikacji - tylko było powiązane z serwerem JavaEE. Stare dzieje,
ale ta technologia (JavaEE) odeszła do lamusa między innymi właśnie z powodu czasu wstawania (ale głównym powodem jest to, że serwery JavaEE to straszne g**no, trudne w konfiguracji i zarządzaniu). Te same aplikacje serwerow w SpringBoot wstają sekundy - a na JavaEE wstawały minutami. NIe mówiąc o tym, że obecnie nawe te sekundy SpringBoota są dla wielu rozczarowujące i używają innych technologii Ratpack, Quarkus - gdzie te same aplikacje wstają już milisekundy.

Ogólnie java jako język to dramat, bo jest stary i nie przystaje do współczesnych języków (Kotlin, Scala, Rust, TS).

Natomiast czas rozpędzania się jvm to problem dość marginalny, który do tego ma już dość dobre rozwiązania (AOT/native image).

0
wartek01 napisał(a):
userek_jakis napisał(a):

Najprawdopodobniej będzie to oznaczało jakiś wybiórczo znaleziony corner case.

Nie. To będzie oznaczało, że napisałem kiepski program indeksujący w C.

"Ktoś napisał kiepski program indeksujący w C, który będzie przypadkiem szczególnym". Może raczej tak powinienem napisać a nie o corner case.
Ale nadal przypadek szczególny, czyli zdecydowanie rzadki przypadek.

Bardzo możliwe, ale z tego co pamiętam to wtedy eclipse nie dał mi wyboru ograniczenia w jakikolwiek sposób zakresu indexowania.
Ale w sumie może za krótko używałem eclipse i da się jakoś kontrolować to indexowanie, żeby dało się tego sensownie używać?
Jeśli tak - to chętnie się dowiem jak.

Jeszcze raz - Eclipse to słaba aplikacja. Pełna zgoda i nie zamierz jej bronić, a ostatnio to jej używałem z dziesięć lat temu. Nie wiem co zrobić, żeby Eclipse szybko indeksowało.
Natomiast twierdzenie, że jakiś język jest szybki lub słaby na podstawie porównania dwóch aplikacji jest po prostu błędem.

Ok, co do eclipse'a to możliwe że kiepsko napisana. I dodatkowo popatrz, że podałem eclipse jako jeden z trzech przykładów ale tych przykładów znalazłoby się duuużo więcej. Kontaktu z aplikacjami javowymi miałem trochę i praktycznie zawsze odczucia co do ich użytkowania były zbieżne.

Czy z tym "in-house soft" to chodzi ci o taki soft pisany na kolanie? W przypadku pewnej firmy to raczej bardzo mało prawdopodobne.

Niekoniecznie.
Po prostu in-house soft ma to do siebie, że ktoś napisze rozwiązanie, które jest good enough na ówczesne potrzeby, a później ludzie zaczynają tego rozwiązania używać i zaczyna ono niedomagać.

I tak mogło być w tym przypadku. System się rozrastał z czasem ale nikt nie chciał ingerować i zmieniać czegoś co po prostu działa i tak to zostało do dzisiaj.

Jeszcze nie widzialem apki w javie która startuje równie szybko i działa równie szybko jak inne aplikacje.
Appki w javie przynajmniej te które widziałem ZAWSZE zostawały w tyle, ale podkreślam: te które widziałem.

Ogólnie znana i lubiana IntelliJ Idea jest raczej wydajna (a już na pewno o niebo wydajniejsza od Eclipse'a). Z tego co pamiętam to ArgoUML też odpalał się tak, że nie widziałem problemów.

Ok, skoro tak reklamujecie IntelliJ to postaram się sprawdzić jak to to działa. W sumie to nie pierwszy raz jak słyszę o niej pozytywne opinie. Obym się nie zawiódł.

Ale doliczasz tutaj czas startu od zera za każdym razem takiej appki w javie czy pomijasz ten czas?

Ja piszę o parsowaniu plików, a nie o odpalaniu apki. Natomiast tak, da się kompilować bytecode JVMowy do natywnych apek, żeby śmigało szybko.

No ok, ja niestety muszę doliczyć tutaj całość czasu - razem ze startem i w przypadku tego parsowania, o którym pisałem to naprawdę kiepsko to wyglądało.

1
userek_jakis napisał(a):

No ok, ja niestety muszę doliczyć tutaj całość czasu - razem ze startem i w przypadku tego parsowania, o którym pisałem to naprawdę kiepsko to wyglądało.

Jeżeli zamierzasz użyć javy do zrobienia narzędzia CLI, tak żeby to potem wywoływać np. w pętli bash (bo tylko wtedy te problemy ze startem są istotne) to najlepiej... po prostu nie rób tego w javie.
Można taką aplikację napisać w javie i pewnie mozna nawet tak podkręcić kompilację AOT, żeby to jakoś działało... ale po co? Będzie potrzeba dużo wiedzy na temat tego jak to optymalizować, a wynik mizerny.
a internet Ci średnio pomoże, bo takich rzeczy nie pisze się w javie. Zrób to w Rust, albo C++.

0
jarekr000000 napisał(a):
userek_jakis napisał(a):

O dziękuję. Próbowałem dawno temu coś równie skomplikowanego i użytecznego skompilować w takim IDE dla Javy o nazwie BEA. Czas uruchomienia samego IDE to było coś koło 5-10 minut +

To chyba musiało być bardzo dawno...

Tak, zgadza się, bardzo dawno temu (licząc czas w świecie IT oczywiście) - gdzieś w okolicach 2005 lub 2006 roku z tego co pamiętam. To było baaardzo zniechęcające.

Btw. dziś jakbyś tego BEA coś tam użył też pewnie by to trwało X minut. Bo to nie służyło do pisania aplikacji - tylko było powiązane z serwerem JavaEE. Stare dzieje,
ale ta technologia (JavaEE) odeszła do lamusa między innymi właśnie z powodu czasu wstawania (ale głównym powodem jest to, że serwery JavaEE to straszne g**no, trudne w konfiguracji i zarządzaniu). Te same aplikacje serwerow w SpringBoot wstają sekundy - a na JavaEE wstawały minutami. NIe mówiąc o tym, że obecnie nawe te sekundy SpringBoota są dla wielu rozczarowujące i używają innych technologii Ratpack, Quarkus - gdzie te same aplikacje wstają już milisekundy.

O - i dowiedziałem się czegoś nowego. Dzięki. Postaram się poczytać o tym.

Ogólnie java jako język to dramat, bo jest stary i nie przystaje do współczesnych języków (Kotlin, Scala, Rust, TS).

Ok, czyli jednak są jakieś alternatywne rozwiązania dla Javy. Dobrze wiedzieć.

Natomiast czas rozpędzania się jvm to problem dość marginalny, który do tego ma już dość dobre rozwiązania (AOT/native image).

Dla mnie to nowość. Tu też muszę się dokształcić.

0
jarekr000000 napisał(a):
userek_jakis napisał(a):

No ok, ja niestety muszę doliczyć tutaj całość czasu - razem ze startem i w przypadku tego parsowania, o którym pisałem to naprawdę kiepsko to wyglądało.

Jeżeli zamierzasz użyć javy do zrobienia narzędzia CLI, tak żeby to potem wywoływać np. w pętli bash (bo tylko wtedy te problemy ze startem są istotne) to najlepiej... po prostu nie rób tego w javie.
Można taką aplikację napisać w javie i pewnie mozna nawet tak podkręcić kompilację AOT, żeby to jakoś działało... ale po co? Będzie potrzeba dużo wiedzy na temat tego jak to optymalizować, a wynik mizerny.
a internet Ci średnio pomoże, bo takich rzeczy nie pisze się w javie. Zrób to w Rust, albo C++.

Nie, nie - tu mnie źle zrozumiałeś. Ja nie próbuję napisać aplikacji w Javie, tylko jestem przymusowym użytkownikiem pewnych aplikacji w Javie. I niestety ktoś wymyślił sobie, że z poziomu skryptów shellowych będzie odpalać jakiś programik w Javie i to po prostu niemiłosiernie zżera czas na pojedyncze wywołanie. Na głowie masz deadline'y, musisz na szybko sprawdzić czy twój program działa poprawnie i odpalasz testy... I czekasz i czekasz... Potem musisz sprawdzić twój program z innymi parametrami - więc znowu test. I znowu czekasz i czekasz...

0

mój roboczy laptop zamula i bez wpływu javy:

  • notepad++ (napisany pewnie w c++) zamula
  • ms outlook - zamula
  • cygwin - nowa instancja terminala długo się uruchamia (rzędu 10s), a odpalanie nowego procesu ma taki narzut, że polecenia typu find -exec grep są wieeeeeelokrotnie wolniejsze niż na czystym linuksie
  • mam wgrany mcaffee - tego nie trzeba dalej komentować
  • zoom mitongi z pokazywaniem kamerki czy ekranu potrafią zarżnąć cały system - jest czasem totalny freeze na kilkanaście sekund albo i więcej
  • powershell odpalany z poziomu javy uruchamia się chyba z minutę - podejrzewam, że konfiguracja jest skopana i pewnie próbuje coś zaciągać, leci timeout i dopiero potem idzie dalej? nie wiem. odpalany bezpośrednio uruchamia się względnie szybko.
0

Programy napisane w javie może i są zwykle bardziej "zasobożerne" w porównaniu do aplikacji natywnych, ale gdyby nie java, to te aplikacje może w ogóle by nie powstały :)

1
userek_jakis napisał(a):

Ok, co do eclipse'a to możliwe że kiepsko napisana. I dodatkowo popatrz, że podałem eclipse jako jeden z trzech przykładów ale tych przykładów znalazłoby się duuużo więcej. Kontaktu z aplikacjami javowymi miałem trochę i praktycznie zawsze odczucia co do ich użytkowania były zbieżne.

Jestem w stanie długo wymieniać słabo zoptymalizowane aplikacje w innych językach.

No ok, ja niestety muszę doliczyć tutaj całość czasu - razem ze startem i w przypadku tego parsowania, o którym pisałem to naprawdę kiepsko to wyglądało.

Widzisz, czyli twoim problemem nie jest sama Java, tylko kwestia tego, że musi to wstawać na JVM. I nie jest to problem z językiem, ale z ekosystemem - taki, który da się rozwiązać. Są wynalazki, które pozwalają trzymać JVM w tle i odpalać skrypty (nie używałem), albo też można skompilować program do native i sprawa się rozwiązuje. Kompilujesz ów programik za pomocą np. GraalVM, podmieniasz i cyk, pora na CSa.

0

@userek_jakis z tego co znalazłem na githubie https://madnight.github.io/githut/#/pull_requests/2022/4 to masz przynajmniej 50 w miarę używanych języków programowania. Jak masz wątpliwości co do javy to możesz zabrać się za eksplorację innych języków.

  • postawię śmiałą tezę, że życia nie starczy aby na sensownym poziomie ogarnąć dwa czy trzy języki
1
bustard2 napisał(a):

Programy napisane w javie może i są zwykle bardziej "zasobożerne" w porównaniu do aplikacji natywnych, ale gdyby nie java, to te aplikacje może w ogóle by nie powstały :)

Ale dlaczego bez javy te aplikacje by nie powstały? Podobno natura nie znosi próżni więc jeśli byłoby zapotrzebowanie na apkę a java w ogóle nie istniałaby to...?

0

Bo bez Javy koszt powstania tych aplikacji mógłby być zbyt wysoki. Oczywiście są alternatywy, ale pytanie czy są one znacząco lepsze niż Java? Nie sądzę.

0
bustard2 napisał(a):

Bo bez Javy koszt powstania tych aplikacji mógłby być zbyt wysoki. Oczywiście są alternatywy, ale pytanie czy są one znacząco lepsze niż Java? Nie sądzę.

Weź pod uwagę, że gdyby nigdy nie było javy w ogóle, tzn. nikt nie wiedziałby o czymś takim jak java, to po prostu użyto by innego języka bo skoro nie ma javy to skąd byłoby wiadomo że napisanie apki jest nieopłacalne? Skoro nie ma javy to jak można porownywać się do niej a konkretniej do kosztów napisania apki w niej?
Czy można porównywać się z czymś co nie istnieje?
Wtedy po prostu stawki za napisanie programu w innym jezyku byłyby zupełnie inne - i wtedy inny język byłby tym najbardziej ekonomicznym do pisania apek.

0

tzn. nikt nie wiedziałby o czymś takim jak java, to po prostu użyto by innego języka bo skoro nie ma javy to skąd byłoby wiadomo że napisanie apki jest nieopłacalne?

Nie tak działa "opłacalność". Koszt wytworzenia mógłby być tak wysoki, że aplikacja nie znalazłaby klienta gotowego za nią tyle zapłacić. To nie jest tak, że ktoś musi za to zapłacić, bo inaczej umrze czy coś. Jeśli większość korzysta z usług linii lotniczych, a nie podróżuje prywatnymi samolotami? Bo ich nie stać na zakup prywatnego samolotu i woli skorzystać z tańszej alternatywy. Podobnie jest z drogim oprogramowaniem, nawet jeśli jest bardzo dobre, to może nie zrekompensować ceny swoją funkcjonalnością. Z reguły aplikacje w takich językach jak Java pisze się szybciej niż w takich językach jak C++, dlatego koszt ich powstania jest mniejszy.

Wtedy po prostu stawki za napisanie programu w innym jezyku byłyby zupełnie inne - i wtedy inny język byłby tym najbardziej ekonomicznym do pisania apek.

Co tutaj masz na myśli? Brak Javy nie sprawi, że w innych językach nagle zacznie się pisać programy szybciej i z mniejszą liczbą błędów, czyli ogólnie taniej.

0

Czepiasz się niskiej wydajności Java na podstawie anegdotycznych przykładów, które w dodatku źle interpretujesz. Jeżeli w języku A, coś trwa sekundy, a w języku B minut wiele i się nie kończy, to na 99.999% problem nie leży w języku, tylko w tym, że ktoś coś ostro zrąbał w jednej z implementacji.
Jeżeli ktoś napisał narzędzie CLI i w Javie i uruchamia je w pętli, to zgłoś się do autora. Gdyby napisał to jako startujący w tle obraz VM'ki na którym chodzi coś w C++, to też by działało wolno. Nie jest to dowód, że C++ jest do bani, że VMki nie mają sensu, tylko, że autor rozwiązania jest dzbanem.
Aplikacje na Androida, to już kompletnie argument z czapy, bo od początku istnienia nie ma w nim Java, tylko używany jest język o składni zbliżonej do Java. Zresztą nie wiem o co chodzi z tym zamulaniem.

Przerzucanie kosztów na użytkownika. No nie bardzo, z definicji, jeżeli ktoś coś produkuje, a ktoś inny tego używa, to użytkownik ponosi koszty. Czy lepiej mieć tańszy soft i droższy sprzęt, czy odwrotnie - kwestia decyzji producenta. W przypadku IDE dyskusja kompletnie bez sensu biorąc pod uwagę przeznaczenie i złożoność tych programów. Zresztą masz wybór, Vi(m) + pluginy, VSC.

Czas startu aplikacji jest jedną z wad Java, chociaż backend pisany w SpringBoot podnosi się w ciągu sekund, a nie minut (chyba, że ktoś przy starcie wykonuje synchronicznie kilkaset requestów do zewnętrznych usług, ale to nie jest wina języka). @jarekr000000 opisał aktualnie trwające próby poradzenia sobie z nią iu to przeszkadza w efektywnym skalowaniu podów.

0
piotrpo napisał(a):

Czepiasz się niskiej wydajności Java na podstawie anegdotycznych przykładów, które w dodatku źle interpretujesz. Jeżeli w języku A, coś trwa sekundy, a w języku B minut wiele i się nie kończy, to na 99.999% problem nie leży w języku, tylko w tym, że ktoś coś ostro zrąbał w jednej z implementacji.
Jeżeli ktoś napisał narzędzie CLI i w Javie i uruchamia je w pętli, to zgłoś się do autora. Gdyby napisał to jako startujący w tle obraz VM'ki na którym chodzi coś w C++, to też by działało wolno. Nie jest to dowód, że C++ jest do bani, że VMki nie mają sensu, tylko, że autor rozwiązania jest dzbanem.

E? Anegdotyczne? W znaczeniu zmyślone lub mało prawdopodobne? Opisywałem sytuacje, z którymi ja osobiście się spotkałem więc dla mnie jak najbardziej realne. Możliwe, że coś gdzieś przegapiłem, nie wiedziałem albo źle zrozumiałem i dlatego założyłem wątek, żeby się dowiedzieć.

Zastanawiam się czy w takim razie nie mam jakiegoś pecha że w wielu rozwiązaniach gdzie pojawia się wrażenie ospałości - to zwykle w tle pojawia się java? Ale z drugiej strony możliwe, że niektóre apki zostały napisane w czymś innym niż java i też lagują. Ok, jestem w stanie przyjąć do wiadomości, że obecnie wiele innych rozwiązań też może być napisane w sposób lagujący - nie tylko java.

Aplikacje na Androida, to już kompletnie argument z czapy, bo od początku istnienia nie ma w nim Java, tylko używany jest język o składni zbliżonej do Java. Zresztą nie wiem o co chodzi z tym zamulaniem.

A co to za język? Pytałem już o to w tym wątku ale nie dostałem odpowiedzi.
Zamulanie: długi czas uruchamiania się aplikacji do stanu używalności GUI + wysoce ospała reakcja na najprostsze czynności. Może problem jest w tym, że te osoby które na codzień pracują przy tworzeniu aplikacji z GUI na tyle przyzwyczaiły się do czasu kompilacji, uruchamiania i lagów w działaniu, że po prostu tego nie zauważają i wydaje im się, że po prostu tak musi być. I to słynne powiedzenie: "jak ci za wolno działa to kup se szybszy procek".
Pracuję z kompami od jakiegoś czasu i z własnego doświadczeniam wiem, że czasy reakcji GUI na eventy usera mogą być sensowne i to na o wiele wolniejszych kompach niż obecnie stosowane.

Czy ktoś wie w czym została napisana apka T-Mobile pod Androida? Ostatnio jak sprawdzałem startowała mi około 56 sekund - czyli trochę szybciej niż poprzednio kiedy zajęło jej to chyba z 5 minut.

Przerzucanie kosztów na użytkownika. No nie bardzo, z definicji, jeżeli ktoś coś produkuje, a ktoś inny tego używa, to użytkownik ponosi koszty. Czy lepiej mieć tańszy soft i droższy sprzęt, czy odwrotnie - kwestia decyzji producenta. W przypadku IDE dyskusja kompletnie bez sensu biorąc pod uwagę przeznaczenie i złożoność tych programów. Zresztą masz wybór, Vi(m) + pluginy, VSC.

Tutaj zaskoczyło mnie zestawienie tych dwu zdań:

  1. Przerzucanie kosztów na użytkownika.
  2. No nie bardzo, z definicji, jeżeli ktoś coś produkuje, a ktoś inny tego używa, to użytkownik ponosi koszty.
    Nie ma tu jakiejś sprzeczności? Pytam bez złośliwości.
4

@userek_jakis: Anegdoytczne, czyli wybrane 3 przykłady powiązałeś z językiem programowania i wydaje ci się, że to musi być właśnie ta przyczyna. W dodatku uparłeś się na aplikacje desktopowe z GUI, czyli obszar w którym Java ma bardzo mało do zaoferowania. Chcesz pisać aplikacje desktopowe, to użyj właściwego narzędzia. Chociaż nadal, wysoki czas reakcji na akcje użytkownika (czyli to słynne "lagowanie"), to w większosci przypadków błąd programisty, który nie potrafi / nie chce wykorzystać tych 32 rdzeni w moim komputerze i uparł się zrobić wszystko na jednym.
Android nie ma i nigdy nie miał "Javy" w sobie. Java to nie tylko język programowania, ale narzędzia do kompilowania plików java i uruchamiania wyników tej komplikacji. Czyli język ze swoją składnią, biblioteką standardową, kompilator i środowisko uruchomieniowe.
Aplikacje na androida wykorzystywały (bo już tego nie robią w większości) język podobny do Java (ale nie identyczny), kompletnie inny kompilator, produkujący kompletnie inny bytecode uruchamiane są na czymś, co kompletnie nie ma nic wspólnego z JVM, czyli Dalvik VM i ART.
Obecnie większość aplikacji nawet nie używa Java jako wejścia. Większość developmentu przeszła na Kotlin, część aplikacji (gry) jest kompilowana natywnie z jakiegoś C++, do tego wynalazki jeszcze bardziej abstrakcyjne jak React Native, Flutter itd.

Jeżeli chodzi o kawałek "kiedyś to były czasy, a teraz nie ma czasów", to przypomnij sobie jak wyglądały te aplikacje kiedyś i popatrz jak wyglądają dzisiaj. 20 lat temu, jak programista wstawił guzik do aplikacji, to odpowiedzialna za renderowanie tego guzika metoda rysowała 4 kreski na canvas robota skończona. Dzisiaj ta metoda dodatkowo wczytuje kilka fragmentów obrazka, dekoduje je do postaci bitmap, skaluje każdą z części, jak użytkownik najedzie myszką, to odpala się animacja. Równie dobrze możesz narzekać, że "kiedyś" takie allegro działało płynnie, a teraz bywa, że gdzieś coś się przytnie. Tylko kiedyś ładowała się statyczna stronka o rozmiarze liczonym w kilobajtach, teraz ładuje się cała aplikacja o rozmiarze liczonym w megabajtach. U mnie poszło coś koło 1.6 MB, czyli w praktyce coś koło 2 godzin pobierania danych na modemie.

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