2.6. Moving Ahead We may never again see a perfect storm like the one that ushered in Java. You shouldn't look for one. Instead, you should learn from the success of Java, and start to understand the factors that led to its success. Minimally, I believe the next commercially successful programming language will need to satisfy four major criteria: It will need to establish a significant community. You won't see broad adoption unless the adopter can achieve relative safety. It will need to be portable. Java's virtual machine has raised the bar for languages that follow. Some economic incentive must justify the movement. Currently, productivity to me looks like the logical economic force, but others may be lurking out there, like wireless computing or data search. It will need demonstrable technical advantages. This is actually the least important of the major criteria. I don't think most of us can possibly thoroughly understand the success of Java. It's easy to overestimate the role of the language and to underestimate the importance of the JVM and the community. In the next chapter, we'll continue to look at the crown jewels of Java in more detail, or the foundation for the most successful programming language ever. 3.1. Language and JVM Design In 1996, the JVM represented a significant departure from traditional thinking. Overwhelmingly, organizations exclusively used high-performance compiled languages on th e server side. Developers patched on security instead of baking it in from the beginning. And vendors attempted to achieve portability by building extensive libraries at a very high level. Instead of driving on this well-traveled road, they reached for the steering wheel with both hands and threw all of their momentum to the side, swerving aggressively into unpaved, uncharted territory. 3.1.1. Portability In the early and mid-1990s, many in the industry were just starting to think about portability. In particular, I vividly remember working on object-oriented technologies at IBM. The project, called System Object Model (SOM) , emerged from a research project that formed the foundation for OS/2's groundbreaking object-oriented desktop, and some experimental technologies that never made it out of the lab. The goals of SOM were ambitious: we wanted to build a common object model underneath as many object-oriented languages as possible. Then, we could develop a common suite of libraries that developers could use across languages and operating systems. Over time, we discovered the difficulties of porting a technology across many operating systems and programming languages. Of course, the technical challenges were daunting, but the political challenges turned out to be insurmountable. We immediately discarded the Smalltalk-like integrated development machine and the virtual machine, concepts introduced by Smalltalk and Lisp, because a VM couldn't possibly be fast enough. We weren't alone in our approach. Many C++-driven companies tried to build programming libraries across many languages. Few succeeded. The Java approach, shown in Figure 3-1, is fundamentally different. Java's virtual machine simply redefines the machine, providing a lower-level, firmer foundation for portability. Java designers bet that they could overcome performance concerns. It was not a new idea; nor was it a popular one. Over time, they proved to be rightjust-in-time compilers im proved performance so that the overhead of the JVM became acceptable, and even rivaled compiled languages. The virtual machine, built into Netscape Navigator, proved to be a fantastic launching pad for the Java platform. It's enabled Java to extend into the realm of mobile devices, application servers, and countless software products. When all is said and done, popularizing the idea of the VM may be the most important technical contribution of Java. Figure 3-1. The JVM took a different approach to performance, security, and portability; most programming languages use compilers to bind them to individual machines, but Java simply redefined the machine Java offers a rich set of interfaces that often delve into operating system territory. Under the covers, Java either implements this type of functionality from scratch, or just calls the native features underneath. Either way, Java developers can count on a rich, consistent library wherever they are. In almost 10 years of software development, though I've seen minor annoyances, I've rarely encountered major problems in porting from one operating system to another. In the end, Sun didn't invent the VM, but Sun did make the VM popular. Java portability is not without its problems. Graphical user interfaces pose a particularly sticky problem: is it important to maintain portability even at the expense of consistency with the operating system underneath? For example, Swing components, not operating system components, implement the menus in a Java GUI. This arrangement causes problems on the Apple platforms, where the menu for an application traditionally is implemented as a single bar on top of the desktop, instead of the separate menu per application that you commonly see on Unix and Windows. Other notable differences, like security and threading, show up differently on different operating systems. Even filenames can present problems, where having two classes called Account.txt and account.txt would be legal on Unix but not on Windows. But for the most part, Java handles portability very well. 3.1.2. Security In the age of the Internet, security takes on an entirely new level of importance. Any ubiquitous technology must deal with it, and deal with it well. Sun's engineers recognized this and dealt with the threat from the very beginning. They were fortunate to have the virtual machine to simplify the problem. Unfortunately, other vendors were not so lucky. 3.1.2.1. Changing threats Microsoft Windows has been besieged with security problems. The Internet and email make a perfect medium for viruses to spread with frightening speed. Dominant market share, combined with huge holes in Windows and its browsers, make them the target of most Internet viruses. In fact, blatant security holes in Windows have led to a whole new type of security threat, called adware . Five years ago, it didn't exist. Today, I found 6 million Google hits on the term! As you probably know, adware seeks to exploit vulnerabilities in Internet Explorer to drive up traffic to certain sites and learn about the activities of a user. Most analysts believe that adware has usurped the virus as the top security threat, because these often malicious applications spread so broadly and so quickly. They often lower security settings to enable other types of more serious attacks. C and C++ also present enormous security concerns. C++ applications have full access to operating system APIs and unrestricted access to every byte in their dedicated memory space. Many versions of the Windows operating system cannot protect one application from another. Given the Internet as the ultimate delivery vehicle through components like ActiveX you can quickly develop unacceptable levels of risk. Given the sensitivity of the data that many of us keep on our machines, these threats take on a more serious dimension. 3.1.2.2. Remedies in Java The virtual machine gave Java designers a chance to have a secure foundation on an insecure platform. The advantages deal primarily with the restricted sandbox: Since Sun designed Java from the ground up, it did not need to worry about patching legacy security problems, like those you might find in Unix and Windows. (These are operating systems, but they also are application platforms.) Java, the language and the JVM, grew up after the Internet, so the inventors had the benefit of knowing what types of attacks might occur. Java has a security manager built in at the lowest level, to enforce security policy and to control access to low-level system priorities. The JVM provides a limited sandbox for a group of Java applications, so a malicious or buggy application can't do as much damage as, say, a C++ application might. Because there's no pointer arithmetic, and because Java has strong runtime typing, the JVM knows precisely where a reference is pointing. The JVM can better restrict an application's access to its own memory. Most Java security attacks try to defeat type safety first. The relative dearth of Java security breaches represents perhaps the biggest compliment to Java's founders. It's just a tough environment for viruses, or adware, or security attacks. The base operating system makes a much riper target. 3.1.3. Moving Forward The idea of the virtual machine is here to stay. The intermediate virtual machine transforms the basic problems of portability, security, and deployment from nearly unsolvable to routine. If the virtual machine adapts to accept dynamic languages, the JVM will probably be the deployment platform of choice for the foreseeable future. If not, a new virtual machine will need to emerge. But the problem of portability has proven to be a difficult one. Jython , a dynamic language based on Python but running in the JVM, never quite reached the expected level of prominence in the Python community, particularly because it wasn't fas t enough, and partly because the Python community never embraced it. A project to implement Ruby on the JVM, called JRuby , has similar difficulties so far. Still, many analysts predict that the JVM will live long beyond the time that the last Java developer writes the last, lonely line of code. I'm convinced that the next major programming language will be much more dynamic. It's pretty clear that newer dynamic languages will also have the benefit of a virtual machine. If the lax sales of security books and Windows alternatives are any indication, security just doesn't mean as much to us as we think it does. Still, alternatives may have the benefit of Java's virtual machine. If not, cross your fingers. The next major alternative may not be as secure as Java, because most language designers don't start by building in security first. Until we fix fundamental holes in our processes, our thinking, and our operating systems, security in the languages built on top won't matter much. . quite reached the expected level of prominence in the Python community, particularly because it wasn't fas t enough, and partly because the Python community never embraced it. A project to. the early and mid-1990s, many in the industry were just starting to think about portability. In particular, I vividly remember working on object-oriented technologies at IBM. The project, called. the VM popular. Java portability is not without its problems. Graphical user interfaces pose a particularly sticky problem: is it important to maintain portability even at the expense of consistency