1. I downloaded the JDK and extracted it into /usr/lib/jvm and renamed it to java-sun-1.7.0.1 to be compliant with the naming system of other Java versions.
2. I changed the symlink java-6-sun to point to java-sun-1.7.0.1. (Previously it pointed to the directory java-sun-1.6.0.24).
3. I edited the file .java-6-sun.jinfo. I changed only 2 lines in that file. I changed the first line, name=java-sun-1.7.0.1 (Previously it was name=java-sun-1.6.0.24). I also changed the priority number to 50. (The higher the priority number, the less prioritized it is).
4. I did sudo update-java-alternatives -l and I saw that java-6-sun is listed.
5. And then I called sudo update-java-alternatives -s java-6-sun. And it worked perfectly. No complaints at all. Well just one complaint: jdk alternative does not exist: /usr/lib/jvm/java-6-sun/bin/HtmlConverter. Well, I think that's not a problem.
6. Done! I checked java -version and it did give me the correct version. I also opened Firefox and went to about:plugins, and the plugins were all at the correct version.

Components                      Debugger Interfaces

                 /    |--------------|
                /     |     VM       |
 debuggee -----(      |--------------|  <---- JVMTI - Java VM Tool Interface
                \     |   back-end   |
                 \    |--------------|
                 /           |
 comm channel --(            |  <------------ JDWP - Java Debug Wire Protocol
                 \           |
                 /    |--------------|
                /     |  front-end   |
 debugger -----(      |--------------|  <---- JDI - Java Debug Interface
                \     |      UI      |
                 \    |--------------|     
   

• Socket-attaching connector
• Shared-memory attaching connector
• Socket-listening connector
• Shared-memory listening connector
• Command-line launching connector

-Xdebug

Enables debugging features.

-Xrunjdwp:

Loads the implementation of JDWP in the target VM. It uses a transport and the JDWP protocol to communicate with a separate debugger application. Specific suboptions are described below.

transport

Generally, socket transport is used. But shared-memory transport can also be used on the Windows platform, if available.

server

If the value is y, the target application listens for a debugger application to attach. Otherwise, it attaches to a debugger application at the specified address.

address

This is the transport address for the connection. If the server is n, attempt to attach to a debugger application at this address. Otherwise, listen for a connection at this port.

suspend

If the value is y, the target VM will be suspended until the debugger application connects.

-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8765

-Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8000

• Socket Attach
• Socket Listen

1. Create a Java project with a simple class

We create a simple class for debugging purpose. Listing 4 shows the sample code.

package com.ibm.developerWorks.debugtest;

public class test {

public static void main(String[] args) {
System.out.println("This is a test.");
}
}

2. Set a breakpoint

Set a breakpoint in the code. In this example, we set the breakpoint in the line System.out.println("This is a test.");.

5. Run the Java application manually

Open a console to launch the application manually to make sure the Java runtime environment is configured properly.

Listing 5. Sample to invoke Java application

java -jar test.jar

6. Debug the application remotely

Copy the JAR file to the appropriate location on the remote computer, or even the same machine, invoke the debug server, and then attach a client to it. The simple Java application can act as a debug server or client. Depending on the configuration, you can choose either Socket Attach or Socket Listen connection type in Eclipse. Learn how to run the application as a server or client in the following two sections.

Target VM acts as debug server

The following example invokes the Java application on the remote side, acts as a debug server, and listens for a socket connection on port 8000. The target VM will be suspended until the debugger connects.

Listing 6. VM invocation sample for socket attaching mode in Eclipse

java -Xdebug -Xrunjdwp:transport=dt_socket,server=y,address="8000" -jar test.jar

Start Eclipse using the remote launch configuration and specify the target VM address of the remote application. To do this, clickRun > Debug Configurations, and double-click the Remote Java Application in the Eclipse menu. From the newly created launch configuration, specify the IP and port for target application. To run the remote application in the same machine, simply specify the host IP as localhost or 127.0.0.1.

Figure 4. Configuration of socket-attaching connection

Select Allow termination of remote VM option to terminate the VM to which you are connecting during application debugging.

Figure 5. Terminate button in Eclipse

Target VM acts as debug client

The second example is to use a simple Java application that acts as a debug client, and the debugger front end acts as a debug server. Eclipse uses the socket listen-mode connection type for listening. The debug front end must be started in advance to listen on a specific port. Figure 6 shows a sample configuration to set up listening.

Figure 6. Configuration of socket-listening connection

Click the Eclipse Debug button, and the status bar will show the message "waiting for vm to connect at port 8000..." When you see that, start the remote application. Listing 7 shows how to invoke the Java application as a debug client and attach it to a running debugger application using a socket on host 127.0.0.1 at port 8000.

Listing 7. VM invocation sample for socket-listening connection in Eclipse

java -Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8000,suspend=y -jar test.jar

If everything goes well, the debug perspective will be displayed to support the application debugging, and the execution of the remote Java application will be stopped normally. This is similar to Step 3 that we did in local debugging (see Figure 3). At this point, you can use standard debugging functions, such as setting breakpoints and values, step execution, etc.

Back to top

Conclusion

This article illustrated how to use the Eclipse built-in remote Java application configuration type to perform application debugging remotely. It introduced how to set up a Java application to invoke remote debugging and helped you understand the connectors Eclipse provides. Finally, you learned how to apply this technology to your projects.

• All the threads that are not daemon threads terminate.
• Some thread invokes the exit method of class Runtime or class System and the exit operation is not forbidden by the security manager.

package test;

import java.util.Map;
import java.util.Set;
import java.util.Map.Entry;

public class ThreadTest {

    /**
     * @param args
     * @throws InterruptedException
     */
    public static void main(String[] args) throws InterruptedException {
        // TODO Auto-generated method stub

        System.out.println("The current main thread: "
                + Thread.currentThread().getName());

        printAllThreads();

        ThreadA tc = new ThreadA();
        tc.start();

        tc.join();
//        Thread.sleep(5000);

        System.out.println("Exiting main thread.");

    }

    static private void printAllThreads() {
        Map stackTraces = Thread
                .getAllStackTraces();
        Set< Entry> entrySet = stackTraces
                .entrySet();
        for (Entry entry : entrySet) {
            Thread t = entry.getKey();
            System.out.println(">>>>>>>>>> " + t.getName());
        }
    }
}