O''''Reilly Network For Information About''''s Book part 7 pdf

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.