I know this could go in the "I/O and Streams" forum, but since my topic was derived from a Java games book I thought I would try here first.
In chapter 6 of "Developing Games in Java" by Brackeen, there is a whole section on how to write a game server. In the example, the communication is done with the java.nio package. When the client talks to the server he passes a GameEvent object that contains information like type, game name, message, player id, session id, etc. But, this GameEvent is not sent as a whole. So for each of the data types contained in the object, there is a method call on ByteBuffer; for example bb.putInt(1); bb.putStr("player 1"); etc. Then on the server, this data is received and a GameEvent is constructed out of it. But I am scratching my head trying to figure out why ObjectInputStream/ObjectOuputStream was not used instead. Is the nio package really that much better than this method of transferring objects from client to server? I believe the purpose of using nio was so there would not be so many threads on the server, since a regular Socket's read() method blocks. I guess I am just looking for a confirmation that this is correct since I don't necessarily go by everything I read.
Thanks for the response! So just to confirm... even though you have to do multiple puts for each member, this is faster than doing a single transfer of the object itself? It seems it would be faster to just send the object all at once.
author and iconoclast
The ObjectOutputStream also does multiple operations; they're just all done "behind the scenes".
This is an example of a general principle in computer programming, really: the tradeoff between performance and convenience. It's often the case that by doing extra work (as here) you can make your program perform better. Some people get obsessed with performance, spending a week of programmer time to save a few minutes of user time. Always try to make this choice wisely.
You might want to check out Jack Shirazi's book "Java Performance Tuning," which includes a section in which he starts off with a plain Serialization application, and improves the performance by something like two orders of magnitude, a step at a time, by implementing more and more by hand.