Newsletter sign-up

View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java

Email Address:

Java Tip 56: How to eliminate debugging problems for RMI-based applications

Make your development of RMI-based applications much easier -- use an in-process server to develop and test your client/server code

By Satheesh A. Donthy, JavaWorld.com, 07/01/98

Developers with experience using RMI for product development largely agree that debugging client/server code presents many difficulties. Stepping into the server from the client or vice versa is not fun for many reasons. Debugging client/server programs using the RMI API is particularly painful, because the execution path jumps back and forth between client and server.

This article presents a simple and elegant solution to the many problems associated with RMI-based product development. The article assumes you have a reasonably good understanding of RMI-based client/server development.

Problems in debugging

Running two debuggers on one machine requires us to have reasonably high-end machines. And switching between two applications is always a nuisance. If we run the debuggers on two different machines, then we need to use two keyboards to step through the debugging process. These petty debugging logistics distract the developer from problem solving.

A common source of trouble is running RMI-based applications on a computer or laptop that is not configured adequately for TCP/IP. This is a big problem for developers who prefer to use their laptops or home PC for product development. Most people use modems to connect to the Internet -- and their TCP/IP is configured to obtain a dynamic address each time they connect to their ISP. So, whenever an RMI application is run, the dial-up dialog box comes up to put the computer on a valid network. To avoid this problem, we can tweak the TCP/IP and COM port settings so that we can run RMI applications without connecting to the ISP -- but then we cannot connect to the Internet while we are developing RMI applications. Reconfiguring the computer (or laptop) frequently is not a feasible solution. As a whole, working from home is not an easy option for those using RMI.

This article describes a simple design technique that allows us to debug the server and client in a single process, without breaking any RMI guidelines or the existing code base. It describes how RMI can be bypassed entirely when you want to debug the client and server code in any debugger in a traditional style (within a single process). The same codebase can be used to run the client and server in separate processes or in a single process, merely by toggling a boolean flag in the client.

Benefits from this design technique

You can implement this technique for your existing codebase in half a day or in a full day, depending on the number of remote interfaces your server supports -- and depending on your typing speed. Once everything is in place, developers can reap the following benefits:

1. Code can be written and tested on a single machine, in a single process.
2. There is no need to have a network card and a valid TCP/IP address.
3. Any JDK 1.1-compatible debugger can be used for debugging both client and server.
4. Development can be done at home without disturbing the ISP settings. There is no need to get online to obtain a dynamic IP address.
5. RMI-based products can be demonstrated on a laptop without changing any network or TCP/IP settings.
6. While the server application is running, a modem can be used to get on the Internet at will.
7. There is no need to run an RMI registry at the time of debugging.

This design technique requires us to implement the server to support two modes of execution. These modes are:

 

About Us | Advertise | Contact Us | Terms of Service/Privacy

Copyright, 2006-2008 Network World, Inc. All rights reserved.