The inevitable 'Change'

They say that change is the only constant. I’ve heard so many times people exclaim that they need change to happen. But do we really like change? I think, being creatures of habit, we of all hate changes. We are in fact, are scared of change, when our existence depends on it.

Though we loathe at the idea of being governed by habits we humans like any other nature’s creation are a creature of habit. Have you ever noticed that we always will keep our wallets or keys in the same place every day, or take the same route to work or home? Even at work, we have predictable patterns and preferences of how we begin our day. Some like to read the news the first thing, while some would check their mails. Some would rearrange their stuff, while few will head straight for the coffee machine.

Of course, there are things we do change. Like our clothes every day for hygiene purposes or cell phones from time to time. But that’s either that our previous one is mal functioning, or it doesn’t have the features you want or maybe it’s not hip enough. Maybe, if you’re like me, you’ll change it just to break the monotony of using the same device. But these changes are only to our peripheral being or towards our superficial interaction with the society. We all hate to come out of our comfort zone otherwise.

History as we know has often showed us that the ones who don’t change are the ones who face extinction.  And this reason alone drives us to accept the change, whether we like it or not. Like in 2000, when a lot of Software engineers went out of jobs because, they were not equipped well enough to handle the new technologies. Or you pick up a new process; introduce new schemes to stay a step ahead of your competitors.

Yet, there are those who in spite of the changing times survived being what they are. Consider the species like the cockroach and many others from the reptilian family. They adapted to the change but did not go through radical metamorphosis as many others. The key word here and to which I want to emphasize is ‘Adaptation’.

Adaptation by definition is: “to make suitable to requirements or conditions; adjust or modify fittingly”. Ninety nine times to one, a change can be predicted. Rarely did you hit an inflection point without having a hunch or visibility into it. Whether you have enough time to adapt to it then becomes the point in question.  And that’s what we’ll talk about in the next post.

Compiling Java Code without the woes of a classpath

Hello World!
Eclipse and other IDEs’ are a great tool for developing, testing and deploying Java applications and save you the trouble of explicitly writing out commands and statements for compilation, which you'll usually have to type in every time if developing from a simple text editors and command line compilers and interpreters. However, often there has been a need or constraint when you cannot use eclipse for compiling and executing purposes always. Let's say you write a neat piece of code involving classes spread across number of different jars. Now you want to move it to, say, a UNIX environment where it may be required that the class be recompiled and executed manually over command-line for testing. Typically, somebody would've taken the pains to write out an ant script or a build script which would set the class path variable for you, but if the class path is changing quite often due to reasons like (project is still under development) or if the build script is unavailable, it becomes a pain for the developer to type in the name of each and every jar explicitly in his class path every time he needs to compile or execute his code.
However, there is a shortcut to save you from the woes of typing in the class path every time especially when you're in a rush to get things done. You can use the java.ext.dirs argument with your other standard JVM arguments. When used, this option will pick up all the jars under the locations pointed out by this environment, without you have to explicitly mentioning each of the jar file names and location in your class path. Here's an example:
java -Djava.ext.dirs=/usr/j2sdk1.4.2_13/jre/lib:/user/user1/myJars -classpath /user/user1/appln/WEB-INF/classes MyClass
However, this should be used only for development purpose and as a short-cut and not as a standard practice. The right way in the end is to specify all the jars in your class path. The simple reason is that maybe during development you may use a jar and have the backup of the same jar also in one of the pointed locations by java.ext.dirs. As per Java specifications: "The rule of class loading clearly states that once an appropriate class is found no further searching is done. The class which is found (lexically) first is used. This is why you can change the name of two jars in the same directory which contain different versions of same class files and the classes in the jar which is lexically first will be used." So while using java.ext.dirs, you won't be able to control which jar to be picked up by java.
(Special thanks to Diloob for pointing this out and for extensive experimenting with this option.)