Debugging J2EE can be cool. Or not.

Unless you’re an ABAP veteran, of course. SAP support employees and many other ABAP vets are perfectly used to debugging ABAP applications remotely. Even in a productive system. Even jumping right into a running user session that is stuck for any reason. Without negative impact on the rest of the system.

But that’s because – despite its image to the contrary – technologically speaking, ABAP has been cool for ages, with an integrated, fully server based and multi user oriented development environment and all that. We’ve come to take that kind of robust and sophisticated approach to developing and troubleshooting applications for granted.

In the Java world things aren’t as easy. The development environment, as well as the program sources needed for coding and debugging, exist locally on the developer’s PC (which implies they have to get there somehow…). Debugging a Java application stops the Java process and prevents everybody else from using the same server. Connecting from a local IDE to a remote J2EE engine (possibly through firewalls inbetween) is definitely a nontrivial task.

So WebAS developers have put in a lot of work to allow remote debugging of SAP J2EE applications: establishing a connection between IDE and J2EE engine (even going via SAProuters through the firewalls between SAP’s and the customer’s intranet) based on connection information maintained in the Service Marketplace, isolating a J2EE engine cluster node from the rest and reserving it for debugging (so the rest of the cluster can continue running productively), getting Java sources for the exact version running on a customer’s WebAS and then, well, debugging away. And all that with full control for customers to limit and monitor what can be done when and on which of their servers.

Sounds easy if you are used to doing it in the ABAP world. But if you look behind the scenes a bit more closely, it’s definitely a very cool thing to be able to do.