We Keep Coding

Eclipse Debugging Run Methods

it's probably really easy but I still don't know how to do this.
Is it possible to run a method while a program in Java is running in debug-mode in Eclipse?

While debugging, open the "Display view" to run any code you want at the position you're currently at.
See:
https://help.eclipse.org/neon/index.jsp?topic=%2Forg.eclipse.jdt.doc.user%2Freference%2Fviews%2Fdisplay%2Fref-display_view.htm

In debug mode, it will open a new perspective and it's going to show the workflow of your Main method, including all the methods invocations during it's execution, which variable's values has changed, everything that happen to the beginning until the end of your Main class code.
May you check this link, got a lot of usefull information.

Debugging using Java source code

Is there a way to include whole Java source code into an eclipse project so the program is easier to debbug (e.g. by inserting println in methods you otherwise couldn't insert anything)?
I have a bug in my code. But to better understand why the bug in my code appears, I'd like to see what intermediate results in some system method (on which use the bug occurs) are.
For example, I'd like to know what JViewPort.scrollRectToVisible() exactly does and how my input behaves in it by printing out some intermediate results that occur in the method itself.
EDIT:
Instead of using JRE System Library X, I want to add the source code from JDK as if I had written the code myself. I want to be able to edit any System class just as I am able to edit any class I created myself. I want editable .java files, not packed .jars...

You would need to add the 3rd-party library to your Eclipse workspace as an project. (How you would do that depends on the code you are dealing with.) Once you have done that, you can hack your copy of the library to add trace prints etcetera.
A better alternative is to simply attach the source code for the 3rd-party library so that the debugger can show you source as you step through the code, set breakpoints,. Then use "advanced breakpoint" techniques instead of trace prints; e.g. http://www.vogella.com/articles/EclipseDebugging/article.html#advanced

You cannot change the library code, but you can view it by using de-compiler. The max you can do is this. Now if you change any code in the libraries which you reached via the de-compiler, you would find an error stating "the integrity of the .jar package has changed which is not allowed"

Eclipse have built-in support for what you wanna do.
All you have to do is set breakpoint and execute application in debugging mode.
You can use these icons in Eclipse debugging perspective.
Follow along Eclipse Debugging Tutorial for details.

Is there a way to disable calls to Runtime.checkRestricted on the GAE Java development server under Eclipse?

I'm one of those guys who step through their code a lot during development. Beginning with version 1.6.4 of the GAE Java development server, the server has been instrumented with calls to a function named Runtime.checkRestricted. This causes two inconveniences when I step through my code:
Whenever I step into a function, the debugger goes into the function Runtime.checkRestricted (for which there is no source code) at least once, often multiple times.
Whenever I step over a function call which has a large call tree underneath, it takes a very long time for the debugger to come back. (That's always a problem in the Eclipse Java debugger, but now it's really bad.)
For me, all this causes a serious drain on productivity. Is there any way to disable this instrumentation, or at least to prevent the debugger from stepping into it? I am using Eclipse with the GAE plugin.

Add a step filter to filter out all step breakpoints you are not interested in. The Eclipse documention provides a guide how to set up step filter.
In your specific case, you will want to add a package filter for com.google.appengine.tools.development.* , as this package and its subpackages contain GAE's Runtime class and RuntimeHelper class. Finally, don't forget to activate the option "Use Step Filters" (Shift + F5).

Eclipse - showing full call stack (like when it hits breakpoint in debugger) without putting in breakpoints?

I'm working with a legacy Java app that is new to me so one way to figure out how it works and find things easier, I have thought would be to be able to get the full stack trace after I perform actions, so as to be able to see which classes are being used based on a particular UI action. I had thought this was possible in the debugger but it seems that it only works if I insert a breakpoint and in this case part of the purpose of this is so that I don't have to know what's being called to be able to insert the breakpoint first (as this would help tell me that).
I apologize if this is a basic question, I have searched on this but I'm not finding the correct answer.

This doesn't directly answer your question, but maybe it will solve your problem better. Take a look at BTrace. It lets you instrument a running Java app and insert some basic code of your own. You could, for instance, have it write out entire method call chains to help you find your way through the app. It's somewhat similar to AspectJ, but with an entirely different purpose and requiring no change in the project source:
"BTrace is a safe, dynamic tracing tool for Java. BTrace works by dynamically (bytecode) instrumenting classes of a running Java program. BTrace inserts tracing actions into the classes of a running Java program and hotswaps the traced program classes."

A few suggestions:
Some profilers will allow you to walk from any particular method up (and sometimes down) to see what's calling and being called. I've found this surprising informative about flow, even in apps I thought I knew well.
For understanding the mainline flow, I don't think there's a better substitute for working interactively with a debugger. It will lead you into learning other important things. Not what you wanted to hear, I know. This presumes that you can rapidly restart the app when you miss a key off-ramp.
Reverse-designing large legacy apps is the one place where I use UML fairly regularly. There's too much to keep in my head to form a good big picture. If you have a UML tool that will do reverse-engineering, load it up with the app, then probably prune down hard on the classes you don't care about, because they are trivial or obvious. Arrange the diagrams in a way that helps you understand. I've used Together, Magic Draw, and Visual Paradigm in this way. Together worked the best - but it was a decade ago.

When you are in the debugger perspective, you will see a view showing the launched processes. In that view you can tell it to pause all threads of a process. Once stopped, you will be able to browse through threads to see what they are all doing. To try to catch what a particular action is doing, you would have to start the action and then quickly pause all threads.

You could always run the application with the VM arg of -verbose:class. You could then watch the console output and see what classes the VM is loading when you perform a particular action. This could possibly give you a starting place for where to place breakpoints. This won't always work depending on the scenario, but may be helpful.

Another trick you can use is to figure what classes you know that have to be involved in the code path you are trying to trap. For instance, you mentioned that it's a Java EE web app and therefore the action is likely some kind of a servlet interaction (at some level). I don't have the API in front of me, but you can place a breakpoint on the method in the response object where the output stream is retrieved. Once that breaks, you will know the code that's trying to service the request.

You can always see where a method is called by clicking "Open Call Hierarchy" from eclipse (left click on the selected method or CTRL+ALT+H ). Also, you always can inspect where a method/class is defined by clicking "Open Declaration" (left click on the selected method/class or F3).

Is there a program that can tell you which class/method is being invoked

I'm working on a very big java/servlets/web project and i find it hard finding which classes and and methods is being called. sometimes it takes hours to find the right class. if there an application or plugin or technique that helps a little? im using eclipse.
edit: I'm using apache and tomcat

Regarding your comment to Bozhos answer: use a profiler on your server instance. You start profiling right before you click on a link in your client application ("the browser") and stop right after you have the correct response. Then just examine the profiler logs/views to find out, what actually happend on the server.
The Eclipse Test & Performance Tools Platform Project is worth a try.

CTRL + ALT + H, or right-click > open call hierarchy (when on a method declaration) will give you all callers, with their callers, and so on. You can also reverse the hierarchy
Right click > references > project will give you where a given class is used.

From your comment on Bhozo's answer I conclude that you do NOT mean at development time, but at runtime.
I suggest you connect a debugger to your application and pause it. You can then inspect the callstack at that time, which will usually give you an idea where to look.
To do that, run your java app with the following settings:
-Xdebug -Xrunjdwp:transport=dt_socket,address=8787,server=y,suspend=n
Then in eclipse, add a debug configuration for 'remote' to port 8787 and execute it. Your debugger is now linked to your application. Put eclipse into the debug perspective.
Now click a link in your application, and immediately click the pause button in the debugger. You can now see the callstack. Usually, once you have a clue, you can quickly find good spots to put breakpoints. But this technique helps you get a clue :)

You might want to consider the use of AOP to add a tracing/logging aspect to certain parts of your code. This way you don't have to update your code and can simply write an aspect that logs a line for every method that is called with in example the name of the method, the class and the parameters. This aspect can of course be 'turned off' when building your production version to prevent the trace logging on production machines. If you're familiar with AOP, you can easily tweak the aspect and the pointcuts a bit to for instance only log calls to certain methods in your controller classes or something like that.
If you need more information on this solution, feel free to comment on this answer requesting more specific information or simply google for AOP and logging.