Spartan Java

In case you are not doing it already, using asynchronous logging is generally a good idea. You don’t want your application to slow down if the server IO is a little behind flushing all that logging to the filesystem. By making it asynchronous your application can continue running without having to wait for the log lines to be written to their final destination.

My personal choice for Java logging is log4j, there are a lot of different frameworks (including Suns own logging API), but log4j works great and is extremely flexible.
(continue reading…)

I’ve faced this problem a few times before, but this time I decided to find a generic solution to it. I needed to prevent users from clicking action links in a web application multiple times and therefore triggering some server side action a lot of times when only one time was enough/needed.

After looking around for a few hours for an elegant solution I just couldn’t find one, all the articles/answers I found required controls on each link and/or special handling on the server side code that reacted to them.
(continue reading…)

I recently had to load a bunch of objects into memory and then perform thousands of look-ups over that collection. Using the good old java.util.ArrayList just didn’t cut it, the contains() function is extremely slow (as you would guess of course since this implementation stores elements as they are inserted and without any aditional indexing structure).
(continue reading…)

There are plenty of times when you need a cache for Java objects in your code. A very easy to use and simple implementation of a cache is provided with Apache ORO, wisely called CacheFIFO (http://jakarta.apache.org/oro/api/org/apache/oro/util/CacheFIFO.html).
(continue reading…)

Just in case you didn’t know, raising an exception makes the JVM do a lot of dirty work breaking execution flow and stuff. (continue reading…)

Do you really need to have a database table with all existing countries? What’s the benefit? Apart from adding one more database query to each page hit and an array to each users context while loading that form…

Think it over, every software component’s goal must be, first of all, to satisfy the users needs as fast and as reliably as possible. Considering the “fast” part, you must always evaluate if it’s really necessary to store this kind of info in a database table, and penalize the applications overall performance by adding another database query, recordset run through and a whole bunch of new objects in an array in request or session context.

(continue reading…)