Nowoczesna recenzja Java [zamknięta]

Programuję od kilku lat i zacząłem w Javie, a w swoim czasie znalazłem wiele różnych źródeł twierdzących, że Java jest w jakiś sposób gorszym językiem. Wiem, że każdy język ma swoje mocne i słabe strony, ale wiele rzeczy, które czytałem o Javie, wydają się być przestarzałe.

Najczęściej cytowanym powodem gorszej jakości Javy jest to, że jest ona znacznie wolniejsza niż w przypadku innych natywnie skompilowanych języków, takich jak na przykład C ++. Wiele osób krytykuje projektanta gier Notch (który opracował Minecraft) za korzystanie z Javy z powodu jego widocznego braku w dziale wydajności. Wiem, że Java była znacznie wolniejsza w tamtych czasach, ale od tego czasu wprowadzono wiele ulepszeń, zwłaszcza kompilację JIT.

Chciałbym dziś uzyskać obiektywne opinie na temat języka Java jako języka. Moje pytanie składa się z 4 części.

1. Występ.

   za. Jaka jest dzisiaj szybkość Javy w porównaniu z C ++?

   b. Czy byłoby możliwe stworzenie nowoczesnego tytułu AAA za pomocą Java?

   do. W jakich obszarach Java jest wolniejsza niż C ++, jeśli w ogóle? (tj. łamanie liczb, grafika lub po prostu dookoła)

2. Czy Java jest teraz uważana za język skompilowany lub język interpretowany?

3. Jakie są główne niedociągnięcia w Javie, które zostały usunięte od pierwszych dni?

4. Jakie są poważne niedociągnięcia w Javie, które wymagają jeszcze rozwiązania?

Edytować:

Dla wyjaśnienia nie robię tego Java vs. C ++, oczywiście średnio c ++ będzie trochę szybszy niż Java. Po prostu potrzebuję czegoś, aby porównać Javę pod względem dojrzałości jako języka w tym momencie. Ponieważ c ++ istnieje już od zawsze, pomyślałem, że będę dobrym punktem odniesienia.

za. Jaka jest dzisiaj szybkość Javy w porównaniu z C ++?

Trudne do zmierzenia. Warto zauważyć, że znaczną część prędkości implementacji, czyli alokatora pamięci, stanowią bardzo różne algorytmy w Javie i C ++. Niedeterministyczny charakter kolektora bardzo utrudnia uzyskanie znaczących danych dotyczących wydajności w porównaniu z deterministycznym zarządzaniem pamięcią w C ++, ponieważ nigdy nie można być pewnym, w jakim stanie jest kolektor. Oznacza to, że bardzo trudno jest napisać test porównawczy to może znacząco je porównać. Niektóre wzorce alokacji pamięci działają znacznie szybciej z GC, niektóre z natywnym alokatorem.

Powiedziałbym jednak, że Java GC musi działać szybko w każdej sytuacji. Natywnego programu przydzielającego można jednak zamienić na bardziej odpowiedni. Niedawno zadałem pytanie na temat SO, dlaczego C # Dictionarymoże wykonać w (0,45 ms na moim komputerze) w porównaniu do równoważnegostd::unordered_mapktóry wykonał (10ms na moim komputerze). Jednak po prostu zamieniając alokator i skrót na bardziej odpowiednie, skróciłem ten czas wykonania do 0,34 ms na moim komputerze - trzydziestej pierwotnego czasu działania. Nigdy nie możesz mieć nadziei na wykonanie takiej niestandardowej optymalizacji za pomocą Java. Doskonałym przykładem tego, gdzie może to naprawdę zmienić rzeczywistość, jest gwintowanie. Rodzime biblioteki wątków, takie jak TBB, zapewniają alokatory buforowania wątków, które są znacznie szybsze niż tradycyjne alokatory w przypadku wielu alokacji dla wielu wątków.

