Kritika Javy je komplexem velkého množství různých stupňů sofistikovanosti kritiky vznesené vůči programovacímu jazyku Java , softwarové platformě stejného jména , návrhových rozhodnutí učiněných na základě tohoto jazyka a platformy, jakož i vůči organizaci. procesu vývoje jazyka a základní platformy.
Kritika Javy, stejně jako dalších rozšířených a populárních HLL , je poměrně rozsáhlá a heterogenní. Lze rozlišit následující hlavní aspekty této kritiky.
Základní ideologie Javy. Kritizována je samotná myšlenka vytvoření systému založeného na vysokoúrovňovém jazyce zkompilovaném do bajtkódu virtuálního stroje a vytvoření interpretru bajtového kódu pro každou výpočetní platformu. Také subsystém garbage collection zabudovaný do systému Java může být terčem kritiky . Jazyk Java a základní platforma. Kritizována jsou téměř všechna technologická řešení Java vývojářů, včetně vypůjčení syntaxe C/C++, ideologie hierarchie balíčků a její propojení s hierarchií stromu zdrojového souboru projektu, přítomnost, sada a vlastnosti fungování základních skalární datové typy a aritmetika. Implementace. Kritizována je implementace výpočtů s pohyblivou řádovou čárkou, pozornost je věnována zranitelnostem vestavěného bezpečnostního systému. Implementace obecných programovacích mechanismů v Javě je kritizována . Slogan společnosti Sun Microsystems „ Napiš jednou, spusť všude ) ( anglicky jednou zapiš, spusť všude ) kritici předělali na „zapiš jednou, laď všude“ („ eng. napiš jednou, odlaď všude “) s odkazem na četné rozdíly v základní platformě, které je třeba vzít v úvahu při psaní jakýchkoli netriviálních Java programů.[ vyčistit ] Účinnost. Výtky ohledně nedostatečné účinnosti Javy se týkají především prvních verzí implementace jazyka a platformy, které byly vydány v polovině 90. let. Následně lavinový růst výkonu procesoru a RAM způsobil, že kritika výkonu Javy byla mnohem méně relevantní. Stále se však lze setkat s tvrzeními, že „genetické vlastnosti“ systémů Java vedou k nadměrné paměti a času procesoru, přičemž neposkytují ekvivalentní výhody oproti ekonomičtějším vývojovým nástrojům. Rozvoj. Někteří kritici se domnívají, že mechanismy vývoje jazyka vytvořené vlastníky autorských práv k jazyku brání začlenění různých inovací do něj. Můžete se setkat i s přímo opačnými názory, podle kterých jsou změny v Javě z verze na verzi příliš aktivní a vývojáři do jazyka zavádějí nové prvky, neřídí se ani tak technickými ohledy, jako spíše módou, což vede k neopodstatněné komplikaci jazyka.V době, kdy byla v Javě 5.0 přidána generika , měla platforma Java rozsáhlou, silně používanou hierarchii tříd, z nichž mnohé byly zastaralé . Aby byla zajištěna zpětná kompatibilita a možnost opětovného použití existujících tříd, byla generika implementována pomocí mechanismu mazání typu (v bajtovém kódu jsou generické typy nahrazeny netypovými odkazy, což umožňuje virtuálnímu stroji spouštět kód s generiky stejným způsobem jako normálně), která ukládala přísná omezení jejich používání. V jiných jazycích jsou generika výkonnější, protože jsou implementována pomocí různých mechanismů. [1] [2] Takže například na platformě .NET byla implementace generik implementována přímo do jádra virtuálního stroje vykonávajícího bytecode, což umožnilo za cenu určité komplikace vyhnout se Java- specifická omezení a zároveň výrazně usnadnil začlenění generik do jakýchkoliv implementovaných jazyků na této platformě.
Protože generika byla implementována pomocí erasure skutečný typ šablony není za běhu dostupný . V Javě proto nejsou možné následující operace: [3]
public class MyClass < E > { public static void mojeMetoda ( Object item ) { if ( item instanceof E ) { // Chyba kompilátoru ... } E item2 = new E (); // Chyba kompilátoru E [] iArray = new E [ 10 ] ; // Chyba kompilátoru } }Java neimplementuje vestavěné celočíselné datové typy bez znaménka . [4] V programech C se často generují nepodepsaná data a absence těchto datových typů v Javě brání přímé komunikaci mezi C programy a Java programy. Velká čísla bez znaménka se také používají v mnoha úlohách numerického zpracování, včetně kryptografie , což může způsobit, že Java je pro automatizaci těchto úloh méně vhodná než jiné programovací jazyky . [5] I když je možné tento problém částečně obejít převodem kódu a použitím jiných datových typů, je práce s Javou při manipulaci s nepodepsanými daty těžkopádná. Ačkoli datový typ pro 32bitová celá čísla se znaménkem lze použít k uložení hodnoty 16bitového čísla bez znaménka beze ztráty, 32bitové číslo bez znaménka by vyžadovalo 64bitový typ celého čísla se znaménkem, a tedy 64bitové číslo bez znaménka. hodnotu nelze v Javě správně převést na žádný celočíselný datový typ, protože v Javě neexistují žádné datové typy pro zpracování čísel s bitovou hloubkou větší než 64. V každém případě se spotřeba paměti zdvojnásobí a jakákoli logika, která závisí na pravidlech přetečení dodatečný kód je obvykle potřeba přepsat. Alternativně lze použít celočíselné datové typy Java se znaménkem k emulaci celočíselných dat bez znaménka stejné velikosti, což však vyžaduje podrobné znalosti práce se složitými bitovými operacemi . [6] a snižuje čitelnost kódu.
Přestože operace s plovoucí desetinnou čárkou v Javě jsou primárně založeny na binárním aritmetickém standardu IEEE 754 s pohyblivou řádovou čárkou , některé funkce nejsou podporovány ani s modifikátorem strictfp jako a rovné zaokrouhlování , což jsou funkce poskytované podle standardu IEEE 754. , vysoce přesné datové typy s plovoucí desetinnou čárkou jsou povoleny standardem IEEE 754, který je implementován v mnoha procesorech a není implementován v Javě. [7] [8] [9]
V prvních verzích Javy (před implementací HotSpot v Javě 1.3 v roce 2000 ) bylo hodně kritizováno kvůli špatnému výkonu. Ukázalo se, že Java běží rychlostí srovnatelnou s optimalizovaným nativním kódem a moderní implementace virtuálního stroje Java si pravidelně vedou mezi nejlepšími dostupnými jazykovými platformami ve výkonnostních testech – obvykle do 3 pozic ve srovnání s C / C++ . [deset]
Výkon Javy se v nových verzích oproti dřívějším výrazně zlepšil. [11] Výkon JIT kompilátorů ve srovnání s univerzálními kompilátory v některých uměle upravených testech byl shledán srovnatelný. [11] [12] [13]
Bytekód Java může být buď interpretován za běhu virtuálním strojem, nebo může být zkompilován při načítání programu nebo za běhu do strojového kódu , který běží přímo na počítači. Interpretace je pomalejší než provádění nativního kódu a kompilace při načítání programu nebo za běhu snižuje výkon na úkor času kompilace. Moderní vysoce výkonné implementace Java Virtual Machine používají kompilaci, takže (po spuštění kompilace JIT ) aplikace vykazuje výkon blízký kódu specifickému pro platformu .
V roce 2010 došlo k výraznému nárůstu počtu exploitů k obcházení omezení JVM sandboxu v prohlížečích, díky čemuž je Java více napadnutelná než Acrobat a Flash. [čtrnáct]
Kritici se domnívají, že aktualizované verze JVM se nepoužívají, protože mnoho uživatelů jednoduše neví, že mají na svém počítači nainstalované JVM, a protože mnoho uživatelů neví, jak JVM aktualizovat. Co se týče podnikových počítačů, mnoho společností omezuje práva uživatelů instalovat software a instalovat aktualizace příliš pomalu. [14] [15]
Nejnovější verze JVM mají možnosti usnadnění Java v prohlížečích.