Frequently Asked Questions

The following are a list of frequently asked questions about JSwat. Please consult this page before sending questions to the mailing lists.

  1. How is JSwat used? What is the JPDA and what role does it play?
    JSwat is a Java application which utilizes the classes provided in the Java Platform Debugger Architecture. JPDA provides the back-end support for debugging Java bytecode. To use JSwat you will need a JDK and the JPDA installed on your system. Recent versions of the JDK include the JPDA. See the README.html file distributed with JSwat for more information.
  2. Which version of the JDK and JPDA should I be using to run JSwat?
    The README file contained in each release explains the detailed requirements information. In a nutshell, the 1.x versions of JSwat require JDK 1.2 or higher, while the 2.x versions require JDK 1.4 or higher, the 3.x versions require JDK 5.0 or higher, and the 4.x versions require JDK 6.0 or higher.
  3. I cannot get JSwat to show me the values of any variables. It seems that JSwat thinks there is no variable information for that class.
    Recompile your classes with the -g option. This generates the debugging information when the compiler creates the .class files. This is necessary for any Java debugger that you would use.
  4. JSwat cannot find my source files. Why is that?
    JSwat uses the classpath and sourcepath to locate source files. Check that these are set with appropriate values. Read the Classpath and Sourcepath help topic to learn all about those settings and how they are used.
  5. Setting breakpoints is failing.
    Make sure you compiled your code with the appropriate debug flags (e.g. javac -g) in order for the class files to contain the required debugging information. If you are using an older version of the HotSpot VM (as in JDK 1.2), try running JSwat and your debuggee VM with the Classic VM.
  6. When I start my program in JSwat, I get errors concerning socket connections to localhost.
    This occurs because the JPDA utilizes sockets to communicate between JSwat and the debuggee. It is attempting to look up the IP address of your machine based on its name, but for some reason is failing. Try adding the IP address of your machine to the /etc/hosts file on your system, with the name of your machine (the name other than "localhost").
  7. When I launch my program within JSwat it has problems, but it runs fine without JSwat.
    If you are running an older JDK release on a Microsoft Windows platform, try setting the "Java Home" value in the VM start dialog to point to the JDK. It has probably defaulted to the JRE installed in C:\Program Files, which will cause all sorts of problems.
  8. When I start JSwat I get an error about the JIT compiler.
    You generally should not debug Java code with the JIT compiler turned on. You can turn off the JIT compiler by passing the "-Djava.compiler=NONE" switch to java when starting your application. You could also define the environment variable JAVA_COMPILER, setting its value to "NONE". JDK 1.4 and higher do not support these flags since the compiler is always enabled.
  9. When I start JSwat and try to load a class to debug, I get the error "can't load 'jdwp.dll'".
    This happens on older releases of the JDK on Windows. In this case, you need to make sure the JPDA lib directory is in your PATH environment variable so that the libjdwp.dll file can be found.
  10. When I start JSwat and try to load a class to debug, I get the error "can't load 'libjdwp.so'".
    This happens on older releases of the JDK on Solaris. In this case, you need to make sure the JPDA lib/i386 or lib/sparc directory is in your LD_LIBRARY_PATH environment variable so that the libjdwp.so file can be found.
  11. When I try to start JSwat it fails with the message "Missing JPDA package."
    This happens in older releases of the debugger. Please upgrade to the latest version and read the README.html file for further instructions.
  12. When I try to launch my program in JSwat it shows the error "FATAL ERROR in native method: No transports initialized".
    If you are running an older JDK release on a Microsoft Windows platform, try setting the "Java Home" value in the VM start dialog to point to the JDK. It has probably defaulted to the JRE installed in C:\Program Files, which will cause all sorts of problems.
  13. When I launch my program within JSwat, the debugger seems to hang.
    You are probably running the HotSpot VM in JDK 1.3 on Linux. The HotSpot VM in JDK 1.3 is not very good for debugging and you should use the Classic VM instead.
  14. When I try to start my program, it immediately indicates that the debuggee VM exited.
    This can occur in older versions of the debugger. If you check the "Output" panel in the JSwat window, you will probably see a message that says the class was not found. You must set the classpath in the launch dialog so the debuggee JVM can find your classes.
  15. When I single step over a method that attempts to read input from the standard input, the call hangs.
    This can occur in older versions of the JDK. Press the Refresh button in JSwat and it will return to normal. JSwat seems to hang on green threaded systems when attempting to send input to the debuggee VM. It works fine on Microsoft Windows and in JDK 1.4 and higher.
  16. The thread status seems to always say "UNKNOWN".
    This seems to happen with older HotSpot VMs and only applies to versions of JSwat prior to 3.0. Try running JSwat and your debuggee VM with the Classic VM to avoid this issue.
  17. Debugging seems very slow, especially the startup time of my program.
    Are you running the HotSpot VM on a JDK earlier than 1.4? If so, use the Classic VM instead. It can greatly affect the run time of your program during debugging. In JDK 1.4 and later, the HotSpot VM is the only VM available. You might also try remotely debugging your program. Start the program and attach to it remotely after it has completed its startup. This is described in the help pages provided with JSwat.
  18. Some local variables seem to be invisible to the debugger. The code compiles and runs fine, but the debugger is unable to display the variables.
    It is unclear if the Java compiler or the Java VM is at fault here. Either way, the solution tends to be the same -- assign an initial value to the variable when you define it. That is, instead of "String s1;" you should write "String s1 = null;". This makes the variable visible to the debugger.
  19. JSwat indicates a parser error when displaying some source files.
    Typically this is caused by use of the string "assert" in a fashion that does not denote a keyword. JSwat 2.x treats "assert" as a keyword and so any methods or variables with that name are treated as a parser error.
  20. JSwat shows "Exception thrown... CharToByteSingleByte.convert" when launching the debuggee.
    You are probably running a Unix-like system and are missing the URW fonts. Use a web search engine to find the freely available URW fonts and install them on your system.
  21. What do I do about the "javaHome is invalid" error message when launching the debuggee?
    This applies to the 2.x releases of the debugger. Try clearing the "Java Home" text field in the Start VM dialog, then launch the debuggee.
  22. When setting breakpoints, JSwat says there is "no line number information".
    This seems to occur on older releases of the JDK, and may be caused by the Java compiler. If you are using jikes, it could be generating invalid debugging information. Try using the Java compiler that comes with the JDK. Sometimes deleting all the class files and recompiling them will help.
  23. I keep getting "no code at that line" messages when starting the debuggee.
    This applies to older releases of the debugger, and is likely caused by a breakpoint that was set on a line of code that has moved after the file was edited.
  24. When using JSwat 2.x in console mode, I cannot enter very long commands.
    It seems that on Solaris, the terminal driver is set to only allow canonical input lines of up to 256 characters. You may need to use a different terminal emulator or command interpreter to avoid this issue.