Fury Unleashed

Applets captured the imagination of programmers everywhere. They solved the deployment problem, they were cool, and they were easy to build. We're only now finding a set of technologies, based on the ugly and often objectionable JavaScript language, that can build rich content for the Web as well as Java did. Still, applets started to wane.

Even today, I think that applets represent a powerful idea, but they fizzled out for many reasons. The Netscape browser's JVM was buggy and unpredictable. Further, with such a rapidly evolving language, applets presented many of the same problems that client-server computing did. You may not have to maintain applications, but you still had to maintain the browser. After you'd deployed a few Java applets, you had to worry about keeping the right version of the browser on the desktop. As the size of the JVM grew, it became less and less likely that you could install a JVM remotely. Even if you could, Java versions came out often enough, and were different enough, that new applications frequently needed to materialize. But a few mad scientists at Sun were up to the challenge again.

James Duncan Davidson: Why Java Won

Author of The Rise of Java

James Duncan Davidson is a freelance computer programmer, photographer, author, and speaker. He invented both Ant and Tomcat, two of the most successful Java open source projects ever. His persistent efforts at Sun led to open sourcing both projects. He is now one of the best-selling authors of Apple operating system books.

What do you like best about Java?

JDD: At the time, it seemed like a really good idea. Mostly, for what Java was designed for, they got it right. Of course, it's a strongly typed language, which for some purposes is great, and other purposes not.

Why do you think it's so successful?

JDD: I think it comes down to the fact that server-side programming in Perl and the like was inefficient, and server-side programming in C and C++ was hard. Java, and servlets in particular, busted open a door for Java where it could really take root.

I may be biased because of my involvement with servlets, but Java without the server side wasn't that interesting. It still isn't. Sure, J2ME is on bazillions of mobile devices, but there aren't that many apps thereand the APIs there are limited unless you actually make the cell phone.

What don't you like?

JDD: Strong typing. Reliance on APIs rather than frameworks. That's a subtle but important distinction. The increasing complexity of even basic APIs. For example, you can't just write a servlet anymore, you have to write a servlet, then edit an XML file. They're killing off the approachability that helped servlets get off the ground. With it, the rest of the server stack gets more and more difficult to work with.

And reliance on tools to make it easy is a cop-out.

As well, I don't like the massive monolithic approach to "Editions." Most people don't need J2EE. They need a web container. End of story.

I also don't like the incredible jump to complexity that Java seems to engender in people. No other platform has grown as fast and as elephantine as Java. Other platforms are as capable, but are 5% of the size. There's an architectural reason for that. And, really, Java the language isn't at fault. Java the class libraries are. They encourage massively inefficient design. Ever see a stack trace come out of a JSP/servlet/J2EE container? The 44 pages of stack call should be a hint.

How does Java hold you back?

JDD: It doesn't. I don't use Java much anymore. I use other languages like Python, Ruby, and ObjC.

And I wish that more tools would just remember the lessons of Unix: small pieces loosely joined. There is no one bersolution, and at the end of the day, if you can take two tools and pipe stuff between them, you have a more powerful and flexible solution than any monolithic beast. And one in which users can discover uses far more powerful than you can imagine.

What emerging alternatives make sense to you, if any?

JDD: Ruby on Rails has picked up an amazing amount of traction for server-side stuff. If you need to slush around mass amounts of content, there are content databases (like MarkLogic) that are interesting that use XQuery to work with the stuff inside. On the GUI front, well, Java wasn't a contender, so everything is already an alternative.

What would prompt (or did prompt) you to move away from Java, or .NET?

JDD: I shifted focus into the GUI application space. Java and GUIs don't mix. Friends don't let friends Swing.


As applets were winding down on the client side, the server side was just getting going. Servlets gave Java developers a way to write applications that would run in the browser. An application would get a request over HTTP, and build a plain web page, with no Java, that would return to the client. Since the web pages were built server side, they could take dynamic content, like the results of database queries, back down to the client. So-called web-based applications finally delivered the goods: now, you could run enterprise applications on a client. You'd only have to deploy them on a server.

It didn't take long to understand that the clients could be within the firewalls of a company, but they didn't have to be. Since people everywhere had Internet access, it opened up the possibility of selling a whole new kind of product: information. The new economy was born. At least in part, it was powered by Java, and the companies that built the servers, databases, and software. Start-up companies sprung up to take advantage of this opportunity. Enormous paper wealth was created. Venture capitalists funded good ideas and bad. A drive for customers fed the fury of the storm. The rules were simple: he who gets the most customers wins. Start-ups were often willing to spend far more to acquire a customer than that customer could possibly generate.

Real wealth was created, too. Companies like eBay and Amazon fueled a new kind of economy without buildings or walls. This new sophisticated commerce drove a new need for new tools. Sun, Oracle, BEA, and IBM worked on new standards to enable enterprise on the Web. IBM coined the term e-business to stand for a new, powerful way to serve customers.


