The debugger limitations and known problems

    There is one big problem - the sun.tools.debug package which is used by the Xelfi debugger. The quality of the implementation of this package is poor on some systems. E.g. you cannot trace into a loop using the Debug|Trace into command. (You must use the command Debug|Go to cursor to get into that.

    We tried the debugger on these platforms

    Sun (Solaris) - the debugger works but sometimes crashes when you start it
    PC (Linux) - works
    PC (OS/2) - works
    PC (Windows 95, Windows NT 4.0) - works

    There is a one necessary condition if you want to use the debugger (but it is not the only one) - you must have TCP/IP support installed on your computer. There is one exception which will be described bellow.

    Because the Xelfi has been developed mostly on Windows 95 and Windows NT 4.0 platforms we will describe our experience with a configuration under these two platforms.

    There are at least three (a bit different) implementations of JDK for Windows 95/Windows NT 4.0. These are

    JDK from Suns (original)
    JDK in Microsoft Visual Java++
    JDK in Symantec Cafe

    If you use the original JDK you can use the debugger if you install the TCP/IP support (see bellow). But there are other problems applying to other parts of Xelfi with in this implementation.

    If you use the only MSVJ++ (version 1.0) you probably have not a chance to use the Xelfi debugger because the MSVJ++ does not contains the package sun.tools.debug. When we tried to take it from the original JDK and connect it together we were not successful because.

    If you use the Symantec Cafe version 1.2 you have a big chance to start the debugger even without the TCP/IP support and with better behavior. But to reach this you have to do four little changes in Xelfi sources. Look into the files

    LocalsView.java
    ThreadsView.java
    CallStackView.java
    Debugger.java

    and in everyone make following change in the beginning of the file. Comment the line with the text

    import sun.tools.debug;

    and delete slashes on the next line with a text

    //import symantec.tools.debug

    Now you must recompile these four files and than you can start the Xelfi

    javac -classpath .;XELFIPATH;CAFEPATH\java\lib\classes.zip;CAFEPATH\java\lib\symclass.zip XELFIPATH\xelfi\debugger\*.java
    java -classpath .;XELFIPATH;CAFEPATH\java\lib\classes.zip;CAFEPATH\java\lib\symclass.zip xelfi.Xelfi

    (The archive symclass.zip stores the package symantec.tools.debug.)

    In case that you cannot use the Symantec Cafe you have to install the TCP/IP support on your computer. But if our computer is not connected to the network you may have problems with IP address. The author of the Xelfi debugger tested on his computer (Windows NT 4.0) this configuration

    IP = 1.1.1.1
    MASK = 255.0.0.0

    If you would try to start the debugger without TCP/IP installed (using sun.tools.debug) you will get UnknownHostException.

    If you are connected to the Internet via the modem you will probable has to get the Symantec Cafe and use the above described solution. In opposite case every time you will try to start the debugger the class "RemoteDebugger" from the package sun.tools.debug will try to establish the TCP/IP connection to the Internet.

    Note: The implementation of the package sun.tools.debug in the SymantecCafe is probably buggy because every time you try to start to create the RemoteDebugger instance you get an error message

    cannot add system thread

    The last note: The author of the Xelfi debugger used both Symantec Cafe and Microsoft Visual Java++ for development of Xelfi. Microsoft has a fine IDE and fast compiler, the Symantec Cafe has a good implementation of symantec.tools.debug classes.