Java IoT Authors: Liz McMillan, Pat Romanski, Yeshim Deniz, Elizabeth White, Stefana Muller

Related Topics: Java IoT

Java IoT: Article

Using The Java Platform Debugger Architecture

Using The Java Platform Debugger Architecture

The Java Platform Debugger Architecture (JPDA) provides a standard set of protocols and APIs at three levels that facilitate the development of a new breed of debugging and profiling tools. The inclusion of JPDA in the Java 2 SDK enables individual developers as well as commercial vendors to find novel ways of analyzing Java applications as they run even remotely across a network.

In this article I provide a quick-start guide to developing with the new APIs, with my own novel use of the JPDA as an example. Hopefully, this pragmatic approach will help you build your first debugger application quickly, making the prospect of wading through the comprehensive JPDA documentation less daunting.

The Example
Object systems are not static; however, judging from the limited reverse-engineering capabilities offered by leading UML CASE tools, you'd think they were. In most cases you're limited to specifying a set of Java ".class" files. What you get in return is just one of the many diagrams offered by UML, a class diagram.

What if you could reverse engineer a Java application as it runs? You could capture the important dynamic behavior of your applications and complete the UML picture with both sequence and state diagrams.

I propose a new kind of tool that bridges the gap between reverse engineering and application profiling, a tool that presents the runtime behavior of your application, as shown in Figure 1.

Note that the left-hand column of the sequence diagram view in Figure 1 shows the thread on which each object interaction has occurred. Note also that the dependencies view shows dynamic dependencies, for example, where an object instantiates and uses another object within a method, rather than the static dependencies that traditional reverse-engineering tools deduce from member variables.

My first attempt at developing a tool such as this was based on using the original command-line Java Debugger, jdb. The idea was to use the input and output streams to drive debugging instructions through the command-line interface, and to parse the resulting text output to extract information on classes, threads, and method invocations. Looking back, I wouldn't have taken this approach; however, after several frustrating attempts, along came the JPDA as a breath of fresh air.

The JPDA Distribution
To begin this project we must first locate the JPDA distribution and understand how its components fit together. The distribution comes bundled with the Java 2 SDK v1.3, and is available to v1.2.2 developers via a separate download at http://java.sun.com/products/jpda. I'll first describe the separate download as the lowest common denominator.

By unpacking the distribution JAR file, several directories are created:

  • \bin directory: Contains dynamic link libraries (for the Win32 distribution) called dt_shmem.dll, dt_socket.dll, and jdwp.dll. These DLLs provide the native communications support for JPDA and must be included in the environment PATH. Equivalent shared libraries are provided with the Solaris distribution.
  • \lib directory: Contains the JPDA Java Archive, jpda.jar, which must be included in the environment CLASSPATH.
  • \examples directory: Contains, among other things, source code for a version of the original Java Debugger, jdb, that's now based on JPDA. This class, TTY.java, is contained in the examples.jar file.
  • \bin directory: Contains the dt_shmem.dll, dt_socket.dll, and jdwp.dll files. It's for the distribution that comes bundled with the Java 2 SDK v1.3, the SDK installation. There's no separate jpda.jar file because the JPDA Java classes are now included in the tools.jar file within the \lib directory, and the examples.jar file is now located in the \demo\jpda directory.
Three parts constitute the JPDA architecture: the Java Virtual Machine Debug Interface (JVMDI), the Java Debug Wire Protocol (JDWP), and the Java Debug Interface (JDI). Figure 2 shows how these aspects of the JPDA fit together.

A JVM that's supporting the JVMDI, such as the Java 2 SDK, provides the debugger back end. This back end interrogates and controls the VM, and communicates through shared memory or over the network via sockets with the debugger front end.

JDWP provides the communication protocol through which the front and back ends exchange messages, irrespective of the transport mechanism, thus opening up the possibility of remote debugging across a network.

The JDI is a 100% Java interface implemented by the front end that defines information and requests at user code level. Although developers can make direct use of the JVMDI and JDWP, the accompanying documentation recommends this JDI layer for all debugger development.

A Step-by-Step Example
Now I'll provide a step-by-step guide to using the JPDA to develop a front-end application. Code examples are based on real application code that runs; however, the examples have been simplified for clarity. In some cases the exception handling and prior declaration of variables have been removed. In all cases, the full package names for the classes have not been used, so you should be aware that all the new classes introduced here belong in one of the following packages:


Running the Target Application
A target application is made available for debugging by invoking it with a special combination of command-line options. This is all you need to do to give the application debugee status, with no changes required within the application code. A typical command to invoke an application to be debugged within the Sun classic VM looks like this:

java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,address=8000 MyApplication

The following describes the options in the command:

  • Djava.compiler=NONE: Disables the JIT compiler
  • Xdebug: Enables debugging
  • Xnoagent: Disables the old debugging agent that predates the JPDA
  • Xrunjdwp:transport=dt_socket,server=y,address=8000: Specifies sockets as the connection mechanism, the type of application to be a server and listen for a front-end debugger application to attach, and the transport address on which to listen

