Tampilkan postingan dengan label Java. Tampilkan semua postingan
Tampilkan postingan dengan label Java. Tampilkan semua postingan

Changing default JDK in Mac OS X Mavericks

So i have two installations of JDK on my Mac OS X. 1.7 and 1.8. The following is to list all JDK in Mac.


/usr/libexec/java_home -V

The above command resulted in the following:

Matching Java Virtual Machines (2):
    1.8.0_05, x86_64: "Java SE 8" /Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home
    1.7.0_25, x86_64: "Java SE 7" /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home

/Library/Java/JavaVirtualMachines/jdk1.8.0_05.jdk/Contents/Home

Because of some problem with Spring when using Java 8, i need to change the default back to Java 7. This is what i do to the .profile file in my home directory.

export JAVA_HOME=`/usr/libexec/java_home -v 1.7`
#export JAVA_HOME=`/usr/libexec/java_home -v 1.8`

Sorted!

JNDI Lookup of EJB from stand alone client on JBoss AS 7.1

I followed the examples explained in the following JBoss official links:

https://docs.jboss.org/author/display/AS71/EJB+invocations+from+a+remote+client+using+JNDI

https://docs.jboss.org/author/display/AS71/Remote+EJB+invocations+via+JNDI+-+EJB+client+API+or+remote-naming+project

This is my lookup method:

private static Hello lookupRemoteStatelessCalculator() throws NamingException {
final Hashtable jndiProperties = new Hashtable();
jndiProperties.put("jboss.naming.client.ejb.context", true);
jndiProperties.put(Context.URL_PKG_PREFIXES,
"org.jboss.ejb.client.naming");
jndiProperties.put(Context.INITIAL_CONTEXT_FACTORY, "org.jboss.naming.remote.client.InitialContextFactory");
jndiProperties.put(Context.PROVIDER_URL,"remote://localhost:4447");
// username
jndiProperties.put(Context.SECURITY_PRINCIPAL, "admin");
// password
jndiProperties.put(Context.SECURITY_CREDENTIALS, "password");
final Context context = new InitialContext(jndiProperties);
// The app name is the application name of the deployed EJBs. This is
// typically the ear name
// without the .ear suffix. However, the application name could be
// overridden in the application.xml of the
// EJB deployment on the server.
// Since we haven't deployed the application as a .ear, the app name for
// us will be an empty string
final String appName = "";
// This is the module name of the deployed EJBs on the server. This is
// typically the jar name of the
// EJB deployment, without the .jar suffix, but can be overridden via
// the ejb-jar.xml
// In this example, we have deployed the EJBs in a
// jboss-as-ejb-remote-app.jar, so the module name is
// jboss-as-ejb-remote-app
final String moduleName = "jbosslookup";
// AS7 allows each deployment to have an (optional) distinct name. We
// haven't specified a distinct name for
// our EJB deployment, so this is an empty string
final String distinctName = "";
// The EJB name which by default is the simple class name of the bean
// implementation class
final String beanName = HelloBean.class.getSimpleName();
// the remote view fully qualified class name
final String viewClassName = Hello.class.getName();
// let's do the lookup
System.out.println("ejb:" + appName + "/"
+ moduleName + "/" + distinctName + "/" + beanName + "!"
+ viewClassName);
return (Hello) context.lookup("ejb:" + appName + "/"
+ moduleName + "/" + distinctName + "/" + beanName + "!"
+ viewClassName);

}

You need to have username and password set up on the server as application user. This username and password credential is used by the client when creating the initial context. This information along with other information is passed as Properties argument into the initial context constructor.

And then, you need to have the jboss-client.jar in the classpath of the client.

But  when i ran the client, i kept getting the following exception:


Exception in thread "main" java.lang.ClassFormatError: Absent Code attribute in method that is not native or abstract in class file javax/ejb/NoSuchEJBException

It turned out that i need to replace the dependency:

     javax
     javaee-api
     6.0
     provided

