Fitz

I’m looking into using a templating engine for formatting output from a Java component.  From what I can tell, the top 3 templating engines for Java are Apache Velocity, Jxp, and FreeMarker.

Right away, Velocity stands out given the reputation of the Apache Foundation.  Looking at Jxp, though, it’s appealing to be able to use standard Java code with the JSP-like syntax.  If we can believe the FreeMarker site comparing it to Velocity, FreeMarker has better support for number and date manipulations (among other things), which could be particularly important for my uses.

I haven’t tried any of these engines out, yet.  Rest assured, though, that I will try them and post my findings.

This article on Netbeans.org discusses using the profiler bundled with the Netbeans IDE to detect memory leaks. By monitoring the surviving generations metric, one can supposedly catch a leak. I believe that this article ignores a certain situation.

Read the rest of this entry »

It was only a matter of time before I needed a Thread-safe Map. Looking at the synchronization wrappers for the Java Collections framework, I couldn’t help but be disappointed. The wrapper classes provide external synchronization on the entire Collection. That means that any read or update method is locking — one thing in at a time. What a performance bottleneck!
Read the rest of this entry »

Working on some Java code, I recently found myself in need of a hash-type data structure. The project I’m working on frequently uses a home-grown hash table implementation, but I wanted to transition to the more recently developed Java Collection classes. Since J2SE 1.5.0, the data structures in the Collections framework have been updated to use Generics, which are cleaner and provide safety against casting errors.

Without giving it much thought, I started using the java.util.Hashtable implementation. But soon I stumbled upon the java.util.HashMap class. Not knowing the differences between the two, I read through the API documentation to compare both implementations.

As it turns out, there are some important differences. First, Hashtable is synchronized, meaning that it can be used concurrently by multiple processes/threads without the need for synchronization outside of the object. HashMap, on the other hand, is not synchronized. To use a HashMap object in a concurrent programming environment, you’d need synchronization external to the object.

Secondly, Hashtable does not allow null keys or values, whereas HashMap does. This was important for my project because the existing code required the ability to use null as a value. To change that behavior would be outside the scope of my task.

Finally, HashMap allows values to be safely removed during iteration, but Hashtable does not.

After comparing the two Collections classes, I chose to use HashMap mainly due to the fact that it allows null values. Since the existing source code requires null values in some cases, this ability was a necessity. The fact that HashMap does not provide synchronization is insignificant for my project — there is no concurrent access to these data structures. Although concurrency is planned in the future, there already exists a need for synchronization at a higher level.

Regardless of the differences between Hashtable and HashMap, I feel much better about using either one than the in-house hash table implementation developed circa jdk 1.0. At least I won’t have to worry about casting.

Update: After reading a little more about the Collections framework, I’ve discovered that there is a way to get synchronized versions of the unsynchronized classes. Java provides a set of synchronization wrappers capable of producing thread-safe versions of any Collection. Pretty cool!