Teraz wiele osób będzie rozmawiać o ulepszeniach JIT i tym, jak JIT ma więcej informacji. Jasne, to prawda. Ale nadal nie jest nawet w niewielkim stopniu zbliżone do tego, co kompilator C ++ może wyciągnąć - ponieważ kompilator ma stosunkowo nieskończony czas i przestrzeń do uruchomienia, z punktu widzenia czasu wykonania końcowego programu. Każdy cykl i każdy bajt, który JIT spędza na zastanawianiu się, jak najlepiej zoptymalizować program, to cykl, którego program nie spędza na wykonywaniu i którego nie może wykorzystać do własnych potrzeb pamięci.

Ponadto zawsze będą momenty, w których kompilator i optymalizacja JIT nie będą w stanie udowodnić pewnych optymalizacji - szczególnie w przypadku takich rzeczy jak analiza ucieczki. W C ++, a następnie jako wartość jest na stosie i tak , kompilator nie trzeba go wykonać. Ponadto istnieją proste rzeczy, takie jak ciągła pamięć. Jeśli przydzielisz tablicę w C ++, to przydzielisz pojedynczą, ciągłą tablicę. Jeśli alokujesz tablicę w Javie, nie jest to wcale ciągłe, ponieważ tablica jest wypełniona tylko wskaźnikami, które mogą wskazywać w dowolnym miejscu. Jest to nie tylko narzut pamięci i czasu dla podwójnych pośrednich, ale także narzut pamięci podręcznej. Tego rodzaju semantyka języka Java po prostu wymusza, że ​​musi być wolniejszy niż równoważny kod C ++.

Ostatecznie moje osobiste doświadczenie jest takie, że Java może być średnio o połowę szybsza niż C ++. Jednak realistycznie nie ma sposobu na wykonanie kopii zapasowej jakichkolwiek oświadczeń dotyczących wydajności bez niezwykle kompleksowego pakietu testów porównawczych, z powodu zasadniczo różnych algorytmów.

b. Czy byłoby możliwe stworzenie nowoczesnego tytułu AAA za pomocą Java?

Zakładam, że masz na myśli „grę”, a nie szansę. Po pierwsze, musisz napisać wszystko od zera, ponieważ prawie wszystkie istniejące biblioteki i infrastruktura docelowa C ++. Nie czyniąc go per se niemożliwym, z pewnością może przyczynić się solidnie do niewykonalności. Po drugie, nawet silniki C ++ z trudem mieszczą się w niewielkich ograniczeniach pamięciowych istniejących konsol - jeśli JVM istnieją nawet dla tych konsol - a gracze na PC oczekują nieco więcej pamięci. Tworzenie wydajnych gier AAA jest wystarczająco trudne w C ++, nie wiem, jak można to osiągnąć w Javie. Nikt nigdy nie napisał gry AAA ze znacznym czasem spędzonym w nieskompilowanym języku. Co więcej, byłby po prostu wyjątkowo podatny na błędy. Deterministyczne zniszczenie jest niezbędne, gdy mamy do czynienia np. Z zasobami GPU, aw Javie „

do. W jakich obszarach Java jest wolniejsza niż C ++, jeśli w ogóle? (tj. łamanie liczb, grafika lub po prostu dookoła)

Zdecydowanie wybrałbym wszystko dookoła. Wymuszona charakterystyka wszystkich obiektów Java oznacza, że ​​Java ma znacznie więcej pośrednich i referencji niż C ++ - przykład, który podałem wcześniej z tablicami, ale dotyczy również na przykład wszystkich obiektów członkowskich. Tam, gdzie kompilator C ++ może wyszukiwać zmienną składową w stałym czasie, środowisko wykonawcze Java musi podążać za innym wskaźnikiem. Im więcej masz dostępu, tym wolniej będzie to robić i JIT nie może nic z tym zrobić.

