Mes Top 5 Ouvrages
Termes les plus recherchés
Table of Contents
About the Author
Learning I ava
First Edition May 2000
ISBN: 1-56592-718-4, 722 pages
For programmers either just migrating to Java or already working
steadily in the forefront of Java development, Learning Java gives a
clear, systematic overview of the Java 2 Standard Edition. It covers
the essentials of hot topics like Swing and JFC; describes new tools
for signing applets; and shows how to write networked clients and
servers, servlets, and JavaBeans as state-of-the-art user interfaces.
Includes a CD-ROM containing example code and JBuilder for
Windows and Solaris.
Learning I ava
Using This Book
Conventions Used in This Book
How to Contact Us
1. Yet Another Language?
1.1 Enter I ava
1.2 A Virtual Machine
1.3 lava Compared with Other Languages
1.4 Safety of Design
1.5 Safety of I mplementation
1.6 Application and User-Level Security
1.7 lava and the World Wide Web
1.8 lava as a General Application Language
1.9 A lava Road Map
2. A First Application
2.1 Hello! aval
2.2 Hellolava2: The Sequel
2.3 Hellolava3: The Button Strikes!
2.4 Hellolava4: Netscape's Revenge
3. Tools of the Trade
3.1 The I ava I nterpreter
3.2 Policy Files
3.3 The Class Path
3.4 The I ava Compiler
3.5 I ava Archive ( I AR) Files
4. The lava Language
4.1 Text Encoding
4.4 Statements and Expressions
5. Objects in I ava
5.3 Object Creation
5.4 Object Destruction
6. Relationships Among Classes
6.1 Subclassing and Inheritance
6.2 I nterfaces
6.3 Packages and Compilation Units
6.4 Visibility of Variables and Methods
6.5 Arrays and the Class Hierarchy
6.6 I nner Classes
7. Working with Objects and Classes
7.1 The Object Class
7.2 The Class Class
8.1 I ntroducing Threads
8.2 Threads in Applets
8.4 Scheduling and Priority
8.5 Thread Groups
9. Basic Utility Classes
9.2 Math Utilities
9.7 The Security Manager
9.8 I nternationalization
10. I nput/ Output Facilities
10.4 Data Compression
11. Network Programming with Sockets and RMI
11.2 Datagram Sockets
11.3 Simple Serialized Object Protocols
11.4 Remote Method Invocation (RMI)
12. Programming for the Web
12.1 Uniform Resource Locators (URLs)
12.2 The URL Class
12.3 Web Browsers and Handlers
12.4 Talking to CGI Programs and Servlets
12.5 Implementing Servlets
13.4 Event Summary
13.5 Multithreading in Swing
14. Using Swing Components
14.1 Buttons and Labels
14.2 Checkboxes and Radio Buttons
14.3 Lists and Combo Boxes
14.6 The PopupMenu Class
14.7 The IScrollPane Class
14.8 The I SplitPane Class
14.9 The ITabbedPane Class
14.10 Scrollbars and Sliders
15. More Swing Components
15.1 Text Components
15.5 Pluggable Look-and-Feel
15.6 Creating Custom Components
16. Layout Managers
16.7 Nonstandard Layout Managers
16.8 Absolute Positioning
17. Drawing with the 2D API
17.1 The Big Picture
17.2 The Rendering Pipeline
17.3 A Quick Tour of I ava 2D
17.4 Filling Shapes
17.5 Stroking Shape Outlines
17.6 Using Fonts
17.7 Displaying Images
17.8 Using Drawing Techniques
18. Working with Images and Other Media
18.1 Implementing an I maqeObserver
18.2 Using a MediaTracker
18.3 Producing Image Data
18.4 Filtering Image Data
18.5 Working with Audio
18.6 Working with Movies
19. I ava Beans
19.1 What's a Bean?
19.2 Building Beans
19.3 Hand-Coding with Beans
19.4 Putting Reflection to Work
19.5 BeanContext and BeanContextServices
19.6 The I ava Activation Framework
19.7 Enterprise lavaBeans
20.1 The I Applet Class
20.2 The <APPLET> Tag
20.3 Using the lava Plug-in
20.4 Using Digital Signatures
A. Content and Protocol Handlers
A.l Writing a Content Handler
A. 2 Writing a Protocol Handler
B. BeanShell: Simple lava Scripting
B. l Running BeanShell
B.2 I ava Statements and Expressions
B.3 BeanShell Commands
B.4 Scripted Methods and Objects
B.5 Learning More ■ ■ ■
This book is about the Java™ language and programming environment. If you've been at all
active on the Internet in the past few years, you've heard a lot about Java. It's one of the most
exciting developments in the history of the Internet, rivaling the creation of the World Wide Web.
Java became the darling of the Internet programming community as soon as the alpha version
was released. Immediately, thousands of people were writing Java applets to add to their web
pages. Interest in Java only grew with time, and support for Java in Netscape Navigator
guaranteed it would be a permanent part of the Net scene.
What, then, is Java? Java is a network programming language that was developed by Sun
Microsystems. It's already in widespread use for creating animated and interactive web pages.
However, this is only the start. The Java language and environment are rich enough to support
entirely new kinds of applications, like dynamically extensible browsers and mobile agents. There
are entirely new kinds of computer platforms being developed around Java (handheld devices
and network computers) that download all their software over the network. In the coming years,
we'll see what Java is capable of doing; fancy web pages are fun and interesting, but they
certainly aren't the end of the story. If Java is successful (and that isn't a foregone conclusion), it
could change the way we think about computing in fundamental ways.
This book gives you a head start on a lot of Java fundamentals. Learning Java attempts to live up
to its name by mapping out the Java language, its class libraries, programming techniques, and
idioms. We'll dig deep into interesting areas and at least scratch the surface of the rest. Other
titles in the O'Reilly & Associates Java Series will pick up where we leave off and provide more
comprehensive information on specific areas and applications of Java.
Whenever possible, we'll provide meaningful, realistic examples and avoid cataloging features.
The examples are simple but hint at what can be done. We won't be developing the next great
"killer app" in these pages, but we hope to give you a starting point for many hours of
experimentation and tinkering that will lead you to learn more on your own.
This book, Learning Java, is actually the third edition — reworked and retitled — of O'Reilly's
popular Exploring Java. We've de-emphasized web-page applets this time around, reflecting their
diminishing role over the past couple of years in creating "smart" web pages. Other technologies
the server side.
We cover the most interesting features of Sun's newest release of Java, officially called Java 2
SDK Version 1.3. (In the old days, it would have been called "JDK," for "Java development kit;"
we use the newer, officially blessed "SDK," for "software development kit," throughout this book.)
These features include servlets, the Java Media Framework ( JMF), timers, the collections, 2D
graphics, and image-processing APIs, using the Java security manager, and using Java 2 signed
Another important change, though not as recent as SDK 1 .3, is the ascendancy of Java Swing as
the main API for graphical user interface programming. Much of the material relating to AWT,
Java's original GUI programming interface, has been recast and updated to use Swing facilities.
This book is for computer professionals, students, technical people, and Finnish hackers. It's for
everyone who has a need for hands-on experience with the Java language with an eye toward
building real applications. This book could also be considered a crash course in object-oriented
programming; as you learn about Java, you'll also learn a powerful and practical approach to
object-oriented software development.
Superficially, Java looks like C or C++, so you'll be in the best position to use this book if you've
some experience with one of these languages. If you do not, you might want to refer to books like
O'Reilly's Practical C Programming for a more thorough treatment of basic C syntax. However,
don't make too much of the syntactic similarities between Java and C or C++. In many respects,
Java acts like more dynamic languages such as Smalltalk and Lisp. Knowledge of another object-
oriented programming language should certainly help, although you may have to change some
ideas and unlearn a few habits. Java is considerably simpler than languages like C++ and
Although we encourage you to take a broad view, you would have every right to be disappointed
if we ignored the Web. A substantial part of this book does discuss Java as a language for World
Wide Web applications, so you should be familiar with the basic ideas behind web browsers,
servers, and web documents.
Using This Book
This book is organized roughly as follows:
• Chapter 1 and Chapter 2 provide a basic introduction to Java concepts and a tutorial to
give you a jump start on Java programming.
• Chapter 3 discusses tools for developing with Java (the compiler, the interpreter, the
JAR file package). It also covers important concepts such as embedding Java code in
HTML support and object signing.
• Chapter 4 through Chapter 8 describe the Java language itself. Chapter 8 covers the
language's thread facilities, which should be of particular interest to advanced
• Chapter 9 and Chapter 10 cover much of the core API. Chapter 9 describes basic
utilities, and Chapter 10 covers I/O facilities.
• Chapter 11 and Chapter 12 cover Java networking, including sockets, URLs, and
remote method invocation (RMI).
• Chapter 13 through Chapter 18 cover the Abstract Window Toolkit (AWT) and Swing,
which provide graphical user interface (GUI) and image support.
• Chapter 19 covers the JavaBeans™ component architecture.
• Chapter 20 covers applets, the area in which Java saw its initial success.
If you're like us, you don't read books from front to back. If you're really like us, you usually don't
read the preface at all. However, on the off chance that you will see this in time, here are a few
If you are an experienced programmer who has to learn Java in the next five minutes, you are
probably looking for the examples. You might want to start by glancing at the tutorial in Chapter
2. If that doesn't float your boat, you should at least look at the information in Chapter 3 , which
tells you how to use the compiler and interpreter, and gives you the basics of a standalone Java
application. This should get you started.
Chapter 11 and Chapter 12 are essential if you are interested in writing advanced networked
applications. This is probably the most interesting and important part of Java.
Chapter 13 though Chapter 19 discuss Java's graphics features and component architecture.
You should read this carefully if you are interested in Java applications for the Web.
There are many online sources for information about Java. Sun Microsystem's official web site for
Java topics is http://java.sun.com ; look here for the latest news, updates, and Java releases.
This is where you'll find the Java Software Development Kit (SDK), which includes the compiler,
the interpreter, and other tools. Another good source of Java information, including free applets,
utility classes, and applications, is the Gamelan site, run by EarthWeb; its URL is
You should also visit O'Reilly & Associates' Java site at http://java.oreilly.com . There you'll
find information about other books in O'Reilly's Java Series, and a pointer to the home page for
Learning Java, http://www.oreilly.com/cataloq/learnjava/ , where you'll find the source
code examples for this book.
The comp.lang.java newsgroup can be a good source of information and announcements, and a
place to ask intelligent questions.
Conventions Used in This Book
The font conventions used in this book are quite simple.
Italic is used for:
• Unix pathnames, filenames, and program names
• Internet addresses, such as domain names and URLs
• New terms where they are defined
Boldface is used for:
• Names of GUI buttons and menus
Constant width is used for:
• Anything that might appear in a Java program, including method names, variable
names, and class names
• Command lines and options that should be typed verbatim on the screen
• Tags that might appear in an HTML document
Constant width bold
is used for:
• In code examples, text that is typed by the user
In the main body of text, we always use a pair of empty parentheses after a method name to
distinguish methods from variables and other creatures.
In the Java source listings, we follow the coding conventions most frequently used in the Java
community. Class names begin with capital letters; variable and method names begin with
lowercase. All the letters in the names of constants are capitalized. We don't use underscores to
separate words in a long name; following common practice, we capitalize individual words (after
the first) and run the words together. For example: thisisAVariabie, thisisAMethod ( ) ,
ThisIsAClass, and THISISACONSTANT.
How to Contact Us
We have tested and verified all the information in this book to the best of our abilities, but you
may find that features have changed or that we have let errors slip through the production of the
book. Please let us know of any errors that you find, as well as suggestions for future editions, by
O'Reilly & Associates, Inc.
101 Morris St.
Sebastopol, CA 95472
1-800-998-9938 (in the U.S. or Canada)
1 -707-829-051 5 (international/local)
You can also send messages electronically. To be put on our mailing list or to request a catalog,
send email to:
To ask technical questions or to comment on the book, send email to:
We have a web site for the book, where we'll list examples, errata, and any plans for future
editions. You can access this page at:
For more information about this book and others, see the O'Reilly web site:
Chapter 1. Yet Another Language?
The greatest challenges and most exciting opportunities for software developers today lie in
harnessing the power of networks. Applications created today, whatever their intended scope or
audience, will almost certainly be run on machines linked by a global network of computing
resources. The increasing importance of networks is placing new demands on existing tools and
fueling the demand for a rapidly growing list of completely new kinds of applications.
We want software that works — consistently, anywhere, on any platform — and that plays well with
other applications. We want dynamic applications that take advantage of a connected world,
capable of accessing disparate and distributed information sources. We want truly distributed
software that can be extended and upgraded seamlessly. We want intelligent applications — like
autonomous agents that can roam the Net for us, ferreting out information and serving as
electronic emissaries. We know, to some extent, what we want. So why don't we have it?
The problem has been that the tools for building these applications have fallen short. The
requirements of speed and portability have been, for the most part, mutually exclusive, and
security has been largely ignored or misunderstood. There are truly portable languages, but they
are mostly bulky, interpreted, and slow. These languages are popular as much for their high-level
functionality as for their portability. And there are fast languages, but they usually provide speed
by binding themselves to particular platforms, so they can meet the portability issue only halfway.
There are even a few recent safe languages, but they are primarily offshoots of the portable
languages and suffer from the same problems.
1 .1 Enter Java
The Java™ programming language, developed at Sun Microsystems under the guidance of Net
luminaries James Gosling and Bill Joy, is designed to be a machine-independent programming
language that is both safe enough to traverse networks and powerful enough to replace native
executable code. Java addresses the issues raised here and may help us start building the kinds
of applications we want.
Initially, most of the enthusiasm for Java centered around its capabilities for building embedded
applications for the World Wide Web; these applications are called applets. Applets could be
independent programs in themselves, or sophisticated frontends to programs running on a server.
More recently, interest has shifted to other areas. With Java 2, Java has the most sophisticated
toolkit for building graphical user interfaces; this development has allowed Java to become a
popular platform for developing traditional application software. Java has also become an
important platform for server-side applications, using the servlet interface, and for enterprise
applications using technologies like Enterprise JavaBeans™. And Java is the platform of choice
for modern distributed applications.
This book shows you how to use Java to accomplish real programming tasks, such as building
networked applications and creating functional user interfaces. There's still a chapter devoted to
applets; they may become more important again when the Java 2 (and subsequent) versions of
the Java platform are more widely distributed in web browsers.
1.1.1 Java's Origins
The seeds of Java were planted in 1990 by Sun Microsystems patriarch and chief researcher, Bill
Joy. Since Sun's inception in the early '80s, it has steadily pushed one idea: "The network is the
computer." At the time though, Sun was competing in a relatively small workstation market, while
Microsoft was beginning its domination of the more mainstream, Intel-based PC world. When Sun
missed the boat on the PC revolution, Joy retreated to Aspen, Colorado, to work on advanced
research. He was committed to accomplishing complex tasks with simple software, and founded
the aptly named Sun Aspen Smallworks.
Of the original members of the small team of programmers assembled in Aspen, James Gosling
is the one who will be remembered as the father of Java. Gosling first made a name for himself in
the early '80s as the author of Gosling Emacs, the first version of the popular Emacs editor that
was written in C and ran under Unix. Gosling Emacs became popular, but was soon eclipsed by a
free version, GNU Emacs, written by Emacs's original designer. By that time, Gosling had moved
on to design Sun's NeWS window system, which briefly contended with the X Window System for
control of the Unix graphical user interface (GUI) desktop in 1987. While some people would
argue that NeWS was superior to X, NeWS lost out because Sun kept it proprietary and didn't
publish source code, while the primary developers of X formed the X Consortium and took the
Designing NeWS taught Gosling the power of integrating an expressive language with a network-
aware windowing GUI. It also taught Sun that the Internet programming community will refuse to
accept proprietary standards, no matter how good they may be. The seeds of Java's remarkably
permissive licensing scheme were sown by NeWS's failure. Gosling brought what he had learned
to Bill Joy's nascent Aspen project, and in 1992, work on the project led to the founding of the
Sun subsidiary, FirstPerson, Inc. Its mission was to lead Sun into the world of consumer
The FirstPerson team worked on developing software for information appliances, such as cellular
phones and personal digital assistants (PDAs). The goal was to enable the transfer of information
and real-time applications over cheap infrared and packet-based networks. Memory and
bandwidth limitations dictated small and efficient code. The nature of the applications also
demanded they be safe and robust. Gosling and his teammates began programming in C++, but
they soon found themselves confounded by a language that was too complex, unwieldy, and
insecure for the task. They decided to start from scratch, and Gosling began working on
something he dubbed "C++ minus minus."
With the foundering of the Apple Newton, it became apparent that the PDA's ship had not yet
come in, so Sun shifted FirstPerson's efforts to interactive TV (ITV). The programming language
of choice for ITV set-top boxes was the near ancestor of Java, a language called Oak. Even with
its elegance and ability to provide safe interactivity, Oak could not salvage the lost cause of ITV.
Customers didn't want it, and Sun soon abandoned the concept.
At that time, Joy and Gosling got together to decide on a new strategy for their language. It was
1993, and the explosion of interest in the Internet, and the World Wide Web in particular,
presented a new opportunity. Oak was small, robust, architecture-independent, and object-
oriented. As it happens, these are also the requirements for a universal, network-savvy
programming language. Sun quickly changed focus, and with a little retooling, Oak became Java.
1.1.2 Future Buzz?
It would not be overdoing it to say that Java has caught on like wildfire. Even before its first official
release, while Java was still a non-product, nearly every major industry player jumped on the
Java bandwagon. Java licensees included Microsoft, Intel, IBM, and virtually all major hardware
and software vendors. (That's not to say that everything has been coming up roses. Even with all
of this support Java has taken a lot of knocks and had some growing pains during its first few
As we begin looking at the Java architecture, you'll see that much of what is exciting about Java
comes from the self-contained, virtual machine environment in which Java applications run. Java
has been carefully designed so that this supporting architecture can be implemented either in
software, for existing computer platforms, or in customized hardware, for new kinds of devices.
Sun and other industry giants are producing fast Java chips and microprocessors tailored to run
media-rich Java applications. Hardware implementations of Java could power inexpensive
network terminals, PDAs, and other information appliances, to take advantage of transportable
Java applications. Software implementations of Java are available now for portable computing
devices like the popular Palm™ PDA.
Many people see Java as part of a trend toward cheap, Internet-based, "operating system-less"
appliances that will weave the Net into more and more consumer-related areas. The first attempts
at marketing "network computers" as alternatives to the standard PC have not gone very well.
(The combination of Windows and cheap PC hardware form a formidable barrier.) But the
desktop is only one corner of the network. Only time will tell what people will do with Java, but it's
probably worth at least a passing thought that the applet you write today might well be running on
someone's wristwatch tomorrow. If that seems too futuristic, remember that you can already get
"smart cards" and "wearable" devices like rings and dog tags that have Java interpreters
embedded in them. These devices are capable of doing everything from financial transactions
(paying a hotel bill) to unlocking a door (the door to your hotel room) to rerouting phone calls (so
your hotel room receives your business calls). The hardware is already here; it can't be long
before the rest of the software infrastructure begins to take advantage of it. A Java wristwatch is
not a silly notion.
1.2 A Virtual Machine
Java is both a compiled and an interpreted language. Java source code is turned into simple
binary instructions, much like ordinary microprocessor machine code. However, whereas C or
C++ source is refined to native instructions for a particular model of processor, Java source is
compiled into a universal format — instructions for a virtual machine.
Compiled Java byte-code, also called J-code, is executed by a Java runtime interpreter. The
runtime system performs all the normal activities of a real processor, but it does so in a safe,
virtual environment. It executes the stack-based instruction set and manages a storage heap. It
creates and manipulates primitive datatypes, and loads and invokes newly referenced blocks of
code. Most importantly, it does all this in accordance with a strictly defined open specification that
can be implemented by anyone who wants to produce a Java-compliant virtual machine.
Together, the virtual machine and language definition provide a complete specification. There are
no features of Java left undefined or implementation-dependent. For example, Java specifies the
sizes of all its primitive data types, rather than leave it up to each implementation.
The Java interpreter is relatively lightweight and small; it can be implemented in whatever form is
desirable for a particular platform. On most systems, the interpreter is written in a fast, natively
compiled language like C or C++. The interpreter can be run as a separate application, or it can
be embedded in another piece of software, such as a web browser.
All of this means that Java code is implicitly portable. The same Java application byte-code can
run on any platform that provides a Java runtime environment, as shown in Figure 1.1 . You
don't have to produce alternative versions of your application for different platforms, and you don't
have to distribute source code to end users.
Figure 1.1. The Java runtime environment
The fundamental unit of Java code is the class. As in other object-oriented languages, classes
are application components that hold executable code and data. Compiled Java classes are
distributed in a universal binary format that contains Java byte-code and other class information.
Classes can be maintained discretely and stored in files or archives on a local system or on a
network server. Classes are located and loaded dynamically at runtime, as they are needed by an
In addition to the platform-specific runtime system, Java has a number of fundamental classes
that contain architecture-dependent methods. These native methods serve as the gateway
between the Java virtual machine and the real world. They are implemented in a natively
compiled language on the host platform. They provide access to resources such as the network,
the windowing system, and the host filesystem. The rest of Java is written entirely in Java, and is
therefore portable. This includes fundamental Java utilities like the Java compiler and Sun's
HotJava web browser, which are also Java applications and are therefore available on all Java
Historically, interpreters have been considered slow, but because the Java interpreter runs
compiled byte-code, Java is a relatively fast interpreted language. More importantly, Java has
also been designed so that software implementations of the runtime system can optimize their
performance by compiling byte-code to native machine code on the fly. This is called just-in-time
compilation. Sun claims that with just-in-time compilation, Java code can execute nearly as fast
as native compiled code and maintain its transportability and security. There is only one true
performance hit that compiled Java code will always suffer for the sake of security — array
bounds checking. But on the other hand, some of the basic design features of Java place more
information in the hands of the compiler, which allows for certain kinds of optimizations not
possible in C or C++.
The latest twist in compilation techniques is a new virtual machine that Sun calls HotSpot. The
problem with a traditional just-in-time compilation is that optimizing code takes time, and is
extremely important for good performance on modern computer hardware. So a just-in-time
compiler can produce decent results, but can never afford to take the time necessary to do a
good job of optimization. HotSpot uses a trick called "adaptive compilation" to solve this problem.
If you look at what programs actually spend their time doing, it turns out that they spend almost all
of their time executing a relatively small part of the code again and again. The chunk of code that
is executed repeatedly may only be a small percent of the total program, but its behavior
determines the program's overall performance.
To take advantage of this fact, HotSpot starts out as a normal Java byte code interpreter, but with
a difference: it measures (profiles) the code as it is executing, to see what parts are being
executed repeatedly. Once it knows which parts of the code are crucial to the performance,
HotSpot compiles those sections — and only those sections — into true machine code. Since it only
compiles a small portion of the program into machine code, it can afford to take the time
necessary to optimize those portions. The rest of the program may not need to be compiled at
all — just interpreted — saving memory and time.
The technology for doing this is very complex, but the idea is essentially simple: optimize the
parts of the program that need to go fast, and don't worry about the rest. Another advantage of
using an adaptive compiler at runtime is that it can make novel kinds of optimizations that a static
(compile time only) compiler cannot dream of.
1.3 Java Compared with Other Languages
Java is a new language, but it draws on many years of programming experience with other
languages in its choice of features. So a lot can be said in comparing and contrasting Java with
other languages. There are at least three pillars necessary to support a universal language for
network programming today: portability, speed, and security. Figure 1.2 shows how Java
compares to other languages.
Figure 1.2. Programming languages compared
You may have heard that Java is a lot like C or C++, but that's really not true, except at a
superficial level. When you first look at Java code, you'll see that the basic syntax looks a lot like
C or C++. But that's where the similarities end. Java is by no means a direct descendant of C or a
next-generation C++. If you compare language features, you'll see that Java actually has more in
common with languages like Smalltalk and Lisp. In fact, Java's implementation is about as far
from native C as you can imagine.
The surface-level similarities to C and C++ are worth noting, however. Java borrows heavily from
C and C++ syntax, so you'll see lots of familiar language constructs, including an abundance of
curly braces and semicolons. Java also subscribes to the C philosophy that a good language
should be compact; in other words, it should be sufficiently small and regular so a programmer
can hold all the language's capabilities in his or her head at once. Just as C is extensible with
libraries, packages of Java classes can be added to the core language components.
C has been successful because it provides a reasonably featureful programming environment,
with high performance and an acceptable degree of portability. Java also tries to balance
functionality, speed, and portability, but it does so in a very different way. C trades functionality for
portability; Java trades speed for portability. Java also addresses security issues, while C doesn't.
Java is an interpreted language, so it won't be as fast as a compiled language like C. But Java is
fast enough, especially for interactive, network-based applications, where the application is often
idle, waiting for the user to do something or waiting for data from the network. For situations
where speed is critical, a Java implementation can optimize performance with just-in-time
compilation to byte-code, as previously discussed.
Scripting languages, like Perl, Python, Tcl/Tk, and Wksh, are becoming very popular, and for
good reason. There's no reason a scripting language could not be suitable for safe, networked
applications (e.g., Safe Tel), but most scripting languages are not designed for serious, large-
scale programming. The attraction to scripting languages is that they are dynamic; they are
powerful tools for rapid prototyping. Some scripting languages, like awk and Perl, also provide
powerful tools for text-processing tasks that more general-purpose languages find unwieldy.
Scripting languages are also highly portable.
One problem with scripting languages, however, is that they are rather casual about program
structure and data typing. Most scripting languages (with a hesitant exception for Perl 5.0 and
Python) are not object-oriented. They also have vastly simplified type systems and generally don't
provide for sophisticated scoping of variables and functions. These characteristics make them
unsuitable for building large, modular applications. Speed is another problem with scripting
languages; the high-level, fully interpreted nature of these languages often makes them quite
Java offers some of the essential advantages of a scripting language, along with the added
benefits of a lower-level language.
Incremental development with object-oriented components, combined with Java's simplicity,
make it possible to develop applications rapidly and change them easily, with a short concept-to-
implementation time. Java also comes with a large base of core classes for common tasks such
as building GUIs and doing network communications. But along with these features, Java has the
scalability and software-engineering advantages of more static languages. It provides a safe
structure on which to build higher-level networked tools and languages.
being developed by Netscape and others. It serves as a glue and an "in the document" language
integration with Java. You can currently interact with Java applets embedded in HTML using
Netscape's web site ( http://home.netscape.com ).
As we've already said, Java is similar in design to languages like Smalltalk and Lisp. However,
these languages are currently used mostly as research vehicles, rather than for developing large-
scale systems. One reason is that they never developed a standard portable binding to operating-
system services, like the C standard library or the Java core classes. Smalltalk is compiled to an
interpreted byte-code format, and it can be dynamically compiled to native code on the fly, just
like Java. But Java improves on the design by using a byte-code verifier to ensure the
correctness of compiled Java code. This verifier gives Java a performance advantage over
Smalltalk because Java code requires fewer runtime checks. Java's byte-code verifier also helps
with security issues, something that Smalltalk doesn't address. Smalltalk is a mature language,
though, and Java's designers took lessons from many of its features.
Throughout the rest of this chapter, we'll present a bird's-eye view of the Java language. We'll
explain what's new and what's not-so-new about Java, how it differs from other languages, and
1 .4 Safety of Design
You have no doubt heard a lot about the fact that Java is designed to be a safe language. But
what do we mean by safe? Safe from what or whom? The security features that attract the most
attention for Java are those features that make possible new types of dynamically portable
software. Java provides several layers of protection from dangerously flawed code, as well as
more mischievous things like viruses and Trojan horses. In the next section, we'll take a look at
how the Java virtual machine architecture assesses the safety of code before it's run, and how
the Java class loader (the byte-code loading mechanism of the Java interpreter) builds a wall
around untrusted classes. These features provide the foundation for high-level security policies
that allow or disallow various kinds of activities on an application-by-application basis.
In this section, though, we'll look at some general features of the Java programming language.
Perhaps more important than the specific security features, although often overlooked in the
security din, is the safety that Java provides by addressing common design and programming
problems. Java is intended to be as safe as possible from the simple mistakes we make
ourselves, as well as those we inherit from contractors and third-party software vendors. The goal
with Java has been to keep the language simple, provide tools that have demonstrated their
usefulness, and let users build more complicated facilities on top of the language when needed.
1.4.1 Syntactic Sweet 'n' Low
Java is parsimonious in its features; simplicity rules. Compared to C, Java uses few automatic
type coercions, and the ones that remain are simple and well-defined. Unlike C++, Java doesn't
allow programmer-defined operator overloading. The string concatenation operator + is the only
system-defined, overloaded operator in Java. All methods in Java are like C++ virtual methods,
so overridden methods are dynamically selected at runtime.
Java doesn't have a preprocessor, so it doesn't have macros, #def ine statements, or
conditional source compilation. These constructs exist in other languages primarily to support
platform dependencies, so in that sense they should not be needed in Java. Conditional
compilation is also commonly used for debugging purposes. Debugging code can be included
directly in your Java source code by making it conditional on a constant (in Java, a variable
declared to be static and final). The Java compiler is smart enough to remove this code
when it determines that it won't be called.
Java provides a well-defined package structure for organizing class files. The package system
allows the compiler to handle most of the functionality of the make utility (a sophisticated tool for
building executables from source code). The compiler also works with compiled Java classes,
because all type information is preserved; there is no need for header files. All of this means that
Java code requires little context to read. Indeed, you may sometimes find it faster to look at the
Java source code than to refer to class documentation.
Java replaces some features that have been troublesome in other languages. For example, Java
supports only a single inheritance class hierarchy, but allows multiple inheritance of interfaces. An
interface, like an abstract class in C++, specifies some of the behavior of an object without
defining its implementation, a powerful mechanism borrowed from Objective C. It allows a class
to implement the behavior of the interface, without needing to be a subclass of anything in
particular. Interfaces in Java eliminate the need for multiple inheritance of classes, without
causing the problems associated with multiple inheritance. As you'll see in Chapter 4 , Java is a
simple, yet elegant, programming language.
1.4.2 Type Safety and Method Binding
One attribute of a language is the kind of type checking it uses. When we categorize a language
as static or dynamic we are referring to the amount of information about variable types that is
known at compile time versus what is determined while the application is running.
In a strictly statically typed language like C or C++, data types are etched in stone when the
source code is compiled. The compiler benefits from having enough information to enforce usage
rules, so that it can catch many kinds of errors before the code is executed, such as storing a
floating-point value in an integer variable. The code doesn't require runtime type checking, so it
can be compiled to be small and fast. But statically typed languages are inflexible. They don't
support high-level constructs like lists and collections as naturally as languages with dynamic
type checking, and they make it impossible for an application to safely import new data types
while it's running.
In contrast, a dynamic language such as Smalltalk or Lisp has a runtime system that manages
the types of objects and performs necessary type checking while an application is executing.
These kinds of languages allow for more complex behavior, and are in many respects more
powerful. However, they are also generally slower, less safe, and harder to debug.
The differences in languages have been likened to the differences among kinds of automobiles. 111
Statically typed languages like C++ are analogous to a sports car — reasonably safe and fast — but
useful only if you're driving on a nicely paved road. Highly dynamic languages like Smalltalk are
more like an offroad vehicle: they afford you more freedom, but can be somewhat unwieldy. It can
be fun (and sometimes faster) to go roaring through the back woods, but you might also get stuck
in a ditch or mauled by bears.
111 The credit for the car analogy goes to Marshall P. Cline, author of the C++ FAQ.
Another attribute of a language is the way it binds method calls to their definitions. In an early-
binding language like C or C++, the definitions of methods are normally bound at compile time,
unless the programmer specifies otherwise. Smalltalk, on the other hand, is a late-binding
language because it locates the definitions of methods dynamically at runtime. Early-binding is
important for performance reasons; an application can run without the overhead incurred by
searching method tables at runtime. But late-binding is more flexible. It's also necessary in an
object-oriented language, where a subclass can override methods in its superclass, and only the
runtime system can determine which method to run.
Java provides some of the benefits of both C++ and Smalltalk; it's a statically typed, late-binding
language. Every object in Java has a well-defined type that is known at compile time. This means
the Java compiler can do the same kind of static type checking and usage analysis as C++. As a
result, you can't assign an object to the wrong type of variable or call nonexistent methods on an
object. The Java compiler goes even further and prevents you from messing up and trying to use
However, Java is fully runtime typed as well. The Java runtime system keeps track of all objects
and makes it possible to determine their types and relationships during execution. This means
you can inspect an object at runtime to determine what it is. Unlike C or C++, casts from one type
of object to another are checked by the runtime system, and it's even possible to use completely
new kinds of dynamically loaded objects with a level of type safety.
Since Java is a late-binding language, all methods are like virtual methods in C++. This makes it
possible for a subclass to override methods in its superclass. But Java also allows you to gain the
performance benefits of early-binding by explicitly declaring (with the final modifier) that certain
methods can't be overridden by subclassing, removing the need for runtime lookup. (Adaptive
runtime compilers like HotSpot may be able to eliminate the need for you to worry about this
though, as they can detect usage patterns and improve performance automatically, where
1.4.3 Incremental Development
Java carries all data-type and method-signature information with it from its source code to its
compiled byte-code form. This means that Java classes can be developed incrementally. Your
own Java classes can also be used safely with classes from other sources your compiler has
never seen. In other words, you can write new code that references binary class files, without
losing the type safety you gain from having the source code. The Java runtime system can load
new classes while an application is running, thus providing the capabilities of a dynamic linker.
A common irritation with C++ is the "fragile base class" problem. In C++, the implementation of a
base class can be effectively frozen by the fact that it has many derived classes; changing the
base class may require recompilation of the derived classes. This is an especially difficult
problem for developers of class libraries. Java avoids this problem by dynamically locating fields
within classes. As long as a class maintains a valid form of its original structure, it can evolve
without breaking other classes that are derived from it or that make use of it.
1.4.4 Dynamic Memory Management
Some of the most important differences between Java and C or C++ involve how Java manages
memory. Java eliminates ad hoc pointers and adds garbage collection and true arrays to the
language. These features eliminate many otherwise insurmountable problems with safety,
portability, and optimization.
Garbage collection alone should save countless programmers from the single largest source of
programming errors in C or C++: explicit memory allocation and deallocation. In addition to
maintaining objects in memory, the Java runtime system keeps track of all references to those
objects. When an object is no longer in use, Java automatically removes it from memory. You can
simply ignore objects you no longer use, with confidence that the interpreter will clean them up at
an appropriate time.
Sun's current implementation of Java uses a conservative mark-and-sweep garbage collector that
runs intermittently in the background, which means that most garbage collecting takes place
between I/O pauses, mouse clicks, and keyboard hits. Next generation runtime systems like
HotSpot have more advanced garbage collection that can even differentiate the usage patterns of
objects (such as short-lived versus long-lived) and optimize their collection. Once you get used to
garbage collection, you won't go back. Being able to write air-tight C code that juggles memory
without dropping any on the floor is an important skill, but once you become addicted to Java you
can "realloc" some of those brain cells to new tasks.
You may hear people say that Java doesn't have pointers. Strictly speaking, this statemen
Lire la suite
- 3.62 MB