— Scott McNealy, Sun Microsystems Chairman, President and ceo

1
Option One: 
Poll the server every 20 seconds
2
Option Two: 
Read something in from the server each time the user 
sends a message.
Pros: Do-able, very easy
Cons: Stupid. Why choose such an arbitrary time to check for messages? What if a user is 
a lurker and doesn’t send anything?
3
Option Three: 
Read messages as soon as they’re sent from the server
Pros: Most efficient, best usability
Cons: How do you do you do two things at the same time? Where would you put this code? 
You’d need a loop somewhere that was always waiting to read from the server. But where 
would that go? Once you launch the GUI, nothing happens until an event is fired by a GUI 
component.
improving the 
chat client

---

networking 
and
threads
you are here
4
489
You know by now that we’re 
going with option three.
In Java you really CAN 
walk and chew gum at 
the same time.
We want something to run continuously, 
checking for messages from the server, 
but without interrupting the user’s ability to 
interact with the GUI! So while the user is 
happily typing new messages or scrolling 
through the incoming messages, we 
want something behind the scenes to keep 
reading in new input from the server.
That means we fi nally need a new thread. 
A new, separate stack
We want everything we did in the Send-
Only version (version one) to work the 
same way, while a new 
process runs along 
side that reads information from the 
server and displays it in the incoming text 
area.
Well, not quite. Unless you have multiple 
processors on your computer, each new 
Java thread is not actually a separate 
process running on the OS. But it almost 
feels as though it is.
Multithreading in Java
Java has multiple threading built right 
into the fabric of the language. And it’s a 
snap to make a new thread of execution: