wood burning stoves*
The moose likes IDEs, Version Control and other tools and the fly likes Eclipse add-on for seeing a Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Engineering » IDEs, Version Control and other tools
Bookmark "Eclipse add-on for seeing a "method view" of a class?" Watch "Eclipse add-on for seeing a "method view" of a class?" New topic
Author

Eclipse add-on for seeing a "method view" of a class?

Jonathan Sachs
Greenhorn

Joined: May 21, 2013
Posts: 15
I have an idea for a useful add-on for debugging. I wonder whether thing I wish for has been written.

I want to view a class in terms of the public properties and methods it exposes, rather than its internal data.

Here's the reason: I'm writing an application that uses the Apache package for parsing an XML document. I don't have to debug this package, but I have to understand what it's doing to debug my own code, and it's not easy.

For example, I called the Element class's getFirstChild method, then used the results in my own code, and my code blew up. Was it because there's something wrong with my code, or because getFirstChild didn't return what I expected?

It turned out to be very difficult to tell! The object that getFirstChild returned has a very complex internal structure, which isn't documented because "you're not supposed to have to know that." I finally found the list where the returned object's properties were kept, and it was empty. Aha! I thought. The problem isn't in my code!

I spent another hour chasing my tail before I realized that the package doesn't finish populating the data in this type of object until the data is referenced. Thus the empty property list didn't mean that the object didn't contain the items was supposed to; it just meant that my code hadn't referenced them yet.

Knowing that will protect me from wasting my time chasing a phantom problem, but won't help me debug. It just tells me that even if I can figure out the undocumented data structure of an Element, I can't rely on what I find there.

So, what I'd like is something like a debugger view that shows the values that the class's methods would return if I called them, and never mind that the internal data is.

Obviously I'd have to be able to select the methods that get this treatment. Methods that change the state of the object would have to be excluded. Still, the ability to see a summary of certain method values would be valuable.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3611
    
  60

I'm using NetBeans personally, but I believe Eclipse has the same functionality: I can add a method call to the Watch window, and the method is called and its result is displayed there.

The IDE has no way of knowing whether the method changes the internal state of the object or not, so it's up to you not to use this functionality with methods that change state. You cannot expect any help here, except from the javadoc (if there is any).

By the way, I usually trust third party libraries until proven wrong. Only when I can clearly demonstrate that the expected behavior of the library differs from the result, I go on to dig deeper. In most cases it turns out I understood it wrong.

Then again, understanding the library from debugging it is an awful lot of work. Doesn't your library come with a decent documentation, or even tutorial? There are lots of XML parsers around, no need to use one which is not really well documented.
Jonathan Sachs
Greenhorn

Joined: May 21, 2013
Posts: 15
Correct me if I'm wrong... if I add method calls to the watch list, don't I have to make those calls on a particular object, rather than the object I choose when I need information? If so, the utility would be limited.

A couple of points of information. First, I don't claim (or believe) that the package is working incorrectly. Only that its internal behavior did not match my default expectations, and makes the information displayed by the debugger almost useless.

Second, there is a reason for using this package, despite the disadvantage I've found: it's the one used by other applications in my employer's source repository.

In any case I don't think I'd be likely to find a package with good documentation for its internal architecture. In the years I've been a programmer, I don't recall ever seeing such a thing.
Martin Vajsar
Sheriff

Joined: Aug 22, 2010
Posts: 3611
    
  60

Jonathan Sachs wrote:Correct me if I'm wrong... if I add method calls to the watch list, don't I have to make those calls on a particular object, rather than the object I choose when I need information? If so, the utility would be limited.

If you're debugging, you can add a variable to the Watch window and you'll see it evaluated at the current context (whatever that is). Adding a method call works the same - the object reference is evaluated at the current context and the method of the resulting object is called. It is, of course, important that the expression you've entered doesn't change state of anything, in any possible context, as the contents of the Watch window can be evaluated at various times.

I also didn't understand why you debugged the internals of the package. It seems more obvious now. Apart from putting method calls to the Watch window I've described I don't see anything which could help you with what you need. After all everything you need to know about the state of the objects from the package should be somehow accessible using public methods, shouldn't it?
Jonathan Sachs
Greenhorn

Joined: May 21, 2013
Posts: 15
"...everything you need to know about the state of the objects from the package should be somehow accessible using public methods, shouldn't it?"

Yes, it does. The catch is in the "somehow." I'm looking for a tool that makes the state of one of these object as easy to access as the values in "debugger friendly" classes where the data elements are useful. Or, if not that easy, at least in the same ballpark.

At this point I think the most cost-effective solution is to write a method in my program that extracts the information I'm likely to want from an object passed to it a an argument, and displays it. I can use the "display" function to apply that method to the object of my choice while I'm debugging. It lacks elegance but it take a lot less work than writing my own add-on, at least in the short run.
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

Jonathan Sachs wrote:
So, what I'd like is something like a debugger view that shows the values that the class's methods would return if I called them, and never mind that the internal data is.


That's a bit unrealistic. It would only work on idempotent methods. Any method that alters the internal state of the object would not run the same as it would stand-alone, and that also applied to classes which don't alter their own state, but which reference other classes whose state is altered.

When dealing with model objects, I generally implement the "toString" method on those objects so that the debugger can display a synopsis of the object's most salient properties so that I know which instance of the object I'm dealing with. I can then examine the object in more detail in the traditional way if I need to. The "toString" method conventionally is idempotent, so there's not an issue there, and Eclipse has a very simple menu command for generating the necessary code with minimal effort.
Jonathan Sachs
Greenhorn

Joined: May 21, 2013
Posts: 15
Tom, I think I'm missing the point of your comment... or you missed the point of mine.

It would only work on idempotent methods.


I looked up "idempotent" to see if I understood its meaning correctly. I did. I mentioned that limitation myself, at least a couple of times, although I didn't use the technical term. I see it as something that an add-on would have to allow for, not something that makes an add-on unrealistic.

I generally implement the "toString" method on those objects...


To do that I'd have to subclass every one of the classes in the package to override the built-in (and grossly inadequate) toString method. The package I'm working with now has about a dozen of them. And each time I used a new package I'd have to do it again. Why sign on for all that extra work if a general solution is possible?

Ironically, in my last post I said I was going to do exactly that as short-term measure, rather than undertake to write an add-on to solve my immediate problem.

I can then examine the object in more detail in the traditional way if I need to.


You do understand that the reason I made this inquiry in the first place is that I'm dealing with a package where I can't "examine the object in more detail in he traditional way" because the objects' internal variables aren't fully populated at construction time?
Tim Holloway
Saloon Keeper

Joined: Jun 25, 2001
Posts: 16305
    
  21

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.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Eclipse add-on for seeing a "method view" of a class?