Tam, gdzie C ++ może niemal natychmiast zwolnić i ponownie wykorzystać część pamięci, w Javie musisz poczekać na kolekcję, i mam nadzieję, że ta część nie wyszła z pamięci podręcznej, a z natury wymaganie większej ilości pamięci oznacza niższą wydajność pamięci podręcznej i stronicowania. Następnie spójrz na semantykę takich rzeczy jak boks i rozpakowanie. W Javie, jeśli chcesz odwoływać się do int, musisz dynamicznie przydzielić go. To nieodłączny marnotrawstwo w porównaniu do semantyki C ++.

Masz wtedy problem ogólny. W Javie można operować na obiektach ogólnych tylko poprzez dziedziczenie w czasie wykonywania. W C ++ szablony mają dosłownie zero kosztów ogólnych - coś, co Java nie może dopasować. Oznacza to, że cały ogólny kod w Javie jest z natury wolniejszy niż ogólny odpowiednik w C ++.

A potem dochodzisz do niezdefiniowanego zachowania. Wszyscy go nienawidzą, gdy ich program wykazuje UB i wszyscy żałują, że nie istniał. Jednak UB zasadniczo umożliwia optymalizacje, które nigdy nie mogą istnieć w Javie. Spójrz na ten post opisujący optymalizacje oparte na UB. Brak zdefiniowania zachowania oznacza, że ​​implementacje mogą przeprowadzić więcej optymalizacji i zmniejszyć kod wymagany do sprawdzenia warunków, które byłyby niezdefiniowane w C ++, ale zdefiniowane w Javie.

Zasadniczo semantyka Java wskazuje, że jest to język wolniejszy niż C ++.

Czy Java jest teraz uważana za język skompilowany lub język interpretowany?

To naprawdę nie pasuje do żadnej z tych grup. Powiedziałbym, że zarządzanie jest naprawdę odrębną kategorią samą w sobie, chociaż powiedziałbym, że zdecydowanie bardziej przypomina język interpretowany niż język skompilowany. Co ważniejsze, są prawie dwa główne systemy zarządzane, JVM i CLR, a kiedy mówisz „zarządzany”, jest wystarczająco wyraźny.

Jakie są główne niedociągnięcia w Javie, które zostały usunięte od pierwszych dni?

Automatyczne boksowanie i rozpakowywanie jest jedyną rzeczą, o której wiem. Leki ogólne rozwiązują niektóre problemy, ale daleko od wielu.

Jakie są poważne niedociągnięcia w Javie, które wymagają jeszcze rozwiązania?

Ich leki generyczne są bardzo, bardzo słabe. Generyczne C # są znacznie silniejsze - choć oczywiście nie są też całkiem szablonami. Deterministyczne zniszczenie to kolejny poważny brak. Każda forma lambda / zamknięcie jest również poważnym problemem - możesz zapomnieć o funkcjonalnym API w Javie. I oczywiście zawsze występuje kwestia wydajności w tych obszarach, które ich potrzebują.

Zacznę od warunku, że prawie niemożliwe jest, aby ktokolwiek wypowiedział prawdziwie neutralną opinię na temat języków programowania. Jeśli znasz dwa języki wystarczająco dobrze, aby w ogóle je komentować, prawie nieuniknione jest, że wolisz jeden od drugiego. Jako uczciwe ostrzeżenie wolę C ++ niż Javę, co niewątpliwie ma wpływ na moje komentarze przynajmniej w pewnym stopniu.

1a. Szybkość: szybkość uzyskiwana z C ++ lub Java będzie generalnie mniej zależała od języka lub jego implementacji niż umiejętności programisty (ów). Ostatecznie C ++ prawdopodobnie może częściej wygrywać z prędkością, ale różnice w pisanym kodzie są naprawdę ważne.
1b. Tak, prawdopodobnie. Jednocześnie C ++ jest już dobrze ugruntowany i wątpię, aby większość studiów gier dostrzegła wystarczającą przewagę, by zawracać sobie głowę przejściem na Javę.
1c. Dokładna odpowiedź na to pytanie może prawdopodobnie wypełnić duży tom. C ++ ogólnie będzie lepiej z bardziej ograniczonymi zasobami. Java czerpie więcej korzyści (na przykład) z posiadania dużej ilości „wolnej” pamięci.
2. Powolne wykonywanie i wolne odśmiecanie byłoby prawdopodobnie najbardziej oczywistymi. Wczesna biblioteka okienkowa (AWT) była dość niezdarna - Swing był znaczną poprawą.
3. Gadatliwość. Brak przeciążenia operatora. Korzystanie ze śmiecia. Brak wielokrotnego dziedziczenia. Generics Java są bardzo ograniczone w porównaniu do szablonów C ++.

