Fitz

This function makes use of Douglas Crockford’s functions available from his Remedial Javascript page. If you haven’t read his series of articles on Javascript, you’re missing out. Also, check out the Yahoo User Interface team’s website and the YUI blog for more Javascript info and tips.

Crockford’s isEmpty function:

function isEmpty(o) {
    var i, v;
    if (typeOf(o) === 'object') {
        for (i in o) {
            v = o[i];
            if (v !== undefined && typeOf(v) !== 'function') {
                return false;
            }
        }
    }
    return true;
}

As a question to the readers, how should the isEmpty function treat object properties that are undefined or functions? Currently, the function ignores undefined properties and functions. Should it count them as properties?

My getProperties function looks much like the isEmpty function and uses the same method for accessing an object’s properties. Rather than return true or false based on the existence of properties, this function returns an array of all of the property names for the given object. A trivial modification of the isEmpty function, but useful none the less.

function getProperties(obj) {
  var i, v;
  var count = 0;
  var props = [];
  if (typeof(obj) === 'object') {
    for (i in obj) {
      v = obj[i];
      if (v !== undefined && typeof(v) !== 'function') {
        props[count] = i;
        count++;
      }
    }
  }
  return props;
};

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!

Years ago, a friend in the software development industry introduced me to the Extreme Programming software development methodology, or XP. Since then, I’ve noticed many of XP’s principles creeping into my own office. Some of the main points of XP include:

* breaking a project lifespan into iterations
* frequently producing small releases
* programming unit test cases first
* using simple, streamlined design
* only adding functionality that meets a requirement of the current iteration
* frequent code refactoring
* constant customer interaction

Many believe that XP’s principles are not effective unless they are all applied to the development process. Some of these ideas, though, seem to me like general good practices. For instance, heavy customer involvement in the development process could help in many stages — requirements gathering, testing, scoping the level of effort, to name a few — whether or not any of the other practices are used.

I had a discussion with a coworker the other day concerning XP’s usefulness for maintaining existing code. He argued that some of XP’s practices don’t make sense for maintenance tasks, particularly programming unit test cases before making code changes. I can see his point; it seems wasteful to spend time writing unit tests for components that apparently already work properly. But what if we started a unit test for a component that needs a bugfix, adding tests to illustrate the component’s failure. Then we can consider the bug fixed when the component passes its unit test. As additional bugs pop up for the component, we add to the unit test for that component. Not only can we be assured that the bug is resolved, we can also be certain that our fix hasn’t broken previous fixes.

It’s true — XP’s practices are less useful for maintenance compared to new development. But I still believe there’s value to using some of its ideas in software maintenance.