BOTTOM LINE

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.

Object Lesson

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. Client-side Java shows up in two different ways: JavaScript and Java applets. (Actually, JavaScript and Java applets can run on Web servers as well.)

JavaScript is a simpler version of Java. When a Web client (such as Navigator or Internet Explorer) supports JavaScript, the page author can modify the behavior of the Web client somewhat. JavaScript isn't full Java--it's a small scripting language that complements Java applications which can run on both the client and the server. Web pages written in HTML may have bits of JavaScript on them, embedded in the pages as comments.

JavaScript programs don't have the full strength of Java behind them, but they are 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.

One of the first examples of JavaScript in a Web page was in an online ordering form: The form automatically calculated totals and sales tax as the customer filled it in, before hitting the Submit button. JavaScript has also been used to add animation to Web pages, change page content based on the location of the mouse, and build interactive chatrooms.

The next step up from JavaScript is a Java applet. Java applets are not embedded in Web 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.

Tangled Web

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 JavaScript you download are not designed to be malicious (i.e., the result of some 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 application once.

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

If you're an Internet user, you may want to consider disabling JavaScript and the Java 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 high.

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 magazine Vol. 8 No. 11, (c) 1997 Mecklermedia Corporation. All rights reserved.