Powinienem dodać, że niektóre (wszystkie?) Z tych wad (szczególnie korzystanie z wyrzucania elementów bezużytecznych, ale także inne) są postrzegane przez wielu jako zalety Javy. Jedynym możliwym wyjątkiem byłaby jego gadatliwość. Sytuacja gadatliwości powoli się poprawia, ale na pewno nie często widuje się wygrane w golfa w Javie, często w zwykłym kodzie, a także w zwykłym kodzie. Podejrzewam, że jest co najmniej kilka osób, które uważają to za bardziej czytelne i zrozumiałe, więc prawdopodobnie można to również uznać za zaletę.

1. W odniesieniu do wydajności;
   1. W czystej prędkości wykonywania kodu Java jest prawie równa zwykłemu C ++. Ale Java zwykle zużywa dużo więcej pamięci - częściowo dlatego, że jest oparta na GC, częściowo dlatego, że jej konstrukcja kładzie większy nacisk na prostotę i bezpieczeństwo niż na wydajność. Z powodu problemów z pamięcią podręczną więcej pamięci przekłada się na niższą prędkość. Dużo niższe w porównaniu z wysoko nastrojone C ++.
   2. Jeśli zakładasz, że tytuł AAA musi działać na granicy tego, co jest możliwe przy użyciu obecnego sprzętu, nie. Przynajmniej nie po stronie klienta. Byłbym skłonny założyć się, że niektóre tytuły AAA już używają Java dla części infrastruktury zaplecza.
   3. Wszystko, gdzie pracujesz z dużymi zestawami danych i C ++, można zoptymalizować, aby uzyskać do nich dostęp w sposób przyjazny dla pamięci podręcznej.
2. Jest skompilowany do kodu bajtowego i skompilowany w JIT w czasie wykonywania. Compiled vs. Interpreted to fałszywa, nieaktualna dychotomia.
3. & 4. Jest zbyt wiele rzeczy, aby wymienić je wszystkie, a większość z nich nie będzie zgodna.

Po pierwsze, mój kontekst jest bardzo zardzewiały, więc większość moich doświadczeń z Javą odnosi się do mojego najnowszego doświadczenia z C #, który i tak jest o wiele większym porównaniu jabłek z jabłkami.

1. Prędkość

za. Jaka jest dzisiaj szybkość Javy w porównaniu z C ++?

Myślę, że najlepiej na to odpowiedzieć pytanie SO. Dlaczego java ma reputację powolności? ale myślę też, że całe to pytanie jest zabarwione blogiem Jeffa Atwooda, Gorilla vs. Shark . ^{Dzięki Péter i Christopher.}

b. Czy byłoby możliwe stworzenie nowoczesnego tytułu AAA za pomocą Java?

To zależy od priorytetów programistów i umiejętności programistów. Ponadto nie jest to ani jedna sytuacja, ani różne części tytułu mogą wymagać różnych elementów języka, w którym są implementowane, co prowadzi do powstania heterogenicznego środowiska językowego.

Widziałem ostatnio wiele gier, w których wspominają, że ładują środowisko Python podczas ładowania i podejrzewam, że konie na kursy są silną motywacją, jeśli chcesz wydać swój tytuł na czas sezonu wakacyjnego (na przykład) .

