No igen, lehetett volna nyelvi elemként behozni, de gondolom úgy döntöttek, hogy inkább így valósítják meg, mintsem hogy egy olyan feature-t rakjanak a nyelvi elemek közé, amit az esetek elhanyagolható számában kell használni. Nekem alapvetően nagyon szimpatikus, ahogy a java nyelvet bővítik, nem szórják tele mindenféle nyelvidegen feature-rel, csak azért, mert a javaPistikéknek az tetszik...
Mondjuk úgy, a 10 éves java fejlesztői pályafutásom alatt még soha nem volt azzal gondunk, hogy a memóriafoglalás túl lassú lett volna, bottleneck mindenhol volt, csak itt nem. Ezeket profiling után algoritmus cserével, kód átszervezéssel, többszálúsítással, illetve cache beiktatásával tökéletesen tudtuk kezelni.
Olyan viszont volt, hogy a GC túl sokáig megakasztotta a program futását (még 1.5-ös java korában) ezt viszont GC tuninggal lehetett megoldani.
Igen, ahogy nézegettem, ott egy c struct szerű memóriatartományod van, azoknak az objektumoknak nincs klasszikus értelemben vett metódusa. Ez mondjuk erőteljesen egy elméleti kérdés, ha olyan nagy mennyiségben kell objektumot csinálni, akkor azok jó eséllyel csak tároló objektumok, lényegében rekordok, és nincs hozzájuk kapcsolt bonyolult üzleti logika. Tehát a rekordokon dolgozó osztályokat (általában típusonként 1-1-et) szépen a heap-en lehet tartani, míg a csilliárd rekord mehet a rendszermemóriába. Ennek a fajta szétválasztásnak (ilyen anti-oo jelleggel) van valami szép pattern neve is, de mindig elfelejtem...