J2SE 1.4.2 is in its Java Technology End of Life (EOL) transition period. The EOL transition period began Dec, 11 2006 and will complete October 30th, 2008, when J2SE 1.4.2 will have reached its End of Service Life (EOSL).

This doesn’t mean that Sun doesn’t support Java 1.4 anymore - with Sun’s Java SE for Business you can get up to 15 years of support for older Java versions.

However, if you’re on a project that still uses Java 1.4 you should really upgrade to Java 6, if you have any say into which Java version is being used. Besides the new features added in Java 5 and 6, you’ll enjoy the performance enhancements and bug fixes.

If you’re a Java programmer and you still didn’t learn the new Java 5 features… then you’re in trouble.

The SCJP exam for Java 1.4 has been discontinued this month.

I knew that there were proposals to add closures to Java, but I hadn’t yet looked into the details of the proposals. The article explains very clearly what closures are exactly and gives a good overview of the three main proposals that there are today: CICE + ARM, BGGA and FCM + JCA. Read the article if you want to know what the alphabet soup means exactly. In short:

• CICE + ARM, proposed by Joshua Bloch and others, is not much more than a new, shorter syntax for anonymous inner classes.
• BGGA, proposed by Gilad Bracha, Neal Gafter, James Gosling, and Peter von der Ahé, is the most ambitious proposal and almost makes Java a functional programming language.
• FCM, proposed by Stephen Colebourne and Stefan Schulz, also adds functional programming paradigms but doesn’t go as far as BGGA in some aspects.

What’s so controversial about adding closures to Java? Adding any new feature to the programming language makes it more complex. There are people who fear that adding a powerful but complicated feature such as closures might make Java too complex - which means that people will turn away from Java in favour of easier programming languages. This talk by Joshua Bloch from JavaPolis 2007 makes clear how complicated Java could become if BGGA closures would be added.

So, the question is, is it really such as good idea to add closures to the Java programming language? I’m not sure that it is worth the trouble. After reading the article and seeing Bloch’s talk, I’m convinced that adding far-reaching closures such as BGGA and FCM will not be so great. What I especially don’t like in the BGGA proposal are the non-local returns: a return statement in a closure means you’re returning from the method that the closure is called in, not from the closure itself. This makes code very confusing and hard to understand.

I can see how CICE closures would be useful and at least it looks like that proposal is a lot simpler than the other two. But regardless of how much complexity closures would add to Java, there are reasons for me to doubt whether it’s a good idea at all to add closures to Java.

Java is an imperative programming language. Because of this, Java programmers generally use an imperative programming style. For example, we write a loop like this:

List<String> names = ...;

for (String name : names) {
    System.out.println(name);
}

Adding closures will encourage a functional programming style, which is completely different from the imperative style. In the functional style, you’d write a loop very differently; you’d call a forEach method on the collection, passing it a closure to execute on each element of the collection (this is what it would look like with BGGA closures):

List<String> names = ...;

names.forEach({ String name => System.out.println(name); });

What are the consequences of this? Does this mean that for example there are going to be lots of new methods (such as the forEach() method shown above) in Java’s collections API to support this style of programming? That would bloat the collections API. Can you imagine what a mess you would get if you’re working on a project with multiple developers where some developers prefer the imperative style and others the functional style?

I’m not opposed to the concept of closures itself, they work very well in other programming languages such as Ruby. The difference is, however, that Ruby has had closures since the beginning, so that Ruby’s standard library was designed to work with closures from the start. If (part of) the standard Java library, such as the collections API, which was designed for the imperative programming style, is going to be extended to add support for closures, it will just grow into a complicated and bloated piece of patchwork.

The cost of adding a new feature to the programming language is very high. Millions of Java developers around the world will need to invest time and money to learn the new feature. The authors of the thousands of libraries and frameworks will need to think about the consequences for their products. And closures is not just another minor feature, it will add a whole new programming paradigm to Java. Are closures really worth all that effort? So far, I haven’t heard any convincing reason why it would be a good idea to add closures to Java. Sure, they are a cool and powerful feature. But how are closures going to make things easier for me as a Java programmer? I’m not convinced that they are worth the extra complexity and API bloat that they will add to Java.

For example (note, the “import BigDecimal._” is the same as “import static java.math.BigDecimal.*” in Java):

object HelloWorld {
def main(args : Array[String]) = {
// Import BigDecimal into the scope of this block of code
import java.math.BigDecimal, BigDecimal._

val a = ONE.add(ONE);
println(”One plus one is: ” + a)
}
}