With the following JBoss implementation dependency:

         <dependency>
            <groupId>org.jboss.spec</groupId>
            <artifactId>jboss-javaee-6.0</artifactId>
            <version>3.0.2.Final</version>
            <type>pom</type>
            <scope>provided</scope>
       </dependency>

But it was  not enough. JBoss wants me to specify the Xalan dependency too.

        <dependency>
            <groupId>xalan</groupId>
            <artifactId>xalan</artifactId>
            <version>2.7.1</version>
            <scope>provided</scope>
        </dependency> 

Java EE dependency does not have implementation in maven repo, that`s what caused the exception. You also need implementation specific dependency when doing unit tests. I read that this issue is solved in Java EE 7 but i haven`t tested this yet.

Fix Java 7 installation on Mac

So i installed Sun Oracle JDK 7 on my Mac. I unzipped Eclipse into /Applications. I opened launcher, trying to launch Eclipse from there.

But a dialog box popped up asking me to install Java 6 in order to run Eclipse.

This is in part due to Oracle's missing definitions of the JRE7 VM capabilities.

Copy the Info.plist located at the path named below to e.g. ~/Downloads/:
/Library/Java/JavaVirtualMachines/jdk.1.7.<…>/Contents/
and then replace
<key>JVMCapabilities</key>
<array>
<string>CommandLine</string>
</array>
with the following:
<key>JVMCapabilities</key>
<array>
<string>JNI</string>
<string>BundledApp</string>
<string>WebStart</string>
<string>Applets</string>
<string>CommandLine</string>
</array>

Then restart Mac, and problem solved.

http://stackoverflow.com/questions/19563766/eclipse-kepler-for-os-x-mavericks-request-java-se-6/19594116#19594116

Getting Apache Tomcat run via Eclipse to produce logs

Click on Servers tab, double click on the server instance to open it up in workspace. Then click Open Launch Configuration. Click on Arguments tab. You need to add the following two arguments:

-Djava.util.logging.manager=org.apache.juli.ClassLoaderLogManager -Djava.util.logging.config.file="/Users/firman/Documents/learnjava/apache-tomcat-7.0.40/conf/logging.properties"

Installing Java on Ubuntu

I still remember how *gruesome* it was to install or update Java on Ubuntu. I wrote it somewhere in earlier post. Fortunately now with Ubuntu 12.10, an easier method (a ready to execute script) is available:

