Friends of OpenJDK Today

What are you Missing by Debugging in VS Code?

February 17, 2023


  • Shai Almog

    Author, DevRel, Blogger, Open Source Hacker, Java Rockstar, Conference Speaker, Instructor and Entrepreneur.

In the first chapter of my debugging book, I discuss IDE debugging.

In that chapter, I mostly talk about IntelliJ/IDEA.

People often ask me why I didn’t write as much about VS Code…

The reason is that there isn’t much to write about. Its debugger is simpler for better and for worse. It isn’t as powerful as other IDEs. I created the following video that covers the content of this post:

This isn’t a slam against VS Code or against Microsoft. Visual Studio has one of the most powerful debuggers around. But Visual Studio Code doesn’t have a lot of the features from Visual Studio or other IDEs. I believe this is intentional.

I think this is a user experience-driven decision in which they removed features to simplify usability. One thing VS Code did well was exposing the logpoint (tracepoint) feature, so it is more discoverable to the casual developer. That’s pretty great and wouldn’t have been practical if the IDE had all the salient features.

But there’s a price that comes with simplicity.

As you can see in the following table there are many missing features that are available in IntelliJ. These are all features I covered in blog posts or videos. Notice that the video links in the following table are direct links to the specific time within the video.

Feature VS Code Comments Links
Breakpoint Video, Post
Conditional Breakpoint Video, Post
Logpoint/Tracepoint Video, Post
Step Over Video, Post
Step Into Video, Post
Step Out Video, Post
Continue Video, Post
Run to Cursor Video, Post
Return Immediately Restart Frame is available Video, Post
Jump to Line Video, Post
Return Value Display (on by default) Video, Post
Evaluate Video, Post
Watch Video, Post
Inline Watch Video, Post
Set Value Video, Post
Object Marking Video, Post
Method Breakpoints Video, Post
Field watchpoints Video, Post
Exception Breakpoints They suck without filters Video, Post
Grouping/Naming Breakpoints Video, Post
Disable Breakpoints Video, Post
Instance Filters Video, Post
Class Filters Video, Post
Caller Filters Video, Post
Filtering Array and Collection filtering Video, Post
Stream Debugger Video, Post
Basic rendering Very simplistic Video, Post
Entry Rendering Video, Post
Rendering Annotations Video, Post
Thread View Video, Post
Async Stack Traces No custom support Video, Post
Searchable memory View Video, Post
Track new Instances Video, Post

The Missing Features

Following is a high-level overview of the missing features.

Flow Control

Return immediately lets us return right away from a method and potentially return an arbitrary value. This is fantastic when you want to test edge cases.

There are also drop frame and throw exception features.

To be fair, VS Code has “restart frame” which is similar to “drop frame” and also nice.

Jump to line requires a plugin for IntelliJ. It lets us drag the execution pointer to an arbitrary location. If you have a bug, just drag the execution back and try again.

Need to skip a line of code because your app is in a problematic state but you still want to debug?

Drag forward. This is a fantastic killer feature when you need it.

Watch Area

Both IDEs contain a watch but only IntelliJ can show the values of the watch variables directly in the editor itself. This is very convenient when watching multiple values. It lets us see the stack at a glance as we scroll through the code.

Object marking is one of my favorite obscure features. It lets us dynamically declare a global variable that helps us track a value. We can use this global variable in a conditional breakpoint to verify things. One such example is saving the current thread as a marked object and then only breaking if we hit the method with a different thread.


Method breakpoints are pretty problematic but they have some edge uses. One of the big values is the ability to break when returning from a long method. This is helpful in tracing threading issues.

Field watchpoints are very useful when tracking field mutation and new values.

We can manage breakpoints, name, group and disable them as a hierarchy group. When dealing with multiple tasks and switching branches in the middle of a debugging session, we can keep that session on hold by grouping all the breakpoints together.

When we return to the task, we can instantly jump right back!

VS Code has exception breakpoints. But without filters they absolutely suck!

We can filter breakpoint hits based on multiple criteria such as instance, class or a specific method in the stack. I spent so much time pressing continue over and over again. We can reduce this pain using these tools.

Arrays, Collections and Streams

There’s another spectacular type of filtering. We can filter the content of an array or collection right in the watch or evaluate area. I spent a great deal of time digging through arrays of image data with thousands of elements. This was a nightmare. With this, we can find the entries that we need in a collection or array, instantly!

This is about the Java 8 and newer stream API which is a functional programming construct. It’s a fantastic tool, but it makes debugging awkward. The stream debugger borrows concepts from time travel debuggers to make stream debugging easier than regular debugging sometimes.

Entry Rendering

This is one of the most fantastic features you can think of. We can completely customize the way entries look in the watch. In the demo here, I show how I can expose the content of an Object Relational Mapping object as I step over in the debugger.

But this is hard to configure every time for every case. Annotations let us configure this globally so we can see this every time for specific library objects when running in the debugger.

Thread and Asynchronous Debugging

VS Code shows threads, but it has very limited display functionality and configurability. IntelliJ can open a dedicated thread view, hierarchies and much more.

It also supports gluing asynchronous stack traces together to make it easier to debug asynchronous code. This works seamlessly with well known APIs and the really cool thing is that we can use annotations to add this to our custom APIs.


We can search through memory to find any object instance. We can find VM internal instances and investigate issues by reviewing the objects in the system.

Better yet. We can track every new instance of a particular class. Get full stack traces to every new instance created between one breakpoint and another. This can track what happened under the hood with surgical precision.


There’s a lot I didn’t cover because there’s just so much. I don’t think VS Code is inherently bad. It just went for simplicity. Personally, I think of myself as a power user. If you’re like me I hope this post gave you a sense of what you’re missing.

Please check out my book, my course, and follow me for videos like the one embedded above.


Related Articles

View All


  • Shai Almog

    Author, DevRel, Blogger, Open Source Hacker, Java Rockstar, Conference Speaker, Instructor and Entrepreneur.

Comments (0)

Your email address will not be published. Required fields are marked *

Highlight your code snippets using [code lang="language name"] shortcode. Just insert your code between opening and closing tag: [code lang="java"] code [/code]. Or specify another language.

Save my name, email, and website in this browser for the next time I comment.

Subscribe to foojay updates:
Copied to the clipboard