Critica Java este un complex de un număr mare de grade diferite de sofisticare a criticilor aduse limbajului de programare Java , platformei software cu același nume , deciziilor de proiectare luate pe baza acestui limbaj și platformă, precum și organizației a procesului de dezvoltare a limbajului și a platformei de bază.
Critica la adresa Java, precum și a altor HLL răspândite și populare , este destul de extinsă și eterogenă. Se pot distinge următoarele aspecte principale ale acestei critici.
Ideologia de bază a Java. Este criticată însăși ideea de a crea un sistem bazat pe un limbaj de nivel înalt compilat în bytecode al unei mașini virtuale și de a crea un interpret de bytecode pentru fiecare platformă de calcul. De asemenea, subsistemul de colectare a gunoiului încorporat în sistemul Java poate fi o țintă pentru critici . Limbajul Java și platforma de bază. Aproape toate soluțiile tehnologice ale dezvoltatorilor Java sunt criticate, inclusiv împrumutarea sintaxei C/C++, ideologia ierarhiei pachetelor și legătura acesteia cu ierarhia arborelui fișierului sursă al proiectului, prezența, setul și caracteristicile funcționării de bază. tipuri de date scalare și aritmetică. Implementarea. Implementarea calculelor în virgulă mobilă este criticată, se atrage atenția asupra vulnerabilităților din sistemul de securitate încorporat. Implementarea mecanismelor de programare generică în Java este criticată . Sloganul Sun Microsystems „ Write once, run everywhere ” ( eng. write once, run everywhere ) a fost refăcut de critici în „write once, debug everywhere” („ ing. scrie o dată, debug everywhere ”), referindu-se la numeroase diferențe în platforma de bază care trebuie luate în considerare la scrierea oricăror programe Java non-triviale.[ clarifica ] Eficienţă. Criticile legate de lipsa de eficiență a Java sunt legate în principal de primele versiuni ale implementării limbajului și platformei, lansate la mijlocul anilor 1990. Ulterior, creșterea avalanșă a performanței procesorului și a memoriei RAM a făcut criticile la adresa performanței Java mult mai puțin relevante. Cu toate acestea, se mai pot întâlni afirmații conform cărora „trăsăturile genetice” ale sistemelor Java conduc la memorie și timp de procesor excesiv, fără a oferi în același timp avantaje echivalente față de instrumentele de dezvoltare mai economice. Dezvoltare. Unii critici consideră că mecanismele de dezvoltare a limbajului create de proprietarii drepturilor de autor asupra limbii împiedică includerea diferitelor inovații în aceasta. De asemenea, puteți întâlni opinii direct opuse, conform cărora modificările Java de la versiune la versiune sunt prea active, iar dezvoltatorii introduc elemente noi în limbaj, ghidați nu atât de considerente tehnice, cât de modă, ceea ce duce la complicarea nejustificată a limbajului.Până în momentul în care au fost adăugate generice în Java 5.0, platforma Java avea o ierarhie de clase mare, foarte utilizată, dintre care multe erau învechite . Pentru a asigura compatibilitatea inversă și capacitatea de a reutiliza clasele existente, genericele au fost implementate folosind mecanismul de ștergere a tipului (în bytecode, tipurile generice sunt înlocuite cu referințe netipizate, ceea ce permite mașinii virtuale să execute cod cu generice în același mod ca în mod normal), care a impus restricţii severe asupra utilizării lor. În alte limbi, genericele sunt mai puternice, deoarece sunt implementate folosind mecanisme diferite. [1] [2] Deci, de exemplu, pe platforma .NET, implementarea genericelor a fost implementată direct în nucleul mașinii virtuale care executa bytecode, ceea ce a făcut posibil, cu prețul unor complicații, evitarea Java- limitări specifice și, în același timp, a facilitat foarte mult includerea genericelor în orice limbă implementată pe această platformă.
Deoarece genericele au fost implementate folosind ștergerea real al parametrului șablon nu este disponibil la runtime . Prin urmare, următoarele operații nu sunt posibile în Java: [3]
public class MyClass < E > { public static void myMethod ( Object item ) { if ( item instanceof E ) { // Eroare compilator ... } E item2 = new E (); // Eroare compilator E [] iArray = nou E [ 10 ] ; // Eroare compilator } }Java nu implementează tipuri de date întregi nesemnate încorporate . [4] Datele nesemnate sunt adesea generate în programele C , iar absența acestor tipuri de date în Java împiedică comunicarea directă între programele C și programele Java. Numerele mari nesemnate sunt, de asemenea, folosite în multe sarcini de procesare numerică, inclusiv criptografia , ceea ce poate face Java mai puțin potrivit decât alte limbaje de programare pentru automatizarea acestor sarcini . [5] Deși este posibil să ocoliți parțial această problemă prin conversia codului și prin utilizarea altor tipuri de date, acest lucru face dificilă lucrarea cu Java atunci când se manipulează date nesemnate. Deși tipul de date pentru numere întregi cu semn pe 32 de biți poate fi utilizat pentru a stoca valoarea unui număr nesemnat pe 16 biți fără pierderi, un număr fără semn pe 32 de biți ar necesita un tip întreg cu semn pe 64 de biți și, prin urmare, un număr nesemnat pe 64 de biți. valoarea nu poate fi convertită corect în niciun tip de date întreg în Java, deoarece nu există tipuri de date în Java pentru manipularea numerelor cu o adâncime de biți mai mare de 64. În orice caz, consumul de memorie este dublat și orice logică care depinde de regulile de depășire. codul suplimentar trebuie de obicei rescris. Alternativ, tipurile de date întregi Java semnate pot fi utilizate pentru a emula tipuri de date întregi nesemnate de aceeași dimensiune, totuși, acest lucru necesită cunoștințe detaliate despre lucrul cu operații complexe pe biți . [6] și reduce lizibilitatea codului.
Deși operațiunile cu virgulă mobilă în Java se bazează în principal pe standardul aritmetic binar în virgulă mobilă IEEE 754 , unele caracteristici nu sunt acceptate nici măcar cu modificatorul strictfp cum ar semnalizatoarele de rotunjirea dreaptă , caracteristici furnizate conform cerințelor standardului IEEE 754. În plus. , tipurile de date în virgulă mobilă de înaltă precizie sunt permise de standardul IEEE 754, implementat în multe procesoare , neimplementat în Java. [7] [8] [9]
În primele versiuni de Java (înainte ca HotSpot să fie implementat în Java 1.3 în 2000 ), au existat multe critici cu privire la performanța slabă. S-a demonstrat că Java rulează la viteze comparabile cu codul nativ optimizat, iar implementările moderne ale mașinii virtuale Java funcționează în mod regulat printre cele mai bune platforme de limbaj disponibile în testele de performanță - de obicei în 3 poziții față de C / C++ . [zece]
Performanța Java s-a îmbunătățit semnificativ în versiunile noi în comparație cu versiunile anterioare. [11] Performanța compilatoarelor JIT în comparație cu compilatoarele de uz general în unele teste adaptate artificial s-a dovedit a fi comparabilă. [11] [12] [13]
Codul de octeți Java poate fi interpretat fie în timpul rulării de către o mașină virtuală, fie poate fi compilat în timpul încărcării programului sau în timpul rulării în codul mașinii care rulează direct pe computer. Interpretarea este mai lentă decât executarea codului nativ, iar compilarea la timpul de încărcare a programului sau timpul de rulare reduce performanța cu prețul timpului de compilare. Implementările moderne de înaltă performanță ale mașinii virtuale Java folosesc compilarea, așa că (după declanșarea compilației JIT ) aplicația arată performanțe apropiate de codul specific platformei .
În 2010, a existat o creștere semnificativă a numărului de exploit-uri pentru a evita restricțiile JVM sandbox în browsere, făcând Java mai atacabil decât Acrobat și Flash. [paisprezece]
Criticii cred că versiunile actualizate ale JVM-ului nu sunt folosite pentru că mulți utilizatori pur și simplu nu știu că au un JVM instalat pe computer și pentru că mulți utilizatori nu știu cum să actualizeze JVM-ul. În ceea ce privește computerele corporative, multe companii limitează drepturile utilizatorilor de a instala software și de a instala actualizări prea încet. [14] [15]
Versiunile recente ale JVM au opțiuni de accesibilitate Java în browsere.