A particularly important objective for developers producing of concurrent systems is to produce designs that always give consistent results and cannot deadlock (see The Four Horsemen on why this can be difficult). Since Java 1.5, the Java API has included the java.util.concurrent package, which contains a range of classes to support thread synchronisation, communication and safe sharing of data. This Java5 API enhancement introduced blocking queues for passing messages between threads, and with this it has been possible to write concurrent Java applications that benefit from decades of theoretical progress in how to design deadlock-free systems.
XML documents typically refer to external entities, for example the public and/or system ID for the Document Type Definition. These external relationships are expressed using URIs, typically as URLs. However, if they're absolute URLs, they only work when your network can reach them. Relying on remote resources makes XML processing susceptible to both planned and unplanned network downtime. Conversely, if they're relative URLs, they're only useful in the context where the were initially created.
Test-driven development (described on Wikipedia) is now widely accepted as the preferred way to develop software, especially Java software. I'm an enthusiastic supporter of this predilection - but there is a problem people seem often to overlook. I call it The Four Horsemen (also on Wikipedia) because there are four potentially major dynamic problems unreachable by testing alone. The problems are: Race Conditions - instability due to concurrent threads changing shared data without sufficient protective locking Deadlock - freezing-up of concurrent threads that have a mutual dependency that cannot ever be satisfied Livelock - similar to deadlock, livelock is a condition in which concurrent threads waste time trying to acquire resources that cannot ever be satisfied due to the mutual dependency between the threads.
‘final’ - underused or overrated? The famous Gang of Four made people sit up and take notice that we developers normally do similar things to each other, and the similarities can be effectively expressed as design patterns. Because of the object oriented nature of Java, it is a language that is well suited to patterns; nowadays design patterns are the industry norm. However, there is an important pattern that seems to have been overlooked - probably because it’s so obvious.
I've always been one of those perhaps slightly annoying people who don't easily accept propositions that seem overly intricate. It's not that I'm a stroppy person - I'm pretty relaxed really - I just don't like wastefulness, and that can mean I'm unhappy when I see other people wasting their time doing things the hard way. I suppose I was trained this way by the years I spent working with the Occam programming language, a language that espouses explicitly the avoidance of complexity by making behavioural semantics really clear to the developer.
I wrote about the Spring Framework Mission Statement earlier. This article follows it by examining the second Spring mission statement bullet, which concerns the use of interfaces in Java: It’s best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero. Everyone knows this is a Good Thing - but why is it good? The answer lies in achieving decoupling. Object oriented programming in Java draws on the precedent set by Smalltalk in which objects communicate by passing messages.