Critica la adresa Java

Versiunea actuală a paginii nu a fost încă examinată de colaboratori experimentați și poate diferi semnificativ de versiunea revizuită pe 25 decembrie 2021; verificările necesită 2 modificări .

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ă.

Caracteristici generale

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 MicrosystemsWrite 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.

Sintaxa și semantica limbajului

Generice în Java

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

Tipuri de date întregi nesemnate

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.

Operații asupra numerelor în virgulă mobilă

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]

Performanță

Î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 .

Securitate

Î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.

Vezi și

Note

  1. Generic în Java . Object Computing, Inc. Consultat la 9 decembrie 2006. Arhivat din original pe 3 septembrie 2012.
  2. What's Wrong With Java: Type Erasure (6 decembrie 2006). Consultat la 9 decembrie 2006. Arhivat din original pe 3 septembrie 2012.
  3. Ștergere tip . Arhivat din original pe 3 septembrie 2012.
  4. Tipuri, valori și variabile Arhivat la 28 februarie 2012 la Wayback Machine , specificația Java Language Specification, ed. a 2-a.
  5. Bibliotecile Java ar trebui să ofere suport pentru aritmetica numerelor întregi nesemnate . Baza de date de erori, Sun Developer Network . Oracol. Data accesului: 18 ianuarie 2011. Arhivat din original la 3 septembrie 2012.
  6. Owen, Sean R. Java și numere întregi nesemnate Java și unsigned int, unsigned short, unsigned byte, unsigned long etc. (Sau mai bine zis, lipsa acestuia) (5 noiembrie 2009). Data accesului: 9 octombrie 2010. Arhivat din original la 20 februarie 2009.
  7. Kahan, W.; Joseph D. Darcy. Cum doare virgulă mobilă Java pe toată lumea de pretutindeni (PDF) (1 martie 1998). Consultat la 9 decembrie 2006. Arhivat din original pe 3 septembrie 2012.
  8. Tipuri, valori și variabile . Microsisteme solare. Consultat la 9 decembrie 2006. Arhivat din original pe 3 septembrie 2012.
  9. Teoria și practica Java: Unde ai ideea? Trucuri și capcane cu virgulă mobilă și numere zecimale . IBM (1 ianuarie 2003). Consultat la 19 noiembrie 2011. Arhivat din original pe 3 septembrie 2012.
  10. Computer Language Benchmarks Game: Java vs Gnu C++ . debian.org. Consultat la 19 noiembrie 2011. Arhivat din original pe 3 septembrie 2012.
  11. 1 2 J.P. Lewis și Ulrich Neumann. Performanța Java versus C++ . Laborator de grafică și tehnologie imersivă, Universitatea din California de Sud . Arhivat din original pe 3 mai 2012.
  12. Java este mai rapid decât C++ și C++ sucks un benchmark imparțial . Consultat la 15 noiembrie 2011. Arhivat din original la 12 iunie 2010.
  13. FreeTTS - A Performance Case Study Arhivat 25 martie 2009. , Willie Walker, Paul Lamere, Philip Kwok
  14. 1 2 Cercetătorii evidențiază o creștere recentă a exploatărilor de securitate Java . Arhivat din original pe 3 septembrie 2012.
  15. Ai verificat Java? . Arhivat din original pe 3 septembrie 2012.

Link -uri