J2EE, or Java's enterprise edition, included many new ways to connect to the enterprise. Under great expectations, the Enterprise JavaBeans? (EJB) spec emerged to add a rich set of tools that would let you program distributed, transactional, secure, and persistent applications, without coding those services yourself. Clustering features enabled good scalability and reliability. These features let major companies move into the Java world without reservation.

Though EJB never quite fulfilled its promise, the specification is an extraordinary example of how an idea can energize a community. The specifications behind EJB are tremendously important, and for the most part, are factored very well. Java thrived on the server side and was off to the races again.

Industry Standards

It's tough to unite through common interests. Java never could have thrived to the extent that it has with only Sun behind it. Some unifying force needed to hold them together. A common enemy in Microsoft was the perfect catalyst.

Software is more prone to monopolies than most other industries because software moves fast and obsolescence can devastate a company. For this reason, market share tends to favor the market leader heavily. So it stands to reason that market leaders love to be proprietary. They can increase market share through their leadership position, and lock their customers in to extend the monopoly. Certainly, Microsoft is not the first company to use this strategy. IBM was incredibly proficient at this game.

If being proprietary works for the market leader, the followers need open standards to level the playing field. If you can't build dominant share, you can lend your customer safety by creating partnerships and embracing a common standard. In this way, your customers are not nearly as afraid of obsolescence.

The Unix operating system helped smaller proprietary server vendors survive for years in the face of market dominance by Intel and Microsoft. After supporting proprietary systems aggressively for decades, IBM is embracing open standards in many areas, including relational databases (where it trails Oracle), operating systems (where it made mainframes a much safer solution with the open source Linux environment), and now, with Java.

IBM is now the most prevalent Java developer. It claims to have more Java developers than any other company, including Sun. I believe IBM. It has been working to catch BEA's Web Logic application server for years, and has now passed BEA. I'd expect IBM to exercise its dominance to build in proprietary features that interest its customers. I would also expect IBM to take a harder line with the Java Community Process (JCP), to force through changes that it finds most interesting. Failing that, it may leave the JCP and seek another avenue for establishing standards. If it does, this strategy should not come as a surprise. It's the prerogative of the market leader, and the dance goes on.

Open Source

Many open source communities look down on Java. That's ironic, because Java has more thriving open source software than any of the alternatives. When you build something that's both hip and popular, people want to play with it and share their creations. Add a massive community that's stretching a language in unexpected ways, and you need only to stand back and watch interesting things happen. And boy, did Java open source happen.

At first, Sun resisted the open source community . Sun developer, James Duncan Davidson, worked to change that. He built two of the most important Java applications ever in Tomcat (that showcased servlets) and Ant (that builds nearly all Java applications today). He then pushed them out to the open source community.

The typical open source development cycle works as follows (and shown in Figure 2-4):

  1. Build. Once Java geeks solve a problem often enough, they often build the solution with their own resources. Sometimes, they're solving business problems. Other times, they're just having fun.

  2. Use. Users then exercise the solution. Those that don't get used atrophy and die.

  3. Refine. Users then refine the solution, to match their requirements.

  4. Contribute. Users then contribute to the project, either with feedback or with code enhancements. They are willing to do so, because they won't have to maintain enhancements.

Figure 2-4. The open source feedback cycle is tremendously important to Java

In this way, some fantastic frameworks evolved to form the foundation of Java web-based development. Today, you'd be hard-pressed to find a major company that does not take advantage of open source software. These solutions are pervasive in the Java community:

  • Developers use JUnit to build automated test cases, which run with every build.

  • IT shops run Apache Web Server as their preferred web server.

  • Customers deploy many lightweight applications with Tomcat as a servlet container.

  • Developers look to Hibernate for persistence.

  • Web-based developers use Struts to separate model, view, and controller layers of their applications.

  • Programmers worldwide use Ant to build applications.

  • Other frameworks like Lucene (search), Spring (infrastructure), Tapestry (web-based component design), JBoss (J2EE), and many others seem to be gaining popularity as well.

You might think that open source development would threaten software companies that build software, but the converse is true. Open source has served Java very well. Innovation in the open source community keeps tremendous pressure on software companies to keep up. That's healthy. If you're providing real value, you'll thrive. If you try to live off of technology that's well understood and popular, you'll die. Open source software raises the bar of what you've got to do to make money. IBM has dealt with the pressure well. BEA is withering under the heat, with IBM above and JBoss below. Either you will see BEA innovate, or an open source framework like JBoss, Geronimo, or Spring will catch it on the low end. Either way, you'll win.

You could even argue that open source software is driving the most important innovation in the Java space. Open source is driving adoption and implementation of integrated development environments, aspect-oriented programming, lightweight containers, persistence, unit testing, and the best web MVC frameworks. It's driving the actions of the largest and most powerful Java vendors. That's an incredible testament to the might of the Java open source community.