There are many other combinations of options described in the JPDA documentation, too many to describe here in detail. For example, it's possible to run a target application that attaches to an already running debugger front end (-Xrunjdwp:server=n), or one that communicates with the debugger front end through shared memory (-Xrunjdwp:transport=dt_shmem) rather than sockets.

Attaching the Front-End Debugger to the Target Application
The simplest way to demonstrate the connection of a front-end debugger to a target application is by using the version of the Java Debugger, jdb, that comes with the JPDA distribution.

The command:

jdb -attach targetHostName:8000 (shorthand for jdb -connect com.sun.jdi.SocketAttach:host=target HostName,port=8000)
attaches the front-end debugger to the (remote) target application listening on machine targetHostname, port 8000.

I recommend using jdb to test the basic JPDA operation prior to developing your own front-end debugger applications. However, for your own debugger applications, and for my example, we need to know how to write the equivalent Java code to establish a connection to a target application.

To use the JDI APIs to establish a connection to a target application, it's necessary to understand the notion of a connector. A JPDA connector is similar to a JDBC driver that separates the implementation details from the API specification. The connectors provided with the JPDA distribution are:

  • Sun Command Line Launching and Raw Command Line Launching: Both connectors launch an application in a new JVM and attach to it.
  • Socket Attaching: Attaches to a currently running, possibly remote, target VM through the socket transport.
  • Shared Memory Attaching (Win32 only): Attaches to a currently running target VM through the shared-memory transport.
  • Socket Attaching and the Shared Memory Attaching: Each connector has a listening version that allows the front-end debugger to be invoked first, with the target application then attaching to it. Although the API for each connector is identical to that for every other connector, the individual capabilities of each one are accessed and controlled through a series of name-value properties.

My example uses the Socket Attaching Connector that attaches to a target application initiated using the typical invocation command shown earlier:

java -Djava.compiler=NONE -Xdebug -Xnoagent -Xrunjdwp:transport=dt_socket,server=y,address=8000 MyApplication
Now onto the Java code. First I look for the required connector by name as shown in Listing 1.

Next I obtain the arguments or name-value pairs for this connector and set their values according to my needs (see Listing 2).

Finally, I create an instance representing the target virtual machine and attach to it (see Listing 3).

Implementing the Front End Using the JDI APIs
For my Runtime Reverse Engineering Tool I'm interested in trapping each method invocation as it occurs in the target application. This allows me to build up the UML sequence diagram and the dependencies view as shown in Figure 1.

The JDI API provides an EventRequestManager class, the singleton instance of which may be obtained from the VM. This may be configured to trap events such as method invocations as they happen. For each set of method invocations that we wish to intercept, a MethodEntryRequest must be added to the EventRequestManager. The Method-EntryRequest may be restricted by adding a class filter, which is important for my example because I want to display interactions between application objects (e.g., mypkg.*), not between Java library classes (java.*). Listing 4 demonstrates how to obtain the singleton EventRequestManager and how to add a MethodEntryRequest to it.

For clarity Figure 3 presents a collaboration diagram showing the steps for attaching to the target VM in the first place, and then adding a MethodEntryRequest.

Each time the EventRequestManager traps an event corresponding to my MethodEntryRequest, it places an event on the EventQueue for my attention. Thus the main body of any front-end debugger application will almost certainly consist of an endless loop in which events are popped from the EventQueue, as shown in Listing 5.

The "// process this event" comment indicates where the code should go to take some action for the event. For my example the action is to call a method to add a new object interaction to the UML sequence diagram shown in Figure 1.

To add a new object interaction I need to know three things: the method that's been invoked, the callee (receiver) class, and the caller (sender) class. The steps involved in getting these three pieces of information are:

  1. Get the method from the event object.
  2. Get the thread on which the event occurred.
  3. Get the list of stack frames for this thread.
  4. Look at the top stack frame for the callee class.
  5. Look at the next stack frame for the caller class.

Listing 6 shows how to implement these five steps, which are also presented as a collaboration diagram in Figure 4.

For my application it gets a little more complicated. Since I'm interested only in interactions between application objects, not Java library objects, the caller class isn't necessarily the one on the second stack frame. I therefore work down the list of stack frames until I find one with a caller class that's not in one of the java.* packages. This identifies the caller application object that interacts with the callee application object, albeit possibly through several levels of Java library objects.

A Variation Using the Command Line Launching Connector
For many applications you may not want to attach to an already running, possibly remote, application. Instead, you might allow the debugger front end to launch the target application on demand. In this case you'll need to use the Command Line Launching Connector rather than the Socket Attaching Connector.

The name of the connector to search for in the list of available connectors (see Listing 1) is "com.sun.jdi.CommandLineLaunch". The arguments for this connector, which can be set by modifying the code shown in Listing 2, are "options" (options, in addition to the debug options, with which to invoke the JVM), "main" (the main class and command-line arguments for the target application), and "suspend" (true if the target VM is to be suspended immediately before the main class is loaded).

A version of Listing 2, modified for the Command Line Launching Connector, is shown in Listing 7.

