Java vs. C++?

Java looks a lot like C++, and so naturally it would seem that C++ will be replaced by
Java. But I’m starting to question this logic. For one thing, C++ still has some features that
Java doesn’t, and although there have been a lot of promises about Java someday being as
fast or faster than C++ the breakthroughs haven’t happened yet (it’s getting steadily faster,
but still hasn’t touched C++). Also, there seems to be a perking interest in C++ in many
fields, so I don’t think that language is going away any time soon. (Languages seem to hang
around. Speaking at one of my “Intermediate/Advanced Java Seminars,” Allen Holub
asserted that the two most commonly-used languages are Rexx and COBOL, in that order.)
I’m beginning to think that the strength of Java lies in a slightly different arena than that of
C++. C++ is a language that doesn’t try to fit a mold. Certainly it has been adapted in a
number of ways to solve particular problems, especially with tools like Microsoft Visual
C++ and Borland C++ Builder (a particular favorite of mine). These combine libraries,
component models and code generation tools to solve the problem of developing windowed
end-user applications (for Microsoft Windows). And yet, what do the vast majority of
Windows developers use? Microsoft’s Visual Basic (VB). This despite the fact that VB
produces the kind of code that becomes unmanageable when the program is only a few
pages long (and syntax that can be positively mystifying). As successful and popular as VB
is, from a language design viewpoint it’s a mountain of hacks. It would be nice to have the
ease and power of VB without the resulting unmanageable code. And that’s where I think
Java will shine: as the “next VB.” You may or may not shudder to hear this, but think about
it: so much of Java is designed to make it easy for the programmer to solve application-level
problems like networking and cross-platform UI, and yet it has a language design intended
to allow the creation of very large and flexible bodies of code. Add to this the fact that Java
has the most robust type checking and error-handling systems I’ve ever seen in a language
and you have the makings of a significant leap forward in programming productivity.
Should you use Java instead of C++ for your project? Other than Web applets, there are two
issues to consider. First, if you want to use a lot of existing libraries (and you’ll certainly get
a lot of productivity gains there), or if you have an existing C or C++ code base, Java might
slow your development down rather than speeding it up. If you’re developing all your code
primarily from scratch, then the simplicity of Java over C++ will shorten your development
time.
The biggest issue is speed. Interpreted Java has been slow, even 20 to 50 times slower than C
in the original Java interpreters. This has improved quite a bit over time, but it will still
remain an important number. Computers are about speed; if it wasn’t significantly faster to
do something on a computer then you’d do it by hand. (I’ve even heard it suggested that you
start with Java, to gain the short development time, then use a tool and support libraries to
translate your code to C++, if you need faster execution speed.)
The key to making Java feasible for most non-Web development projects is the appearance of
speed improvements like so-called “just-in time” (JIT) compilers and possibly even native
code compilers (two of which exist at this writing). Of course, native-code compilers will
eliminate the touted cross-platform execution of the compiled programs, but they will also
bring the speed of the executable closer to that of C and C++. And cross compiling programs
in Java should be a lot easier than doing so in C or C++. (In theory, you just recompile, but
that promise has been made before for other languages.)
You can find comparisons of Java and C++, observations about Java realities and
practicality and coding guidelines in the appendices.

Analysis and Design

