There is a small problem with the approach as outlined in the lessons. Let’s trace through the method calls in a game where there is one player and a dealer. Both players stand during their turn.

Listing 21.1 represents a trace of all method calls in the game. The stack terminates when a method returns.

BlackjackSim.main
 BlackjackDealer.newGame
  Player.play
   BlackjackDealer$DealerCollectingBets.execute
    Player.play
     BettingPlayer$Betting.execute
      BlackjackDealer.doneBetting
       Player.play
        BlackjackDealer$DealerCollectingBets.execute
         BlackjackDealer$DealerDealing.execute
          BlackjackDealer$DealerWaiting.execute
           Player.play
            Player$Playing.execute
             Player$Standing.execute
              BlackjackDealer.standing
               Player.play
                BlackjackDealer$DealerWaiting.execute
                 Player$Playing.execute
                  BlackjackDealer$DealerStanding

The problem is subtle. None of the methods return until the dealer finishes his turn! The methods recursively call one another. So for example, the notifyChanged method in Listing 21.2 will not execute until the current game ends.

public void execute( Dealer dealer ) {
    if( hit( dealer ) ) {
        dealer.hit( Player.this );
    } else {
        setCurrentState( getStandingState() );
        notifyStanding();
    }
    current_state.execute( dealer );
    // transition

    // will not get called until stack unwinds!!!!
    notifyChanged();
}

In the Blackjack game, this is not really a problem because there is a limit of seven players and the method call stack unwinds after every game. You can also code carefully around problems like the one demonstrated in Listing 21.2.

However, imagine a simulator with hundreds or thousands of objects that follow the Blackjack game design. If these objects call one another recursively, even if the stack does eventually unwind, you could end up running out of memory. Either way, each method call will allocate more memory. If you follow this design unaltered, your system either will not run or will require a whole lot more memory than absolutely necessary.

Luckily there is a solution: threads. While a full discussion of threading is well beyond the scope of this book, you’ll see how you can use threading to solve the method call problem quickly.

A thread is simply a path of execution through your program. So far, the Blackjack system has one thread of execution. Figure 21.1 helps visualize that single thread.

Figure 21.1. The single threaded Blackjack system.

Because the Blackjack game is single threaded (it only has one thread), that single thread does everything.

Threading allows you to create multiple threads of execution through your program. By creating multiple threads, your program can do many different things at the same time. Figure 21.2 helps visualize two threads running through the Blackjack system.

Figure 21.2. The multithreaded Blackjack system.

Threading the Blackjack system can allow a method to return right away. Let’s look at a simple thread example from Java. Listing 21.3 presents a simple thread that prints out "Hello World!".

public class HelloWorld {

    public void sayHello() {
        System.out.println( "Hello World!" );
    }

    public static void main( String [] args ) {
        final HelloWorld hw = new HelloWorld();

        Runnable runnable = new Runnable() {
            public void run() {
                hw.sayHello();
            }
        };

        Thread thread = new Thread( runnable );
        thread.start();

        System.out.println( "All Done!" );
    }
}

HelloWorld itself is a simple class that has one method: sayHello. sayHello prints out a message to the command line.

The main is where it gets interesting. First, the main instantiates HelloWorld. It then creates an anonymous Runnable class. Runnables have one method: run. run tells the thread what to do when it is started. In this case it will tell the HelloWorld instance to print its message.

After creating the Runnable, the main instantiates a Java Thread. When you create a Thread you need to pass it a Runnable. The Runnable’s run method tells the Thread what to do when you tell the Thread to start. After starting the Thread the main prints out a message of its own.

You may be surprised when you see the main run. Figure 21.3 presents the output of HelloWorld.

Figure 21.3. The output of HelloWorld.

When running HelloWorld, you’ll find that “All Done” gets printed before “Hello World!” The call to Thread.start does not block like other method calls. Because start starts a new thread of execution it automatically returns. After you call start you have two threads of execution in the HelloWorld program. It just so happens that the main prints its message before the new thread gets a chance to call sayHello.

You can use the fact that start does not block to fix the design shortcoming in the Blackjack game. Listing 21.4 presents a new Waiting state for the BlackjackDealer that starts each player on its own thread.

private class DealerWaiting implements PlayerState {
    public void handChanged() {
        // not possible in waiting state
    }
    public void handPlayable() {
        // not possible in waiting state
    }
    public void handBlackjack() {
        // not possible in waiting state
    }
    public void handBusted() {
        // not possible in waiting state
    }
    public void execute( final Dealer dealer ) {
        if( !waiting_players.isEmpty() ) {
            final Player player = (Player) waiting_players.get( 0 );
            waiting_players.remove( player );
            Runnable runnable = new Runnable() {
                public void run() {
                    player.play( dealer );
                }
            };
            Thread thread = new Thread( runnable );
            thread.start();
        } else {
            setCurrentState( getPlayingState() );
            exposeHand();
            getCurrentState().execute( dealer );
            // transition and execute
        }
    }
}

By starting each player on its own thread, the BlackjackDealer’s state execute method can return right away, thus unrolling the stack. This does interject some difficulties if you loop calls to newGame because newGame will now return before the game is actually finished. If you loop, you’ll start another game before the last has finished and then you’ll run into all kinds of nasty problems. You can solve this problem by telling the BlackjackDealer how many times to loop. At the end of each game, it can check to see if it needs to play again.

The good news is that if you don’t loop, such as in the GUI, you can easily thread by simply changing the BlackjackDealer’s DealerWaiting state! The downloadable source contains threaded versions of the GUI.