Thursday, April 17, 2008

Improve performance of legacy code using Java 5 language features

Practical Advice for practical programmers

As a senior engineer, you sometimes are thrown into a situation, where you have to come up with some ways to improve the performance of your server side java multithreaded application.
The code was written over a span of 6-7 years and you have only a vague idea of what it does and does not do. More importantly it uses java language features that are old. What do you do?

Before kicking up a profiler and doing memory/CPU profiling - there is something very easy you can do which does not involve all that, provided you can move to Java 5.

There are a number of new classes and frameworks in Java 5 which should improve the performance and reduce the boilerplate code you need to write for a multithreaded application.
Here are some of them.

  1. Replace synchronized collections from your old code with new concurrent collections.i.e. of you have a synchronized HashMap - replace it with ConcurrentHashMap. The Concurrent classes in Java 5 perform fine grained locking and hence provide better scalability.
  2. Identify places where you use Java list class with Queue semantics and replace it with the Java Queue class , introduced in version 5 or 6. Java Queue class is much more efficient than the List class, whose interface supports random access.
  3. Use Blocking Queue (or Bounded Blocking queue), whenever possible.
  4. A common pattern in multithreaded Java applications, is the thread pool along with a work queue. See if you can use Java 5 Executor Task Execution framework.
These are some of the ideas I got so far from reading Java 5 concurrency book by Brian Goetz.
I will keep posting some more patterns to emulate as I come across more of them.

Monday, April 14, 2008

It is not your Mama's Java concurrency anymore

I have been going through this great book on Java Concurrency by Brian Goetz.
I studied a part of this book two years ago but at some point stopped. This time, I am determined to complete it. Reading(nay, Studying) this book makes you realize how much your language(I mean, programming language) changes/has changed over the years.

Here is the thing about high-tech and software development. You start career in this industry as a programmer/developer and you get used to a certain habits of programming or thinking about your programs. A programming language is essentially a tool for you to produce software. You start off enthusiastically and attain a certain proficiency/ comfort level to get the job done. Unfortunately, you get to use and actually need a very small percentage of the language to build about anything- provided you have sufficient time. This results in a flat learning curve for most programmers in their core language. True, they will be learning the latest zing thing framework - which requires changing another 10 xml files - from time to time.
But essentially, their understanding of their language remains stagnant.

That's when they need a kick in the pants. This book is such a kick in the pants for the average java programmer. This book will make you

1)Understand JMM(Java Memory model)
2) Understand how badly you are lagging the language synchronization constructs..
3)Clear Misconceptions you have regarding the java synchronization constructs.

If you are like me, who try to solve Josh Bloch's Java puzzlers/bloopers once in a while and fail 30% of the time or more, this book is for you.

Happy Reading :)

Tuesday, February 05, 2008

SDForum Technical Events for February

There are a number of good Technical events being hosted by SDForum for the month of February.
The SDForum calendar is here
Some good ones I am interested in are
  • Java SIG -Improving code with dependency injection and aspects (Feb 5th)
  • Search SIG - Using the Social Graph / Social Platforms to Enhance Search & Discovery(Feb 12th)
  • Web Services SIG- Mashing Up The Enterprise(Feb 26th)

Vendors get serious about Business Event Processing

One of the latest trends in SOA is Event Processing - more importantly Complex Event Processing.
However , everyone hates the word "Complex", so IBM and other vendors are simply referring to it as Business Event Processing - even though the technology can be used for processing any kind of events.

So what is really event processing? Event processing is nothing but processing those events that arise in the enterprise and making some sense out of them. Have we not been making sense of them with application integration for the last ten years??

The short answer is NO - because while we might have been integrating applications, synchronizing orders and making enterprises have a consistent view of their systems, we never really derived any higher order meaning from the various events that happen in the enterprise.

We never really understood why something happens.

We never understood what multiple events in isolation meant as a whole.

We never maintained any state regarding those events.

In essence, we never had the notion of time while processing events, except for a very rudimentary event sequencing.

About three years ago, I worked on a prototype to demonstrate how event processing could be used in conjunction with our integration broker. It is good to see that these things are now slowlybeing adopted by various enterprises.

BEA has started using Esper as its event processing engine in WebLogic Integration Server and IBM has recently acquired AptSoft.