Need help improving a java client side port listener

Question

I have a small bit of code that runs in an applet that contains SWING controls and is used to write information to a socket on a certain port and then listens for a response. This works fine, but there is a problem with it. The port listener is essentially in a loop until null is received by the server. I want users to be able to perform other actions in the GUI instantiated by the applet while waiting for the server to respond (this could take minutes to occur). I also need to worry about the connection between the server and the client disconnecting. But the way the code is written, the applet appears to freeze (its really in a loop) until the server responds. How can I allow the listener to do its listening in the background, allowing other things to occur in the program. I assume I need to use threads and I'm sure for this application, it is easy to implement, but my lack of a solid thread foundation is hampering me. Below is the code (you can see how simple it is). How can I improve it to make it do what I need it to do>

  public String writePacket(String packet) {
/* This method writes the packet to the port - established earlier */
   System.out.println("writing out this packet->"+packet+"<-");
   out.println(packet);
  String thePacket =    readPacket();  //where the port listener is invoked.  
   return thePacket;
   }
    private String readPacket() {
      String thePacket ="";
      String fromServer="";
      //Below is the loop that freezes everything.   
     try {
      while ((fromServer = in.readLine()) != null) { 
        if (thePacket.equals("")) thePacket = fromServer;
        else 
        thePacket = thePacket+newLine+fromServer;
    }
        return thePacket;  //when this happens, all listening should stop.   
   } catch (IOException e) {
        // TODO Auto-generated catch block
    e.printStackTrace();
    return null;
    }

     }  

Thanks,

Elliott

Answer 1

There lots of different means of getting the IO performed on a different thread, but in this case you probably want to use SwingWorker .

Your code would look something like:

private final Executor executor = Executors.newSingleThreadExecutor();

public void writePacket(final String packet) 
{
  // schedules execution on the single thread of the executor (so only one background operation can happen at once)
  //
  executor.execute(new SwingWorker<String, Void>()
      {

        @Override
        protected String doInBackground() throws Exception
        {
          // called on a background thread


          /* This method writes the packet to the port - established earlier */
          System.out.println("writing out this packet->"+packet+"<-");
          System.out.println(packet);
          String thePacket = readPacket();  //where the port listener is invoked.  
          return thePacket;            
        }

        @Override
        protected void done()
        {
          // called on the Swing event dispatch thread


          try
          {
            final String thePacket = get();

            // update GUI with 'thePacket'
          }
          catch (final InterruptedException e)
          {
            // TODO Auto-generated catch block
            e.printStackTrace();
          }
          catch (final ExecutionException e)
          {
            // TODO Auto-generated catch block
            e.printStackTrace();
          } 
        }
      });
}

private String readPacket() 
{
  String thePacket ="";
  String fromServer="";
  //Below is the loop that freezes everything.   
  try 
  {
    while ((fromServer = in.readLine()) != null) 
    { 
      if (thePacket.equals("")) 
        thePacket = fromServer;
      else 
        thePacket = thePacket+newLine+fromServer;
    }
    return thePacket;  //when this happens, all listening should stop.   
  } 
  catch (IOException e) 
  {
    e.printStackTrace();
    return null;
  }
}

Answer 2

All the network I/O should be in a separate thread.

BTW readLine() returns null when the server closes the connection, not when it has finished sending data for the moment.