Wednesday, April 25, 2012

'volatile' keywork in Java

Found this excellent article on the web explaining the 'volatile' keyword in Java and how it can be used for concurrency. The tutorial also explains the changes to the volatile keyword functioning in Java 5.

Also found it interesting to understand what 'livelock' is? We often encounter dead-lock and thread starvation in parallel programming, but livelock is also possible :)

Difference between Concurrent Collections and Synchronized Collections in JDK

Traditionally, we have also used object locks (semaphores) and synchronized methods to make our collections thread-safe. But having an exclusive lock on an object brings in scalability issues.

Hence the latest versions of JDK have a new package called "java.util.concurrent". This package contains many new collections objects that are thread-safe, but not so because of synchronization :)

More details at this link:

Snippet from the above link:

The "Concurrent" prefix used with some classes in this package is a shorthand indicating several differences from similar "synchronized" classes. For example java.util.Hashtable and Collections.synchronizedMap(new HashMap()) are synchronized. 

But ConcurrentHashMap is "concurrent". A concurrent collection is thread-safe, but not governed by a single exclusion lock. In the particular case of ConcurrentHashMap, it safely permits any number of concurrent reads as well as a tunable number of concurrent writes.

 "Synchronized" classes can be useful when you need to prevent all access to a collection via a single lock, at the expense of poorer scalability. In other cases in which multiple threads are expected to access a common collection, "concurrent" versions are normally preferable. And unsynchronized collections are preferable when either collections are unshared, or are accessible only when holding other locks. 

Most concurrent Collection implementations (including most Queues) also differ from the usual java.util conventions in that their Iterators provide weakly consistent rather than fast-fail traversal. A weakly consistent iterator is thread-safe, but does not necessarily freeze the collection while iterating, so it may (or may not) reflect any updates since the iterator was created. 

Also a good post on Concurrency basics is available at: (All chapters a must read :)

Another good blog that explains how ConcurrentHashMap maintains several  locks instead of one single mutex to deliver better performance.

Friday, April 20, 2012

Google Chart APIs

The last time (around 1 year ago), when I had evaluated Google Charts API, I was a bit disappointed. The Chart API only enabled you to embed an image (chart) that would be created on Google servers.

But looks like Google has completely revamped the concept and branding and have a brand new Chart API.

The new charting API looks cool and very easy to use. There are also samples and libraries that will help you write server side code to pass chart data to the client. I was particularly impressed with the Java DataSource library and Oracle PL/SQL library.

It is important to note that Google right now, does not allow these JS API to be downloaded offline and used in a web app that does not have internet connection (e.g. intranet applications). Please consider this constraint before you decide to use Google Chart Tools.

The older version of the image charts is still available here.There is also an online tool for quicking creating an image of a chart. Could be useful if you quickly want to create some stuff for your PPTs :)

JavaScript coding guidelines

With RIA applications becoming the norm, developers have to deal with a lot of JavaScript code. It is important to have proper coding conventions for JS too. Was glad to see a good document posted by Google on JavaScript coding conventions.

Also, there are tools available to check the code quality of JavaScript code. Here are a few examples available:


JAMon lives on !

I have been a big fan of JAMon tool for monitoring Java applications.It is lightweight and has a cool UI that gives you the stats you want. Also it is very clean and simple to use.

The last time I used JAMon was around 5 years ago. I was suprised to see that the project is still alive and kicking and has a few updates that make it even more interesting. I liked the concept of Listeners, which makes it easy to customoize JAMon.

The one thing that was missing in JAMon in the yesteryears was a consolidation app to read stats from multiple nodes in a cluster and present in on a unified dashboard. Luckily there seems to be a project called JARep that just does that. There is no much documentation available on JARep, but there is a good case study on DZone that explains how JARep works.

The case study is available at:

Though I have experiemented with a lot of other tools, I found JAMon to be the best and simplest. One can get it up and running in a project with a few minutes.

Thursday, April 19, 2012

Passing wilcard * in Runtime.exec() command

One of the projects I was consulting on approached me with a peculiar problem.
The application was executing unix commands from a Java program using RunTime.exec() APIs. But strangely for some reason, the "rm" command was not working. The user account running the Java process had the necessary rights for deletion, so the problem was somewhere else.

A quick googling around answered the problem :)

Its important to remember that when we pass wildcards to the RunTime.exec() API, it will treat it as a string only. It is the Unix shell that understands the "*" syntax.
Hence something like this would work: Runtime.exec(new String[] { "sh", "-c", "rm /tmp/ABC*" });

Cool library for Java NIO

I often felt the need to write a wrapper class libaray around Java NIO packages to reduce the complexity for developers.
I was pleased to find one opensource project that does just that :)

The Netty project provides a very clean and easy API for writing network applications. Very useful if we need to implement a customized protocol for special purpose.

Friday, April 06, 2012

Closed Loop vs Open Loop Models in Card Processing

Found this good article on the internet that describes the differences between closed loop and open loop models.
Excerpts from the article:

"Open-loop payments networks, such as Visa and MasterCard, are multi-party and operate through a system that connects two financial institutions—one that issues the card to the cardholder, known as the issuing financial institution or issuer, and one that has the banking relationship with the merchant, known as the acquiring financial institution or acquirer—and manages information and the flow of value between them.
In a typical closed-loop payments network, the payment services are provided directly to merchants and cardholders by the owner of the network without involving third-party financial institution intermediaries. Closed-loop networks can range in size from networks such as American Express and Discover, which issue cards directly to consumers and serve merchants directly."

The site also has another interesting link on how companies such as American Express make money and the competitive advantage they gain because of the closed loop model.