Kritik af Java er et kompleks af en lang række forskellige grader af sofistikering af kritik fremsat af Java - programmeringssproget , softwareplatformen af samme navn , designbeslutninger truffet på grundlag af dette sprog og platform, såvel som til organisationen af sprogets udviklingsproces og den bagvedliggende platform.
Kritikken af Java, såvel som andre udbredte og populære HLL , er ret omfattende og heterogen. Der kan skelnes mellem følgende hovedaspekter af denne kritik.
Grundlæggende ideologi af Java. Selve ideen om at skabe et system baseret på et højt niveau sprog kompileret ind i bytekoden på en virtuel maskine og skabe en bytekode fortolker for hver computerplatform kritiseres. Desuden kan affaldsopsamlingsundersystemet, der er indbygget i Java-systemet, være et mål for kritik . Java sprog og underliggende platform. Næsten alle teknologiske løsninger fra Java-udviklere kritiseres, inklusive lån af C/C++-syntaksen, ideologien af pakkehierarkiet og dets forbindelse med hierarkiet af projektkildefiltræet, tilstedeværelsen, sæt og funktioner i funktionen af grundlæggende skalære datatyper og aritmetik. Implementering. Implementeringen af floating point-beregninger kritiseres, opmærksomheden henledes på sårbarheder i det indbyggede sikkerhedssystem. Implementeringen af generiske programmeringsmekanismer i Java kritiseres . Sun Microsystems slogan " Write once, run everywhere " ( eng. skriv en gang, løb overalt ) blev omdannet af kritikere til "skriv en gang, debug overalt" (" eng. skriv en gang, debug overalt "), med henvisning til talrige forskelle i den underliggende platform, der skal tages i betragtning, når du skriver eventuelle ikke-trivielle Java-programmer. [ ryd op ] Effektivitet. Kritikken af Javas manglende effektivitet er hovedsageligt relateret til de første versioner af implementeringen af sproget og platformen, udgivet i midten af 1990'erne. Efterfølgende gjorde lavinevæksten i processorydeevne og RAM kritik af Java-ydeevne meget mindre relevant. Imidlertid kan man stadig støde på påstande om, at de "genetiske egenskaber" i Java-systemer fører til overdreven hukommelse og processortid, mens de ikke giver tilsvarende fordele i forhold til mere økonomiske udviklingsværktøjer. Udvikling. Nogle kritikere mener, at mekanismerne for sprogudvikling skabt af ejere af ophavsrettigheder til sproget hindrer inddragelsen af forskellige innovationer i det. Du kan også møde direkte modsatte meninger, ifølge hvilke Java-ændringer fra version til version er for aktive, og udviklere introducerer nye elementer i sproget, styret ikke så meget af tekniske overvejelser som af mode, hvilket fører til uberettiget komplikation af sproget.Da generika blev tilføjet i Java 5.0, havde Java-platformen et stort, meget brugt klassehierarki, hvoraf mange var forældede . For at sikre bagudkompatibilitet og muligheden for at genbruge eksisterende klasser, blev generika implementeret ved hjælp af typesletningsmekanismen (i bytekode erstattes generiske typer med utypede referencer, hvilket gør det muligt for den virtuelle maskine at eksekvere kode med generics på samme måde som normalt). som indførte strenge restriktioner for deres brug. På andre sprog er generika mere kraftfulde, fordi de implementeres ved hjælp af forskellige mekanismer. [1] [2] Så for eksempel på .NET-platformen blev implementeringen af generiske stoffer implementeret direkte i kernen af den virtuelle maskine, der eksekverer bytekode, hvilket gjorde det muligt, på bekostning af en vis komplikation, at undgå Java- specifikke begrænsninger og på samme tid lettet i høj grad inkluderingen af generiske stoffer på alle implementerede sprog på denne platform.
Fordi generiske artikler blev implementeret ved hjælp af sletning faktiske type af skabelonparameteren ikke tilgængelig under kørsel . Derfor er følgende operationer ikke mulige i Java: [3]
public class MyClass < E > { public static void myMethod ( Object item ) { if ( item instanceof E ) { // Compiler error ... } E item2 = new E (); // Compiler fejl E [] iArray = ny E [ 10 ] ; // Compiler fejl } }Java implementerer ikke indbyggede usignerede heltalsdatatyper . [4] Usignerede data genereres ofte i C -programmer , og fraværet af disse datatyper i Java forhindrer direkte kommunikation mellem C-programmer og Java-programmer. Store usignerede tal bruges også i mange numeriske behandlingsopgaver, herunder kryptografi , hvilket kan gøre Java mindre egnet end andre programmeringssprog til at automatisere disse opgaver . [5] Selvom det er muligt delvist at omgå dette problem ved at konvertere koden og bruge andre datatyper, gør dette det besværligt at arbejde med Java ved håndtering af usignerede data. Selvom datatypen for 32-bit fortegnede heltal kan bruges til at lagre værdien af et 16-bit usigneret tal uden tab, ville et 32-bit usigneret tal kræve en 64-bit fortegnsheltalstype og dermed en 64-bit usigneret tal værdi kan ikke konverteres korrekt til nogen heltalsdatatype i Java, da der ikke er nogen datatyper i Java til håndtering af tal med en bitdybde større end 64. Under alle omstændigheder fordobles hukommelsesforbruget, og enhver logik, der afhænger af overløbsreglerne ekstra kode skal normalt omskrives. Alternativt kan signerede Java-heltalsdatatyper bruges til at emulere usignerede heltalsdatatyper af samme størrelse, men dette kræver detaljeret viden om at arbejde med komplekse bitvise operationer . [6] og reducerer kodens læsbarhed.
Selvom operationer med flydende komma i Java primært er baseret på den binære flydende aritmetiske standard IEEE 754 , understøttes nogle funktioner ikke, selv med strictfp-modifikatoren såsom lige afrunding , funktioner, der leveres som krævet af IEEE 754-standarden. , højpræcisions flydende kommadatatyper er tilladt af IEEE 754-standarden, implementeret i mange processorer , ikke implementeret i Java. [7] [8] [9]
I de første versioner af Java (før HotSpot blev implementeret i Java 1.3 i 2000 ) var der megen kritik af dårlig ydeevne. Java har vist sig at køre med hastigheder, der kan sammenlignes med optimeret indbygget kode, og moderne implementeringer af den virtuelle Java-maskine udfører regelmæssigt blandt de bedste tilgængelige sprogplatforme i ydeevnetest - normalt inden for 3 positioner i forhold til C / C++ . [ti]
Java-ydeevne er forbedret betydeligt i nye versioner sammenlignet med tidligere. [11] Ydeevnen af JIT -kompilatorer sammenlignet med compilere til generelle formål i nogle kunstigt skræddersyede tests blev fundet at være sammenlignelige. [11] [12] [13]
Java-bytekode kan enten fortolkes ved kørsel af en virtuel maskine, eller den kan kompileres ved programindlæsningstid eller ved kørsel til maskinkode, der kører direkte på computeren. Fortolkning er langsommere end at udføre indbygget kode, og kompilering ved programindlæsningstid eller runtime reducerer ydeevnen på bekostning af kompileringstid. Moderne højtydende implementeringer af Java Virtual Machine bruger kompilering, så (efter JIT-kompilering er udløst ) viser applikationen ydeevne tæt på platformsspecifik kode .
I 2010 var der en betydelig stigning i antallet af udnyttelser til at omgå JVM -sandbox-begrænsninger i browsere, hvilket gjorde Java mere angribeligt end Acrobat og Flash. [fjorten]
Kritikere mener, at opdaterede versioner af JVM ikke bruges, fordi mange brugere simpelthen ikke ved, at de har en JVM installeret på deres computer, og fordi mange brugere ikke ved, hvordan man opdaterer JVM. Hvad angår virksomhedscomputere, begrænser mange virksomheder brugernes rettigheder til at installere software og installere opdateringer for langsomt. [14] [15]
Nylige versioner af JVM har Java-tilgængelighedsmuligheder i browsere.