Some Possible Enhancements for Java and Java EE The recent discusssion about Java EE and Spring made me think. Actually I find it odd to fight over the programming model used to develop Java applications. Neither Java EE nor Spring will go away - the market shares of both are just too large. At the end everyone involved in the discussion is trying to sell a platform i.e. an application or web server. That product must offer good support for both programming models - and all the others like Scala, Groovy etc. IMHO the programming models have a lot in common now. Spring also covers advanced challenges like Social Media, NoSQL etc - see my older blog post Spring vs. Java EE and Why I Don't Care. So it is not in the field of programming models where innovation is laking. Instead we should focus on improving the platform. So what is it that would really make Java a better platform? Here are some ideas:

• Ever since the invention of Java EE roles like the Application Assember were defined. I never saw a project that followed this workflow. Nowadays there is just an automated process that results in an EAR or even a complete setup including an application server. It is time to face this reality and get rid of these role descriptions. The deployment process is not done that way. Java needs to step away from it.
• Nowadays application server are seldom used to host more than one application. So maybe that offers some possibilities to improve the deployment processes and also the features. If there is just one application on a server anyway the strict isolation between applications Java EE offers does not make that much sense any more.
• It would be good to focus more on deployment during the development process. Applications are much more often deployed into testing or development environments than into production. I am wondering how many CPU and I/O cycles are wasted compressing WARs and JARs and then EARs during a build process - and immediately decompressing them on the web or application server so testing can start. Can't the Java EE standard do something about this? Obviously there are exploded WARs and EARs - but they are not used as often as they should be. Obviously there are tools like JRebel and Play - but what if the complete tool chain including IDEs, build tools, servers etc would support a standard here? What if all of those parties could collaborate to make this work flawlessly? I think we would see quite a boost in developer productivity.
• Often I see applications modularized in several WARs. These modules need to talk to each other. However, there is no easy way to do this. Usually they end up using Web Services or another HTTP based protocol. Compared to a local method call this adds the overhead of HTTP, sockets and marshalling / demarshalling. A possible solution would be OSGi - but that technology is quite complex. The reason to me seems to be the problems around shared class loading. Classes that might represent parameters or return values can be shared between modules. JBoss includes a solution based on JMX that did not support shared classes - so modules need to have the correct classes available. This is the same as for Web Services or the other HTTP protocols. But there is no standard apart from JMX - which is very low level. Can't we have some communication between WARs that in the standard? Maybe based on JMX? Or at least best practices around it?
• Concurrency in languages like Erlang is very different from what we are used to in Java. There are actors that work on a serial list of messages. Concurrency is achieved by multiple actors working in parallel - while the actors themselves are just working serially. This approach is also used by the Scala library Akka on the JVM. In Erlang this approach leads to lots of actors - far more than the number of threads that can be supported on the JVM. If the JVM wants to stay relevant for this model we need proper support for it.
• Actors in Erlang and in Google Dart - they are called Isolates have separated heaps. Those heaps can be independently GC'd - so while one actors spends time doing GC the other can continue to work on messages. By design you end up with less stop-the-world-GC. Maybe we could have a similar concept in Java? This is an extension of the previous suggestion but there might be other options as well. For example each WAR file could have a separate heap.

Those are just some - possibly crazy - ideas. My intention is to focus on making the Java platform better for all of us. And I believe for that the discussion around the future of Java must focus more on the JVM and the infrastructure like web or application server than on programming models. There is quite some innovation in the area of the programming models anyway. For example there are lots and lots of Open Source projects - frameworks and complete languages. But for infrastructure standards are needed - so any server and environment can work with the solution. So that is what the standardization process should focus on. What do you think? I am looking forward to your comments!  ¶ 14:56 1 comments

  Testing: Again As you have probably noticed, the last blog posting Testing Considered Harmful was actually a April Fool's Joke. I believe Test Driven Development is one of the most important innovations in the last years. I have been infected ever since Kent Beck explained JUnit to me. Here are some things adesso does to make TDD a reality:

• We did an internal Code Retreat
• We are sponsoring the Legacy Code Retreat in Berlin.
• Also adesso Mobile Solutions does internal Katas.

The list could go on. So please program - and drive - safely! If you were caught by the April Fool's Joke: I hope you don't mind. If you do: I apologize.  ¶ 16:26 1 comments

  Testing Considered Harmful Unit testing started with JUnit - and was infectious. As you can see in JUnit Test Infected: Programmers Love Writing Tests that was the intention from the very beginning. And so the infection spread.

Nowadays almost all programmers do extensive Unit Tests. And therefore we see problems arising. Instead of thinking about a problem and building a reliable solution developers now just write a test and code away. At one point they get a green bar and consider the job done. But can you build proper software that way? Dijkstra stated in 1972: "If you want more effective programmers, you will discover that they should not waste their time debugging, they should not introduce the bugs to start with." - see Wikiquote. I think the same holds true for testing. So instead of the ever famous code-test-refactor cycle we could use more of the Feynman Way of Solving Problems. If you really think about the solution first you will find you won't need a test. Instead you will actually write correct code from the beginning. You won't need to rely on tests. They cannot show the absence of bugs anyway - as Dijkstra mentioned. In the end you will end up with cleaner code and less code - as there are no tests to be written.

This principle can be applied to other areas as well. I think one reason why there are so many car accidents are the very effective brakes cars have now. If we had less effective brakes people would think about possible problems beforehand, drive more carefully - and we would have less accidents.

  ¶ 13:04 5 comments