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.
Comments:
[Øyvind Wergeland] - Feb 15, 2007
A good historical perspective, Johannes, but I lack suggestions for improvement! It’s really not sufficient to say that .Net is not any better. Some may even decide .Net is better, since it’s completely controlled by one company.
Johannes Brodwall - Feb 15, 2007
Hi, Øyvind. Good point. Maybe suggestions for improvement could be a good subject for a new article. Maybe you could even write it. :-)
[Geir Hedemark] - Feb 19, 2007
Good article, Johannes. Keep up the good work.
I halfway agree with Øyvind. The article would be “complete” in a totally bogus aesthetic sense if it also tried to give pointers to what is happening today. There sure is enough to choose from: AOP, testing moving from unit testing to subsystem-style tests (?), the JCP dying, “developer” roles starting to become less technology oriented and more people-interaction oriented in some ways (and not in others, since there is such a bewildering amount of technologies and frameworks to keep up with) …
Write it myself? Hum, I already have three projects that aren’t moving.
[Kukenspeil] - Mar 9, 2007
J2EE was horrible from the start. It’s a great example of what happens all too often in software development. Good solutions exist, someone ignores all the hard lessons learned making it and goes ahead and makes something new that is full of problems.
Look at CORBA - don’t laugh yet - especially if you don’t have any real experience with 2.x and POA. Sure, it had several problems, but look how J2EE basically took all that was bad from it, removed all the powerful extensibility, and everyone thought it was something brand new and “Incredible! Look how I can call remote methods!” Woo hoo. And then came SOAP, a horribly broken standard - SOAP had serious technical shortcomings, but, as a market strategy, it was a masterstroke. Again, people with no real understand of distributed systems working in areas they have no business doing.
It happens all the time. Something works. Then someone re-invents it without looking at the previous work and ends up with something that really could have been great, but turned out to be garbage in the end (and lots of disastorous projects based on it).
Johannes Brodwall - Feb 19, 2007
Alright, I hear you. I’ll add a follow-up of this article to my backlog. But you guys better read it!
[undefined] - May 5, 2011
The leading J2EE vendor BEA appear that their new administration would body on the Spring accessible antecedent framework.
NABH - May 28, 2011
I really appreciate your post and you explain each and every point very well.Thanks for sharing this information.And I’ll love to read your next post too. Regards: NABH