The Trouble with Java
Java has arrived--but is it worth the trouble?
By Joel Snyder
We call her "La Pompa," an Italian-made, pump-driven espresso
machine. It provides my office with the best espresso in North America. And that's the
only java we use: Sun's Java programming language creates too many potential problems
to even consider using it.
There continues to be a lot of confusion about Java: what it's good--and not good--for.
Here are a few things to consider when deciding if Java is for you.
Java is an object-oriented language. Traditional programming languages, such
as C and Perl, are "procedural" and consist of a series of procedures that tell the computer
what to do.
In an object-oriented language, the emphasis is on the information a program manipulates.
Bits of information (data) are grouped together into "objects," which have rules for how
they can be manipulated. And because most programs essentially move bits of data from
one point to another, anything that can enhance this process is especially desirable.
Java was also designed to be an object-oriented environment, including the Java Virtual
Machine (VM), which is supposed to provide true platform independence. With the Java
VM, you can, it claims, write a program once and have it run on Windows, Macintosh,
Unix, OpenVMS, MVS, you name it. However, it seldom works as promised.
Nevertheless, Sun Microsystems touted Java as the premiere Internet application
implementation tool. This impression was confirmed when Netscape agreed to build Java
into its browser.
Brewing Java On The Net
When you talk about Java in the context of the Internet, there are actually three places you
find the language.
The first is on the Web server itself. Servers run programs to build Web pages on the fly,
handle indices, utilize shopping cart applications, or search databases. These can be written
in Java. (In this case, the choice of language is insignificant to the client user.) Large
Internet applications, where the traditional Perl breaks down quickly, are greatly enhanced
by the added power of Java. Platform independence isn't critical here, but the other benefits
of object-oriented software development are.
Many programmers are turning to Java for server-side Internet applications. However,
from the client's point of view, this is immaterial: You can't tell which application is
generating the data stream your Web browser is reading.
The other two places you can find Java are on the client side, as opposed to the server side.
applications which can run on both the client and the server. Web pages written in HTML
powerful enough to control and modify the Web browser. This lets the application
developer go beyond the standard click-to-do-anything model of the browser, although
usually in a fairly simplistic way.
form automatically calculated totals and sales tax as the customer filled it in, before hitting
page content based on the location of the mouse, and build interactive chatrooms.
pages; they are downloaded separately as precompiled objects. Like all Java applications, a
Java applet runs in the Java VM.
Java applets have a huge amount of power available to them. However, they are tightly
constrained by the Java VM they live in. For example, although the full Java VM has
access to the network facilities of its host operating system, the secure applet VM can only
make connections to the server it originated from.
Despite its benefits, the implementation of Java raises some serious concerns both for
network users and application designers.
The security issue is the biggest problem. Java security is based on blind faith. You must
trust that your Java implementation is perfect, has no bugs, and that the Java applets and
destructive Internet prankster).
When the basic purpose of a tool is to connect to a network so it can download and
manipulate data, you've got to have a lot of confidence that it isn't going to go berserk.
And in the case of Java, I don't. Now, you might say, you can extend that argument to
any network application: If I don't trust Java, then why should I trust Netscape Navigator
or Microsoft Internet Explorer? That's a good point, but there's a big difference between
what Navigator does with a page of data and what Java does with an applet.
When a Web browser reads a page, it interprets the HTML code: centering, bolding,
pulling in graphics, and so on. There are no operations in HTML to say "read this file from
disk" or "send this data across the network." Any security bugs on the Web browser will
be due to extensions by the vendor or some other error. On the other hand, Java is a
complete programming language. HTML can be explained to a novice in about 10 minutes;
Java is as complex as any other programming language. The potential for bugs in a system
is directly related to the size of the system, and Java is big.
While there are some standards afoot to help you identify where a Java applet originated,
none of these are supported in today's browsers. More importantly, the security experts
designing these security measures have hopelessly naive ideas about how much bother
people will go through to keep their computers secure.
The other problem with Java is its lack of compatibility. Like most programming
languages, Java has a specification that controls how it operates. That's fine, except that the
two major places you'll see Java operating in the client--Navigator and Internet Explorer--
are not perfectly compatible with each other. This is directly antithetical to the nature of
Java: The language is supposed to be ubiquitous, so that you only have to write your
For example, one of my clients makes historical data on agriculture available over the
Internet. The company uses Java to assist the reader of the data in analyzing and
summarizing the information. But it had to "just say no" to Microsoft because its Java
implementation isn't compatible with Netscape's.
Protecting Your Privacy
language in your Internet browser if you have anything on your computer that needs to be
kept confidential. On a private network, where you trust your server, Java is a great tool.
But on the public Internet, the potential for loss or the unauthorized disclosure of data is
If you're an Internet developer, counting on Java being present in your client's public
Internet is a bad idea. Of course, if you're on a private intranet or if you have a special
relationship with the people using your site, you may be in luck. However, if you can't
convey your message without using Java, you should reconsider your design.
Finally, disregard what people say about how wonderfully portable Java is. Only the most
rudimentary applications will work across platforms. This will probably get better over
time, but it's going to be a while before we get to that stage.
Joel Snyder is a senior partner at Opus One,
an IT services firm, in Tucson, Ariz.
Reprinted from Internet World
Vol. 8 No. 11, (c) 1997 Mecklermedia
Corporation. All rights reserved.