Some impressions and thoughts on the first day of the Jazoon conference.

The future of Java seems to be about support of various programming language. Is this not paradox? Isn’t Java exactly one programming language? The situation reminds of the Bible’s story about the Tower of Babel, built by humans in order to reach a state equal to God. Following to this they got punished by speaking different languages, unable to communicate with each other again.

The use of several programming languages does not necessarily need to be a punishment for developers. Java’s attempts to compete on the presentation layer of web applications by technologies and frameworks such as JSPs, Java Server Faces, Struts, Spring MVC and various others never allowed an efficiency comparable to Jython, JRuby or Groovy. And in addition, Java is more than a programming language. At first place, the core of the technology stack is the virtual machine, allowing to run bytecode on any platform that has a Java Virtual Machine developed for it. That you could write Java bytecode compilers for any other language is obvious. And not that the Java platform is to be open sourced, everyone will be free to dig in deep and start working on that.

Today’s keynote and two of the speeches I attended touched this subject. I am very excited about the fact, that the support of some languages (e.g. JRuby, Jython) will be targeted for Java SE 7. Well – besides of the Visual Studio’s ease of use, the openness to several programming languages was maybe the only reason that made us Java developers watching our .NET colleagues full of envy. Unfortunately, I did not find any answers to my main questions today. If the Java programming language can coexist with more dynamic – in some cases more efficient – programming languages: which ones would you choose? How would an ideal multi tier software architecture be mapped to those languages? How does the interoperability look in the real case? And – even if development could take less time – how could you assure that a large project stays maintainable when the complexity of speaking several language arises beneath the complexities that the project causes itself?

Even though I know that certain programming languages are better suited for certain tasks than others I am not a very big fan of a complete freedom of choice within a project. Clear separation of concerns is still needed. In our project, we started using Jython to support the pure Java development. But we try to use it really “only” as a scripting language, which allows us to job control in import, export, aggregation and maintenance tools. The main business functionality is still written in Java. In the future, the advantages of other languages will possibly only count if the whole platform stays homogeneous and maintainable. Otherwise the parable of the Tower of Babel will be applied once again.

But let’s not talk to bad. I am really looking forward to the Dynamically Typed Language Support. Besides of that, the new Java Standard Edition will bring a lot of other exciting features. The ones I am already nervous about:

  • Selective export of classes (how is it at your place? Is everyone in your house your friend?)
  • Java Module System (“superJARs” making packaging easier)
  • JSR 203 NIO.2 (extending non-blocking io)

If you want to know more about this, have a look at Danny Coward’s blog. He is supposed to know which features are going to make the cut.

Of course there have been other interesting topics as well. For example I was impressed by the possibilities that Open ESB will bring to all those who face the challenge of building homogeneous applications in a heterogeneous environment. Not only that a lot of Binding Components are implemented for communicating with external systems and technologies, the monitoring capabilities and the IDE integration (even though currently limited to NetBeans) look promising as well. And a speech about JPOX and spatial extensions covered mechanisms for persisting spatial data. The most helpful pointer of this lecture was however not JPOX itself but the supported Java Topology Suite JTS, which offers a large set of operations on spatial data types. I’m surely going to have a look deeper look at this framework, hoping that it will provide means to geographical search to more complex area shapes than just rectangles and circles.