A Java kritikája

Az oldal jelenlegi verzióját még nem ellenőrizték tapasztalt közreműködők, és jelentősen eltérhet a 2021. december 25-én felülvizsgált verziótól ; az ellenőrzések 2 szerkesztést igényelnek .

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.

Általános jellemzők

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.

A nyelv szintaxisa és szemantikája

Generikus Java

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 } }

Előjel nélküli egész adattípusok

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.

Műveletek lebegőpontos számokkal

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]

Teljesítmény

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 .

Biztonság

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.

Lásd még

Jegyzetek

  1. Generics a Java nyelven . Object Computing, Inc. Letöltve : 2006. december 9. Az eredetiből archiválva : 2012. szeptember 3..
  2. Mi a baj a Java-val: Type Erasure (2006. december 6.). Letöltve: 2006. december 9. Az eredetiből archiválva : 2012. szeptember 3..
  3. Típustörlés . Az eredetiből archiválva: 2012. szeptember 3.
  4. Típusok, értékek és változók archiválva : 2012. február 28., a Wayback Machine , Java Languaege Specification, 2-nd ed.
  5. A Java könyvtáraknak támogatniuk kell az előjel nélküli egész számok aritmetikáját . Bug Database, Sun Developer Network . Jóslat. Hozzáférés dátuma: 2011. január 18. Az eredetiből archiválva : 2012. szeptember 3.
  6. Owen, Sean R. Java és előjel nélküli egészek Java és unsigned int, unsigned short, unsigned byte, unsigned long stb. (Vagy inkább annak hiánya) (2009. november 5.). Hozzáférés dátuma: 2010. október 9. Az eredetiből archiválva : 2009. február 20.
  7. Kahan, W.; Joseph D. Darcy. Hogyan fáj a Java lebegőpontos pontja mindenkinek mindenhol (PDF) (1998. március 1.). Letöltve: 2006. december 9. Az eredetiből archiválva : 2012. szeptember 3..
  8. Típusok, értékek és változók . Sun Microsystems. Letöltve: 2006. december 9. Az eredetiből archiválva : 2012. szeptember 3..
  9. Java elmélet és gyakorlat: hol a véleményed? Trükkök és csapdák lebegőpontos és decimális számokkal . IBM (2003. január 1.). Letöltve: 2011. november 19. Az eredetiből archiválva : 2012. szeptember 3..
  10. Számítógépes nyelvi teljesítménymérő játék: Java vs Gnu C++ . debian.org. Letöltve: 2011. november 19. Az eredetiből archiválva : 2012. szeptember 3..
  11. 1 2 J. P. Lewis és Ulrich Neumann. A Java teljesítménye a C++-hoz képest . Grafikai és magával ragadó technológiai laboratórium, Dél-Kaliforniai Egyetem . Archiválva az eredetiből 2012. május 3-án.
  12. A Java gyorsabb, mint a C++ és a C++ Sucks Unbased Benchmark . Letöltve: 2011. november 15. Az eredetiből archiválva : 2010. június 12.
  13. FreeTTS – A teljesítmény esettanulmánya archiválva : 2009. március 25. , Willie Walker, Paul Lamere, Philip Kwok
  14. 1 2 A kutatók kiemelték a Java biztonsági kizsákmányolásainak legutóbbi növekedését . Az eredetiből archiválva: 2012. szeptember 3.
  15. Ellenőrizted a Java-t? . Az eredetiből archiválva: 2012. szeptember 3.

Linkek