(Persze, nem tudom, a Java esetében mi a helyzet. Bár számításokat ma már Java-ban is írnak.)
A java esetében az a helyzet, hogy számítási teljesítényben az optimalizálás nélkül fordított C programokat kb 3-4x-esen megverei, -O2 vel fordított C programokkal szemben kicsi, kb 10%-os hátrányban van. Metódushívás, attribútumlekérdezés nagyjából ugyanannyi idő alatt fut le java alatt, mint egy c programban egy függvényhívás illetve egy struct adattagjának elérése. Az egyetlen dolog, amiben a java rémesen lassú (kb 10x-esen) a c-hez képest az az új objektum létrehozása vs. új struct lefoglalása malloc-kal. De pl az új 1.5-ös java vm már csinál object pooling-ot, ami azt jelenti, hogy ha már korábban létrehozott és törölt egy bizonyos típusú objektumot akkor egy későbbi ugyanolyan típusú új objektumnál újrahasználja a memóriaképet, ha az még nem íródott felül. Aztán van olyan is, hogy a metóduson belüli lokális élettartamú objektumokat stack-en hozza létre, ami kb megfelel a c-ben a sima függvényen belüli lokális változóknak. Ezek bizonyos körülmények között elég nagyot tudnak gyorsítani.
Igazából a javas alkalmazások nem azért lassúak, mert a java lassú, hanem azért mert rettenetesen bloatware-ek. A programokat többnyire egy valamilyen framework api-ját felhasználva írják, és nem ritka, hogy ez a framework egy másik frameworkre van építve, ami szintén egy újabb framework apijára támaszkodik. Gyakori, hogy 3-4 ilyen egymást elfedő rétegen is keresztül megy egy hívás és az egyes adapter osztályok mindig átcsomagolják az adatot, mert az egyik metódus Array-t vár, a másik List-et ad vissza stb. Az is tetézi a problémát, hogy az 1.5-ös java api-ja már template-tel megadott típusos kollekciókat használ, de sok 3rd party api-t még nem frissítették erre. Továbbá jellemző még, hogy sok helyen teljesen suta, oda nem illő adatszerkezetet használnak (pl Vector a HashTable helyett, stb), amiben pont az a művelet lassú, amit leggyakrabban használni kell rajta. Ami még rosszabb, az api-k miatt az ember néha maga is rá van kényszerülve ilyen disznóságokra. Persze tisztelet a kivételnek...
Tehát az, hogy a solaris java-s driverei mennyire lesznek sikeresek az teljesen azon múlik, hogy mennyire jól átgondolt a kernel java-s api-ja, illetve a ráépített modulok api-jai mennyire lesznek egységesek. Gondolom a sun-nál egy kicsit több gondot fordítanak erre, mint a hárombetűsnél...
---
Az ember mindig szerepet játszik. Ha másnak nem, hát saját magának.