Q's and A's

Q: When I run jd on Windows95, I get the message:

>jd.bat [13]  Out of environment space

What's going on?

A: The "out of environment space" message is coming from Windows95 when it tries to execute your .bat file.
Try this:

Go to DOS command window from which you're invoking jd.
Right click on title bar and select "Properties".
Select "Memory" tab.
Goto "Initial Environment" and pick a larger value (4096, say).

Your .bat file should run ok now.

Q: When I run jd, I get the message:

jd: sorry, this version of jd only works with java version 1.1.5

What's going on?

A: Jd uses a Sun debugging API that's been undergoing rapid changes. As a result, jd may or may not run properly on jdk releases other than the one for which it was compiled. If you have a version of the jdk that's newer than 1.1.5, try going back to the site where you originally obtained jd, and see if there's a more recent version of jd available. If you have a version of the jdk that's older than 1.1.5, you're out of luck. Sorry. As a last resort, you can try using the -noversioncheck command line flag to bypass the version number check, but all bets are off: jd might work a little bit, or not at all.

Q: Why can't I see my local variables?
A: Try compiling your classes with -g .

Note that jd will not be able to display local variables for methods in the java.* class hierarchy because Sun does not compile those methods with -g.

Q: Why can't I see the source code for certain packages?
A: Jd normally looks for a class's source (.java) file in the directory where it found the class's bytecode (.class) file. However, some programmers prefer to split files into "source" (.java) and "build" (.class) directories. You can use the -sourcepath and -classpath options to tell jd where your files are. For example:

java jd.Main -classpath cls;cls;cls -sourcepath src;src;src MyMainClass

where cls and src represent directories or zip files to be searched for classes and sources, respectively. Make sure the directory structure of your sources match those of your classes. For example:

package:      x.y.Z

classpath:    /a/b
filesystem:   /a/b/x/y/Z.class

sourcepath:   /c/d
filesystem:   /c/d/x/y/Z.java

Note that sourcepath must point to the directory containing x and not to the directory containing Z.java.

Q: How can I debug a program using Sun's applet viewer?
A: Invoke the applet viewer like this:

jd sun.applet.AppletViewer MyPage.html

Q: How can I "attach" the debugger to a remotely executing program on another machine?
A: To debug a class named "MyClass" on a remote machine named "gumby", do the following:

On the remote machine, type:
```
java_g -debug MyClass
```
Note the underscore g.
On the screen you'll see:
```
Agent password=xxyyzz
```
Make a note of it.
Later, on another machine (or the same machine) you can attach jd to the program by typing:
```
jd -host gumby -password xxyyzz
```
where xxyyzz is the password you saw earlier.

Q: I wrote some native code and put it into my own dll file. It runs fine under java but won't run under java_g or jd. What'ts wrong?
A: The name of your dll file must end in _g. For example, it must be named mystuff_g.dll and not mystuff.dll

Q: I see the following message on the console window when I attempt to invoke jd:

Debugger: caught an exception
java.io.IOException: CreateProcess: C:\Hotjava\runtime\bin\..\bin\java_g 
                      -debug -classpath [...more path stuff...]
                        sun.tools.debug.EmptyApp error=2
     at java.lang.Win32Process.(Win32Process.java:59)
     at java.lang.Runtime.exec(Runtime.java:175)
     at java.lang.Runtime.exec(Runtime.java:137)
     at sun.tools.debug.RemoteAgent.(RemoteAgent.java:117)
     at sun.tools.debug.RemoteDebugger.(RemoteDebugger.java:70)

A: This happens if you are using the JRE (java runtime environment) supplied with programs like Hotjava. The JRE does not support debugging. You must use the JDK (java development kit) for debugging.

Q:After using the "Edit Class Path" dialog, I get the following message:

Internal debugger error: Failed to exec a child java interpreter.

A:In order to launch a new debugee, Sun's debugging api requires that java/lib/classes.zip appear somewhere in the class path. When editing the class path, make sure not to remove this item from the list.

Q: I see the following message on the console window when I attempt to invoke jd:

java.net.UnknownHostException
[...more traceback stuff...]

A: Jd uses TCP/IP to communicate with the program being debugged. To run it on on a standalone machine (laptop computer, for example) that is not connected to a network, you must do the following (on Windows95...):