Martin Odersky, the inventor of Scala, is currently busy writing a book of which a pre-print version is available at Artima. At the moment, Scala is not yet ready for prime time (there are still some funky bugs in the compiler and some rough edges in the language itself, and IDE support is not yet complete), but there’s a good chance that this is going to be an important new programming language in the next two or three years.

The second session I went to today was “Distributed Computing and MapReduce: Technology Selection, Implementation and Deployment Made Easy” by Eugene Ciurana. He explained what MapReduce is - an algorithm for processing large amounts of data efficiently in two steps (”map” and “reduce”). The idea came from Google. Eugene explains how it’s used in the company where he works to analyze log files from webservers, to find out from which countries people are accessing their website. There are a number of implementations of MapReduce available, for example the open source Hadoop from Apache and commercial products from for example GigaSpaces, GridGain and Terracotta. He also used Mule (see also this case study from Eugene).

My third session of today was “Performance Tuning a Web Shop with Open Source Tools” by Jeroen Borgers of Xebia. Often, when developers have to solve a performance problem, they make a guess about what’s wrong with the application and try to fix that, but in reality the only way to know what’s really wrong is by measuring instead of guessing. Jeroen talked about a project in which he used tools such as JMeter and JAMon to measure performance, and JARep, a reporting tool for application performance data that he wrote himself.

After lunch I went to “How to Choose your Java Web Framework” by Shashank Tiwari. It’s a question that ofcourse interests a lot of developers, because there are hundreds of frameworks and it’s not easy to determine which one you should use. Besides discussing the characteristics of the most popular frameworks he also talked about whether you should use a framework at all, because there are also some disadvantages: you’ll have to deal with a learning curve, for simple applications a framework can unnecessarily complicate things, it can cause infrastructure bloat, and it presents challenges for testing and maintenance. Ofcourse he didn’t come up with a perfect recipe for choosing a framework. He finished with two conclusions: For simple applications, it doesn’t matter a lot which framework you choose (or if you use a framework at all), so you shouldn’t waste much time on it; for larger applications, that are part of a bigger system, it’s probably best to go for a “full stack” solution such as Spring or JBoss Seam, because you’ll have less integration problems in your project.

The last session I went to was “Real Google Web Toolkit Applications” by Jeff Dwyer. Google Web Toolkit is a web application framework by Google which allows you to program in Java, as if you’re writing a Swing desktop application. It compiles your Java code into a web application with JavaScript. He showed how GWT works by looking at a real-world example application which integrates GWT with Spring MVC. GWT is one of those things that’s on my list of things to look at sometime.

So, it was an interesting conference, I’ve learned a number of new things and got some new ideas. Thanks to JavaRanch for giving me a free ticket for this conference!

At 9:10 I went to “Spring 2.5 On the Way to 3.0″ by Jürgen Höller (one of the main committers on the Spring framework). He explained some new features in Spring 2.5, and went quite deep into the technical details of the @Autowired and other annotations - which was quite boring. He spent so much time on talking about those details that he had almost no time left to talk about 3.0. Spring 3.0 will be for Java 5 and newer only, and some new features that it will have are an expression language, support for REST and some preparation to support servlets 3.0. I wonder why they’re going to give it version number 3.0 instead of 2.6, since it didn’t sound like it would be a lot different from the current Spring 2.5.

The next session I attended was “Groovy in the Enterprise: Case Studies” by Guillaume Laforge. As the title suggested, he showed some examples of where and how Groovy has been used by companies. He discussed a number of use cases, such as: using Groovy as a developer tool (for example for testing or extending Ant or Maven), using Groovy to extend your applications (for example by using the Java scripting API to run Groovy scripts from within your application), using Groovy to create a DSL and using Groovy and Grails for web development. There was some overlap with his presentation about Grails that I attended yesterday.

At 11:40 there was an expert panel session titled “Languages: The Next Generation” with Ola Bini, Ted Neward and Guillaume Laforge. They discussed about the programming languages that are currently popular or that get a lot of attention. I found the session a bit disappointing, I had expected more. The panel didn’t come up with a clear answer or vision about what the next generation of programming languages is going to be. The only conclusion they came to was that Java is here to stay and that other languages such as Groovy, JRuby and Scala will be important additional languages, but they’re not going to completely replace Java.

After lunch I went to “Lifecycle APM: Monitor, Diagnose and Prevent Performance Issues” by Alois Reitbauer (from dynaTrace). This session was a “vendor tech brief”, so there was some marketing talk, about dynaTrace’s tool that allows you to follow transactions through a whole chain of systems (so that you can monitor and debug performance of the system).