The object-oriented paradigm is a new and different way of thinking about programming
and many folks have trouble at first knowing how to approach a project. Now that you
know that everything is supposed to be an object, you can create a “good” design, one that
will take advantage of all the benefits that OOP has to offer.
Books on OOP analysis and design are coming out of the woodwork. Most of these books are
filled with lots of long words, awkward prose and important-sounding pronouncements.9 I
come away thinking the book would be better as a chapter or at the most a very short book
and feeling annoyed that this process couldn’t be described simply and directly. (It disturbs
me that people who purport to specialize in managing complexity have such trouble writing
clear and simple books.) After all, the whole point of OOP is to make the process of software
development easier, and although it would seem to threaten the livelihood of those of us who
consult because things are complex, why not make it simple? So, hoping I’ve built a healthy
skepticism within you, I shall endeavor to give you my own perspective on analysis and
design in as few paragraphs as possible.
Staying on course
While you’re going through the development process, the most important issue is this: don’t
get lost. It’s easy to do. Most of these methodologies are designed to solve the largest of
problems. (This makes sense; these are the especially difficult projects that justify calling in
that author as consultant, and justify the author’s large fees.) Remember that most projects
don’t fit into that category, so you can usually have a successful analysis and design with a
relatively small subset of what a methodology recommends. But some sort of process, no
matter how limited, will generally get you on your way in a much better fashion than
simply beginning to code.
9 The best introduction is still Grady Booch’s Object-Oriented Design with Applications, 2nd edition, Wiley
& Sons 1996. His insights are clear and his prose is straightforward, although his notations are
needlessly complex for most designs. (You can easily get by with a subset.)
Chapter 1: Introduction to Objects 65
That said, if you’re looking at a methodology that contains tremendous detail and suggests
many steps and documents, it’s still difficult to know when to stop. Keep in mind what
you’re trying to discover:
1. What are the objects? (How do you partition your project into its component parts?)
2. What are their interfaces? (What messages do you need to be able to send to each
object?)
If you come up with nothing more than the objects and their interfaces then you can write a
program. For various reasons you might need more descriptions and documents than this,
but you can’t really get away with any less.
The process can be undertaken in four phases, and a phase 0 which is just the initial
commitment to using some kind of structure.
Phase 0: Let’s make a plan
The first step is to decide what steps you’re going to have in your process. It sounds simple
(in fact, all of this sounds simple) and yet, often, people don’t even get around to phase one
before they start coding. If your plan is “let’s jump in and start coding,” fine. (Sometimes
that’s appropriate when you have a well-understood problem.) At least agree that this is the
plan.
You might also decide at this phase that some additional process structure is necessary but
not the whole nine yards. Understandably enough, some programmers like to work in
“vacation mode” in which no structure is imposed on the process of developing their work:
“It will be done when it’s done.” This can be appealing for awhile, but I’ve found that having
a few milestones along the way helps to focus and galvanize your efforts around those
milestones instead of being stuck with the single goal of “finish the project.” In addition, it
divides the project into more bite-sized pieces and make it seem less threatening.
When I began to study story structure (so that I will someday write a novel) I was initially
resistant to the idea, feeling that when I wrote I simply let it flow onto the page. What I
found was that when I wrote about computers the structure was simple enough so I didn’t
need to think much about it, but I was still structuring my work, albeit only semiconsciously
in my head. So even if you think that your plan is to just start coding, you still
go through the following phases while asking and answering certain questions.
Phase 1: What are we making?
In the previous generation of program design (procedural design), this would be called
“creating the requirements analysis and system specification.” These, of course, were places to
get lost: intimidatingly-named documents that could become big projects in their own right.
Their intention was good, however. The requirements analysis says “Make a list of the
guidelines we will use to know when the job is done and the customer is satisfied.” The
system specification says “Here’s a description of what the program will do (not how) to
satisfy the requirements.” The requirements analysis is really a contract between you and
the customer (even if the customer works within your company or is some other object or
system). The system specification is a top-level exploration into the problem and in some
sense a discovery of whether it can be done and how long it will take. Since both of these
will require consensus among people, I think it’s best to keep them as bare as possible –
ideally, to lists and basic diagrams – to save time. You might have other constraints that
require you to expand them into bigger documents.
66 Thinking in Java www.BruceEckel.com
It’s necessary to stay focused on the heart of what you’re trying to accomplish in this phase:
determine what the system is supposed to do. The most valuable tool for this is a collection
of what are called “use-cases.” These are essentially descriptive answers to questions that
start with “What does the system do if …” For example, “What does the auto-teller do if a
customer has just deposited a check within 24 hours and there’s not enough in the account
without the check to provide the desired withdrawal?” The use-case then describes what the
auto-teller does in that case.
You try to discover a full set of use-cases for your system, and once you’ve done that you’ve
got the core of what the system is supposed to do. The nice thing about focusing on usecases
is that they always bring you back to the essentials and keep you from drifting off into
issues that aren’t critical for getting the job done. That is, if you have a full set of use-cases
you can describe your system and move onto the next phase. You probably won’t get it all
figured out perfectly at this phase, but that’s OK. Everything will reveal itself in the fullness
of time, and if you demand a perfect system specification at this point you’ll get stuck.
It helps to kick-start this phase by describing the system in a few paragraphs and then
looking for nouns and verbs. The nouns become the objects and the verbs become the
methods in the object interfaces. You’ll be surprised at how useful a tool this can be;
sometimes it will accomplish the lion’s share of the work for you.
Although it’s a black art, at this point some kind of scheduling can be quite useful. You now
have an overview of what you’re building so you’ll probably be able to get some idea of how
long it will take. A lot of factors come into play here: if you estimate a long schedule then
the company might not decide to build it, or a manager might have already decided how
long the project should take and will try to influence your estimate. But it’s best to have an
honest schedule from the beginning and deal with the tough decisions early. There have been
a lot of attempts to come up with accurate scheduling techniques (like techniques to predict
the stock market), but probably the best approach is to rely on your experience and
intuition. Get a gut feeling for how long it will really take, then double that and add 10
percent. Your gut feeling is probably correct; you can get something working in that time.
The “doubling” will turn that into something decent, and the 10 percent will deal with final
polishing and details. However you want to explain it, and regardless of the moans and
manipulations that happen when you reveal such a schedule, it just seems to work out that
way.
Phase 2: How will we build it?
In this phase you must come up with a design that describes what the classes look like and
how they will interact. A useful diagramming tool that has evolved over time is the Unified
Modeling Language (UML). You can get the specification for UML at www.rational.com. UML
can also be helpful as a descriptive tool during phase 1, and some of the diagrams you create
there will probably show up unmodified in phase 2. You don’t need to use UML, but it can
be helpful, especially if you want to put a diagram up on the wall for everyone to ponder,
which is a good idea. An alternative to UML is a textual description of the objects and their
interfaces (as I described in Thinking in C++), but this can be limiting.
The most successful consulting experiences I’ve had when coming up with an initial design
involves standing in front of a team, who hadn’t built an OOP project before, and drawing
objects on a whiteboard. We talked about how the objects should communicate with each
other, and erased some of them and replaced them with other objects. The team (who knew
what the project was supposed to do) actually created the design; they “owned” the design
rather than having it given to them. All I was doing was guiding the process by asking the
right questions, trying out the assumptions and taking the feedback from the team to
Chapter 1: Introduction to Objects 67
modify those assumptions. The true beauty of the process was that the team learned how to
do object-oriented design not by reviewing abstract examples, but by working on the one
design that was most interesting to them at that moment: theirs.
You’ll know you’re done with phase 2 when you have described the objects and their
interfaces. Well, most of them – there are usually a few that slip through the cracks and
don’t make themselves known until phase 3. But that’s OK. All you are concerned with is
that you eventually discover all of your objects. It’s nice to discover them early in the
process but OOP provides enough structure so that it’s not so bad if you discover them later.
Phase 3: Let’s build it!
If you’re reading this book you’re probably a programmer, so now we’re at the part you’ve
been trying to get to. By following a plan – no matter how simple and brief – and coming up
with design structure before coding, you’ll discover that things fall together far more easily
than if you dive in and start hacking, and this provides a great deal of satisfaction. Getting
code to run and do what you want is fulfilling, even like some kind of drug if you look at
the obsessive behavior of some programmers. But it’s my experience that coming up with an
elegant solution is deeply satisfying at an entirely different level; it feels closer to art than
technology. And elegance always pays off; it’s not a frivolous pursuit. Not only does it give
you a program that’s easier to build and debug, but it’s also easier to understand and
maintain, and that’s where the financial value lies.
After you build the system and get it running, it’s important to do a reality check, and here’s
where the requirements analysis and system specification comes in. Go through your
program and make sure that all the requirements are checked off, and that all the use-cases
work the way they’re described. Now you’re done. Or are you?
Phase 4: Iteration
This is the point in the development cycle that has traditionally been called “maintenance,” a
catch-all term that can mean everything from “getting it to work the way it was really
supposed to in the first place” to “adding features that the customer forgot to mention
before” to the more traditional “fixing the bugs that show up” and “adding new features as
the need arises.” So many misconceptions have been applied to the term “maintenance” that
it has taken on a slightly deceiving quality, partly because it suggests that you’ve actually
built a pristine program and that all you need to do is change parts, oil it and keep it from
rusting. Perhaps there’s a better term to describe what’s going on.
The term is iteration. That is, “You won’t get it right the first time, so give yourself the
latitude to learn and to go back and make changes.” You might need to make a lot of
changes as you learn and understand the problem more deeply. The elegance you’ll produce
if you iterate until you’ve got it right will pay off, both in the short and the long run.
What it means to “get it right” isn’t just that the program works according to the
requirements and the use-cases. It also means that the internal structure of the code makes
sense to you, and feels like it fits together well, with no awkward syntax, oversized objects
or ungainly exposed bits of code. In addition, you must have some sense that the program
structure will survive the changes that it will inevitably go through during its lifetime, and
that those changes can be made easily and cleanly. This is no small feat. You must not only
understand what you’re building, but also how the program will evolve (what I call the
vector of change). Fortunately, object-oriented programming languages are particularly adept
at supporting this kind of continuing modification – the boundaries created by the objects
68 Thinking in Java www.BruceEckel.com
are what tend to keep the structure from breaking down. They are also what allow you to
make changes that would seem drastic in a procedural program without causing
earthquakes throughout your code. In fact, support for iteration might be the most
important benefit of OOP.
With iteration, you create something that at least approximates what you think you’re
building, and then you kick the tires, compare it to your requirements and see where it falls
short. Then you can go back and fix it by redesigning and re-implementing the portions of
the program that didn’t work right.10 You might actually need to solve the problem, or an
aspect of the problem, several times before you hit on the right solution. (A study of Design
Patterns, described in Chapter 16, is usually helpful here.)
Iteration also occurs when you build a system, see that it matches your requirements and
then discover it wasn’t actually what you wanted. When you see the system, you realize
you want to solve a different problem. If you think this kind of iteration is going to happen,
then you owe it to yourself to build your first version as quickly as possible so you can find
out if it’s what you want.
Iteration is closely tied to incremental development. Incremental development means that you
start with the core of your system and implement it as a framework upon which to build
the rest of the system piece by piece. Then you start adding features one at a time. The trick
to this is in designing a framework that will accommodate all the features you plan to add
to it. (See Chapter 16 for more insight into this issue.) The advantage is that once you get
the core framework working, each feature you add is like a small project in itself rather than
part of a big project. Also, new features that are incorporated later in the development or
maintenance phases can be added more easily. OOP supports incremental development
because if your program is designed well, your increments will turn out to be discreet
objects or groups of objects.
Plans pay off
Of course you wouldn’t build a house without a lot of carefully-drawn plans. If you build a
deck or a dog house, your plans won’t be so elaborate but you’ll still probably start with
some kind of sketches to guide you on your way. Software development has gone to
extremes. For a long time, people didn’t have much structure in their development, but then
big projects began failing. In reaction, we ended up with methodologies that had an
intimidating amount of structure and detail. These were too scary to use – it looked like
you’d spend all your time writing documents and no time programming. (This was often the
case.) I hope that what I’ve shown you here suggests a middle path – a sliding scale. Use an
approach that fits your needs (and your personality). No matter how minimal you choose to
make it, some kind of plan will make a big improvement in your project as opposed to no
plan at all. Remember that, by some estimates, over 50 percent of projects fail.
10 This is something like “rapid prototyping,” where you were supposed to build a quick-and-dirty
version so that you could learn about the system, and then throw away your prototype and build it
right. The trouble with rapid prototyping is that people didn’t throw away the prototype, but instead
built upon it. Combined with the lack of structure in procedural programming, this often leads to
messy systems that are expensive to maintain.

