I am working in Eclipse with a program that someone else wrote, There is a certain section where I cannot figure out the procedure of method calls. It seems like methods that modify a class are being called from nowhere at all. Is there a way to see the order that methods are called in eclipse? Like as a debugging feature. Or would I manually have to go add println's to thousands of methods?
One possible way is to set a breakpoint in the method being called "from nowhere", and then inspect the call stack to see from where the invocation came.
The screenshot below shows the call stack in the top-left corner of the IDE.
You can right click the method name, and select Open Call Hierarchy. That will givwe a list of places where the method is called from, and where they are called from etc.
Alternatively you can Thread.currentThread().getStackTrace()
That returns an array of StackTraceElements that represent the current stack trace of a program. You can iterate and print as if it were an exception stack trace, to see where the method was actually called from.
Related
I use jdb for my Java development. For my application I have two classes: WordUniverseTest and WordUniverse, and the main method is contained in WordUniverseTest. When I execute WordUniverseTest inside of jdb, I construct a WordUniverse object called obj inside of the main method.
But I do not know how to have jdb leave the WordUniverseTest class and step inside WordUniverse while obj is being constructed. How do I do this?
You can put a regular breakpoint there stop at and then when you are actually on the line (call list to verify), you can call step into.
As long as all your classes are known to jdb, it is going to work, I tested it.
I found the answer, and although Gergely Bacso didn't give the full answer, he did lead me to find the full answer.
jdb uses a different procedure for stepping into methods versus stepping into constructors. To step into a method, you have to do what Gergely Basco said, which is set a breakpoint at where the method is called and then step into. But for stepping into a constructor you must say stop in ClassName.<init> (with brackets). Saying that command will take you inside of the constructor.
I have a Java application and basically I want to know all the methods that are called in the background when I do something in the GUI. I know you can view the Call Hierarchy by selecting a method but that's while the code isn't running. I want to view every single method called in every class when I select something for example so I can figure out which methods/classes/packages are responsible for this functionality. I also don't want to have to set a breakpoint at the start of every method as there are far too many methods/classes/packages for that to be feasible. Bear in mind that I don't even know the first method called for some of the operations, if I knew that, it'd be easy to figure out what's going on.
Is there a way to do this or am I ahead of my time?
I think you could use the debug mode to see all methods called
Run DEBUG in your IDE, your each step in application will move you to the right place in the code, during your program you can see each variable value.
Also you can follow each code line which your code is doing.
http://www.vogella.com/tutorials/EclipseDebugging/article.html
Regards!
Usually to find the callers of a method in Eclipse I use ctrl-alt-h on the method. If nothing comes up, it is a callback from some other library. I'm pretty certain this method is not a callback and I'm pretty certain it's being called from somewhere. How can I find out if nothing shows up with a ctrl-alt-h?
You can put the cursor on the method name and press Ctrl-Shift-G (default key combination).
This will open a search in the project to look for references to your method.
Edit
On frameworks using declarative markup (Spring, Android, etc.) you might actually need to use a more manual approach: the file search.
Copy or highlight your method name
Press Ctrl-H (default binding) and select File search (you can assign a custom key binding for that but no custom is provided)
Fill the containing text with your method name if not automatically filled
Optionally, select "case sensitive", or your file pattern if any
Then select your scope (the project should be a good place to start)
Other tactics include:
If the method is implementing a interface, ask Eclipse for the callers of the interface method. Sometimes Eclipse will identify more callers through the interface method, particularly when callers don't know they're using a particular implementation.
Similarly, if the method is overriding a base class method, ask Eclipse for the callers of that.
Put a breakpoint in the method, and look at the call stack in the debugger.
If it's possible that the Java method might be called by native code through JNI, use text search for the Java method name in the native code.
If available, ask the authors of the method.
So let's say that I have method A and I want to know if kicking off method A could possibly result in method D being kicked off. It's obviously easy to determine if A calls D directly, but is there a way to determine if D is called further down the stack (ex: A calls B, B calls C, C calls D)?
Basically I'm looking to do a recursive search of all method calls with in a particular method to find another specific method call. Any help on this would be greatly appreciated.
Regards,
Brandon
Found the solution! Apparently I wasn't the only one that came up with this question, I just didn't word it quite the same. Here's the best solution (and it does use the Call Hierarchy in Eclipse, thanks Raedwald!)
If you have an IDE (like Eclipse or Netbeans), you could put a breakpoint in method D, and then have a look at the stack at that point in the Debug view.
In Eclipse for example, there will be a panel that looks something like this:
Image from Eclipse Help
You can see in the stack that main() has been called.
In your example it might look something like this:
ClassZ.D() line: P
ClassY.C() line: O
ClassX.B() line: N
ClassW.A() line: M
I just have a simple question, consider the following method
public void do_something(long arg){
//some work
}
and in eclipse, I added a break point for the above method and run the program, everything is fine, but I cannot find out the stack of current point?! for example
call do_something
push id
call previous_method
call xyz
pop z
call useZ
push z
I mean this method is called by 10 different methods and different stack, how would I find out the full stack of the thread(including methods) with eclipse?! should I change some default property or what?!
To put an image, I repeat my comment as an answer.
In the Debug View you can find the call stack and in the Variables View you can find the actual parameters and values of the local variables:
To get the actual parameters and values of local variables of an other method in the call stack just click in the Debug View on a method above the current method.
This isn't working for a multi-threaded application. You can only see the call stack for the current thread where the method is running in it. Look at:
In the method foo a thread is created by creating a timer. If the jvm suspend on bar, it only sees the call stack of TimerTask.run -> bar but not main -> foo -> run -> bar.
What you've described isn't a stack.
It's a history.
Eclipse isn't designed to give you a history. However, there are other tools that can show you the history, such as Chronon. However, that might be too expensive for you! It also might use too much memory if your application is very complex.
The simplest way to get a history, however, is to put System.out.println("some message") in lots of places.
It can be inconvenient to use System.out.println everywhere, so a couple of other ideas have been developed to improve on this:
Logging frameworks handle common tasks such as printing the time when something happened, rotating big log files etc.
Aspect-oriented programming allows you to inject logging in lots of places at once.