今天使用 eclipse 进行 debug 处理，在 eclipse 的 debug 模式中跟踪变量。
发现这个变量在Variables view视图中的详情信息中只显示了这个变量 toString()的内容。由于这个类的toString()没有被复写而是继承了 Object 基类的toString()，打印的是 hashCode()的值，不是我想要的。我想让它的 toString()被格式化为 JSON 结构并且是被格式化之后的 JSON结构，方便人的阅读。虽然我可以去改写这个类的toString()，但是我不想这么做，而是想利用 eclipse 的功能来实现。我去 Google 找了找，还真找到了解决方案。
参考地址：http://www.robertwloch.net/2012/01/eclipse-tips-tricks-detail-formatter/
它里面就是使用了eclipse 下面 debug 的 Detail Formatters 的功能。详情请参考上面的地址。
设置的地方1： Preference -> Java - Debug -> Detail Formatters 。在这里进行设置。
设置的地方2：在 Variables view 的视图中，选择里面一个变量，点击鼠标右键会出现右键菜单，里面有一项菜单就是”New Detail Formatter...“的。选择这个功能，在这里设置。
在“Types with detail formatter" 的这里选择你要覆盖 toString() 方法的 interface 或者 class 都行。跳出的对话框中会让你在”Detail formatter code snippet“里面输入 format 的格式化代码。
我的代码如下：
return new com.google.gson.GsonBuilder().setPrettyPrinting().create().toJson(this);
使用 Gson 对代码进行 json 化，使用 GsonBuilder 的setPrettyPrinting()方法使得 json 被格式化为人方便阅读的格式。
然后就可以 debug 去了，你会发现在 debug 模式的Variables view窗口的 detail 里面你关注的类已经被覆盖了 toString() 方法显示出你格式化之后的内容。这个是 eclipse 非常强大的功能。
下面是参考网址的内容：
Eclipse Tips & Tricks: Detail Formatter
1. Your Situation
You find yourself debugging a Java app with Eclipse and you’re stepping through the code in the Debug perspective. You have the Variables view open and for most of the selected types you can see a reasonable toString() output below the variables list.
However, many types don’t have a type specific implementation of toString(). E.g., consider an array of objects. There’s no toString() on arrays. That’s why the variables view prints you some meaningless default text with a hashcode for such variables.
But did you know that you can change that by defining a custom toString() implementation that’s used by the variables view at runtime? Let me introduce you to the concept of Detail Formatters and learn about the Display view along the way, too.
2. Preparing a custom type evaluation
Lets start at a breakpoint in some arbitrary code as shown in the following screenshot. 
The debugger stopped within a for-loop that iterates over a collection of CellBindDesc elements. 
In the Variables view the variable desc is selected to see what’s inside. Unfortunately, the class CellBindDesc didn’t override toString(). That’s why the default gibberish is printed below the variables list 
.
You do not need to know all the details about the CellBindDesc. It’s enough to know that it’s a description of mapping a model element’s field to an uiElement, e.g. a String property to a Text field.
To find a specific field of a model element the CellBindDesc holds an array of model element properties 
that’s similar to a tree path. The first element is a reference to a property of the model root element that’s stored in the model field of CellBindDesc. The other elements are references to properties of the model tree.
So, what I actually want to see below the variables list is not the gibberish, but at least the path to the model property and a hint to which uiElement it is bound. Sounds like some StringBuilder code, right? To create and test this code on the fly you should open the Display view 
. Imagine this view as being a container of code statements that are inlined at the position of the current debug step. In case of the screenshot above that would be line 170.
But the code is not really inlined. Instead you can use the Inspect command to execute the selected statements at that debug step. You can run that command with [Ctrl]+[Shift]+[I].
As you can see in the screenshot all lines are selected and the last statement even is a return statement that concatenates stuff to a String. Running [Ctrl]+[Shift]+[I] on that selection will show the familiar Inspect popup containing a String node with the return value if you did it right.
As you can see in this example, the Display view is very powerful. It’s so important to me, that I always open it when debugging. By the way, code completion does work there, too.
3. Edit the Detail Formatter
Now, with the snippet being tested in the Display view and the result being what one would actually like to see at it’s time to configure the Detail Formatter. Open the context menu on the variable for which you wish to configure a Detail Formatter and select the Edit Detail Formatter…entry 
.
In the Edit Detail Formatter dialog paste the snippet from the Display view and make sure the Detail Formatter is enabled.
After closing the dialog you should see the detail formatted output of your selected variable. In case of my example I’m now able to see the type, the model path and the ui element of each CellBindDesc directly below the variables list.
As the Detail Formatter is used for every instance of the type on which it is defined I am now able to step through the list via [F8]. No more need to check each property of the variable desc until I know all the values I need to tell if something is wrong. Ain’t that a great time safer? I bet it is!
4. Happy Debugging
Things you should have learned:
- Always open the Display view when you’re in the Debug perspective and make use of it. You can even collect several statements there and select only the one(s) you need for inspection depending on your debug context.
- Write Detail Formatters for arrays and complex types to show more details in the Variables view. Detail Formatters do even override toString() implementations if there should be one!
Happy debugging!