A separate arena: applications

Most of the brouhaha over Java has been about applets. Java is actually a general-purpose
programming language that can solve any type of problem, at least in theory. And as
pointed out previously, there might be more effective ways to solve most client/server
problems. When you move out of the applet arena (and simultaneously release the
restrictions, such as the one against writing to disk) you enter the world of general-purpose
applications that run standalone, without a Web browser, just like any ordinary program
does. Here, Java’s strength is not only in its portability, but also its programmability. As
you’ll see throughout this book, Java has many features that allow you to create robust
programs in a shorter period than with previous programming languages.
Be aware that this is a mixed blessing. You pay for the improvements through slower
execution speed (although there is significant work going on in this area). Like any language,
Java has built-in limitations that might make it inappropriate to solve certain types of
programming problems. Java is a rapidly-evolving language, however, and as each new
release comes out it becomes more and more attractive for solving larger sets of problems.

Server-side programming

This whole discussion has ignored the issue of server-side programming. What happens
when you make a request of a server? Most of the time the request is simply “send me this
file.” Your browser then interprets the file in some appropriate fashion: as an HTML page, a
graphic image, a Java applet, a script program, etc. A more complicated request to a server
generally involves a database transaction. A common scenario involves a request for a
complex database search, which the server then formats into an HTML page and sends to
you as the result. (Of course, if the client has more intelligence via Java or a scripting
language, the raw data can be sent and formatted at the client end, which will be faster and
less load on the server.) Or you might want to register your name in a database when you
join a group or place an order, which will involve changes to that database. These database
requests must be processed via some code on the server side, which is generally referred to as
server-side programming. Traditionally, server-side programming has been performed using
Perl and CGI scripts, but more sophisticated systems have been appearing. These include
Java-based Web servers that allow you to perform all your server-side programming in Java
by writing what are called servlets.
64 Thinking in Java www.BruceEckel.com

