Kritik mot Java är ett komplex av ett stort antal olika grader av sofistikering av kritik mot programmeringsspråket Java , programvaruplattformen med samma namn , designbeslut som fattas på grundval av detta språk och plattform, såväl som till organisationen av språkets utvecklingsprocess och den bakomliggande plattformen.
Kritiken mot Java, liksom andra utbredda och populära HLL , är ganska omfattande och heterogen. Följande huvudaspekter av denna kritik kan särskiljas.
Javas grundläggande ideologi. Själva idén med att skapa ett system baserat på ett högnivåspråk kompilerat i bytekoden för en virtuell maskin och skapa en bytekodtolkare för varje datorplattform kritiseras. Dessutom kan undersystemet för sophämtning som är inbyggt i Java-systemet vara ett mål för kritik . Java-språk och underliggande plattform. Nästan alla tekniska lösningar för Java-utvecklare kritiseras, inklusive lån av C/C++-syntaxen, pakethierarkins ideologi och dess koppling till hierarkin i projektkällfilträdet, närvaron, uppsättningen och funktionerna i grundläggande funktioner. skalära datatyper och aritmetik. Genomförande. Implementeringen av flyttalsberäkningar kritiseras, uppmärksamhet uppmärksammas på sårbarheter i det inbyggda säkerhetssystemet. Implementeringen av generiska programmeringsmekanismer i Java kritiseras . Sun Microsystems slogan " Write once, run everywhere " ( eng. skriv en gång, kör överallt ) gjordes om av kritiker till "write once, debug everywhere" (" eng. write once, debug everywhere "), med hänvisning till många skillnader i den underliggande plattformen som måste beaktas när du skriver alla icke-triviala Java-program. [ klara upp ] Effektivitet. Kritiken om bristen på effektivitet hos Java är främst relaterad till de första versionerna av implementeringen av språket och plattformen, som släpptes i mitten av 1990-talet. Därefter gjorde lavintillväxten av processorprestanda och RAM-minne kritiken av Java-prestanda mycket mindre relevant. Men man kan fortfarande stöta på påståenden om att de "genetiska egenskaperna" hos Java-system leder till för mycket minne och processortid, samtidigt som de inte ger motsvarande fördelar jämfört med mer ekonomiska utvecklingsverktyg. Utveckling. Vissa kritiker tror att de mekanismer för språkutveckling som skapats av ägare av upphovsrätt till språket hindrar införandet av olika innovationer i det. Du kan också möta rakt motsatta åsikter, enligt vilka Java-ändringar från version till version är för aktiva, och utvecklare introducerar nya element i språket, styrda inte så mycket av tekniska överväganden som av mode, vilket leder till omotiverad komplikation av språket.När generika lades till i Java 5.0 hade Java-plattformen en stor, mycket använd klasshierarki, varav många var föråldrade . För att säkerställa bakåtkompatibilitet och möjligheten att återanvända befintliga klasser implementerades generika med hjälp av typraderingsmekanismen (i bytekod ersätts generiska typer med otypade referenser, vilket gör att den virtuella maskinen kan exekvera kod med generika på samma sätt som normalt). som införde stränga restriktioner för deras användning. På andra språk är generika mer kraftfulla eftersom de implementeras med olika mekanismer. [1] [2] Så, till exempel på .NET-plattformen, implementerades generika direkt i kärnan av den virtuella maskinen som exekverade bytekod, vilket gjorde det möjligt, till bekostnad av en viss komplikation, att undvika Java- specifika begränsningar och underlättade samtidigt införandet av generika på alla implementerade språk på denna plattform.
Eftersom generika implementerades med typradering faktiska typen av inte tillgänglig vid körning . Därför är följande operationer inte möjliga i Java: [3]
public class MyClass < E > { public static void myMethod ( Object item ) { if ( item instanceof E ) { // Compiler error ... } E item2 = new E (); // Kompilatorfel E [] iArray = ny E [ 10 ] ; // Kompilatorfel } }Java implementerar inte inbyggda osignerade heltalsdatatyper . [4] Osignerad data genereras ofta i C -program , och frånvaron av dessa datatyper i Java förhindrar direkt kommunikation mellan C-program och Java-program. Stora osignerade nummer används också i många numeriska bearbetningsuppgifter, inklusive kryptografi , vilket kan göra Java mindre lämpligt än andra programmeringsspråk för att automatisera dessa uppgifter . [5] Även om det är möjligt att delvis kringgå detta problem genom att konvertera koden och använda andra datatyper, gör detta det krångligt att arbeta med Java när man hanterar osignerad data. Även om datatypen för 32-bitars signerade heltal kan användas för att lagra värdet av ett 16-bitars osignerat tal utan förlust, skulle ett 32-bitars osignerat tal kräva en 64-bitars signerad heltalstyp, och därmed en 64-bitars osignerad värde kan inte korrekt konverteras till någon heltalsdatatyp i Java, eftersom det inte finns några datatyper i Java för att hantera nummer med ett bitdjup större än 64. Minnesförbrukningen fördubblas i alla fall och all logik som beror på överflödesreglerna tilläggskoden behöver vanligtvis skrivas om. Alternativt kan signerade Java-heltalsdatatyper användas för att emulera osignerade heltalsdatatyper av samma storlek, men detta kräver detaljerad kunskap om att arbeta med komplexa bitvisa operationer . [6] och minskar kodens läsbarhet.
Även om flyttalsoperationer i Java huvudsakligen är baserade på den binära flyttalsaritmetiska standarden IEEE 754 , stöds vissa funktioner inte ens med strictfp-modifieraren undantagsflaggor rak avrundning , funktioner som tillhandahålls enligt kraven i IEEE 754-standarden. , högprecisions flyttalsdatatyper tillåts av IEEE 754-standarden, implementerad i många processorer , inte implementerad i Java. [7] [8] [9]
I de första versionerna av Java (innan HotSpot implementerades i Java 1.3 år 2000 ) fanns det mycket kritik om dålig prestanda. Java har visat sig köra med hastigheter jämförbara med optimerad inbyggd kod, och moderna implementeringar av den virtuella Java-maskinen presterar regelbundet bland de bästa tillgängliga språkplattformarna i prestandatester - vanligtvis inom 3 positioner i förhållande till C / C++ . [tio]
Java-prestanda har förbättrats avsevärt i nya versioner jämfört med tidigare. [11] Prestandan hos JIT-kompilatorer jämfört med kompilatorer för allmänna ändamål i vissa konstgjorda skräddarsydda tester visade sig vara jämförbara. [11] [12] [13]
Java-bytekod kan antingen tolkas vid körning av en virtuell maskin, eller så kan den kompileras vid programladdning eller vid körning till maskinkod som körs direkt på datorn. Tolkning är långsammare än att köra inbyggd kod, och kompilering vid programladdningstid eller körning minskar prestandan på bekostnad av kompileringstid. Moderna högpresterande implementeringar av Java Virtual Machine använder kompilering, så (efter att JIT-kompilering har utlösts ) visar applikationen prestanda nära plattformsspecifik kod .
Under 2010 skedde en betydande ökning av antalet utnyttjanden för att kringgå JVM -sandlådebegränsningar i webbläsare, vilket gjorde Java mer attackerbart än Acrobat och Flash. [fjorton]
Kritiker tror att uppdaterade versioner av JVM inte används eftersom många användare helt enkelt inte vet att de har en JVM installerad på sin dator, och för att många användare inte vet hur man uppdaterar JVM. När det gäller företagsdatorer begränsar många företag användarnas rättigheter att installera programvara och installera uppdateringar för långsamt. [14] [15]
Senaste versioner av JVM har Java-tillgänglighetsalternativ i webbläsare.