Java IoT Authors: Yeshim Deniz, Liz McMillan, Zakia Bouachraoui, Elizabeth White, William Schmarzo

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
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...
Nicolas Fierro is CEO of MIMIR Blockchain Solutions. He is a programmer, technologist, and operations dev who has worked with Ethereum and blockchain since 2014. His knowledge in blockchain dates to when he performed dev ops services to the Ethereum Foundation as one the privileged few developers to work with the original core team in Switzerland.
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...
Andrew Keys is Co-Founder of ConsenSys Enterprise. He comes to ConsenSys Enterprise with capital markets, technology and entrepreneurial experience. Previously, he worked for UBS investment bank in equities analysis. Later, he was responsible for the creation and distribution of life settlement products to hedge funds and investment banks. After, he co-founded a revenue cycle management company where he learned about Bitcoin and eventually Ethereal. Andrew's role at ConsenSys Enterprise is a mul...
In his general session at 19th Cloud Expo, Manish Dixit, VP of Product and Engineering at Dice, discussed how Dice leverages data insights and tools to help both tech professionals and recruiters better understand how skills relate to each other and which skills are in high demand using interactive visualizations and salary indicator tools to maximize earning potential. Manish Dixit is VP of Product and Engineering at Dice. As the leader of the Product, Engineering and Data Sciences team at D...
Dynatrace is an application performance management software company with products for the information technology departments and digital business owners of medium and large businesses. Building the Future of Monitoring with Artificial Intelligence. Today we can collect lots and lots of performance data. We build beautiful dashboards and even have fancy query languages to access and transform the data. Still performance data is a secret language only a couple of people understand. The more busine...
Whenever a new technology hits the high points of hype, everyone starts talking about it like it will solve all their business problems. Blockchain is one of those technologies. According to Gartner's latest report on the hype cycle of emerging technologies, blockchain has just passed the peak of their hype cycle curve. If you read the news articles about it, one would think it has taken over the technology world. No disruptive technology is without its challenges and potential impediments t...
If a machine can invent, does this mean the end of the patent system as we know it? The patent system, both in the US and Europe, allows companies to protect their inventions and helps foster innovation. However, Artificial Intelligence (AI) could be set to disrupt the patent system as we know it. This talk will examine how AI may change the patent landscape in the years to come. Furthermore, ways in which companies can best protect their AI related inventions will be examined from both a US and...
Bill Schmarzo, Tech Chair of "Big Data | Analytics" of upcoming CloudEXPO | DXWorldEXPO New York (November 12-13, 2018, New York City) today announced the outline and schedule of the track. "The track has been designed in experience/degree order," said Schmarzo. "So, that folks who attend the entire track can leave the conference with some of the skills necessary to get their work done when they get back to their offices. It actually ties back to some work that I'm doing at the University of San...
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...