Setting JBuilder up to debug a remote application

By: Louis-Eric Simard

Abstract: Performing debugging sessions in distributed environments has been a challenge. We will show how to easily configure a remote virtual machine and JBuilder for that very purpose.

William WITTWER has been a consultant with Borland since 2001; he joins the team dedicated to IDEs to focus on JBuilder, Borland Developer Studio, as well as the Interbase and JDataStore databases. On top of his consulting activities with major clients (Crédit du Nord, quite a few government agencies, HP, Thales, France Telecom), William heads sessions at Borland conferences, writes technical articles, and answers technical questions on these solutions. You may contact him via email at

When testing recent developments, we often need to launch debugging sessions in order to see what is really going on in local variables, method call chains, etc.

In traditional Client/Server development, one can simply launch their application in a classic debugging session; in distributed development, however, applications can be spread amongst many servers, whether on a partitioned machine or on many systems; the problem lies in performing debugging sessions without necessarily being on the same machine as that which we want to debug.

The JPDA (Java Platform Debugger Architecture) provides development tools with the necessary infrastructure to debug in those circumstances. The JBuilder debugging functionalities make use of this architecture.

In this white paper, we will show the simple steps needed to configure a remote virtual machine and our JBuilder to easily debug such applications.

    Configuring the launch of the remote virtual machine to debug

Options need to be added to the standard launch of a virtual machine (VM) to enable the debugging architecture, allowing us to attach (hook in) and collect data.


Enables remote debugging.


On a Sun VM, disables the proprietary debugging interface thus letting JPDA work correctly.


Disables Just-In-Time (JIT) compilation.






Loads JDWP (Java Debug Wire Protocol), the reference implementation of JPDA. Sub-options further specify the option. 


Sets the transport type for the connection with the debugging application; in this example, we will connect via a socket.


Tells the VM whether it must be receptive to an attaching debugging application.


The port address for our connection; we will need 5000 for our example.


This option can be set depending on whether we want to suspend the exectution of the VM until a debugging application connects. This is useful if we seek to understand what happens when a server starts.

If we wish to make the VM wait for a connection before a full launch, we will need a command line such as this :

java …. -Xdebug -Xnoagent -Djava.compiler=NONE


If we want the VM to be fully executing and listening for a debugging application, we will require a command line such as this one :

java …. -Xdebug -Xnoagent -Djava.compiler=NONE


Hide image
Click to see full-sized image

Figure 1 : JBoss Example

Then, we can execute the connection chain from JBuilder to collect data, use breakpoints, etc.

Hide image
Click to see full-sized image

Figure 2 : Server launch

    Attaching into a remote virtual machine

To hook into the VM that we just launched, we will create a new execution configuration within JBuilder.

Click on Run/Configurations…

Then click on New to create the desired configuration..

Hide image
Click to see full-sized image

Figure 3 : New configuration creation wizard

Give it a name, then specify that the run will be of type Server. Then, choose the Connection item under Debug in the left-hand tree.

Hide image
Click to see full-sized image

Figure 4 : Port specification

We specify that we will attach remotely and set the port to that which we chose previously (5000 in our example)

We then run the configuration and attach to the server by clicking the debugging button and choosing the configuration we just created (See figure 5).

Hide image
Click to see full-sized image

Figure 5 : Running the configuration and attaching

As we chose the suspend=y command-line sub-option, the JBuilder debugger is immediately put on pause, allowing us to to execute the server step-by-step and verify the contents of variables at startup.

Hide image
Click to see full-sized image

Figure 6 : Hooking completed, debugger paused

    Using the debugger

Now, we can add breakpoints on our server-side code in JBuilder by clicking on the line number and hitting the F5 key.

Hide image

Figure 7 : Adding a breakpoint

If we run the application using the code line where a breakpoint has been set the debugger will stop automatically, allowing us to investigate.

Hide image
Click to see full-sized image

Figure 8 : The program stops on the breakpoint

This way, we can run the server-side code step by step and see what is really happening on the server while we call these components.

Hide image
Click to see full-sized image

Figure 9 : Variable investigation / Step-by-step execution


As we saw in this white paper, using remote debugging is easy when we know the right parameters to specify and the steps necessary to set it all up. JBuilder 2006 features a number of debugging options and brings productivity gains thanks to its rich set of functionalities, such as the EJB, Web Services and GUI wizards, the tools to generate code very quickly, and the support for numerous application servers and databases on the market. It also allows JDK 5.0 development. JBuilder’s advanced peer-to-peer collaboration tools let developers work seamlessly together, whether they are on the same PC or on opposite sides of the planet (collaborative editing and debugging, active differentiation, etc.)

I invite you to download the latest version of JBuilder from this link if you don’t already own it :

William WITTWER (

Translated from French by Louis-Eric Simard (

Server Response from: ETNASC01