Debugging Collections, Streams and Watch Renderers

In the last two ducklings, I finished the extensive discussion on breakpoints and switched my focus to the watch area. In it, we have several amazing and lesser known tools that let us build insight into our running application. Being able to tell at a glance if something works correctly is crucial for many applications. This is very important for collections and arrays. We can have thousands or millions of elements within a collection. Debugging this is very difficult without some basic tools. Collections, Arrays and Streams Debugging collections (lists, maps etc.) and arrays is painful. You need to dig through results or place conditional breakpoints in for loops. That’s all painful. There are better solutions… Filtering Collections I talked about a a couple of weeks ago, so please don’t confuse the two. There are many filter types. Here, they apply to the collections and arrays. different type of filters This is a minor feature that’s actually on by default. Yet most developers don’t even notice it. When you expand an array of objects, you might have noticed that the IDE hides null values. This is a filter that’s on by default, you can also add your own… We can start by selecting an array or collection in the watch and right clicking it. Then clicking the “Filter” option. We can then input any condition we want where “this” stands for the current element. When we press enter, the filter will be applied and we’ll only see the applicable elements. Notice that in this case, I used method calls and their results as part of the filter. Here we see the filter in action. We can clear it by pressing the “clear” button next to it. We can edit it by clicking on it too. Stream Debugger While I use the Java 8 stream API frequently, I still prefer the old for loops for most cases. The reason for this is debugging. Loops are just inherently easier to debug. It doesn’t mean we can’t debug streams, but it’s often more challenging and requires more wiggling. JetBrains understood that problem and introduced the stream debugger, initially as a plugin and currently as a built-in tool in the IDE. You can see the button to launch the stream debugger when the current breakpoint is stopped on a stream. When you press this button, the stream debugger is launched. It’s one tool where watching the video will probably explain it better, but I’ll try… This tool represents every stream function as a stage. You can go back and forth between the stages where you can see how elements in one stage map to their counterparts in the next stage. E.g. a map operation can convert the type of element to a new type. So you would see the elements before the mapping and an arrow to the post mapping instance. Notice that all the elements are “live” and you can inspect everything as you can with normal inspection in the watch. Renderers We normally look at elements in the watch area without giving it too much thought. That’s the “object” or the data… But what we see is the way a renderer interprets the data. The default behavior for renders in Java is to invoke the toString() method. So while customizing this helps, there’s a lot more that a good renderer can accomplish… In fact, next week's duckling will dig even deeper into this subject. Mute Renderers to Speed Up Debugging Don’t you just hate unresponsive debugging? Pressing step over and just waiting forever for something to happen is very frustrating. There are many reasons a debugger can be slow. Some of them relate to the application we’re debugging, but quite a few of them relate to features we turn on/off. Renderers fall into this category. They can be VERY expensive when we have many watch elements or if the process for rendering them is slow. Luckily JetBrains provides a simple workaround: mute renderers. You can enable this by right clicking on the watch area. Once we mute the renderers, they appear as a short form rendering. Just the object ID next to a button. Clicking on this entry automatically performs the rendering lazily. In this case, the rendering will just invoke the toString() method, as indicated here. Once clicked, we can see the correct value in the renderer and we can inspect the result only for this value. Other values might still be “unrendered”. Renderer Customization toString() is great for many things, but it might not represent what we want to know about an object. Especially 3rd party objects where we can’t control the toString() implementation for cases where performance is an issue. toString() must be efficient since we might use it when logging an object in production. We can’t overburden it with data. The “Customize Data Views…” menu item launches the renderer customization menu. This is a pretty powerful feature that lets us control many nuanced capabilities in the default renderer. There are many options in this dialog that let you customize the way elements are rendered in the watch. One of my favorite options is the one to show hex values for integers, which is pretty useful for some of the low level stuff I do. Here you can uncheck the hide null elements in arrays and collections option we discussed in the filter section above. You can also limit the toString() behavior to specific objects. Type Renderer For simple cases, toString() works really well. But there are complex cases where our ability to affect the rendering logic can make a vast difference. Case in point, Spring Boots JPA Repositories. These are interfaces that abstract the underlying database as a set of CRUD operations. A detailed toString() method will be expensive. It can trigger SQL queries, which isn’t something we’d want to do normally. But when we debug, this might be pretty valuable. First off, we need to select the right type for renderer. Notice you can use a base type to select the appropriate objects. In this case, JpaRepository is the base interface. By using the expression: "JPA Repository with " + count() + " elements" We effectively invoke the count() method on the object that’s rendered. This will probably result in an SQL call to the underlying database, but that might be performant enough during regular debugging. Notice we can check the “On-demand” flag to make the rendering behave similarly to muted renderers, so it will only render on click. For elements that support expanding, we can use additional expressions to fetch the full set of data. Here, I use findAll() to list the elements that IntelliJ will show upon expansion. I also use count() > 0 to indicate that the list is expandable. As you can see, the top repository is a JPA repository. The one below isn’t. The top repository is easy to understand at a glance and we can inspect every element in the database instantly. That’s remarkably powerful! Notice that the video above doesn’t yet cover the last portion here. I ran out of time there. Next week’s video will cover that and an additional interesting renderer feature. Summary Showing the right information in the watch is crucial. We can get a sense of what’s going on in an instant! Debugging can fail over stupid things: Too much information Too little information Information we need to dig through deep hierarchies to find We can resolve these things with the techniques I discuss above. If you get your watch section in order, your debugging sessions will become far more fluent. In the next installment, I will teach you how to make the debugging sessions of your entire team more fluent… Also Published Here