We Keep Coding

How do I invoke the debugger from code?

From Javascript, I can simply write
debugger;
and when that line executes, it stops the code as if I had put a breakpoint there.
Is there an equivalent in Java? I need it to work in Eclipse specifically.
EDIT: can we take it as read that I am not an idiot and if placing a breakpoint with the IDE itself were an option, I would have already done so?
FURTHER EDIT: I had not thought it necessary to point out that since placing a breakpoint with IDE is not an option, any answer that revolves around placing a breakpoint with IDE is not likely to be helpful. In case everybody is dying of curiosity, the original code is not written in Java -- it's processed down to Java byte-code. As a result, Eclipse is confused enough it doesn't want to set breakpoints.

The JVM debugger, which Eclipse uses (mostly) under the covers, can set breakpoint at a line number in a method IF compiled with certain optional debugging info OR at method entry (always).
If your classes were compiled without debugging "lines" so the debugger can't set a line breakpoint, and you don't want to or can't recompile them, you can still set a method-entry breakpoint. In Package Explorer -- NOT an edit window for the source -- right-click the method name/signature and Toggle Method Breakpoint to on.
This can be combined with the comment by #ajp: add a method e.g. void [static] debugger(){} that doesn't do anything when you call it, but provides a convenient target where you can set a method breakpoint.
Warning: although it is possible to compile with partial debugging info, like debugging "vars" but not debugging "lines", generally people just use "debug on" or "debug off". If your classes are compiled without debugging "vars", the debugger will be much less useful.

I am probably going to get a few downvotes, but so be it...
If you open a source file in Eclipse and right-click on the left edge of the document view, you will get the popup menu illustrated in the image below.
As you can see, you have the option to toggle a breakpoint and also to turn off and on the line numbers. So, I am not sure what you mean by "My Eclipse is being operated in an environment where it cannot find line numbers to the source code". Unless you have some modified version of Eclipse that does not show this menu, I don't know what you mean by that. The option is there.

You wrote:
From Javascript, I can simply write
debugger;
and when that line executes, it stops the code as if I had put a breakpoint there.
And also:
can we take it as read that I am not an idiot and if placing a
breakpoint with the IDE itself were an option, I would have already
done so?
Option 1: The simple, "incorrect" answer is that there is no instruction in the Java language to make the program pause in a breakpoint nor there is an option like in languages like C++ to
make a debug build. So, your "ONLY" option is to execute a breakpoint from the IDE.
Option 2: The complicated, correct answer is that you can do what you want following these instructions: https://docs.oracle.com/javase/7/docs/technotes/tools/windows/jdb.html
In your case, I don't believe that you don't have the option to place a breakpoint with the IDE to debug your program; no matter how complex your program is. BUT, I am not here to debate that point. According to your post, you have to do option 2 laid out here.

Catch the current executed method Eclipse Java

I have an application that was written by another guy and I have to add function there. The code is pretty complex to simply look for a method I need to change. So I wanted to ask if there is a possibility to debug the application and catch on the run what method is currently called,concrete: I want to open a graphical editor in application, add an object in this editor and get the trace of methods that are being executed during adding the object without knowing anything about the application code. Is there any possibility for that? Practically I want to know what methods are executed by JVM
Thank for your help,
Jeff

you can use a profiler to get into the code but this won't be easy. Nevertheless, it's crucial to understand the code before working on it. Eclipse offers a broad range of static code analysis tools for this, like call hierarchy, ...

Find all instances of a class while debugging in Eclipse

I was wondering if the way Java/JVM works means debugging tools like Eclipse can show me a list of all instances of a given class? I suppose one could write some reflection code but I don't want to break execution at the same place every time... rather I;d like to break execution and bring up a list of all MyClass123 objects in a debug window.
Is this even possible? Is it provided in Eclipse or any plugin?

Yes, it's possible in the standard eclipse debugger. See here. While debugging, right-click on a variable entry in the 'Variables View' and then click on 'All Instances':
This will open a list like this:

You may want to instatall Eclipse Test & Performance Tools Platform plugin in your application and perform MemoryAnalysis. This gives you details around all different objects in memory and their references.
You will not need to put any breakpoint in the code. It will gather the required data on its own.

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.