Thanks for fixing your display name, Manu. Here's your answer.
The Java VM has built-in debugging capabilities. If you start a JVM and supply certain parameters, the JVM will start listening on a TCP/IP port for debug commands - in other words, it starts up a special debugging server as part of the Java runtime environment. There is no standard port number that I know of, although 8000 is popular. You tell it which port to use as part of the debugger options.
Although you can use this builtin debugger with a simple command-line interface, most Java IDEs can also use it, and that includes Eclipse. What you have to do is use the Debug setup dialog to create a Remote Debugging configuration . In that configuration, one of the options you must supply is the host location and debugging port number of the JVM that you want to debug. The host may be the same machine that Eclipse is running on, or some other machine - all that's required is a clear TCP/IP connection to the debugging server in the JVM under
test.
The only other restriction is that Eclipse has to have filesystem access to source code that matches the compiled classes being tested. To work properly, that mans
you should have defined an Eclipse project and be able to view and edit the source files in the usual way. If the source code doesn't match the compiled classes exactly, the debugger will get confused, and if there is no source code available, Eclipse will have only limited debugging abilities for that class.
The JVM debugger is very powerful and can be activated anywhere where you can control the startup of a JVM. For
applets, that's done using the Java Control Panel. For servers like
Tomcat,
JBoss, and so forth, there's usually some way you can pass the debugger activation/setup parameters in as part of the server startup. For stand-alone Java applications, you just provide them on the startup command line.