do. W jakich obszarach Java jest wolniejsza niż C ++, jeśli w ogóle? (tj. łamanie liczb, grafika lub po prostu dookoła)

Możesz napisać słabo działający kod w dowolnym języku, ale niektóre języki ułatwiają dokonywanie dobrych wyborów, podczas gdy inne są bardziej skłonne pozwolić sobie na wyciągnięcie ręki przez własnego petarda . Java należy do pierwszej kategorii, C ++ zdecydowanie do drugiej.

Z wielką mocą wiąże się wielka odpowiedzialność, jak mówią (nie wspominając o możliwości całkowitego spieprzenia stosu * 8 ').

2. Czy Java jest teraz uważana za język skompilowany lub język interpretowany?

Nie mogę powiedzieć, co uważa większość ludzi , ale wiele osób zna różnicę między językami kompilowanymi a tłumaczonymi i nie mieszkało w jaskini przez ostatnie 20 lat, wiedziałoby również, że JIT ( Just-in -Time ) kompilator jest ważną częścią ekosystemu Java, więc prawdopodobnie jest bardziej prawdopodobne, że zostanie uznany za skompilowany w dzisiejszych czasach.

3. Jakie są główne niedociągnięcia w Javie, które zostały usunięte od pierwszych dni?

Jestem dość niedawnym konwerterem na Javę, więc mam niewielki kontekst, jak ewoluowała. Warto jednak zauważyć, że istnieją książki takie jak Java: The Good Parts, które starają się kierować ludzi w kierunku części języka, które powinny być preferowane w dzisiejszych czasach i odciągać ludzi od obszarów, które są lub powinny być przestarzałe.

4. Jakie są poważne niedociągnięcia w Javie, które wymagają jeszcze rozwiązania?

Moim zdaniem jednym z problemów związanych z Javą było powolne wdrażanie nowych funkcji.

Po przejściu na Javę z C # i przejrzeniu strony porównawczej Wikipedii wyróżniają mnie:

Rzeczy, za którymi tęsknię w Javie, w porównaniu do C #

• Właściwości , zwłaszcza właściwości automatyczne. Robią Budowanie i utrzymywanie interfejsów znacznie łatwiejsze.
• Zamknięcia / lambdas . Byłem naprawdę rozczarowany, gdy usłyszałem, że obsługa Java została ponownie wyparta . ^{Wreszcie mamy Java / Closures / lambdas, ale czas, jaki to zajęło, świadczy o moim oświadczeniu o powolnym wdrażaniu.}
• Inferencja typów ( var) może wydawać się cukrem syntaktycznym, ale gdy masz złożone typy ogólne, może to uczynić kod znacznie wyraźniejszym poprzez usunięcie dużej ilości bezwartościowego powielania.
• Klasy częściowe naprawdę pomagają utrzymać automatycznie generowany kod (powiedzmy z konstruktora GUI) oddzielnie od kodu napisanego przez programistę.
• Typy wartości , czasami istnieje argument za zastosowaniem lekkości w structstosunku do pełnej klasy.
• Metody rozszerzeń mogą sprawić, że systemy będą skomplikowane, jeśli zostaną użyte w nadmiarze, ale świetnie nadają się do wskazania kanonicznego sposobu implementacji czegoś dla klasy, jeśli jest to potrzebne.
• Nie podpisane typy , czasem ten dodatkowy bit może mieć znaczenie. * 8 ')

Rzeczy, za którymi nie tęsknię w Javie, w porównaniu do C #

• Przeciążenie operatora jest świetne, gdy jest używane prawidłowo, ale gdy jest używane źle, może powodować trudności w znalezieniu błędów i rozłączenie między tym, co operator powinien oczywiście zrobić, a tym, co faktycznie robi.
• Rodzaje wartości dopuszczających wartości zerowe zawsze wydawały się powodować więcej problemów niż były warte.
• Dostęp do unsafekodu. Musisz być z tym tak ostrożny, że rzadko uważam, że jest to warte dodatkowego wysiłku.

Jako taki, nawet przy porównywaniu jabłek z jabłkami, uważa się, że Java pozostała w tyle.

Pozostałe dwa duże problemy, które widzę w Javie, to rażące opóźnienie uruchamiania oraz fakt, że (w przypadku niektórych maszyn JVM) musisz zarządzać stertą, a nawet stertą stałej generacji . Dzięki aplikacjom C # zawsze uruchamiano natychmiast i nigdy nie musiałem nawet myśleć o stercie, ponieważ został on przydzielony z puli pamięci systemowej, a nie z puli wstępnie przydzielonej przypisanej do maszyny wirtualnej.

Mogę wskazać ci źródło, które może pomóc ci odpowiedzieć na pierwszą część twojego pytania. Języki programowania strzelają http://shootout.alioth.debian.org/u64q/which-programming-languages-are-fastest.php jest całkiem dobrym źródłem do sprawdzenia, jak szybko języki się ze sobą porównują. Można je nawet filtrować według różnych kategorii, aby zobaczyć, w których obszarach języki radzą sobie lepiej niż inne. Java jest znacznie szybsza niż kilka lat temu.

1) Ściśle mówiąc o UX, które otrzymuję z Javą, wydaje się powolny. Nie mogę ci powiedzieć, dlaczego tak naprawdę. Nie spotkałem się jeszcze z aplikacją komputerową opartą na Javie, która nie jest powolna i ma szybszą alternatywę inną niż Java. To powiedziawszy, Java może być bardzo szybka z czystą szybkością obliczeniową, a Internet jest pełen testów, aby to udowodnić. Jednak czas uruchamiania aplikacji Java i szybkość reakcji ich graficznych interfejsów jeszcze nie poprawiły IMHO. Może mógłbyś to zrobić;)
Ostatecznie prędkość nie jest tak dużym problemem. Sprzęt jest nie tylko coraz szybszy i szybszy, ale także, że większość ludzi wciąż dba o to zaskakująco mało, dopóki robi to oprogramowanie, co powinien robić, a stosunek czasu spędzonego na interakcji do czasu oczekiwania jest rozsądny.

