Have you looked at the Forum FAQ, in particular Q12.
Yes, but it narrowly answers a part of my question. At least, from that, I am able to understand what a network packet's content may want to have, depending on the game that uses the packet.
This is a completely implementation specific question. No, there is no necessity for a "packet" to be runnable. However, this might be part of a solution to move networking logic to a separate thread, if desired.
Oh I see. I tend to see them as together, but I don't know why it has to be together, until now. Moving network logic to a separate thread seems to be a very reasonable answer.
No. Using the built in Java serialization might be a great way to bootstrap your game, and for certain types of games (e.g. our aforementioned chess example) might be all you need to do. However, Java serialization has a number of draw backs. The biggest one, from a game programmer's point of view, is that the overhead tends to be very large. Another issue is handling protocol version changes - though this isn't an easy one to do in general.
Since I haven't had much experiences in Java serialization, before, I was thinking if a packet were to be thought as a binary file, wouldn't sending a binary file, in the order of a standard network packet, be easier to read/write? Now, this is my first taste of knowing that there would be drawbacks, something I never thought it would be that severe before. I'll keep my head up regarding this.
It is conceivable that someone would write a class "Packet" like that. However, a packet tends to be the lowest stage of the networking, at which point you are generally talking about arrays of bytes rather than higher level constructs. Some designs might not even model packets using a class - they might serialise messages to a byte buffer which is wrapped in a datagram or written to the stream.
I was worried that I have to write a few packets entirely in bytes. What a relief.