Java Remote Debugging — The 2022 Guide
Debugging is an essential part of the software development lifecycle. Therefore, modern developer tools are well-equipped to support application debugging. However, what if you need to debug the code running in a production environment instead?
That’s where you need remote debugging. This article will guide you to perform remote debugging on your Java applications using cutting-edge developer tools.
What is remote debugging in Java?
Remote debugging helps investigate issues in external environments. Typically you have to connect from your local environment or from a Bastion host to the remote server to perform debugging.
Java has established a unique architecture called Java Platform Debugger Architecture (JPDA) to facilitate this. Its multi-tier architecture comprises the components such as the Java Debug Interface (JDI), Java Virtual Machine Tool Interface (JVMTI), and Java Debug Wire Protocol (JDWP).
But why should a developer debug remotely instead of debugging locally?
Nowadays, most Java applications we develop are multi-threaded solutions that incorporate cloud infrastructures and services. Also, there can be distributed applications that are not feasible to debug in local machines. Therefore, local debugging is not practical for such solutions.
Current solutions for Java application debugging
There are several ways of debugging Java applications. Some work locally, while others may facilitate both local and remote debugging.
- Classic Debuggers are the most standard version of the debuggers typically embedded with IDEs. It is easy to use, but it has challenges when debugging applications running on remote servers. For example, suppose you configure a classic debugger to investigate an application running on a remote server. Yet, It is not feasible since debugging could significantly impact the application’s performance.
- Logging is the simplest way of tracking data to debug applications. In addition, it may help analyze application execution paths and behaviors. Java Logging Frameworks make this job easier to implement logging in Java applications. However, the downside is that it is a very time-consuming process.
- Production Debuggers are designed for remote debugging. It requires adding an agent to the server application that establishes the connection for remote debugging.
However, before choosing a solution for remote debugging, it is worthwhile to understand the challenges that come along with it.
Remote debugging challenges in Java
1. Complexity in setting-up: Configuring a remote debugging tool on a server is not very straightforward, like local debugging using a tool in-built to an IDE. Developers need to allow remote connections to servers through various server security layers such as firewalls. Further, additional effort can be required to smoothly establish the seamless connections between remote servers and client devices used for debugging.
2. Risk of security vulnerabilities: Opening up firewall ports and whitelisting more inward and outbound network traffic can be a risk in terms of remote server security. And also, as with the very recent Log4J vulnerability, there can be some exploits based on remote debugging tools and infrastructure.
3. Impact on application performance: If the JVM’s remote debugging configuration is turned on, production application execution can be a noticeable delay
Despite these challenges, you can still gain many benefits through remote debugging. Next, I will present a step-by-step guide to remote debugging using one of the best Java Remote Debuggers I have recently experimented with. You will have better exposure to remote debugging and its best practices to overcome the challenges discussed above.
An Effective Approach to Remote Java Debugging
Sidekick — live debugger — is a feature-rich solution that I have recently tried out among several remote debuggers. I used a Spring Boot ToDo List Java application and configured the Thundra Sidekick agent to work.
If you are interested in trying out Sidekick, you can follow the simple steps below.
Step 01: First, you need to create an account on Sidekick.
Step 02: Connect the Java application with the Sidekick agent. For live debugging, Sidekick provides the ability to integrate your version controlling system (GIT). Interestingly, Sidekick has only read-only access to your source code and never fetches the code into their servers. It processes only within your browser, which is excellent in security.
Step 03: Add the Sidekick agent to the project. The Sidekick agent is available to download for free at the Sidekick repo. Then there are multiple ways of configuring it. I preferred setting up environment variables as below.
export SIDEKICK_APIKEY=
export SIDEKICK_AGENT_APPLICATION_NAME=app-name
export SIDEKICK_AGENT_APPLICATION_STAGE=dev
export SIDEKICK_AGENT_APPLICATION_VERSION=1.0.1-SNAPSHOTYou can find the Sidekick API key by logging into the Sidekick dashboard. The command below can integrate the Sidekick agent into the Java application.
Step 04: Add tracepoints to your code and start live debugging. The screenshot below shows some of the tracepoints I have added to my Java application.
What I like most in Sidekick is its Tracemap feature which comes with the native Thundra APM integration. There you can inspect the architecture of your application and traces of its behavior live, which helps you detect errors and identify the root causes of those in real-time.
Sidekick also provides the ability to inspect Stack Trace, and it is configurable to alert upon critical errors and exceptions.
I recommend you check the Quick Start Guide of Sidekick and experiment with Sidekick by yourself to try out many more features offered.
Conclusion
When a bug is identified in a remote server and using a remote debugger, you do not need to reproduce it, but you can directly debug it. Knowing the available debugging solutions, best practices, and challenges will help you decide when you pick your Java debugger for your project.
I hope this article will help you experiment further with remote debugging and improve the productivity of your development work. Thank you for reading!
Originally published at https://www.runsidekick.com.
