A Java kritikája a Java programozási nyelvet , az azonos nevű szoftverplatformot, az ezen nyelv és platform alapján hozott tervezési döntéseket, valamint a szervezetet érintő kritikák nagyszámú, különböző kifinomultsági fokának komplexe. a nyelv és a mögöttes platform fejlesztési folyamatáról.
A Java, valamint más széles körben elterjedt és népszerű HLL kritikája meglehetősen kiterjedt és heterogén. Ennek a kritikának a következő főbb aspektusai különböztethetők meg.
A Java alapideológiája. Maga az ötlet, hogy egy virtuális gép bájtkódjába fordított magas szintű nyelven alapuló rendszert hozzunk létre, és minden számítási platformhoz egy bájtkód értelmezőt hozzunk létre. Emellett a Java rendszerbe épített szemétgyűjtő alrendszer is kritika célpontja lehet . Java nyelv és az alapul szolgáló platform. A Java fejlesztők szinte minden technológiai megoldását kritizálják, beleértve a C/C++ szintaxis kölcsönzését, a csomaghierarchia ideológiáját és a projekt forrásfájlfa hierarchiájával való kapcsolatát, az alapszintű meglétét, készletét és működésének jellemzőit. skaláris adattípusok és aritmetika. Végrehajtás. A lebegőpontos számítások megvalósítását kritizálják, felhívják a figyelmet a beépített biztonsági rendszer sérülékenységeire. Az általános programozási mechanizmusok Java nyelven történő megvalósítását kritizálják . A Sun Microsystems szlogenjét: „ Írj egyszer, fuss mindenhol ” ( angol. írj egyszer, fuss mindenhol ) a kritikusok „egyszer írd meg, mindenhol debug”-ra (“ eng. write Once, debug everything ”) alakították át, utalva a számos különbség a mögöttes platformban, amelyeket figyelembe kell venni a nem triviális Java programok írásakor. [ tiszta ] Hatékonyság. A Java hatékonyságának hiányával kapcsolatos kritikák főként a nyelv és a platform implementációjának első, az 1990-es évek közepén megjelent verzióihoz kapcsolódnak. Ezt követően a processzorteljesítmény és a RAM lavina növekedése miatt a Java teljesítményével kapcsolatos kritikák sokkal kevésbé relevánsak. Azonban továbbra is találkozhatunk olyan állításokkal, miszerint a Java rendszerek „genetikai adottságai” túlzott memória- és processzoridőhöz vezetnek, miközben nem biztosítanak egyenértékű előnyt a gazdaságosabb fejlesztési eszközökkel szemben. Fejlődés. Egyes kritikusok úgy vélik, hogy a nyelvre vonatkozó szerzői jogok tulajdonosai által létrehozott nyelvfejlődési mechanizmusok akadályozzák a különféle újítások beépítését. Találkozni lehet egyenesen ellentétes véleményekkel is, miszerint a Java verziónkénti változtatások túl aktívak, a fejlesztők pedig nem annyira technikai megfontolások, mint inkább divat vezérelve új elemeket visznek be a nyelvbe, ami a nyelv indokolatlan bonyolításához vezet.Mire a Java 5.0 -ban az általánosokat hozzáadták , a Java platform nagy, erősen használt osztályhierarchiával rendelkezett, amelyek közül sok már elavult volt . A visszamenőleges kompatibilitás és a meglévő osztályok újrafelhasználásának biztosítása érdekében az általánosokat a típustörlési mechanizmus segítségével implementáltuk ( a bájtkódban az általános típusokat típus nélküli hivatkozások helyettesítik, ami lehetővé teszi a virtuális gép számára, hogy a szokásos módon hajtson végre kódot generikusokkal), amelyek szigorú korlátozásokat szabtak a használatukra. Más nyelveken a generikusok erősebbek, mert különböző mechanizmusokkal valósítják meg őket. [1] [2] Így például a .NET platformon a generikus implementációt közvetlenül a bájtkódot végrehajtó virtuális gép magjába implementálták, ami lehetővé tette némi bonyodalmak árán, hogy elkerüljük a Java- specifikus korlátozások, ugyanakkor nagymértékben megkönnyítette a generikumok beillesztését bármely implementált nyelvre ezen a platformon.
Mivel az általánosokat a típustörlés használatával valósították meg , tényleges típusa érhető el futás közben . Ezért a következő műveletek nem lehetségesek Java-ban: [3]
public class MyClass < E > { public static void myMethod ( Object item ) { if ( item instanceof E ) { // Fordítóhiba ... } E item2 = new E (); // Fordítóhiba E [] iArray = new E [ 10 ] ; // Fordítóhiba } }A Java nem valósítja meg a beépített előjel nélküli egész adattípusokat . [4] A C -programokban gyakran elő nem írt adatok , és ezen adattípusok hiánya a Java-ban megakadályozza a közvetlen kommunikációt a C-programok és a Java-programok között. A nagy előjel nélküli számokat számos numerikus feldolgozási feladatban is használják, beleértve a kriptográfiát is, ami miatt a Java kevésbé alkalmas más programozási nyelvekhez képest ezen feladatok automatizálására . [5] Bár ez a probléma részben megkerülhető a kód átalakításával és más adattípusok használatával, ez megnehezíti a Java-val való munkát az aláíratlan adatok kezelésekor. Bár a 32 bites előjelű egész számok adattípusa használható a 16 bites előjel nélküli számok értékének veszteség nélküli tárolására, a 32 bites előjel nélküli számokhoz 64 bites előjeles egész típusra lenne szükség, így egy 64 bites előjel nélküli számra. érték nem konvertálható helyesen semmilyen egész adattípusra Java-ban, mivel a Java-ban nincsenek adattípusok a 64-nél nagyobb bitmélységű számok kezelésére. Mindenesetre a memóriafelhasználás megduplázódik, és minden olyan logika, amely a túlcsordulási szabályoktól függ a kiegészítő kódot általában át kell írni. Alternatív megoldásként az előjeles Java egész adattípusok használhatók azonos méretű előjel nélküli egész adattípusok emulálására , azonban ehhez részletes ismeretekre van szükség az összetett bitenkénti műveletek kezelésében . [6] és csökkenti a kód olvashatóságát.
Bár a Java lebegőpontos műveletei elsősorban az IEEE 754 bináris lebegőpontos aritmetikai szabványon alapulnak , bizonyos funkciók még a strictfp módosítóval sem támogatottak mint és az egyenes kerekítés , amelyeket az IEEE 754 szabvány előír. , a nagy pontosságú lebegőpontos adattípusokat az IEEE 754 szabvány engedélyezi, sok processzorban implementálva van, Javaban nem. [7] [8] [9]
A Java első verzióiban (mielőtt a HotSpotot 2000 -ben implementálták a Java 1.3-ban ) sok kritika érte a gyenge teljesítményt. Bebizonyosodott, hogy a Java az optimalizált natív kódhoz hasonló sebességgel fut, és a Java virtuális gép modern megvalósításai rendszeresen a legjobb elérhető nyelvi platformok között teljesítenek a teljesítménytesztekben – általában 3 pozíción belül a C / C++- hoz képest . [tíz]
A Java teljesítménye jelentősen javult az új verziókban a korábbiakhoz képest. [11] A JIT fordítók teljesítménye az általános célú fordítókhoz képest néhány mesterségesen testreszabott tesztben összehasonlíthatónak bizonyult. [11] [12] [13]
A Java bájtkód futás közben értelmezhető egy virtuális gép által, vagy a program betöltési idején vagy futás közben lefordítható gépi kódba , amely közvetlenül a számítógépen fut. Az értelmezés lassabb, mint a natív kód végrehajtása, és a program betöltési vagy futási idejében történő fordítás csökkenti a teljesítményt a fordítási idő árán. A Java Virtual Machine modern, nagy teljesítményű megvalósításai fordítást használnak, így (a JIT-fordítás elindítása után) az alkalmazás a platform-specifikus kódhoz közeli teljesítményt mutat .
2010-ben jelentősen megnőtt a JVM sandbox korlátozásait a böngészőkben megkerülő kihasználások száma, ami támadhatóbbá tette a Java-t, mint az Acrobat és a Flash. [tizennégy]
A kritikusok úgy vélik, hogy a JVM frissített verzióit nem használják, mert sok felhasználó egyszerűen nem tudja, hogy van JVM telepítve a számítógépére, és mert sok felhasználó nem tudja, hogyan kell frissíteni a JVM-et. Ami a vállalati számítógépeket illeti, sok vállalat korlátozza a felhasználók jogait a szoftverek telepítéséhez és a frissítések túl lassú telepítéséhez. [14] [15]
A JVM legújabb verziói Java-kisegítő lehetőségeket tartalmaznak a böngészőkben.