Java

Can decision-makers realistically steer their development projects from Java to Scala yet, or is it too early? Clearly, such a transition is not without risk. Have the benefits now stacked up to outweigh the risks?

A significant part of the lines of code in any enterprise Java application are devoted to plain old java objects (pojos) that carry data. Although they are simple, they represent a non-trivial effort in development and testing. And they make an application resistant to change because often a small change requires alteration of code in several places. Pojos written in Scala are so simple that the value of mixing Scala into Java development becomes worth the extra startup effort.

A Java logging framework should be effective but low fuss. There are many to choose from - some would say too many perhaps. What is needed is something that is simple, productive, reliable and with good performance. SLF4J is a façade for logging in Java that achieves best-of-breed capability and plays nicely with pre-existing frameworks.

Scala is a general purpose programming language designed to express common programming patterns in a concise, elegant, and type-safe way. It smoothly integrates features of object-oriented and functional languages. It is also fully interoperable with Java. Code sizes are typically reduced by a factor of two to three when compared to an equivalent Java application.

Minimising or eliminate code that uses synchronized and instead use the higher-level primitives in java.util.concurrent.

Using XML entity resolvers and URI resolvers in Java, the performance of XML parsing can be substantially improved - even by orders of magnitude in some cases.

Test-driven development 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 ...

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. The Single Assignment pattern can a major benefit to Java developers.

J2EE should be easier to use. This is one of the key objectives of the Spring Framework.

It's best to program to interfaces, rather than classes. Spring reduces the complexity cost of using interfaces to zero. How does this relate to CSP notions of decoupling?