Całkowicie w Javie napisane było MMO Star Wars Galaxies. I ponad milion użytkowników nie narzekał wcale na wydajność.
Co prawda gra upadła, ale nie z powodu zastosowanego języka czy środowiska, lecz poważnych zmian projektowych w trakcie jej największego rozkwitu. Zresztą może i Java częściowo się do tego przyczyniła ponieważ dużo łatwiej było w Javie przeprowadzić tak wielkie zmiany w rozgrywce jakich dokonano z dnia na dzień.
Jeżeli ktoś nie chce używać JVM, to obecnie są kompilatory Javy produkujące kod natywny, co prawda wszystkie (za wyjątkiem chyba jednego) są komercyjne, ale istnieją.
JNI/JNA może się przydać tylko po to aby uzyskać interfejs z systemem, który nie jest zaimplementowany w bibliotekach standardowych. Cały nieprzenośny kod można zamknąć więc w kilku wymiennych "chudych" klasach. W ten sposób cała gra może być w ograniczony sposób przenośna między platformami (gra musiałaby "znać" platformę na której zostanie uruchomiona, co i tak jest oczywiste dla wszelkich projektów C/C++).
Jeżeli chodzi o prędkość skomplikowanych obliczeń, to Java ma realnie przewagę nad C++. Szczególnie w sytuacji wykorzystywania wielu rdzeni procesora i bardzo skomplikowanych obliczeń. Należy jedynie traktować polecenie new jako operację wyjątkową, a nie standardową bo nagminnym błędem pisania w Javie jest rozpasane użycie przydziału pamięci starty na obiekty.
W C/C++ jest to stosunkowo rzadkie. Przydział taki powoduje niepotrzebne wywoływanie kodu, który bardzo opóźnia wszelkie obliczenia, a w sytuacji wywołania systemowego na przydział kolejnych porcji pamięci jest to wydajnościowa katastrofa. Dzieje się tak zazwyczaj w miejscach gdzie potrzeba aby kod działał maksymalnie szybko.
To dlatego testy szybkości aplikacji, o których pisał walec51 wychodzą wolniej o 50% niż dla kodu natywnego. Ale jest to wyłącznie zasługą wielu kiepskich programistów javy, a nie skuteczności skompilowanego kodu. Bo ten potrafi kręcić pętle obliczeniowe pod JiT nie tylko zaledwie o 5% wolniej, lecz wiedząc jak kod źródłowy przekłada się na byte-code, a potem na maszynowy można uzyskać niemierzalne różnice wydajności między C++, a Javą na konkretnej platformie. I to wciąż w czytelnie napisanym kodzie.
Przydzielanie pamięci w Javie ma taką strategię aby jak najmniej pobierać od systemu w wielu wywołaniach. A takie podejście jest dokładnie odwrotne od żądanego dla gier. Można to ominąć przez przydzielenie na początku działania gry kilku ogromnych tablic aby totalMemory zrównać z maxMemory, dzięki czemu całą dostępną dla aplikacji pamięcią będzie zarządzać już tylko manager sterty w javie (odśmiecacz). Kiedy tak już się stanie można te tablice zlikwidować i odśmiecić bo pamięć pobrana nie zostanie już zwrócona, tak samo jak nie będzie już ani jednego żądania pamięci z systemu. Maksymalnie można przydzielić w ten sposób 1,5 GB pamięci - i to jest górne ograniczenie dla jakiejkolwiek gry napisanej w Javie (chyba, że wyjdzie 64-bitowa wersja Javy). Np. W 32-bitowym Windows pozostałą pamięć zajmie sama JVM i inne procesy systemowe.
W ten sam sposób można napisać serwer gry. Zresztą można też pokusić się o system rozproszony oparty o P2P. Pisanie w Javie nie wyklucza żadnych opcji. W Javie łatwiej też napisać moduły odpowiedzialne za ochronę przed piratami. Wystarczy do tego wyłączenie kompilatora JiT, napisanie własnych loaderów klas i trochę sprytu. I taka ochrona może być skuteczniejsza nawet od kodu natywnego ponieważ mało kto potrafi crackować byte-code na poziomie porównywalnym z crackowaniem kodu maszynowego x86/x64.
No na na koniec wcale nie trzeba używać bibliotek standardowych. Cała komunikacja z systemem może być oparta o JNI/JNA. Wtedy trzeba niestety zbudować całą przekładkę do API systemu omijając powolne i obarczone kwestiami kompatybilności biblioteki Javy. Kto choć raz przyjrzał się źródłom tych bibliotek będzie od razu wiedział o co chodzi. Kod w nich zawarty w przeciwieństwie do kodu bibliotek standardowych C/C++ nie jest wzorem do naśladowania, a w wielu miejscach jest modelowym przykładem jak nigdy nie powinno się programować. I tutaj upatrywałbym wielu przyczyn dla których w Javie nie pisze się zwykle wydajnych gier. Co prawda od Javy 5 kod bibliotek polepsza się, ale są to jak na razie tylko wyspy wydajności w morzu starych śmieci.