First you need to remove openjdk for this run the following command from your terminal
sudo apt-get purge openjdk*
If you installed java 7 from any other PPA and you are having problem with java then you have to do following steps before installing the PPA menctioned here
sudo rm /var/lib/dpkg/info/oracle-java7-installer*
sudo apt-get purge oracle-java7-installer*
sudo rm /etc/apt/sources.list.d/*java*
sudo apt-get update
Install oracle java 7 in ubuntu 12.04
Open the terminal and run the following commands
sudo add-apt-repository ppa:webupd8team/java
sudo apt-get update
sudo apt-get install oracle-java7-installer

http://www.ubuntugeek.com/how-to-install-oracle-java-7-in-ubuntu-12-04.html

Hiero. Bitmap Font Tool

So I needed bitmap font atlas for my game. Bitmap font atlas is something similar to Image Atlas, only for font.

There's an open source code for it. The Slick project http://slick.cokeandcode.com/ The bitmap font tool is part of the project, which is located in the Hiero directory.

To correctly set it up as Eclipse project:

1. Create new Eclipse project. Copy the Hiero directory of the Slick project into the source directory of the new project.
2. Copy the lwgl.jar and lwgl-util.jar and slick.jar into the lib directory.
3. Copy the native (platform dependent) binary into some directory in the project structure.
4. Properties -> Java build path -> libraries then click on lwgl.jar and double click on native library location and in the resulting dialog, navigate to the directory where you saved the native binaries of lwgl for your platform.
5. Run the Hiero.java as Java application.

Or, if you still get errors or those steps are too much hassle, you can buy Glyphdesigner for USD 30. Glyphdesigner is better (not much better, just better) than Hiero, and it's easy to run and understand.

Java Home on Mac

The shortest symlink to Java home (pointing to where the JDK is installed) is:

/Library/Java/Home

To set the JAVA_HOME env var:

export JAVA_HOME=/Library/Java/Home

But that only applies for the current session. To persist it, add it as entry in ~/.profile. Check that it's set:

echo $JAVA_HOME

Updating to JDK 7

So I updated my Ubuntu to 10.04.01 LTS and then updated my Java to version 7 release 1. Having been through traumatic update experience as I wrote in this blog post, I was rather reluctant at first to update to version 7. But I updated anyway. And surprise, surprise, it was not at all that complicated! It was almost magical. I did the following steps:
  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.
So, I guess.... that's it :)

Wrong Java version

So the situation is like this: We have an application that relies on a jar file. This jar file is our customization to the W3C flute project. Let's call this jar flute1.jar. Our app has a bug that necessitates fiddling with flute1.jar.

So I located the bug. I rebuilt the flute1 project. I installed the newly built flute1.jar into our app. And then I committed the newly built jar (replacing the old jar) into the svn repo.

Our Hudson threw this message:

    [javac] bad class
    [javac] class file has wrong version 50.0, should be 48.0
    [javac] Please remove or make sure it appears in the correct subdirectory of the classpath.
    [javac] import org.w3c.flute.parser.Parser;
    [javac]                             ^
    [javac] 1 error





What has gone wrong? It turned out that I built the flute1.jar to conform to Java 1.5 while our app conformed to Java 1.4 only. So I added the target="1.4" switch to the javac task in my ant build file. And it worked.

Debug Java applications remotely with Eclipse

I found this gem on IBM website when I looked for ways to debug my running applet. The original link:
http://www.ibm.com/developerworks/opensource/library/os-eclipse-javadebug/index.html
Remote debugging can be useful for application development, such as developing a program for a low-end machine that cannot host the development platform, or debugging programs on dedicated machines like Web servers, whose services cannot be shut down. Other examples include Java applications running with limited memory or CPU power, such as mobile devices, or developers wanting to separate the application and development environments, etc.

Launch-configuration type

launch configuration keeps a set of attributes that can be used to launch a program. The launch-configuration type is a unique type of program that can be launched in the Eclipse platform.
If you don't have it already, download Eclipse V3.4 (Ganymede). In Ganymede, the socket listening connector has been added to the Remote Java Application launch-configuration type. Eclipse's new socket listening connector allows you to start the Java debugger, which listens for a connection on a specific socket. The program being debugged can then be started with command-line options to connect to the debugger. Prior to the Ganymede release, only a socket-attaching connector was provided, and the program being debugged had to be a debug host that was connected by the debugger. It is impractical for mobile devices to be a host due to insufficient memory and CPU power.
To use remote debugging, Java Virtual Machine (JVM) V5.0 or later must be used, such as IBM® J9 or Sun Microsystems' Java SE Development Kit (JDK). In this article, we focus on remote debugging, rather than detail each of Eclipse's debugging features. See Resources for more information about debugging with Eclipse and where to find the aforementioned software.

Frequently used acronyms

  • JDI — Java Debug Interface
  • JDT — Java Development Tools
  • JDWP — Java Debug Wire Protocol
  • JPDA — Java Platform Debugger Architecture
  • JVM — Java Virtual Machine
  • JVMDI — JVM Debug Interface
  • JVMTI — JVM Tool Interface
  • VM — Virtual Machine
Sun Microsystems' Java Platform Debugger Architecture (JPDA) technology is a multitiered architecture that allows you to debug Java applications in all situations easily. The JPDA consists of two interfaces (the JVM Tool Interface and JDI, respectively), a protocol (Java Debug Wire Protocol), and two software components that tie them together (back-end and front-end). It's designed for use by debuggers in any environment. JPDA is not only for desktop systems but works well with embedded systems, too.
The JVM Tool Interface (JVMTI) defines that a VM must provide for debugging. (Editor's note: Starting with Java V5, JVMTI replaced JVMDI, which was used in Java V1.4.) The Java Debug Wire Protocol (JDWP) describes the format of debugging information and requests transferred between the process being debugged and a debugger front end, which implements the JDI, such as Eclipse, Borland JBuilder, and many others. The program being debugged is often called the debuggee in Sun's JPDA specification. The JDI is a high-level interface to define the information and requests used for remote debugging. The architecture is structured as follows.

Listing 1. The Java Platform Debugger Architecture
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 |
\ |--------------|

Therefore, any third-party tools and VM based on JPDA should work together without complaint. This client-server architecture allows you to debug a Java program from a local workstation running the platform, or even debug it from a remote computer on your network.
Before talking about the debug-scenario stuff, we need to introduce two terms used in the JPDA specification: connector and transport. A connector is a JDI abstraction used to establish a connection between a debugger application and a target VM. A transport defines how applications access and transmit data between the front end and back end. The connectors "map" to the available transport types and the modes of connection. In Sun's reference implementation of JPDA, two transport mechanisms are provided on Microsoft® Windows®: socket transport and shared memory transport. Available connectors:
  • Socket-attaching connector
  • Shared-memory attaching connector
  • Socket-listening connector
  • Shared-memory listening connector
  • Command-line launching connector
In establishing a connection between a debugger application and target VM, one side acts as a server and listens for a connection. At some later time, the other side attaches to the listener and establishes a connection. The connections allow the debugger application or the target VM to act as a server. The communications among processes can be running on one machine or different machines.
The problem with debugging a Java program remotely is not in the debugger front end but the remote Java back end. Unfortunately, there is not much information about this in the Eclipse help system. In fact, JDI and JVMTI are implemented by Eclipse and the Java runtime environment, respectively. The only thing we are concerned with is the JDWP, which contains the information to communicate with the JVMTI and JDI. The JDWP contains many arguments that have been added to invoke the application for the remote Java application. Following are some of the arguments used in this article.
-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.
Starting from Java V5, you can use the -agentlib:jdwp option, instead of -Xdebug and -Xrunjdwp. But if you have to connect to the VM prior to V5, -Xdebug and -Xrunjdwp will be the only choice. Following are brief descriptions of the -Xrunjdwp suboptions.
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.
For detailed explanations for each debug setting, refer to the JPDA documentation (see Resources).
Listing 2 shows an example of how to launch a VM in debug mode and listen for a socket connection at port 8765.

Listing 2. Target VM acts as a debug server
-Xdebug -Xrunjdwp:transport=dt_socket,server=y,address=8765

Listing 3 shows how to attach to a running debugger application using a socket on host 127.0.0.1 at port 8000.

Listing 3. Target VM acts as a debug client
-Xdebug -Xrunjdwp:transport=dt_socket,address=127.0.0.1:8000

Eclipse is a graphical Java debugger front end. The JDI is implemented in org.eclipse.jdt.debug bundle. In this article, we don't discuss the details of JDI implementation. See Resources for information about Eclipse JDT and Java JDI technology.
The first thing we want to know is which Eclipse connector to use. To learn the remote connection types provided by Eclipse, you can add a launch configuration in Remote Java Application by going to the Eclipse menu and selecting Run > Debug Configurations..., then selecting the connector from the dropdown list. Two connectors are provided in Ganymede:
  • Socket Attach
  • Socket Listen
For the socket-listening connector, the Eclipse VM will be the host to be connected by the remote Java application. For the socket-attaching connector, the target VM will be the host. There is no difference for application debugging between the two connectors — the user may choose. A good rule of thumb is to use the faster, more powerful computer as the VM debug host because of the computational resources required.
Before debugging your Java application, you may need to make sure the debug options are all enabled for your remote application. If that information is not available, you will get an error message, such as "Debug information is not available" or "Unable to install breakpoint due to missing line number." You can modify the settings from the Eclipse menu by changing what's set in Window > Preferences > Java > Compiler.

Figure 1. Debug options in Eclipse





We are ready to start debugging an application remotely. Let's do it step by step:
1. Create a Java project with a simple class
We create a simple class for debugging purpose. Listing 4 shows the sample code.

Listing 4. Sample code for debugging
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.");.

Figure 2. Set breakpoints in Eclipse
3. Debug the application locally
Before debugging your application, ensure that the debug options described in Figure 1 are enabled for the project. It's unnecessary to debug an application locally, but we can make sure all the debug information is available. Right-click on the Java project, select Debug As and select Java Application (see Figure 3). If the application execution is stopped at the breakpoint, the debugging information is presented correctly. You can continue to use the debugging features, such as displaying the debug stack, variables, or breakpoint management, etc.
Figure 3. Debug the application locally






4. Export the Java project




We will use this application as the debug target. Right-click on the Java project, select Export, select Java, then chooseJAR file or Runnable JAR file to export the project. The JAR file will be generated at the desired location. Be aware that if the Java source does not match the target application, the debug function will not work correctly.

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.
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
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.
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.

Java resource consumption

So yesterday I fired up Eclipse, I did SVN update on my project and I ran the ant. And it took unusually long time to finish. 10 minutes! At some points, Eclipse occupied so much computing resource that it brought my computer to an unresponsive state. Mouse clicks would not respond. Neither would keyboard presses. I took print screen of the resource usage and it surprised me to see that java (Eclipse) occupied 228% of CPU. How could that be? 228%? Well I have quadcore processor, so does it mean that the maximum CPU percentage would be 400%? I also noticed that the signjar target of the ant was the most resource consuming. Following are the screenshots:


Threads in Java can outlive the thread that spawned it!

I often read in Java blogs that main thread is the last thread to die after all other threads die. This is obviously not what I experience. Main thread dies right after it finishes its business, leaving the threads that main spawned working alone. Moreover, if main spawns ThreadA, for example, and main joins ThreadA using Thread.join() method, then main only waits until ThreadA dies, then main dies. If in the process of running ThreadA spawns some other threads, then when ThreadA and main dies, those other threads will keep running if their business is not finished yet.

Interesting comment from this website:

The main() method must indeed have a void return type. From the Java Language Specification on "Execution - Virtual Machine Start-Up" (§12.1.4): The method main must be declared publicstatic, and void. It must accept a single argument that is an array of strings.



A program terminates all its activity and exits when one of two things happens:
  • 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.
In other words, the program may exit before or after the main method finishes; a return value frommain would therefore be meaningless. Therefore the return value of main is void.

main() method has no control over JVM. When JVM starts, it will run main() method, but when main() finishes, it doesn't mean that JVM terminaes. JVM continues to execute all threads until 1) Runtime.exit() is called OR 2) all normal (not daemon) threads have died. Daemon threads do not count for this second condition. In other words ... if main() method spawns some normal threads, JVM will notterminate when main() finishes. If main() doesn't spawn any threads, JVM will terminate. If main() spawns only daemon threads, JVM will also terminate when main() finishes.



Compile and run the following code:

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());
}
}
}

----------------------------------------------------------

package test;

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

public class ThreadA extends java.lang.Thread {

    private volatile int counterA = 0;
    
    public ThreadA(){
        setName("Threadcounter");
    }

    public void run() {

        while (counterA < 10) {
            System.out.println("Printing from within ThreadA: " + counterA++);
            printAllThreads();
            try {
                sleep(1000);
            } catch (InterruptedException e) {
                // TODO Auto-generated catch block
                e.printStackTrace();
            }
        }
        
        ThreadB pt = new ThreadB();
        pt.start();
        
        System.out.println("Exiting ThreadA.");

    }

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

    private class ThreadB extends Thread {

        private volatile int counterB = 0;
        
        public ThreadB(){
            setName("Privatethread");
        }

        public void run() {
            while (counterB < 100) {
                System.out.println("Printing from within ThreadB: " + counterB++);
                printAllThreads();
                try {
                    sleep(1000);
                } catch (InterruptedException e) {
                    // TODO Auto-generated catch block
                    e.printStackTrace();
                }
            }
            System.out.println("Exiting ThreadB.");
        }
    }

}