At 13:50 I went to “JRuby on Rails: Web Development Evolved” by Ola Bini. He spent a lot of time on explaining the Ruby programming language, and had unfortunately not a lot of time left to explain how Rails works on JRuby, which was what I was interested in (I’ve already used Ruby for some time, so the intro to Ruby was not so interesting for me). Anyway, Ruby is an interesting, easy to learn and easy to use programming language, and I’d recommend any Java developer who wants to learn some other language to have a look at it.

The next session I went to was “Concurrency & High Performance” by Kirk Pepperdine. He’s a well-known guy in the field of high-performance and concurrent programming in Java. Writing software that efficiently uses multi-core processors is not easy, but it’s becoming more and more important with the current trend of multi-core processors. One of the things Kirk mentioned was the fork/join framework that will be added in Java SE 7. One book that I want to read someday soon is Java Concurrency in Practice, I’ve heard that it’s a very good book.

At the end of the afternoon there were “fireside chats”, which were sessions in which a few people did some short demos and then discussed among each other and with the audience about the things they demonstrated. I went to the fireside chat titled “Zero Turnaround in Java development”, which was about developing in Java in such a way that you don’t have to go through stop / recompile / redeploy / start cycles all the time. Guillaume Laforge showed how you can edit your Groovy web application on the fly. Geert Bevin showed how the RIFE framework supports the same thing, and Jevgeni Kabanov (from ZeroTurnaround) showed his (commercial) tool JavaRebel, which is a JVM plugin that allows you to reload classes in a running JVM. They discussed about the use and limitations of their tools and answered questions from the audience.

I arrived here late in the evening last Tuesday and I’ve hardly been outside the hotel (the conference is held at the hotel), so I haven’t seen Prague yet. Tonight there’s a “meet a stranger” dinner - you could put your name on one of five lists, and you’re going out to dinner with the other people on the list. So I’m going to a restaurant in the center of the city tonight with a few other people to have traditional Czech food.

The first day started early at 8:00 AM with a keynote by Stephan Janssen from BeJUG (famous for organising JavaPolis, which has now been renamed to Javoxx). His keynote was about different RIA (Rich Internet Applications) technologies. He gave an overview of the different choices that you have for the client side, server side and data protocols to communicate between the two (HTML, XML, JSON, Hessian, …). He demonstrated his Parleys website, which is an AIR multimedia-application (have a look, it’s a very interesting website with lots of presentations with video and slides from the past few JavaPolises and other conferences). Besides the AIR version, he also had an implementation of the Parleys website done in GWT and also one done in JavaFX. He calls JavaScript “VoodooScript” because writing an application in JavaScript and DHTML requires black magic to make it work in all the webbrowsers that people might use.

After the keynote I went to a session titled “Integrating JPA and Hibernate with Rich Internet Applications” by Shashank Tiwari (from Saven Technologies). He talked about using Hibernate (as an implementation of JPA, the Java Persistence API) on the server for a client written with Adobe Flex. There are different ways to do this, you can use LCDS (Lifecycle Data Services, a product by Adobe) or an open source alternative such as GraniteDS or dpHibernate. He gave an idea of how you could use those libraries by showing some examples of configuration files. I found this talk not the most interesting one I’ve seen on the first day (probably because the topic wasn’t really relevant to my current job).

The third session I went to was “Monitoring, Management and Troubleshooting in the Java SE 6 Platform” by Jean-Francois Denise (from Sun). He first talked about JMX and how to write MBeans or MXBeans for your application so that you can monitor and manage your application with a tool like JConsole. Besides JConsole, Java SE 6 comes with a whole list of other useful tools, such as: jinfo, jstat, jstack, jps, jmap and jhat. Sun is working on a new tool, jvisualvm, which looks like a new and improved version of JConsole, which Jean-Francois demonstrated. This was an interesting session, and it reminded me of JMX and all those tools. I think JMX is a very useful API that people unfortunately often overlook; it’s not that hard to write MBeans and tools like JConsole can be very useful as a simple memory profiler and for managing running Java processes.

Next was another keynote, “Getting Ready for the Cloud”, by Nati Shalom from GigaSpaces. I was afraid that this was going to be not much more than a marketing talk, but it wasn’t really. Nati talked about cloud computing: instead of having a few big servers, you have a large amount of smaller computers to do the work. This has certain benefits for scalability.

