Debugging with Java 1.2

I want to use remote debugging with Java 1.2, simply prepared by calling 'java -debug AnyClass'. On different platforms I always get the annoying message 'not a debugging VM'.

What can I do to get a debugging VM for Solaris, Windows and AIX (or what went wrong with my debugging attempt ?)
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.


Example from Sun to try first:

Debugging the TicTacToe Applet


Start the appletviewer in "-debug" mode, specifying an HTML file with the applet to debug. If you have problems, make sure you can first run the applet without the "-debug" flag. jdb will start, and report that the sun.applet.AppletViewer class is loaded.
Type "threads" to show the thread running at startup.
Type "run" to start the AppletViewer.
After the TicTacToe applet is displayed, type threads again. This time, two threadgroups will be displayed: one for the AppletViewer and one for the TicTacToe applet. Although all threads are running, try examining the threads and classes as in the previous tutorial.
To set a breakpoint, type "stop in TicTacToe.mouseUp". The "stop in" command sets a breakpoint at the first Java bytecode in the specified method. The "stop at <class:line>" will stop at the first bytecode generated by a particular line in a Java source file.
Click on a square in the TicTacToe applet. jdb will stop the applet's execution at the breakpoint just set. Type "where" to show the applet's stack. Type "threads" to see that the current thread is at a breakpoint, and the other threads suspended.
Type "step" to execute the first line in mouseUp(). Notice how it entered the status() method. Step again to execute additional lines.
Type the "use" command to see the path list jdb uses to find source files (by default, the classpath). Type "list" to view the current source. If isn't in your class path, change the source path list using "use <path list>".
Type "up" to examine the previous stack frame (mouseUp()). Type "list" again to view its source." Type "down" to go back to the status() stack frame.
To see the local variables, type "locals", or the name of the variable (use "this" to print the object whose method we are stopped in). If no local variables are available, try this tutorial again after re-compiling the TicTacToe applet using the "-g" option.
Type "cont" to continue execution from the breakpoint. Click another TicTacToe square to show that the breakpoint is still active.
The breakpoint message shows the line number of the breakpoint. Try clearing that breakpoint with "clear TicTacToe <line number>. Type "cont" and click another TicTacToe square to verify that the breakpoint is cleared.

I believe also the following VM invocation options are required to debug applications running under the classic VM.

Enables debugging
Disables the old agent. JPDA attaches its "agent" in a different manner, described below.
Disables the JIT compiler. Debugging with the classic VM requires that it's JIT compiler be disabled.
Loads the JPDA reference implementation of JDWP. This library resides in the target VM and uses JVMDI and JNI to interact with it. It uses a transport and the JDWP protocol to communicate with a separate debugger application. Specific sub-options are described below.

There is also some more general info here:

Hope this helps...
smileAuthor Commented:
Hi sqoms, I do not want to purchase another debugging tool, I am already using Visual Age distributed debugger.

Hi Jod,

many thanks to your huge answer. My problem is more straight, that the Java 1.2 VM on Solaris just prints to cited error message and sadly does _not_ include the 'java_g'; I found a 'java_g' in version 1.1.6 on AIX as an old relict of former times - I want to debug Java 1.2 with the class.

Supplying 'Xnoagent' works, but I _need_ the agent, I think.

Do you have any other Idea of how to debug Java 1.2 Servlets on a Solaris machine, started from Apache JServ ?

Maybe it's more difficult than I thought, I'll increase to 200 Pts.
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

It is a bit tricky but can be done. The basic details of how to start a general debugging session are below but there are specific details for debugging a servlet I have included further down.

Starting a normal jdb debug Session
(for servlets, see below but try this first to make sure everything is working OK)

Like dbx, there are two ways jdb can be used for debugging. The most frequently used way is to have jdb start the Java interpreter with the class to be debugged. This is done by substituting the command jdb for java in the command line. For example, to start the AppletViewer under jdb, you use the following:
   % jdb sun.applet.AppletViewer

   % jdb -classpath $INSTALL_DIR/classes sun.applet.AppletViewer

When started this way, jdb invokes a second Java interpreter with any specified parameters, loads the specified class, and stops the interpreter before executing that class's first instruction.
The second way to use jdb is by attaching it to a Java interpreter that is already running. For security reasons, Java interpreters can only be debugged if they have been started with the -Xdebug option. When started with the -Xdebug option, the Java interpreter prints out a password for jdb's use. In addition, the debugged interpreter must not be run with a JIT compiler. Use the option -Djava.compiler=NONE to disable the loading of any JIT compiler. Special debugger classes must be available to the debugged interpreter. These classes are not part of the default runtime class library. Use the option -Xbootclasspath:$INSTALL_DIR/jre/lib/rt.jar:$INSTALL_DIR/lib/tools.jar to allow the debugged interpreter to locate all necessary classes. To summarize, launch the Java interpreter as follows:

   % java -Xdebug -Djava.compiler=NONE   \
     -Xbootclasspath:$INSTALL_DIR/jre/lib/rt.jar:$INSTALL_DIR/lib/tools.jar <class>

To attach jdb to a running Java interpreter (once the session password is known), invoke it as follows:

   % jdb -host <hostname> -password <password>

from as it has a bit more info than sun on this.

Does this basic startup for a debug session work at all for you? Try it with a normal java class first.

If this works, then you can use servletrunner to load up and test out your servlet class as follows...


Debugging a servlet by Running servletrunner in Debug Mode

In this example, the servlets examples directory is included on the CLASSPATH. You can configure the CLASSPATH for debug mode as follows:

$ export CLASSPATH=./lib/jsdk.jar:./examples:$CLASSPATH  


$ set CLASSPATH=lib\jsdk.jar;examples;%classpath%

To start the servletrunner program you can either run the supplied startup script called servletrunner or just supply the servletrunner classes as a parameter to jdb. This example uses the parameter to servletrunner.
$ jdb sun.servlet.http.HttpServer
Initializing jdb...
> stop in SnoopServlet.doGet
Breakpoint set in SnoopServlet.doGet
> run
run sun.servlet.http.HttpServer
running ...
main[1] servletrunner starting with settings:
port = 8080
backlog = 50
max handlers = 100
timeout = 5000
servlet dir = ./examples
document dir = ./examples
servlet propfile = ./examples/

To run SnoopServlet in debug mode, enter the following URL in a browser where yourmachine is the machine where you started servlet runner and 8080 is the port number displayed in the settings output.


In this example jdb stops at the first line of the servlet's doGet method. The browser will wait for a response from your servlet until a timeout is reached.

main[1] SnoopServlet: init

Breakpoint hit: SnoopServlet.doGet (SnoopServlet:45)

We can use the list command to work out where jdb has stopped in the source.

Thread-105[1] list
41        throws ServletException, IOException
42        {
43      PrintWriter     out;
45 =>   res.setContentType("text/html");
46      out = res.getWriter ();
48      out.println("<html>");
49      out.println("<head>
                     <title>Snoop Servlet

The servlet can continue using the cont command.
Thread-105[1] cont

Further details are here:

Any problems, let me know...

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Also, because it is a bit hidden away in the details above this comment is just to point out that if you compile using the -g option you will enable maximum visibility of program details to the debugger.

-g generates all debugging information, including local variables. By default, only line number and source file information is generated.
It's fine
smileAuthor Commented:
thanks to Jod !
I think I'll can go much deeper into dubugging with this info !
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today

From novice to tech pro — start learning today.