You'll notice that in this example I obtain the InputStream and ErrorStream from the VM process and pass each to a displayRemoteOutput() method. The output from the invoked application must go somewhere, and for my application "somewhere" means the standard output of the debugger front end. A more elegant solution would be to provide both an "output" and "error" window as part of the debugger front-end GUI, and channel the target application's output streams to these windows as appropriate.

As stated in the beginning of this article, the inclusion of the JPDA in the Java 2 SDK should facilitate the development of a new breed of debugging and profiling tools.

Using the JPDA I succeeded in developing a prototype of my proposed Runtime Reverse Engineering Tool, which allows any running - local or remote - application to be visualized as a UML sequence diagram and a (dynamic) dependency diagram as shown in Figure 1. Without this addition it wouldn't have been so easy, if at all possible, to realize my own debugger front end.

The listings in this article have been simplified for publication, but they're based on code that actually runs as part of my prototype Runtime Reverse Engineering Tool. The complete code has taken a significant amount of time to develop, but I'll consider genuine e-mail requests for access to the full binary and source code for this project.

More Stories By Tony Loton

Tony Loton works through his company - LOTONtech Limited (www.lotontech.com) - as an independent consultant, course instructor, and technical author. He has a degree in computer science and management and has spent 10 years in I.T. The last five years have been devoted almost exclusively to Java, UML, and related technologies.

Comments (4)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.

IoT & Smart Cities Stories
The explosion of new web/cloud/IoT-based applications and the data they generate are transforming our world right before our eyes. In this rush to adopt these new technologies, organizations are often ignoring fundamental questions concerning who owns the data and failing to ask for permission to conduct invasive surveillance of their customers. Organizations that are not transparent about how their systems gather data telemetry without offering shared data ownership risk product rejection, regu...
The best way to leverage your Cloud Expo presence as a sponsor and exhibitor is to plan your news announcements around our events. The press covering Cloud Expo and @ThingsExpo will have access to these releases and will amplify your news announcements. More than two dozen Cloud companies either set deals at our shows or have announced their mergers and acquisitions at Cloud Expo. Product announcements during our show provide your company with the most reach through our targeted audiences.
Bill Schmarzo, author of "Big Data: Understanding How Data Powers Big Business" and "Big Data MBA: Driving Business Strategies with Data Science," is responsible for setting the strategy and defining the Big Data service offerings and capabilities for EMC Global Services Big Data Practice. As the CTO for the Big Data Practice, he is responsible for working with organizations to help them identify where and how to start their big data journeys. He's written several white papers, is an avid blogge...
When talking IoT we often focus on the devices, the sensors, the hardware itself. The new smart appliances, the new smart or self-driving cars (which are amalgamations of many ‘things'). When we are looking at the world of IoT, we should take a step back, look at the big picture. What value are these devices providing. IoT is not about the devices, its about the data consumed and generated. The devices are tools, mechanisms, conduits. This paper discusses the considerations when dealing with the...
Machine learning has taken residence at our cities' cores and now we can finally have "smart cities." Cities are a collection of buildings made to provide the structure and safety necessary for people to function, create and survive. Buildings are a pool of ever-changing performance data from large automated systems such as heating and cooling to the people that live and work within them. Through machine learning, buildings can optimize performance, reduce costs, and improve occupant comfort by ...
Business professionals no longer wonder if they'll migrate to the cloud; it's now a matter of when. The cloud environment has proved to be a major force in transitioning to an agile business model that enables quick decisions and fast implementation that solidify customer relationships. And when the cloud is combined with the power of cognitive computing, it drives innovation and transformation that achieves astounding competitive advantage.
With 10 simultaneous tracks, keynotes, general sessions and targeted breakout classes, @CloudEXPO and DXWorldEXPO are two of the most important technology events of the year. Since its launch over eight years ago, @CloudEXPO and DXWorldEXPO have presented a rock star faculty as well as showcased hundreds of sponsors and exhibitors! In this blog post, we provide 7 tips on how, as part of our world-class faculty, you can deliver one of the most popular sessions at our events. But before reading...
René Bostic is the Technical VP of the IBM Cloud Unit in North America. Enjoying her career with IBM during the modern millennial technological era, she is an expert in cloud computing, DevOps and emerging cloud technologies such as Blockchain. Her strengths and core competencies include a proven record of accomplishments in consensus building at all levels to assess, plan, and implement enterprise and cloud computing solutions. René is a member of the Society of Women Engineers (SWE) and a m...
Poor data quality and analytics drive down business value. In fact, Gartner estimated that the average financial impact of poor data quality on organizations is $9.7 million per year. But bad data is much more than a cost center. By eroding trust in information, analytics and the business decisions based on these, it is a serious impediment to digital transformation.
CloudEXPO New York 2018, colocated with DXWorldEXPO New York 2018 will be held November 11-13, 2018, in New York City and will bring together Cloud Computing, FinTech and Blockchain, Digital Transformation, Big Data, Internet of Things, DevOps, AI, Machine Learning and WebRTC to one location.