Unlike you, the IDE is not permitted to operate based on "reasonable" code. It has to limit itself to allow for the screwball antics that real code does. The toString method's "grossly inadequate" default, implementation, for example, is because a "reasonable" default that exposed the values of the bean's properties would have to allow for insane things like beans with hundreds of trivial properties - and what order to display them in. PLUS allow the programmer to know which of possibly thousands of identical copies of the bean was being inspected. And properties whose very values will cause the debugger to throw an exception if you attempt to look at them, which is something I see a lot of in ORM code, where the class has been instrumented and uses late-binding techniques. ORM model object are one of the primary cases where I do what I suggested, since I definitely want to see the key values, as they determine the uniqueness the object, and often want to see certain other critical properties, but the hundreds-of-trivial-properties case is endemic.
Likewise, the debugger cannot assume that it knows when your object is "fully populated". Unlike 1960s-era programming languages,
Java always initializes every property at construction time. When it's "fully populated" is for you to determine, but those values will be populated from the very beginning, and in no few debugging cases, seeing a value and knowing that it's not "fully populated" is how you discover the bug.
There is no realistic way to know if a method is idempotent, since the method can potentially drill down into many other classes and methods and do so using a multitude of conditional paths. Although there are some definitely non-idempotent methods, such as factory methods and methods that return auto-incrementing keys, there is no language support to either report or enforce idempotency in Java. The closest you can get is a static constant.
In any event, your solution wouldn't have helped much in the use case you mentioned. Firstly, because good java design doesn't recommend
public properties. JavaBean properties are recommended private, and only exposed via standardized set/get methods. The "set" methods, by their very nature not idempotent, but the "get" methods may not be idempotent, either, since while it's not good design, offenders are common. Debuggers display these private internal objects using Java's introspection services. Which can also be freely used by applications, and thus further muddy the waters.
The most telling reason why your solution won't work, however is your stated use case. You have confused DOM properties with bean properties. Although there are many ways to convert XML to a DOM, the most common implementations involve DOM-specific classes which hold the XML "properties" (technically
attributes) in collections of objects that themselves are complex XML-specific object types, not as simple javabean properties that can be easily-displayed via a simple debug operation. That's even before you get into some of the late-binding tricks I mentioned earlier that make it virtually impossible to simply "click and see".
In other words, the reason that something like a dom4j object cannot be simply inspected by the debugger is because it's not a simple object to begin with. It's a horrible monster. And for the record, I hate digging through them, too. What I usually do is jam a snippet of code into my module in development that will render it out as an XML
string for inspection. Or, when possible, use a cleaner option such as the Apache Digester.
