2.3. Clouds Open The sound and fury of the Java storm caught many of us off-guard. And why not? It came from an unlikely source, was delivered in an unconventional vehicle, and defied conventional wisdom regarding performance of interpreted languages. Other than the language, nothing about Java was conventional at all, including the size of the explosion. In retrospect, you can look back and see just how well it filled a void. Figure 2-3 shows the many ingredients that come together to form the perfect storm. Figure 2-3. Many forces formed the combined ingredients that led to a perfect storm 2.3.1. New Economics The jet stream that powered this storm emerged from a series of standards: TCP/IP, HTTP, URI, and HTML. The Internet gathered steam, and Sun took full advantage with Java. The Internet was everywhere. Java was cool. The Java developers quickly built the API set that would allow developers to code for the Internet, including TCP/IP APIs for communication, and applets for building user interfaces that you could embed in a browser. JDBC allowed database access. The perfect combination formed by the relationship between Netscape Navigator and Java drove each company to new heights. Through Netscape, Sun was able to put Java in front of an incredible number of developers, nearly instantaneously. Through Java, Netscape could showcase smart applications that looked cool, and were simultaneously practical. The Navigator/Java combination seemingly solved the most critical problems of client-server computing: management and distribution. If you could install a browser, you could then automatically distribute any application that you wanted through the browser. Java had the perfect economic conditions for success. Java found an important ally in the bean counters that liked the manageability of the green screen, but the productivity and usability of the fat client. Customers wanted solutions, and Sun realized that Java would give them what they wanted. Sun immediately saw the opportunity it faced. With the open standards around the Internet and the Java language powering it, Solaris on Sun servers would be a compelling, and even hip, alternative. Above all, Java made Sun safe. Because its virtual machine ran in a browser and on many different operating systems, some hard decisions didn't seem so hard. You could try out a deployment scenario. If you didn't like it, you could just move on. The new jet stream was in position to feed power to the growing storm. 2.3.2. C++ on Prozac When Lucene founder Doug Cutting called Java C++ on Prozac, [*] I immediately liked the comparison. Because of its C++ syntax, Java found an impressive waiting community of developers looking for a solution. They moved to add a hip Java, and Internet experience, to their resumes. They stayed because they liked it. Java had most of the benefits of C++, without the problems. The similarities of the languages made it easy to learn. And Java was liberating, for many reasons: [*] TheServerSide.com, "Doug CuttingFounder of Lucene and Nutch," Tech Talk (March 10, 2005); http://www.theserverside.com/talks/videos/DougCutting/interview.tss. Java provided more structure in places that needed it, such as providing interfaces instead of inheritance. Java eliminated the burden of pointers, improving stability and readability. Garbage collection got easier, because the JVM automatically took care of abandoned references. Java allowed a much better packaging mechanism, and simplified the use of libraries. Java cleaned up problems like nested include files and macros. 2.3.3. Architecture The benefits of Java went beyond economics and C++. I can still vaguely remember the first sentence that I saw describing Java. Sun said it was a portable, safe, secure, object-oriented, distributed programming language for the Internet. Those words were all buzzwords of the time. For C++ developers, Java underpinnings made significant strides: The JVM allowed unprecedented portability. Many experts believe that the JVM, and not the language, is the most important feature of Java. Sun marketed this capability brilliantly with the acronym WORA. Java developers the world over recognize those letters as standing for Write Once, Run Anywhere. Java published the byte code specification for the JVM. People who want to build their own JVM or build a language on the existing JVM standard can do so, or even modify byte codes of existing applications. Frameworks like JDO do modify byte code with great success. While C++ allowed unrestricted access to application memory, Java restricted access to one area of the JVM called the sandbox . Even today, you see very few exploitations of Java security. The Java metamodel, made up of the class objects that describe types in Java, allowed sophisticated reflective programming. Though it's a little awkward, the capabilities of Java extend far beyond the basic capabilities of C++. The Java metamodel enables frameworks that increase transparency, like Hibernate (persistence) and Spring (services such as remoting and transactions). The fathers of Java saw the importance of security, and baked it into the language. Java introduced a generation of programmers to the term sandbox , which limited the scope and destructive power of applications. Java had improved packaging and extensibility. You could effectively drop in extensions to Java that transparently added to capabilities of a language. You could use different types of archives to package and distribute code. Both the low-level grunts and high-level architects had something to love. Businesspeople had a motivation to move. At this point, if all else had failed, Java would have been a successful language. But it didn't fail. The winds just kept picking up speed, and the storm started feeding on itself. .4. 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. W ith 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. . TheServerSide.com, "Doug CuttingFounder of Lucene and Nutch," Tech Talk (March 10, 20 05) ; http://www.theserverside.com/talks/videos/DougCutting/interview.tss. Java provided more. 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. 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