The first session after lunch that I wanted to attend was “Comparing Dependency Injection Frameworks”, but a few minutes after the talk was supposed to start, it was announced that the presenter wasn’t there. So I went to “SOA Using Service Component Architecture” instead, by Mike Keith. This session was about SCA and Open SOA. SCA is a set of specifications about components and their interfaces for using in a service oriented architecture. It specifies components that have input and output interfaces, properties to configure them and how they can be wired together. There are also specifications for how SCA is implemented using for example Java, webservices, C++, PHP and other technologies. In Java, you can use annotations to specify a component and its interfaces and properties. The good thing about SCA is that it makes it possible to wire together service components that are implemented in different technologies, because the components will have a standard interface.

The next session I went to was “Simplifying Java EE Development with Grails” by Guillaume Laforge. It was a straightforward presentation about Groovy and Grails. Grails is a web framework and a set of tools that enables you to quickly build a (CRUD) web application, just like Rails (for Ruby). I’ve played with Ruby and Rails myself, but I haven’t really looked at Groovy and Grails much yet. Looks like an interesting language and framework to have a look at when I have time.

The last session of the first day that I went to was “Better Enterprise Software with the Spring Portfolio” by Eberhard Wolff (from SpringSource). He talked about a case study in which he used different Spring technologies, such as Spring Beans, Spring Webservices and Spring Batch. The Spring framework really tries to be a big framework which you can use for almost anything, and its popularity shows its success. While watching this session I thought back about the session about SCA, because there seemed to be some overlap in the way that you declare components with annotations in the way that SCA specifies and in how you declare and configure different kinds of components with annotations in Spring.

And now the first day is already over. I always feel that time goes by very quickly at conferences.

For my assignment I used metrics to evaluate the modularity, encapsulation and complexity of different implementations of the same concurrency functionalities.The modularity, encapsulation and complexity gave an indication of their maintainability.

The fact that more and more tools for software metrics are released and used is a good thing, because evaluating source-code and refactoring the ‘bad’ code can be of great importance for a good evolution of a software product (to keep it maintainable).
But it should not be used as a ‘development method’, lately I see other developers write their code in a way to get optimal results on one or two of these metrics. This is what I would like to call metric driven development and should be avoided. Why ?
Well because software metrics are indicators no more no less, a program for which metrics show good complexity metrics indicates the code is easy to understand, but does not guarantee it !

Software with good metric values can still be ‘bad’. For example, brainlessly refactoring for good metrics might hurt the shared abstraction levels of the methods or their cohesiveness. Which are also important source-code characteristics according to McConnell, and therefore making it doubtful that the refactoring was of any help to the project.

A second reason would be that optimizing code for some metrics will likely hurt the other metrics. For example when minimizing the number of lines of code in a method, one might extract new methods, resulting in a larger amount of methods per object and probably larger amount of lines per class.

So my personal advice would be to use software metrics only in the way they where meant to be: to evaluate a piece of software and to realize that it’s just a tool to indicate software quality not a guarantee.

The commons lang contains all kind of utility classes that will make you think why it is not part of the standard Java lang(uage).

One of the most handy features of the Commons Lang are the Builder classes to easily create toString, equals and hashCode implementations for a class. All these builder classes are smart enough to detail with null and array arguments, so you don’t have to.

Another handy class is the StringUtils class that contains a whole bunch of string functionality like isEmpy / isBlank, trimming, replacing, chomp / chop etc.

When coding I like to aggressively enforce my constructor / method pre-conditions by throwing and IllegalArgumentException when any argument value is not according to a pre-condition. The Validation class will help you with that. It contains utility methods to easily check if the supplied argument isTrue, notEmpty and notNull. Furthermore for a collection / array you can easily validate if there are no null element and that all elements are of a certain type.

There last class I would like to mention is the Enum / ValuedEnum base class.
By extending from this class you can easily create a enum class in Java 1.4 (in Java 5 you should use the new enum language functionality).

I would advise any Java programmer to have a (short) look at the Javadocs of Commons Lang, because besides the features I described above there are a lot more gems to be discovered.

That seems simple enough, but if you study generics in more detail, you will discover that there are some strange limitations that don’t look obvious at first sight.

For example, here is one limitation of generics I would like to highlight: You cannot create an array whose component type is a concrete parameterized type. An example to explain what this means:

// An array of a list of strings. This is illegal, but why?
List<String>[] data = new ArrayList<String>[10];


At first sight, this looks perfectly reasonable. But if you try to compile this, you get an error message, and it isn’t very helpful either:

Jesper.java:6: generic array creation
        List<String>[] data = new ArrayList<String>[10];
                              ^
1 error


The compiler just tells you that you can’t do this, but it doesn’t give a hint why. To understand why this is illegal, we have to know a few things about arrays and generics in Java.

First of all, arrays are covariant, which means that an array of supertype references is a supertype of an array of subtype references. For example, Object[] is a supertype of String[], and a string array can be accessed through a reference variable of type Object[].