2) To rozróżnienie stało się ostatnio tak rozmyte, że ma naprawdę niewielką wartość.

3 + 4) W rzeczywistości nastąpiły pewne zmiany w Javie. Niektórzy twierdzą już, że zmiany te osłabiły czysto uproszczoną filozofię Javy, wykorzystując obce funkcje. Naprawdę trudno jest obiektywnie powiedzieć, czym jest wada i jaka jest siła. Dla mnie Java jest niepotrzebnie gadatliwa, restrykcyjna i uboga w funkcje, podczas gdy inni ludzie uważają te cechy za przyjemną jednoznaczność, bezpieczeństwo i przejrzystość.
Chociaż to właśnie te rzeczy sprawiają, że osobiście nie używam Javy, nie sądzę, aby dodawanie rzeczy, za którymi tęsknię w Javie, było dobrym pomysłem. Jest wiele języków, które lubię uruchamiać na JVM, a wyginanie Javy, aby być bliżej, po prostu pokonałoby cel Javy.

To kwestia preferencji

Rzecz w Javie polega na tym, że została zaprojektowana tak, aby uniemożliwić ci postrzelenie się w stopę. Szlachetna sprawa, ale przy wszystkich ograniczeniach, jakie na ciebie ciąży, nie jest prawdopodobne, że potkniesz się o jedną ze swoich bezpiecznych stóp, nie będziesz w stanie oprzeć się rękami związanymi za plecami dla własnego bezpieczeństwa i ostatecznie umrzeć, ponieważ łamiesz czaszkę. : D
W pewnym sensie Java była odpowiedzią na C ++, która daje ci wystarczająco dużo liny, aby nie tylko powiesić się, ale także resztę świata. To cała ta lina, która czyni ją tak atrakcyjną dla kowbojów. Cała ta wolność i cała ta moc.