Client-side programming

The Web’s initial server-browser design provided for interactive content, but the interactivity
was completely provided by the server. The server produced static pages for the client
browser, which would simply interpret and display them. Basic HTML contains simple
mechanisms for data gathering: text-entry boxes, check boxes, radio boxes, lists and dropdown
lists, as well as a button that can only be programmed to reset the data on the form or
“submit” the data on the form back to the server. This submission passes through the
Common Gateway Interface (CGI) provided on all Web servers. The text within the submission
tells CGI what to do with it. The most common action is to run a program located on the
server in a directory that’s typically called “cgi-bin.” (If you watch the address window at
the top of your browser when you push a button on a Web page, you can sometimes see
“cgi-bin” within all the gobbledygook there.) These programs can be written in most
languages. Perl is a common choice because it is designed for text manipulation and is
interpreted, so it can be installed on any server regardless of processor or operating system.
Many powerful Web sites today are built strictly on CGI, and you can in fact do nearly
anything with it. The problem is response time. The response of a CGI program depends on
how much data must be sent as well as the load on both the server and the Internet. (On top
of this, starting a CGI program tends to be slow.) The initial designers of the Web did not
foresee how rapidly this bandwidth would be exhausted for the kinds of applications people
developed. For example, any sort of dynamic graphing is nearly impossible to perform with
consistency because a GIF file must be created and moved from the server to the client for
each version of the graph. And you’ve no doubt had direct experience with something as
simple as validating the data on an input form. You press the submit button on a page; the
data is shipped back to the server; the server starts a CGI program that discovers an error,
formats an HTML page informing you of the error and sends the page back to you; you
must then back up a page and try again. Not only is this slow, it’s not elegant.
The solution is client-side programming. Most machines that run Web browsers are
powerful engines capable of doing vast work, and with the original static HTML approach
they are sitting there, just idly waiting for the server to dish up the next page. Client-side
programming means that the Web browser is harnessed to do whatever work it can, and the
result for the user is a much speedier and more interactive experience at your Web site.
8 The material in this section is adapted from an article by the author that originally appeared on
Mainspring, at www.mainspring.com. Used with permission.
60 Thinking in Java www.BruceEckel.com
The problem with discussions of client-side programming is that they aren’t very different
from discussions of programming in general. The parameters are almost the same, but the
platform is different: a Web browser is like a limited operating system. In the end, it’s still
programming and this accounts for the dizzying array of problems and solutions produced
by client-side programming. The rest of this section provides an overview of the issues and
approaches in client-side programming.
Plug-ins
One of the most significant steps forward in client-side programming is the development of
the plug-in. This is a way for a programmer to add new functionality to the browser by
downloading a piece of code that plugs itself into the appropriate spot in the browser. It tells
the browser “from now on you can perform this new activity.” (You need to download the
plug-in only once.) Some fast and powerful behavior is added to browsers via plug-ins, but
writing a plug-in is not a trivial task and isn’t something you’d want to do as part of the
process of building a particular site. The value of the plug-in for client-side programming is
that it allows an expert programmer to develop a new language and add that language to a
browser without the permission of the browser manufacturer. Thus, plug-ins provide the back
door that allows the creation of new client-side programming languages (although not all
languages are implemented as plug-ins).
Scripting languages
Plug-ins resulted in an explosion of scripting languages. With a scripting language you
embed the source code for your client-side program directly into the HTML page and the
plug-in that interprets that language is automatically activated while the HTML page is
being displayed. Scripting languages tend to be reasonably simple to understand, and
because they are simply text that is part of an HTML page they load very quickly as part of
the single server hit required to procure that page. The trade-off is that your code is exposed
for everyone to see (and steal) but generally you aren’t doing amazingly sophisticated things
with scripting languages so it’s not too much of a hardship.
This points out that scripting languages are really intended to solve specific types of
problems, primarily the creation of richer and more interactive graphical user interfaces
(GUIs). However, a scripting language might solve 80 percent of the problems encountered in
client-side programming. Your problems might very well fit completely within that 80
percent, and since scripting languages tend to be easier and faster to develop, you should
probably consider a scripting language before looking at a more involved solution such as
Java or ActiveX programming.
The most commonly-discussed scripting languages are JavaScript (which has nothing to do
with Java; it’s named that way just to grab some of Java’s marketing momentum), VBScript
(which looks like Visual Basic) and Tcl/Tk, which comes from the popular cross-platform
GUI-building language. There are others out there and no doubt more in development.
JavaScript is probably the most commonly supported. It comes built into both Netscape
Navigator and the Microsoft Internet Explorer (IE). In addition, there are probably more
JavaScript books out than for the other languages, and some tools automatically create
pages using JavaScript. However, if you’re already fluent in Visual Basic or Tcl/Tk, you’ll be
more productive using those scripting languages rather than learning a new one. (You’ll
have your hands full dealing with the Web issues already.)
Chapter 1: Introduction to Objects 61
Java
If a scripting language can solve 80 percent of the client-side programming problems, what
about the other 20 percent – the “really hard stuff?” The most popular solution today is
Java. Not only is it a powerful programming language built to be secure, cross-platform and
international, but Java is being continuously extended to provide language features and
libraries that elegantly handle problems that are difficult in traditional programming
languages, such as multithreading, database access, network programming and distributed
computing. Java allows client-side programming via the applet.
An applet is a mini-program that will run only under a Web browser. The applet is
downloaded automatically as part of a Web page (just as, for example, a graphic is
automatically downloaded). When the applet is activated it executes a program. This is part
of its beauty – it provides you with a way to automatically distribute the client software
from the server at the time the user needs the client software, and no sooner. They get the
latest version of the client software without fail and without difficult re-installation. Because
of the way Java is designed, the programmer needs to create only a single program, and that
program automatically works with all computers that have browsers with built-in Java
interpreters. (This safely includes the vast majority of machines.) Since Java is a full-fledged
programming language, you can do as much work as possible on the client before and after
making requests of the server. For example, you won’t need to send a request form across
the Internet to discover that you’ve gotten a date or some other parameter wrong, and your
client computer can quickly do the work of plotting data instead of waiting for the server to
make a plot and ship a graphic image back to you. Not only do you get the immediate win
of speed and responsiveness, but the general network traffic and load upon servers can be
reduced, preventing the entire Internet from slowing down.
One advantage a Java applet has over a scripted program is that it’s in compiled form, so the
source code isn’t available to the client. On the other hand, a Java applet can be decompiled
without too much trouble, and hiding your code is often not an important issue anyway.
Two other factors can be important. As you will see later in the book, a compiled Java applet
can comprise many modules and take multiple server “hits” (accesses) to download. (In Java
1.1 this is minimized by Java archives, called JAR files, that allow all the required modules
to be packaged together for a single download.) A scripted program will just be integrated
into the Web page as part of its text (and will generally be smaller and reduce server hits).
This could be important to the responsiveness of your Web site. Another factor is the allimportant
learning curve. Regardless of what you’ve heard, Java is not a trivial language to
learn. If you’re a Visual Basic programmer, moving to VBScript will be your fastest solution
and since it will probably solve most typical client/server problems you might be hard
pressed to justify learning Java. If you’re experienced with a scripting language you will
certainly benefit from looking at JavaScript or VBScript before committing to Java, since
they might fit your needs handily and you’ll be more productive sooner.
ActiveX
To some degree, the competitor to Java is Microsoft’s ActiveX, although it takes a completely
different approach. ActiveX is originally a Windows-only solution, although it is now being
developed via an independent consortium to become cross-platform. Effectively, ActiveX says
“if your program connects to its environment just so, it can be dropped into a Web page and
run under a browser that supports ActiveX.” (IE directly supports ActiveX and Netscape does
so using a plug-in.) Thus, ActiveX does not constrain you to a particular language. If, for
example, you’re already an experienced Windows programmer using a language such as
C++, Visual Basic, or Borland’s Delphi, you can create ActiveX components with almost no
62 Thinking in Java www.BruceEckel.com
changes to your programming knowledge. ActiveX also provides a path for the use of legacy
code in your Web pages.
Security
Automatically downloading and running programs across the Internet can sound like a
virus-builder’s dream. ActiveX especially brings up the thorny issue of security in client-side
programming. If you click on a Web site, you might automatically download any number of
things along with the HTML page: GIF files, script code, compiled Java code, and ActiveX
components. Some of these are benign; GIF files can’t do any harm, and scripting languages
are generally limited in what they can do. Java was also designed to run its applets within a
“sandbox” of safety, which prevents it from writing to disk or accessing memory outside the
sandbox.
ActiveX is at the opposite end of the spectrum. Programming with ActiveX is like
programming Windows – you can do anything you want. So if you click on a page that
downloads an ActiveX component, that component might cause damage to the files on your
disk. Of course, programs that you load onto your computer that are not restricted to
running inside a Web browser can do the same thing. Viruses downloaded from Bulletin-
Board Systems (BBSs) have long been a problem, but the speed of the Internet amplifies the
difficulty.
The solution seems to be “digital signatures,” whereby code is verified to show who the
author is. This is based on the idea that a virus works because its creator can be anonymous,
so if you remove the anonymity individuals will be forced to be responsible for their actions.
This seems like a good plan because it allows programs to be much more functional, and I
suspect it will eliminate malicious mischief. If, however, a program has an unintentional bug
that’s destructive it will still cause problems.
The Java approach is to prevent these problems from occurring, via the sandbox. The Java
interpreter that lives on your local Web browser examines the applet for any untoward
instructions as the applet is being loaded. In particular, the applet cannot write files to disk
or erase files (one of the mainstays of the virus). Applets are generally considered to be safe,
and since this is essential for reliable client-server systems, any bugs that allow viruses are
rapidly repaired. (It’s worth noting that the browser software actually enforces these
security restrictions, and some browsers allow you to select different security levels to
provide varying degrees of access to your system.)
You might be skeptical of this rather draconian restriction against writing files to your local
disk. For example, you may want to build a local database or save data for later use offline.
The initial vision seemed to be that eventually everyone would be online to do anything
important, but that was soon seen to be impractical (although low-cost “Internet appliances”
might someday satisfy the needs of a significant segment of users). The solution is the
“signed applet” that uses public-key encryption to verify that an applet does indeed come
from where it claims it does. A signed applet can then go ahead and trash your disk, but the
theory is that since you can now hold the applet creator accountable they won’t do vicious
things. Java 1.1 provides a framework for digital signatures so that you will eventually be
able to allow an applet to step outside the sandbox if necessary.
Digital signatures have missed an important issue, which is the speed that people move
around on the Internet. If you download a buggy program and it does something untoward,
how long will it be before you discover the damage? It could be days or even weeks. And by
then, how will you track down the program that’s done it (and what good will it do at that
point?).
Chapter 1: Introduction to Objects 63
Internet vs. Intranet
The Web is the most general solution to the client/server problem, so it makes sense that you
can use the same technology to solve a subset of the problem, in particular the classic
client/server problem within a company. With traditional client/server approaches you have
the problem of multiple different types of client computers, as well as the difficulty of
installing new client software, both of which are handily solved with Web browsers and
client-side programming. When Web technology is used for an information network that is
restricted to a particular company, it is referred to as an Intranet. Intranets provide much
greater security than the Internet, since you can physically control access to the servers
within your company. In terms of training, it seems that once people understand the general
concept of a browser it’s much easier for them to deal with differences in the way pages and
applets look, so the learning curve for new kinds of systems seems to be reduced.
The security problem brings us to one of the divisions that seems to be automatically
forming in the world of client-side programming. If your program is running on the
Internet, you don’t know what platform it will be working under and you want to be extra
careful that you don’t disseminate buggy code. You need something cross-platform and
secure, like a scripting language or Java.
If you’re running on an Intranet, you might have a different set of constraints. It’s not
uncommon that your machines could all be Intel/Windows platforms. On an Intranet,
you’re responsible for the quality of your own code and can repair bugs when they’re
discovered. In addition, you might already have a body of legacy code that you’ve been using
in a more traditional client/server approach, whereby you must physically install client
programs every time you do an upgrade. The time wasted in installing upgrades is the most
compelling reason to move to browsers because upgrades are invisible and automatic. If you
are involved in such an Intranet, the most sensible approach to take is ActiveX rather than
trying to recode your programs in a new language.
When faced with this bewildering array of solutions to the client-side programming
problem, the best plan of attack is a cost-benefit analysis. Consider the constraints of your
problem and what would be the fastest way to get to your solution. Since client-side
programming is still programming, it’s always a good idea to take the fastest development
approach for your particular situation. This is an aggressive stance to prepare for inevitable
encounters with the problems of program development.

