Application Development Blog Posts
Learn and share on deeper, cross technology development topics such as integration and connectivity, automation, cloud extensibility, developing at scale, and security.
cancel
Showing results for 
Search instead for 
Did you mean: 
Former Member
1,397
  • SAP Managed Tags:

JPDA ( Java Platform Debug Architecture ) [video tutorial]

Quoting from Oracle's Official Documentation:


"JPDA is a multi-tiered debugging architecture that allows tools developers to easily create debugger applications which run portably across platforms, virtual machine (VM) implementations and JDK versions."

The JPDA is designed to be made up of three Layers.

a) JVM TI: Java Virtual Machine Tooling Interface.

This interface specifies the behaviour that is to be implemented by the client to to be able to provide the desired debugging features. The Java HotSpot VM does provide a reference implementation for the same.

b) JDI: Java Debug Interface:

To state things simply, this is the “client” side of the whole JPDA Specification. Any IDE, Debugger or a Debugger like process like a live telemetry and profiling application may use this Interface to implement a view which needs to control the remote VM in some manner.

c) JDWP: Java Debug Wire Protocol:

This is the protocol in which the Debugger and the Debuggee communicate. There are gory details to this protocol which one can go into if needed, but which would not be pertinent to this article. (Refer: Links section).


With this background information in mind, let us now skim through rest of the JPDA Concepts.

  1. Transports 
    Transports is the sub-protocol under JPDA, which details the method of communication between the Source VM and the Target VM. The Source VM and the Target VM can be on same as well as on different machines. What must be noted is that Transports are an abstraction and any implementer can choose to implement what they are up to, however, the reference implementation ships with two transports.
    1. Socket Transport(dt_socket):

      The source and the target VM-s use TCP/IP sockets to communicate between them. This transport is available for Windows, Linux and Solaris (in the reference implementation).

    2. Shared Memory(dt_shmem):

      This uses one of the three ICP (Interprocess Communication) methodologies native to the Unix Systems, i.e the Shared Memory to exchange messages between themselves. What is ironical is that this method is only available for Windows currently in the reference implementation.

  2. Connectors 

A connector is an abstraction as a part of the JDI (refer above), which allow for a concrete way to establish a connection between the Source and the Target VM s.

The JDI reference implementation has a lot (really a lot) of Connector implementations that cater to launching ,listening and attaching and other modes of communication.

Here, in this article I shall enumerate only two, which are the most commonly used ones. Not to say others aren't as important, but I feel they would further bloat this already dry subject material. For details on all available types of Connectors please refer to the links section.

Socket Attaching Connector:

As the name suggests, it uses the “socket” method of transport. It requires certain configuration parameters that are as follows:

Name

Required

Default

Description

Hostname

No

Localhost

Host-Name

Port

Yes

None

Port-name of machine

Timeout

No

None

Connect attempt after how much delay.

Shared Memory Connector:

As the concept of shared memory goes, there is a file or a memory handle usually managed by the underlying operating system that is the common place where both Source and Target VM s write to / read from.

As highlighted above, the default implementation in the HotSpot VM currently supports the Windows Operating System only.

The parameters required for configuration are as follows:

Name

Required

Default

Description

Name

Yes

None

Shared Memory Transport Address at which VM Connections Listen for.

Timeout

No

None

Connect attempt after how much delay.

This concludes a (very) brief theoretical introduction to the JPDA. This should be enough right now to understand in some detail what is going on behind the scenes as I take you through the process of Remote Debugging in this video that follows. Do go through the links for a complete and exhaustive documentation of the same.

Please note that although I have used Netbeans IDE for this Video Tutorial, the process in its essential matter, remains similar for whatever client you choose to use.

Enough Theory, let's get our hands dirty !

References and Additional Readings:

https://docs.oracle.com/javase/7/docs/technotes/guides/jpda/jpda.html

Labels in this area