"Lost Programming Skills"

All too familiar with that "corporate IT solution" consisting of various inefficient black boxes haphazardly glued together using a plethora of acronyms?

This article entitled Lost Programming Skills looks at some of the once common knowledge which has not been passed on to generations of programmers. Interestingly, they highlight the inability to appreciate I/O issues (as much as, say, code optimisation).

Additional information on the 'final' keyword

The section on the Java final keyword has been expanded. Previously, we concentrated on the use of 'final' for thread-safety but did not give much information about a separate use of 'final' to indicate that a class or method cannot be overridden. The new material expands upon this use with a look at the performance implications of the 'final' keyword as a class or method modifier.

A common view that I have both heard among colleagues and seen in various Java textbooks is that 'final' is as much a performance hint to the compiler as a specification of design. In the new section, I present some data showing that this view is probably misguided: the timing of calls to methods to final vs non-final classes comes down to whether the JIT compiler can determine at runtime the precise subclass of an object rather than whether or not the class in question is or may be overridden.

The performance impact of object orientation

Today's new Javamex article looks at the performance impact of using an object-oriented approach vs an optimised, non-object-oriented approach in a case where the OO approach requires high object throughput. Specifically, we look at the case of calculations with complex numbers.

The basic tenet is that the most intuitive program design is to have a complex number encapsulated as a Java object, and furthermore, as an immutable object. This means that at each individual step in a calculation, a brand new object is created. However, performance measurements suggest that using immutable objects is only around 28% slower than using mutable objects, whilst the codability and maintainability impact (threading issues; bugs introduced by forgetting to copy objects and hence making accidental modifications to an obejct) may be considerable.

In our example, a version of the algorithm that does away with encapsulation and "inlines" its calculations on raw double primitives is more than twice as fast, as perhaps might be expected. On the other hand, "only" being between twice and three times as fast means that a comparable improvement will be possible in some applications by making use of more processors, or potentially making other algorithm improvements, whilst the codability and maintainability implications of not using encapsulation become more severe for more complex applications.

New section on sorting

A new section on sorting has been added to the Java Collections section of the web site. The section currently contains information on:

• Intrudction on sorting
• Simple sorting of strings (sorting a list or array of "naturally sortable" objects)
• The Comparable interface, used to dictate the "natural sort order" of objects
• The false economy of compreTo optimisations
• Comparators, used to dicate the sort order for a particular sort, or for classes whose sort order can't otherwise be specified.
• An analysis of Java's sort algorithm, including a look at its performance.

The latter section shows that, if your application makes repeated sorts of very small data sets, an alternative sort algorithm may be beneficial.