Debug Like a Pro in 2025: 10 New Eclipse Java Debugger Features to Enhance Your Productivity (With Spring Boot Examples)

Note: This is different from Open Declared Type, which takes you to the class definition (eg. java.util.List for reviews variable), not the actual line where the variable was introduced in the code.

Now you’re left wondering:  “Which BookService is this coming from?”

Not anymore… :D

Now Eclipse Understands the Signature!

If the stack trace includes the method name and signature, Eclipse can now disambiguate between classes with the same name.

So on latest Eclipse (v4.35 onwards) you will be redirected to the indented class.

Now, Eclipse understands the version specified in the stack trace and opens exactly the correct class from JDK 22.0.2, no mismatches, no confusion—pure results.

5. Auto-Resuming Trigger Points - “I Only Care About This One Flow, Why Do I Keep Stopping Everywhere Else?”

You want to debug the BookService.formatSummary(Book) method that builds a book's display string. The issue is this method is used in multiple flows like /books/{id}/summary, /books/all, and /books/recommended. You care only about the /recommended flow, but every time you debug, Eclipse hits breakpoints in unrelated code flows. You keep hitting Resume again and again just to reach where you want to stop in the expected flow.

Let Eclipse do the skipping for you…

Here's how: Set a trigger point on the method getRecommendedSummaries() in BookController. Enable "Continue execution on hit" in the trigger then place a regular breakpoint or method entry breakpoint inside BookService.formatSummary(Book)

Eclipse will skip the trigger point, fly past all the noise, and pause directly where your focus is, inside BookService.formatSummary(Book). You can even add a resume condition to the resume trigger (only resume when a specific condition is true else pause the execution similar to other breakpoints) for even more control.

 

6. Primitive Detail Formatter - “I Just Want to See This Value Rounded, but I Don’t Want to Touch the Code”

On inspecting avgRating variable which of primitive double type in BookService.formatSummary(Book). Its showing something like 4.538888… but you want to see it rounded to two decimal places, just to understand what the final value would look like when shown to customers. Now with Primitive Detail Formatter support you can define a New Detail Formatter for double type in variables view directly

or from Debug settings!

Configure your formatter : Use “this” to represent the primitive

Now, instead of showing the raw value, Eclipse will show you the adjusted value with two decimals...

7. Array Detail Formatter - “There’s an Array. I Only Care About One Value. Let Me See That.”

In our temperature analytics method “BookService.getTemperatureStats()”, we're working with a hardcoded primitive array of temperature readings temps[]. But only the 6th value (index 5) matters. Say it represents the temperature recorded at noon.

Usually, you'd scroll through the array or log specific indexes.

But now, you can simply focus on exactly what you need. Simply add a Detail Formatter for arrays similar to previous one..

Use this[] to represent arrays

And Voilà..

Perfect when you’re dealing with huge datasets but only care about a tiny slice…

8. Compare Elements - “I Wrote Three Different Ways to Generate Tags - But Which One Is Actually Doing a Good Job”?

You’re developing a feature that adds tags to books like "java", "oop", or "bestseller". You’ve written three different methods to generate them, and now you just want to see if their results are consistent, complete, clean, and in the right order.

You could print all the lists and manually check them, but when the lists are long, that gets slow and error-prone. 

Instead, you can now use Eclipse’s Compare Elements to instantly spot the differences.

Simply select all three generated lists then Right-click → Compare

Eclipse tells you what’s missing in each list when compared to the others.

Note : You can compare Lists, Sets, Maps, Strings, and even custom objects - just make sure you're comparing the same type on both sides.

Let’s take another scenario..

“These books look the same, but the system treats them differently - why?”

You recently made Set<Book> allBooks to avoid duplicate book entries being listed but several customers have reported seeing "Clean Code" listed twice. And on debugging the source, you realize that every Book has different reference ids but still having duplicates in final result..

You suspect the issue is because filtering based on reference id’s, but it's hard to tell by glancing the objects, especially if there are many similar books. So for analysing you can Select the suspicious  Book objects and then Right-click → Compare

On comparing with Eclipse it is confirmed that object’s contents are same and it’s their reference id are different! – Bug confirmed!

So now you can fix the bug by re-writing the logic to filter based on author and title!

You also noticed that some books have identical title and author but different IDs, which sparks another idea…. maybe sometime in the future, duplicates should be identified based on content...

9. Disable on Hit - “I Only Want This Breakpoint to Hit Once - Not 100 Times.”

You’re debugging a method like getAverageRating() that runs in a loop or across multiple books. You’re only interested in checking the first call, not stepping through all of them.

You used to: Let it hit once then disable the breakpoint manually…

Now Eclipse handles that for you.

Click on a breakpoint and enable Disable on hit option

Now on hitting the breakpoint it will automatically disabled.

This is super handy for loops, Scheduled jobs & frequently called methods.

10. Labelled Breakpoints - “Wait… What Was This Breakpoint for Again?”

After stepping through different flows, using resume triggers, collapsing stack frames, comparing variables, and disabling breakpoints on hit and modifying formatters of variables you now have 10+ breakpoints scattered across your project. One checks for null titles another one’s for catching duplicates one is testing trigger flow a few were just for one-time validations..

You open your Breakpoints view, and you’re met with this.. :O

No need to guess anymore. Eclipse now lets you label your breakpoints with meaningful descriptions. It’s like adding sticky notes directly to your debugging process.

Right click on a breakpoint -> Label

Once clicked provide your custom label :D

Now your breakpoint will be highlighted with your custom label – finally!

Debugging is one of those things we all do - but rarely talk about until it’s painful. And yet, when the right tools quietly guide you to the root cause, it feels effortless. That’s the kind of experience the Eclipse debugger aims to provide—thoughtful improvements that show up right when you need them most... :)

If you run into an issue, spot something unexpected, or have an idea for improving these features (or even a brand new one!), feel free to raise it under here: https://github.com/eclipse-jdt/eclipse.jdt.debug

Thanks for reading  and until next time! Happy debugging!