Interpretalt byte code ugye?
Tehat lasabb.
Driver eseteben, ha 0.1% kal lenne lasabb es 0.1% kal fogna tobb memoriat java/JVM es 100 szor kevesebb kodsorbol alna, akkor is C -re szavaznek.
Ha veszunk egy utasitast pl. ertek adas (egy konstanst beteszunk pl. egy int -be) ami ~egy ora jel native, ha azt interpretaljuk, az hany orajel szerinted minimum?
Legalabb 2. Es legtobb driverben foleg 1 orajeles utasitasok vannk, ami interpretalva min. 2 -lesz. Egy 40+ orajeles utasitasnal lehet, hogy anyira nem szembetuno (float div).
Arrol nem is beszelve, hogy try,throw os hibakezelest, methous hivasokat is intrpretalni kell, ami nyilvan koltseges.
Ha csoda java -ban, hasznalsz ojjektumokat, az tobb memoriat eszik, mig C++ ban, egy nem virtualis osztaly objektumai anyit esznek, mint amenyi adat van bennuk, virtualis methodusos objektumok egy + mutatonyival hosszabbak. Java -ban minden ojektum tartalmaz virtualis methodust (Orokolve Objektol). A gc is biztosan hasznal nemi memoriat, plusz figyelni kell a referencia szamot... stb.
Java nem igazan ismeri az elofordito csodait. Ami miatt igen kenyelmetlen lehet a driver kodolas, vagy futasi idelyu dontesekre kesztetheti a programozot, meg tobb memoriat megeve.
Generikus programozas tekinteteben is, hagy maga utan nem kivanni valot. (Inakbb csak generikusnak csufolt.) (ami C -ben sincs, de sok # el kezdodo sor csodakra kepes)
De vegulis senki nem tiltja, hogy gcc eloforgatojan atkuldjuk a java kodot, es akkor mar van eloforditonk :)
Ketelkedem abban, hogy egy drivert java -ban kenyelmesebben lehetne irni.
EnhancedForStatement 1.5 javaban az tenyleg kenyelmes dolog.