Category Archives: Coding

Know the JVM Series -3- When Weaker is Better: Understanding Soft, Weak and Phantom References

How many times have we created various object instances, and assign those to reference variables? We all know very well that Java has automatic garbage collection; so we just play around the reference variables, and once those variables are assigned null or falls out of scope, JVM takes care of it. No need to worry about ‘free’ as in C / C++. It’s a headache-less approach, which minimizes the risk of introducing memory leaks to our programs, and it works out great day in day out in billions of Java applications running out there 24×7. Kudos to John McCarthy for inventing GC for Lisp, and to  all the folks who implemented the concept in Java.

But there are times, where we a little bit of more control over the process of garbage collection. I’m not talking about the dark art of tuning the garbage collector (which I might cover in a later article). This is about programmatic situations where we expect some object instances to be eligible for garbage collection, to release some unwanted memory that might get accumulated over the time. Well, the classic solution of explicitly assigning null could help us out; given that particular object is referred only through that particular ref variable. What if assigning null doesn’t work out for the problem at hand?

Continue reading

Know the JVM Series – 2 – Shutdown Hooks

In this article of the Know the JVM Series, we will be looking at yet another feature that is offered by the JVM, which is not very well known, and used by the developers. Shutdown Hooks are a special construct that allows developers to plug in a piece of code to be executed when the JVM is shutting down. This comes in handy in cases where we need to do special clean up operations in case the VM is shutting down.

Handling this using the general constructs such as making sure that we call a special procedure before the application exists (calling System.exit(0) ) will not work for situations where the VM is shutting down due to an external reason (ex. kill request from O/S), or due to a resource problem (out of memory). As we will see soon, shutdown hooks solve this problem easily, by allowing you to provide an arbitrary code block, which will be called by the JVM when it is shutting down.

From the surface, using a shutdown hook is downright straight forward. All you have to do is simply write a class which extends the java.lang.Thread class, and provide the logic that you want to perform when the VM is shutting down, inside the public void run() method.  Then you register an instance of this class as a shutdown hook to the VM by calling Runtime.getRuntime().addShutdownHook(Thread) method. If you need to remove a previously registered shutdown hook, the Runtime class provides the removeShutdownHook(Thread) method as well.

For example,

public class TestHook {
    public static void main(String[] args) {
        Runtime.getRuntime().addShutdownHook(new Thread() {
            public void run() {
                System.out.println("Shutdown Hook is running !");
        System.out.println("Application Terminating ...");

That’s it, and when you run the above code, you will see that the shutdown hook is getting called by the JVM when it finishes execution of the main method. The output you will get is,

Application Terminating ...
Shutdown Hook is running !

Simple right? Yes it is.

So the question popping in your mind would be “what’s the purpose of writing an article to demonstrate something that is so simple, that could have easily fit within the 140 character limit of a tweet?”;  well, the answer is that story doesn’t end there.

While it is pretty simple to write a shutdown hook, one needs to know the internals behind the shutdown hooks to make use of those properly. Therefore, in this article, we will be exploring some of the ‘gotchas’ behind the shutdown hook design. Continue reading

Know the JVM Series – 1 – The Uncaught Exception Handler

The Java API, backed by the JVM provides tons of features and facilities to Java developers, which could be used to get things done easily for certain specific scenarios. However, these features are often overlooked by developers, mainly due to the lack of reading material and  resources regarding these APIs. The purpose of this article series is to introduce such features of the JVM and Java API to intermediate Java developers.

Most of the content that will be discussed as part of this series may not be applicable for your day to day work, but knowing this will enable to you to utilize these to get things done simply, and elegantly.

As first part of the series, we will be looking at the Uncaught Exception Handler API of the JVM.  Java uses (or in more specific terms, throws) exceptions to notify exceptional situations in programs. Developers write try-catch blocks to handle these exceptions, or simply propagate the exceptions upwards in the call stack. The uncaught exception handler allows developers to provide a code segment to be executed when an exception is propagated up the call stack, without being caught.This is helpful when we need to perform some operations when exceptions occur, such as in safety critical applications.

Continue reading

What’s harder, synchronizing 2 threads or synchronizing 1000 threads?

Recently, I came across an interesting presentation by Paul Tyma (Senior Engineer at Google / CEO at ManyBrain Inc), regarding the performance of Java NIO vs classic IO APIs. The presentation was titled as ‘Thousands of Threads and Blocking I/O – The old way to write Java Servers is New again (and way better)‘. The title itself sounds downright interesting, and it was worth reading (learned a lot from it). I highly recommend this presentation to any Java programmer. You can download the slides from here.

However, the reason for this blog post is not the presentation itself. Rather, this blog post is about a question that Pual raises (tagging it as ‘Interview question’), that many people will answer wrong, because the answer that comes to mind looking at the surface is misleading.

What’s harder, synchronizing 2 threads or synchronizing 1000 threads?

Continue reading

Changing the default JBossWS (JAX-WS) Web Service End Point Address

If you are working with JAX-WS on JBoss (in my case version 4.2.3.GA) to expose SLSBs as Web Services, you might notice that in the generated WSDL, the end-point address is set as the machine’s name or localhost. The address JBoss uses by default is the ‘bind address’, which you can specify via the -b argument when starting up the container. If you (like me) are specifying it as (which binds it for all interfaces), it generally resolves to the machine name.

This affects a lot if the JBoss instance is published to the web, since we would like to have the WSDL end point mappings via the public IP address. I had this problem for quite a time, and finally managed to find the solution for this in the JBoss Forums. With a slight change in the JBoss configuration, you can get JBoss to use any IP address of your choice in the WSDL.

The steps are as follows:

  1. Goto deploy/jbossws.sar/jbossws.beans/META-INF
  2. Edit the jboss-beans.xml file (the file itself is well commented)
  3. Change the webServiceHost property to the address that you wish to have.