Object[] example = new String[10]; // ok
example[0] = “Hello World!”;


Arrays also carry runtime type information about their component type. At runtime, when you assign a value to an array element, an array store check is performed to check that you’re not storing a value in the array that’s not compatible with its component type. If the check fails, an ArrayStoreException is thrown.

Object[] example = new String[10];
example[0] = new Long(123); // compiles, but throws ArrayStoreException at runtime


That still doesn’t explain why arrays of concrete parameterized types are illegal. There’s one more thing we have to understand, and that is the process of type erasure.

When you compile Java source code in which generic types are used, the compiler does the extra type checks and then translates the code into plain old Java code without generics. If you would decompile the byte code, you would see that the generics have disappeared. So for example List<String> and List<Integer> would both look like the plain old List in the byte code - the information about the generics has been lost by the process of type erasure. The following example illustrates this:

List<String> names = new ArrayList<String>();
List<Integer> values = new ArrayList<Integer>();

System.out.println("Runtime type of 'names': " + names.getClass().getName());
System.out.println("Runtime type of 'values': " + values.getClass().getName());


The output of this piece of code is:

Runtime type of 'names': java.util.ArrayList
Runtime type of 'values': java.util.ArrayList


As you see, both look like plain old ArrayList at runtime. I won’t go into the details here of how and why the compiler handles generics using type erasure.

So here comes the catch. The combination of how arrays work (covariance and runtime type information about the component type) and type erasure for generic types creates a problem when you want to create an array of a concrete parameterized type.

Because of type erasure, there is no exact type information available for the generic type at runtime, so that the array store check doesn’t work, and an unacceptable situation occurs. Here’s an example.

List<String>[] data = new ArrayList<String>[10]; // illegal, but assume that this would be ok

Object[] objArr = data;
objArr[0] = new ArrayList<Integer>(); // should fail, but would succeed

List<String> firstList = data[0]; // would fail with ClassCastException, but there’s no cast!


Because of type erasure, List<String> looks like a plain List and ArrayList<Integer> looks like a plain ArrayList at runtime. The array store check would succeed, because ArrayList is a subtype of List. Ofcourse we now end up in an unacceptable situation - the first element of the array now contains an ArrayList<Integer>, which shouldn’t be possible.

To avoid this problem, the Java language engineers at Sun simply decided to make arrays of concrete parameterized types illegal.

Isn’t it ugly that a construct that looks perfectly reasonable (you can make an array of any type, so why not of a concrete parameterized type?) is made illegal essentially because of the way the compiler treats generics? In other words, the language has a hole now because of the implementation details of the compiler.

This is just one of the quirks that you find when you look at generics in depth. You can find a lot of detailed information about generics in Angelika Langer’s Java Generics FAQ.

You can use this ThreadLocal in several situations:

To keep state with a thread (user-id, transaction-id, logging-id)
Log4j uses this for the NDC (Nested Diagnostic Contexts) feature, you surely need this if you ever want to be able to debug a heavily used production application (some more info here).
My current project uses ThreadLocals to trace incoming and outgoing messages (XML via JMS). When we receive a message we put a pseudorandom 44-bit number into the thread-local variable. Important events (exceptions, any outgoing messages, result of processing) are logged with the value of the thread-local variable. This way we correlate events in the main log of the application.

To cache objects which you need frequently
Another way of using a ThreadLocal is for performance optimalization. You can imagine that there are certain objects which are relatively expensive to initialize, but are not threadsafe. Examples of these objects are XML DocumentBuilders (with XSD validation), and SimpleDateFormat (needs a Calendar instance).
When you put the SimpleDateFormat in a thread-local variable, you don’t have to create a local one for every format operation you need to do (we need them quite often), but still are safe with concurrent processing. Implement this as:

public class DateUtil {
   private static final ThreadLocal datetimeFormatter = new ThreadLocal() {
      protected Object initialValue() {
         return new SimpleDateFormat("yyyyMMdd HHmm");
      }
   };
   public static String toDateTime(Date d) {
      SimpleDateFormat sdf = (SimpleDateFormat) datetimeFormatter.get();
      return sdf.format(d);
   }
}

Watch out
Be careful, do not use thread-local variables as instance variables. Although it is not explicitly stated as such in the SDK API docs, they will cause problems when you don’t use them as static variables. Note that this is still an issue in 1.5.

For you J2EE-addicted, these objects can also be held as instance variable in a SLSB (because they’re accessed by one thread at a time), but I tell you, there are still situations you don’t want to create a Enterprise Bean