Understanding existing 'legacy' java applications is not always simple. Especially if the original developers left the company and you have to fix a bug or apply some enhancements. Dependency injection frameworks (Spring) and other very dynamic factors like Hibernate make it very difficult to quickly grasp the structure of an application and understand where the 'core business' resides. Traditional tools like a debugger do help, but their view is often too fine-grained or they cause timeouts, breaking the normal program flow.
A better alternative to understand an opaque java application might be to use a profiler. JProfiler is my favorite, other choices are JProbe or the embedded profiler of NetBeans. When running your application against a profiler, you don't hit timeouts and you quickly get a very useful and in-depth view of the application: cpu an heap usage statistics with detailed call tree graphs immediately point you to the relevant 'hot' parts of the application.
Conclusion: profilers can be a welcome addition to debuggers and other analysis tools when inheriting a complex codebase. This is the first time that I look at profilers this way, and I must admit, having done many JProfiling sessions that you quickly get an indepth view in the most obscure (generated) code with these tools.