Monthly Archives: October 2010

Nothing Personal; It’s Just Business

Recently, Apple informed that they will be deprecating the JDK in Mac OS X 10.7, code named Lion. With the history of Apple being indifferent towards Java as a platform (for example, not supporting Java on their i Platforms – iPhone, iPad), this is not a suprise move. To quote from the Apple release notes,

As of version 10.6 Update 3 of the version of Java that is ported to Apple (and consequently ships with Mac OS X) is deprecated. Apple’s port will not be maintained, and may be removed from future versions of Mac OS X. The Java runtime that ships with Mac OS X 10.6 Snow Leopard, and Mac OS X 10.5 Leopard, will continue to be supported and maintained.

A significant portion of Java development commmunity have been using Apple based products, and the JDK maintained by Apple supported the growth of this community. However, with Apple backing off their support in future Mac OS versions, this community will need to have another alternative coming up, hopefully, from the (now Oracle + IBM backed) OpenJDK movement.

As I see this, from Apple’s perspective, this is a “nothing personal, it’s just business” situation. With the success of Apple’s i Platform, what I see in this move is that they are attempting to bring in the i Platform based development into the arena of desktops and notebooks, so that they could expand their business on development platforms as well. May be someday in the near future, we might be able to witness the dawn of another development toolkit from Apple (probably based on the i Platform), competing with Java and .NET platforms.

Personally, I believe that the Java community will work out a solution to keep the Java platform running on Mac based products, but certainly, this will not have the same momentum as it had so far.


Note : Just to avoid confusion, the ‘i Platform’ that I refer to in this blog entry merely stands to represent the platform which is the basis for iPhone and iPad products.

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

Upgrading from Ubuntu 10.4 to 10.10

If you are wondering why the Ubuntu 10.04 Update Manager does not show the button to upgrade to 10.10 release, then do the following.

Open the /etc/update-manager/release-upgrades file and set Prompt=normal (you will need super user privileges – sudo). By default, this is set to lts, which will only prompt when a LTS upgrade is available.

Once you have done that, go back to the Update Manager, and click Check button. Now the Upgrade to 10.10 button will appear !