Drinking from the Java firehose: A manager’s primer to Java projects

Updated (again) based on comments from helpful readers

Recently, I have discovered that managers who come into Java projects are totally unprepared for the reality that they face. Some programming environments have been basically stable for decades. COBOL has been stable from before most of us were born! But Java is different.

There are a few things you need to understand about Java. First of all, Java is not a programming language. It is what many call a technology ecosystem. It consists of the technical foundations in the Java language and virtual machine, but also of a growing set of library functionality in the Java platform itself, and made available through open-source projects. Last, and perhaps, most important, there are strong cultural movements within the Java space. Many developers, and especially brilliant developers, will be committed to one or more of these cultural movements. The cultural movements, like any cultural movements are not static.

Like it or not, Java has been through four radically different phases in it’s short lifespan. For those who haven’t paid attention to the programming environment, here is a short recap:

Era one: The applet. When Java first was created, people thought it would be predominately a client side technology. This turned out not to be the case, although the client side properties of the environment are still in use and still evolving.

Era two: Moving to the server. In the late nineties, people started experimenting with using Java for server applications. Compared to the contemporary C-based applications, productivity improved enormously, and Java quickly gained a foothold in this space. Java was not a perfect match for the job, but the respite from the memory management problems that still plague C programs lead to increased productivity.

A lot of custom solutions were developed in this era, and some of them, like ATG Dynamo created their own standards. This era was productive, but there was a lot of waste as most in-house development teams had to create their own frameworks, many of which were bad.

Era three: The time of J2EE containers. Around the turn of the millenium, most of the big actors in the Java space had recognized the need to standardize on technologies beyond the basic Java platform to raise the platform to a new level. The result of this standardization was J2EE. J2EE in its early incarnations was a bit of a hit-and-miss. There were two issues: For many of the problems J2EE tried to solve, there existed no knowledge of the solutions needed at the time. To solve things like transaction management, software developers were forced to jump through many hoops, simply because the ideas on how to solve these problems were not available at the time. Second, many of the ideas in J2EE were standardized before they were mature and were used beyond their capabilities.

Deploying applications in J2EE Containers solved a lot of problems that previously had to be solved with error-prone, custom developed solutions. But as the use of J2EE spread, the technology was increasingly used for applications were it was not intended to be used.

In some ways, early J2EE can be viewed as a step back. The predictability of the Java development field dropped in this period as projects risked their deliveries in complex solutions from software infrastructure companies like BEA, Sun, and IBM. And the field reacted. Many had doubts about the direction J2EE was headed. In 2002/2003, Rod Johnson published “Expert One-on-one J2EE Design and Development.” Behind this prosaic title lurked a dissenting view. The undercurrent of dissent grew, largely unnoticed by the big software vendors.

In 2004, Bruce Tate published the article “Don’t Make me Eat the Elephant Again,” in Java.net and it was like a dam broke. One of Java’s well-respected gurus expressed deep dissatisfaction with where Java was headed, voicing what many had felt for a long time. Tate’s article marked the beginning of the end for the third era.

Era four: Domain-driven design. More than anything, the new wave within the Java ecosystem was that of a return to old object-oriented ideas. The system should be structured in the same way as the problem domain. All technologies of the fourth era build on the idea that technology that is visible is bad. The problems J2EE tried to solve have all been solved, but with tools that were not available at the time. The poster child of this era is the Spring framework which is the continuation of the framework Rod Johnson described in “Expert One-on-one J2EE Design and Development”.

We are in this era now. The final end of the third era was JavaOne 2005. The hour of the death of old-school J2EE can be pinned down to an exact moment in time: The leading J2EE vendor BEA announced that their new direction would build on the Spring open source framework. Rod Johnson entered the scene to talk about the details, but he needed not do much more than confirm the announcement. The reaction from the audience was unanimous: Old-school J2EE as of that moment was dead. The current version of J2EE has already embraced the new paradigm.

Will it end here? There is no reason to think so. The trends I have outlined show the large picture. When you observe Java at a more detailed level, this large picture is made up of myriads of open source projects running in similar or different directions. New projects are spawned frequently, and many existing projects are competing for the minds and hearts of developers and architects.

And it matters! As we saw with old-school J2EE, Java has for many projects been a step back in productivity. Development projects are given a staggering array of tools to work with, and many of these tools don’t work very well. EJB, the staple of old-school J2EE has been the bane of many projects. And other technologies will play this role in the future.

As a manager, you might find this situation unacceptable. In that case, my recommendation to you is simple: Java is not the choice for you. And that is all right, too. By the way, you won’t do much better with .NET or Ruby, the newest kid on the block, with this regard! If you want a stable technology, your only option is the “stale” old technologies of yore: C/C++, COBOL, Fortran.

About Johannes Brodwall

Johannes is Principal Software Engineer in SopraSteria. In his spare time he likes to coach teams and developers on better coding, collaboration, planning and product understanding.
This entry was posted in Software Development. Bookmark the permalink.