Install the "Microsoft TCP/IP Dialup Adapter" software, if you haven't already done so:

Click on: Start --> Settings --> Control Panel --> Network
Click on: "Add" button
Select:   "Protocol"
Click on: "Add" button
Select:   "Microsoft"
Select:   "TCP/IP"
Click on: "Ok" button
Follow instructions, inserting Windows95 CD-ROM or diskettes, as required.

Set your "TCP/IP Dialup Adapter DNS Configuration":

Click on: Start --> Settings --> Control Panel --> Network --> TCP/IP DialUp Adapter
Click on: "Properties" button
Click on: "DNS Configuration" tab

Your settings should look like this:

   Enable DNS              = true
   Host                    = spike           <-- your machine name
   Domain                  = watson.ibm.com  <-- your domain name
   DNS Server Search Order = [don't care]

Save the settings.

Create a "hosts" file:

Issue the command:

   copy \windows\hosts.sam \windows\hosts

Edit the file you just created and add the following lines:

   127.0.0.1 localhost
   127.0.0.1 spike.watson.ibm.com <-- same host + domain names as specified above

The number 127.0.0.1 is a special address recognized by TCP/IP.
Type it exactly as shown.

Reboot.

Q: I see the following message on the console window when starting jd:

java.net.ConnectException: Connection refused
   at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:290)
   at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:132)
   at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:119)
   at java.net.Socket.(Socket.java:229)
   at java.net.Socket.(Socket.java:97)
   at sun.tools.debug.RemoteAgent.(RemoteAgent.java:146)
   at sun.tools.debug.RemoteDebugger.(RemoteDebugger.java:70)
   at jd.Debugger.doConnect(Debugger.java:442)
   at jd.Debugger.run(Debugger.java:144)

A: This happens on NT if you've installed a Hummingbird TCP/IP "socks" client. The solution is to modify your socks.cnf file to contain the following line:

   direct 127.0.0.1 255.255.255.255

Q: When attempting to debug graphical applications, why do I get a system error box saying "...MSVCRTD.dll could not be found...", or, a java message saying "Uncaught exception: java.lang.UnsatisfiedLinkError: no winawt in shared library path"?
A: This is a bug in the way Sun linked the 1.1.1 version of "/java/bin/java_g.exe". To fix it you must obtain a copy of MSVCRTD.DLL (for example from the Microsoft Visual C++ 4.2 CD ROM) and copy it into your "/java/bin" directory. Sigh.

Known Bugs

There seem to be some bugs in Sun's implementation of the remote debugging and AWT classes. Here are some I know about.

Symptom: The elements of multi-dimensional arrays are always displayed as "null".
Workaround: Seems to be a Sun bug. (fixed in 1.1.4 ?)

Symptom: Line stepping through a breakpoint sometimes sends the program off into breakpointing code rather than application code.
Workaround: Seems to be a Sun bug. Try removing the breakpoint before stepping. (fixed in 1.1.4?)

Symptom: Flyover help windows do not appear above control buttons (AIX only).
Workaround: Seems to be an AWT bug. No workaround yet, sorry.

Symptom: "About" popup dialog freezes the debugger application (AIX only).
Workaround: Seems to be an AWT bug. No workaround yet, sorry.

Symptom: AWT application programs never appear on the screen when run under control of the debugger.
Workaround: For some reason the application's top level window gets displayed *behind* the debugger's window on the desktop. Try dragging the debugger's window off to the side, and you should see the application's window. This problem only appears on Windows95/NT systems.

Symptom: Closing the debugger window sometimes causes the application's windows (if it created any) to remain behind instead of politely vanishing. (fixed in 1.1.4 ?)
Workaround 1: hit ctl-c on the command line from which you invoked the debugger.
Workaround 2: on Windows95/NT, hit ctl+alt+delete and use the task manager's End Process function to kill the hung windows (look for processes named java_g)

Symptom: The -v[erbose] option prevents the debugger from starting properly.
Workaround: None. Sun's jdb debugger exhibits the same problem.

Symptom: Attaching the debugger to a remote virtual machine causes the remote machine to crash.
Workaround: Sun's jdb debugger exhibits the same problem. It seems to happen if the remote machine was invoked using java. Try using java_g instead.