Mówiąc wprost, jest to naprawdę kwestia preferencji.

Ale chodzi o to, że z C ++ jako alternatywą dla Javy, możesz swobodnie wybierać własne ograniczenia. Lub naprawdę zwariować na punkcie całej kontroli, ryzykując całkowitym zdezorientowaniem swoich rówieśników:

Widziałem, jak „cout” przesuwa się razy „Witaj świecie” w lewo i tam się zatrzymuję.
- Steve Gonedes

Z tego właśnie powodu Java zdecydowała się nie oferować przeciążania operatora. Oczywiście zapobiega to zaciemnianiu kodu przez mnożenie wskaźników funkcji przez listy. Ale jednocześnie uniemożliwia innym osobom wykonywanie obliczeń geometrycznych / algebraicznych za pomocą zwykłych operatorów. (v1 * v2 / scale) + (v3 * m)naprawdę jest o wiele jaśniejsze niż v1.multiply(v2).divide(scale).add(v3.multiply(m)). Rozumiem, dlaczego może to zniechęcać osoby zajmujące się grafiką 3D i obliczeniami.

Java zdecydowała się narzucić wyrzucanie elementów bezużytecznych, podczas gdy w C ++ możesz to zrobić. Możesz naprawdę kopać do samego końca i zbliżyć się do sprzętu. Możesz gęsto upakować dane do struktur. Możesz wykonywać mroczną magię, na przykład szybki odwrotny pierwiastek kwadratowy . Za pomocą szablonów możesz wykonywać najbardziej skomplikowane i tajemnicze metaprogramowanie na ziemi. Ale oznacza to również, że możesz się zgubić i spędzić godziny na debugowaniu całego bałaganu, który stworzyłeś lub przeglądaniu absolutnie niepomyślnych błędów kompilatora.
Ale jeśli masz dyscyplinę, aby używać tylko tych części języka, który naprawdę opanujesz, możesz pisać kod C ++ tak samo bezpiecznie, jak kod Java, ale masz możliwość stopniowego przejścia do przodu.

Tak więc, choć technicznie nic nie stoi na przeszkodzie, aby napisać najnowocześniejsze oprogramowanie w Javie, przekonasz się, że wielu programistów naprawdę pasjonuje się pisaniem świetnego oprogramowania oraz dobrą zabawą i ewolucją, wykraczając poza to, co Java oferuje jako język.

Ale świat nie składa się tylko z ludzi wyznaczonych do stworzenia następnej wielkiej rzeczy lub tylko z ludzi, którzy ograniczą użycie mocy, którą im przekazują, tylko w zakresie, w jakim ją kontrolują. IMHO Java jest idealnym rozwiązaniem dla osób, które chcą osiągać stabilne wyniki w wygodny sposób.

Śmieci to wielka sprawa. Co jakiś czas GC blokuje wszystko inne na kilkaset milisekund (w zależności od wielkości stosu) i wykonuje dużą kolekcję. Jest to w porządku, jeśli nie masz żadnych ograniczeń czasowych, ale jeśli spóźnienie oznacza porażkę, jest to zatrzymanie pokazu. Możesz wydawać pieniądze na Javę w czasie rzeczywistym i na system operacyjny w czasie rzeczywistym, ale możesz po prostu użyć GCC i standardowego Linuksa i nie będziesz mieć tych problemów.

Bez nieprzewidywalnych losowych przerw Java jest prawdopodobnie wystarczająco szybka na większość rzeczy w dzisiejszych czasach. A jeśli spędzasz miesiące na ulepszaniu ustawień GC i może, być może, może sprawisz, że będzie działał wystarczająco długo, aby klient mógł cię sprawdzić.

3) Naprawione niedociągnięcia.

Kilka lat temu w Javie było dużo gniewu. Większość programistów Java to programiści WWW / serwerów i oszaleli na punkcie gadatliwości Javy. Dlatego niektóre języki, takie jak Ruby, stały się popularne, a Java zaczęła słabnąć. Jednak dzięki nowym adnotacjom i frameworkom, takim jak hibernacja i Spring, ludzie przestali narzekać i wrócili do Javy.