Java and the Internet

If Java is, in fact, yet another computer programming language, you may question why it is
so important and why it is being promoted as a revolutionary step in computer
programming. The answer isn’t immediately obvious if you’re coming from a traditional
programming perspective. Although Java will solve traditional stand-alone programming
problems, the reason it is important is that it will also solve programming problems on the
World Wide Web.
What is the Web?
The Web can seem a bit of a mystery at first, with all this talk of “surfing,” “presence” and
“home pages.” There has even been a growing reaction against “Internet-mania,”
questioning the economic value and outcome of such a sweeping movement. It’s helpful to
step back and see what it really is, but to do this you must understand client/server systems,
another aspect of computing that’s full of confusing issues.
58 Thinking in Java www.BruceEckel.com
Client/Server computing
The primary idea of a client/server system is that you have a central repository of
information – some kind of data, typically in a database – that you want to distribute on
demand to some set of people or machines. A key to the client/server concept is that the
repository of information is centrally located so that it can be changed and so that those
changes will propagate out to the information consumers. Taken together, the information
repository, the software that distributes the information and the machine(s) where the
information and software reside is called the server. The software that resides on the remote
machine, and that communicates with the server, fetches the information, processes it, and
displays it on the remote machine is called the client.
The basic concept of client/server computing, then, is not so complicated. The problems arise
because you have a single server trying to serve many clients at once. Generally a database
management system is involved so the designer “balances” the layout of data into tables for
optimal use. In addition, systems often allow a client to insert new information into a server.
This means you must ensure that one client’s new data doesn’t walk over another client’s
new data, or that data isn’t lost in the process of adding it to the database. (This is called
transaction processing.) As client software changes, it must be built, debugged and installed
on the client machines, which turns out to be more complicated and expensive than you
might think. It’s especially problematic to support multiple types of computers and
operating systems. Finally, there’s the all-important performance issue: you might have
hundreds of clients making requests of your server at any one time, and so any small delay
is crucial. To minimize latency, programmers work hard to offload processing tasks, often to
the client machine but sometimes to other machines at the server site using so-called
middleware. (Middleware is also used to improve maintainability.)
So the simple idea of distributing information to people has so many layers of complexity in
implementing it that the whole problem can seem hopelessly enigmatic. And yet it’s crucial:
client/server computing accounts for roughly half of all programming activities. It’s
responsible for everything from taking orders and credit-card transactions to the
distribution of any kind of data – stock market, scientific, government – you name it. What
we’ve come up with in the past is individual solutions to individual problems, inventing a
new solution each time. These were hard to create and hard to use and the user had to learn
a new interface for each one. The entire client/server problem needs to be solved in a big
way.
The Web as a giant server
The Web is actually one giant client-server system. It’s a bit worse than that, since you have
all the servers and clients coexisting on a single network at once. You don’t need to know
that, since all you care about is connecting to and interacting with one server at a time (even
though you might be hopping around the world in your search for the correct server).
Initially it was a simple one-way process. You made a request of a server and it handed you
a file, which your machine’s browser software (i.e. the client) would interpret by formatting
onto your local machine. But in short order people began wanting to do more than just
deliver pages from a server. They wanted full client/server capability so that the client could
feed information back to the server, for example, to do database lookups on the server, to
add new information to the server or to place an order (which required more security than
the original systems offered). These are the changes we’ve been seeing in the development of
the Web.
Chapter 1: Introduction to Objects 59
The Web browser was a big step forward: the concept that one piece of information could be
displayed on any type of computer without change. However, browsers were still rather
primitive and rapidly bogged down by the demands placed on them. They weren’t
particularly interactive and tended to clog up both the server and the Internet because any
time you needed to do something that required programming you had to send information
back to the server to be processed. It could take many seconds or minutes to find out you
had misspelled something in your request. Since the browser was just a viewer it couldn’t
perform even the simplest computing tasks. (On the other hand, it was safe, since it couldn’t
execute any programs on your local machine that contained bugs or viruses.)
To solve this problem, different approaches have been taken. To begin with, graphics
standards have been enhanced to allow better animation and video within browsers. The
remainder of the problem can be solved only by incorporating the ability to run programs
on the client end, under the browser. This is called client-side programming.

Persistence

When you create an object, it exists for as long as you need it, but under no circumstances
does it exist when the program terminates. While this makes sense at first, there are
situations in which it would be incredibly useful if an object could exist and hold its
information even while the program wasn’t running. Then the next time you started the
program, the object would be there and it would have the same information it had the
previous time the program was running. Of course you can get a similar effect now by
writing the information to a file or to a database, but in the spirit of making everything an
object it would be quite convenient to be able to declare an object persistent and have all the
details taken care of for you.
Java 1.1 provides support for “lightweight persistence,” which means that you can easily
store objects on disk and later retrieve them. The reason it’s “lightweight” is that you’re still
forced to make explicit calls to do the storage and retrieval. In some future release more
complete support for persistence might appear.