Storm Warnings

To know where Java is going, you've got to know where it came from. You need to remember the conditions that caused us to leave the existing dominant languages in droves. You must understand the economic forces that drove the revolution. And you cannot forget the sentiment of the time that pried so many of us away from C++, and other programming languages for the Internet.

In 1995, Java was working its way through the labs of Sun Microsystems, unborn. Sun garnered attention as a champion of standards, and for bringing Unix out of the academic ghetto, but it was not a major player in development environments or programming languages. Frustrations, driven by economics but stemming from inadequacies in programming languages and programming models, rippled through the community in another kind of gathering storm.

Economics of Client-Server Computing

Frustration with long development cycles and inadequate user interfaces drove many companies to move off of mainframe computers. At first, the movement amounted to nothing more than a trickle. As the cost-cutting financial offices measured the software and hardware costs of IBM versus Microsoft on Intel, the trickle became a flood.

But the wave of migrating customers did not consider all the costs. The rapid movements from mainframes to Intel servers drove the first tsunami of chaos because the client-server movement hid significant costs:

  • Management costs skyrocketed. It was too difficult to deploy tiny changes to hundreds of fat clients. Technologists could not figure out how to maintain the many desktop applications and frameworks necessary to make the architecture go.

  • Many customers became increasingly wary of a gathering Microsoft monopoly.

  • The tools of the day made it easy to get started, but did not handle complexity well. Typical customers simply could not make them scale.

Decision makers were caught between the pragmatic approach of a centrally managed solution and the adaptability and lower costs of Intel-based servers. They waited for a better solution, and the clouds darkened.


While developers struggled with C++, Microsoft planned to hammer the final nails in the coffin of OS/2, a competing operating system that it once created, but abandoned to IBM. So Microsoft grew in stature and influence, and it learned to cater to developers very well. Companies like IBM dominated the infrastructure groups (called IT for information technology). Microsoft didn't care. It went straight to the lines of business that used IT applications. Offering quick turnaround time with Excel macros and Visual Basic applications, it stole a large part of development mindshare across the world. Screw IT. The line of business could build the applications itself, and involve IT only after the fact, to clean up the resulting mess.

Microsoft grew, and some of the same people that lauded the end of OS/2 began to grow wary. Microsoft's dominance was a double-edged sword. You didn't have the problem of navigating through a bewildering sea of products and solutions. You didn't have the oppressive integration problems of making multiple vendors work together. You just pitched all the competition and looked to Redmond for the answers. But you had to be willing to give up other choices, and you had to live with the answers that you got. An evolving API stack moved quickly through OLE to COM to COM+. Operating systems' APIs changed from Win to Win32. New flavors and options emerged with new operating systems.

Microsoft captured a core of diligent developers more or less completely. Others bought some of the message, but cast a wary eye northwest. A growing core of developers looked openly for alternatives, like Novell's Netware or various Unix-based alternatives. Individual products, like Netscape Navigator, emerged to compete with Microsoft. The gathering storm seemed imminent.

The Internet

Thunder began to rumble in the distance, in the form of a rapidly growing Internet. In 1995, most people used the Internet to share static documents. Most dynamic sites were powered by command-line scripts through an interface called Common Gateway Interface (CGI) , in languages like Perl . That approach didn't seem to scale very well. While Perl was a very efficient language, applications were hard to read and difficult to maintain. And CGI started a new shell for each request, which proved prohibitively expensive. For enterprise computing, the Internet had the reputation of a limited toy, outside of scientific and academic communities.

In the mainstream, Microsoft seemed to miss the significance of the Internet, but many of the brightest minds in other places looked for ways to combine forces, to defang the dominant menace in the northwest. Market leaders always strive to protect their base through proprietary products and frameworks. Everyone else loves standards. IBM, which once built an empire on proprietary models encompassing hardware, software, and services, suddenly did an about-face, embracing every standard that it could find. It Internet-enabled its main products like its DB2 database through a product like and its mainframe-based transaction engine through web-enabled emulators. Other companies also built better servers, and more efficient ways to share dynamic content. Netscape rose to prominence with a popular web browser. It looked for a way to share applications with documents, and found the answer in a fledgling language, recently renamed from Oak to Java. It started to rain.

Object Orientation

Object-oriented systems support three ideas that you now take for granted: encapsulation, inheritance, and polymorphism. For many years, the industry had been working toward object-oriented programming (OOP) . They tried several times, but it never quite came together. The first major attempt was with Smalltalk . It was a highly productive environment, but when less-experienced developers tried to push it beyond its natural borders, they had problems. Initially, the early hype around OOP was counterproductive. It positioned OO languages as tools to achieve reuse, and suggested that inexperienced OOP teams could be many times more productive than their procedural counterparts.

Object-oriented software has the potential to be much less complex than procedural programming, but it takes some time to build the expertise to recognize patterns and to layer OO software in a way that makes sense. It also took the industry time to deliver educated developers. Though it now looks like OOP exploded overnight, that's not the case at all. After some early failures with languages like Smalltalk, systems programmers went back to the drawing board to deliver a less-ambitious version of an OOP language, and worked on delivering OOP concepts in a more limited way, as you see in Figure 2-1:

  1. Smalltalk, invented in 1971, was successful as a research project, but did not experience the same success commercially.

  2. In the late 1970s and into the 1980s, APIs for things like presentation systems began to organize the interfaces into logical actions, called events, around objects, like windows and controls.

  3. In 1980, the United States Department of Defense commissioned the Ada programming language, which offered some of the features of OOP, like encapsulation and inheritance.

  4. Companies like IBM and Microsoft delivered toolkits to let their users express object-oriented ideas in procedural languages. The most notable were IBM's System Object Model and Microsoft's Component Object Model.

  5. C++ let C developers use C procedurally, and also develop object-oriented applications, side by side.

  6. Java was invented, combining many of the inventions along the way.

Figure 2-1. This timeline shows the slow commercial acceptance of object-oriented programming

Unfortunately, C++ came with its own sorts of problems.