4) Obecne niedociągnięcia

Sprzęt przechodzi w tryb wielordzeniowy. Chociaż Java może wykonywać wielowątkowość, jest oparta na języku C, który jest językiem sekwencyjnym, a funkcjonalność umożliwiająca wielowątkowość nie jest elegancka, delikatnie mówiąc. Nawiasem mówiąc, to nie jest tylko krytyka Javy, ale prawie wszystkie języki. Potrzebny jest zupełnie inny sposób myślenia o kodzie. Być może programowanie funkcjonalne jest drogą przyszłości.

W pewnym sensie zareagowałem na to pytanie, ponieważ da ono mylące i w dużej mierze nieistotne odpowiedzi:

b. Czy byłoby możliwe stworzenie nowoczesnego tytułu AAA za pomocą Java?

Wszyscy mogą się zgodzić, że tytuły AAA byłyby trudne do wyprodukowania przy użyciu Javy i że nie ma faktycznych przykładów, o których jestem świadomy. Jednak biorąc pod uwagę charakter AAA, który zakładałby wiele rzeczy (ponieważ tak naprawdę jest to mylące określenie pochodzące z marketingu), lepiej zamiast tego zapytać:

Czy można stworzyć nowoczesny tytuł z rozsądnym sukcesem przy użyciu Java?

Odpowiedź brzmi: „ Tak, możesz ”. Jednak faktyczna część sukcesu równania jest bardziej oparta na twojej wytrwałości i szczęściu (lub przestrzeganiu zeitgeist), ale to jest poza zakresem tej witryny.

Obszar prędkości Certian sprowadza się do kompilatora vs kompilatora. Nie język kontra język. Kompilacja JIT może mieć wiele zalet, ponieważ może ona zoptymalizować pod kątem specyfikacji komputera, na którym działa. Porównaj skompilowane JIT C ++ vs Java, aby uzyskać więcej kompilatora „jabłka do jabłek”.

Ale są pewne rzeczy, w których sam język Java ogranicza jego własną wydajność.

1. przydział na stosie. Java nie może tego zrobić. W przypadku małych klas stałych rozmiarów w rozwiązaniu nierekurencyjnym jest to często idealne rozwiązanie. Możesz także uniknąć fragmentacji sterty.

2. funkcje niebędące wirtualnymi. Java nie może tego zrobić. Wszystkie wywołania metod otrzymują stałe trafienie, nawet jeśli nie planuje się ich zastąpienia.

Prawdopodobnie jakieś inne rzeczy, ale to wszystko, co mogę myśleć z góry.

1) nieistotne i argumentujące do uruchomienia.
W Javie można tworzyć nie tylko duże oprogramowanie, ale takie systemy są dostarczane codziennie i do tej pory obsługują większość dużych firm na świecie.
2) podobnie.
Przeczytaj specyfikację JVM i wiesz. Java nigdy nie była językiem interpretowanym.
3) podobnie.
Przeczytaj 15 lat informacji o wersji. Nie jesteśmy w stanie dowiedzieć się, co uważasz za „poważne wady”, którym należy się zająć.
4) podobnie.
Główną wadą, którą należy rozwiązać, jest JCP, który ma skłonność do wtrącania się w podstawowy język i biblioteki bez żadnego wyraźnego powodu poza tym, aby uzyskać nazwisko Jomoene na JSR, aby mogli napisać książkę z autorytatywnym napisem, że „oni byli przywódca JSR-666 ”. Mamy nadzieję, że zajmie się tym restrukturyzacja JCP przez Oracle.
Wygląda na to, że po prostu chcesz wywołać wojnę językową i przekonać innych o uprzedzeniach do Javy, ponieważ sam nie możesz znaleźć prawdziwego uzasadnienia.