The problem grows with a growing heap. So a ‘benchmark’ might not be the best testcase.
If you tested in real world usecases, and thought it was acceptable (which I find surprising) you’re OK, ofcourse
The problem is that this application doesn’t need real-time performance unlike my FPS. If I decide not to implement a small piece of the multiplayer mode now, it will be harder when I will have to do it. The much time I wait, the more efforts I will need to do it.
To reduce this pause, you can choose a low-pause algorithm for garbage collection, you can fix a maximum length for pauses and all objects in the model part of the application (MVC) have to implement Serializable and Remote to prevent the JVM from copying the remote objects instead of using a stub. You can use a table that tells when something has changed on the server and the clients can look at this (synchonized) table to check if it is really useful to get the data from the server rather than using the data already in the proxy. The model part has to be thread-safe as several clients can get data from it. However, the biggest problem comes from the latency.
I agree with Riven, RMI is most definitely not designed for real-time.
This topic has actually been debated a few times before. I’ll refer you to a previous post I made:
http://www.java-gaming.org/index.php/topic,17309.msg137256.html#msg137256
Also, as far as games that use JGN, there are many more, but my lack of attention to mentioning them and letting developers know that page even exists is entirely my fault. 