Web Wandering: Java

Java is either going to change the world, or it isn't.

Here Be Hippogriffs

I'm not much of a fan of Java. That's obvious. Still, it's not my job to decide what technologies other people should waste their time on. People are interested in Java, so it's my duty to write about it.

Nobody said I have to be objective, though, so here's my list of the Top 12 Reasons not to use Java:

1. No pointers. Java's developers seem to think that C programmers only use pointers for hacking strings. Java has a String data type, so pointers won't be missed, right? That shows you how little Java's developers know about building real applications.
2. Security. Running in a browser, Java doesn't have enough security for users (new breaches are constantly being discovered), yet it has far too much security for developers (if you want to do it, the chances are you can't).
3. Javascript. It's like Java, it uses the same syntax as Java, but it isn't Java. Instead, it has its own completely different set of flaws and limitations. Javascript's most famous application to date: sending private information about you to Internet data scavengers using browser "cookies."
4. No infrastructure. Developers have spent the last several years creating software components and tools for real languages like C++. This trend has now reached the point where you can buy a compete spreadsheet component, for example, and plug it into your application in seconds. Java has none of this; unless a whole bunch of people start rewriting their components in Java, it'll be years before Java components reach the maturity of those now available for C. And, of course, the C component developers won't be standing still in the meanwhile.
5. Bad tools. Java tools are now where C++ tools were five years ago: in pretty sad shape. They're getting better, but there's still no comparison with a development environment like Borland C++ or Microsoft Visual C++.
6. Senseless duplication. I've been able to find eight different ways to write a line of text to an ASCII file using Java. There may well be more. All of these ways work, and all are syntactically correct. Why is it, then, that some of these methods are ten times faster than others? Why do we have to figure out the "right" way by trial and error? The whole point of object-oriented programming is to reduce this sort of API-induced confusion.
7. The missing inheritance. Java's designers went whole hog in objectifying the Java API: everything inherits from something else. Unfortunately, though, lots of Java API objects ignore the properties and methods of their parent classes. Try setting the foreground and background color in a Button and you'll see what I mean.
8. Event method madness. Most OO languages provide a message map or discrete methods to respond to events. For example, if your application has a button, you usually will have a function that is tripped only when that button is clicked. The function doesn't need to respond to any other events or contain any code not related to the button click event.
   Java has--that's right--the equivalent of Windows's dreaded Big Switch Statement. There's only one event handler for an applet; you have to test and dispatch events yourself. This is only one example of a basically inept language design, a design which I find difficult to forgive. Java's builders were starting from scratch, yet they didn't bother to learn from the experiences of all those OO programmers who went before.
9. Machiavellian class design. In a real object-oriented language, if you wanted to create a button that behaved differently than the one supplied with the language, you would inherit from the language's Button class and override existing methods. For example, to create a plaid button, you might override the supplied Button class's Paint method.
   Good luck doing that in Java. Despite the fact that the Java Button class has a Paint method listed in the API and the documentation, the Paint method is never called. That's right: Java's designers just included that method to tease you. Button painting is hard-coded into the Window Toolkit, where you can't easily get at it.
   It's not that you couldn't build a button from the supplied class, it's just that the way you need to do so is insanely complex and indirect. Take a look at the Java base class library source code some time, and you'll see what I mean. Sun's own designers weren't able to build their class library without thoroughly macerating object-oriented design principles; how are mere mortals supposed to survive?
10. Platform independence. Too bad there isn't much. Only the simplest lowest common denominator Java applications work in exactly the same way on all platforms. As soon as you rise above the primordial ooze, you start running into trouble. The differences are most pronounced in applets run from Web browsers: not only do applets work differently (or not at all) depending on the browser being used, they even depend on the version of the host browser. Some Java applets run in Navigator 3 and not in version 2, and vice versa. I shudder to think what will happen when somebody writes a really complex application in Java and then tries to run it on all those "independent" platforms…
11. Code bundling model. Within a Java program, each public class you define lives in a separate file. Complex applets will probably have dozens or hundreds of classes. Each class will have to be downloaded from the server. Each download means a connection to the server, and you know how long those can take.
    Even better, most Java applets will probably want to use graphics. That's right: each graphic has to be stored as a separate file on the server and downloaded before the applet can begin running. Lots and lots more connections to the server.
    For Java applications meant to run locally on your system (like Excel rewritten in Java, right?), imagine today's problems with DLL versions multiplied by a thousand. Combine that with the fact that every Java developer will probably name at least one of his classes "MyClass" and you have the ingredients for a real nightmare.
12. IBM. IBM recently embraced Java, promising to build it right into a future release of OS/2. Name one smart decision IBM's software division has made in the past few years.

If you must…

Some people embrace Java of their own free will; others have it thrust upon them. If you're one of those unlucky souls who can't escape, or if you believe all the hype (remember Pen Computing?) and want to use Java, herewith a brief introduction.

If your browser is Java-enabled (as are Netscape Navigator 2.01 or later and Microsoft Internet Explorer 3.0), you should see a Java applet above. It's hopefully labeled "WinPost Search."

This applet is simple to the point of silliness. All it does is forward a search to one of four Internet search engines: Infoseek Ultra, AltaVista, Yahoo, or DejaNews. Though hardly Office 97, it does perform a useful function: if you submit a search through the applet, you don't have to wait for your chosen search engine's advertisement-raddled front page to load. You jump directly to the engine's advertisement-raddled results page.

To use the applet, you just type the word or phrase you want to search for in the "Search" field, then click the button for the engine you want to search. Simple. If everything works, you should see the search results page after a few moments.

How it got there

Obviously, my little applet didn't spring into existence of its own free will. If it had, it would do something more interesting. So, what do you need to create a Java applet? First, you need to know the language.

Learning Java

Java is the Next Big Thing. Bookstore shelves groan beneath the weight of tomes on this new language that makes all preceding languages obsolete. By all means, peruse the selection and bring home a few of the heftiest; writers need to make a living too. If your funds only run to one treatise, I recommend "the Purple Book," also known as Hooked on Java (van Hoff, Addison-Wesley, 1996).

Hooked on Java isn't for amateurs. At 180 pages, it's very dense; more than 50 pages are devoted to screen captures of sample applets. Not much room to introduce a whole new language.

If you're already familiar with object-oriented programming (especially using C++), Hooked is a great book. It introduces the essentials of Java without spoon-feeding you basic programming techniques. Even better, once you've got the basics, Hooked functions as an excellent reference guide. It's well-organized for those moments when you need to look up some bit of Java arcana.

You'll still need a reference to the Java API; the book only covers the highlights. Java development tools like Symantec Café usually include a complete hypertext version of the Java API reference, which is probably better than a book anyway. The hypertext links allow you to understand and follow the intricate interrelationships between API classes.

Getting a development tool

There are now several commercial Java development environments, such as:

• Microsoft Visual J++ (not yet released)
• Borland Latté (coming soon, supposedly)
• Sun Java Workshop
• Symantec Café

My favorite is Symantec Café, which can be purchased online if you're in a hurry. It offers many of the features of real development environments like Microsoft Visual C++.

Café's debugger and source code editor are adequate, but its class browser and online help (including a complete hypertext API reference) really shine. The ability to view your code by class and member function is indispensable for Java development.

Creating an applet

Building a Java applet is like programming in any other language, only more frustrating. Java is somewhat like C++, so if you know C++, you'll quickly manage to find all the ways Java isn't like C++.

Fortunately, building the applet framework is no longer something you have to do yourself. Most Java development tools will now create a basic applet for you automatically. Some can even generate the code needed to display a form like the one in my sample applet above.

You might want to take a look at the source code and resource file for the sample WinPost Search applet. That should give you an idea what Java code looks like, if you've never seen any.

At this point, I must insert a disclaimer: I actually wrote only a few lines of the Search applet. Most of the code was generated automatically by Café.

To build the Search applet, I created a new project in Café. I then fired up Café Studio, the development environment's resource editor. I added a resource, the main form, and populated it with the label "Search:," the text field where you enter your search, and the four buttons. For each button, I added an event handler for the "click" event.

When I closed Café Studio, the program automatically created a working Java applet framework, including functions for the four click events. I take no responsibility for the nasty if statement in the handleEvent member function; that was generated by Studio, as were the calls in the init function that actually "create" the form.

In fact, the only function I wrote myself was SendQuery. That's the function that creates the URL from the search text and engine selection, then tells the browser to jump to that URL. The rest of the program was created entirely automatically.

Once I'd written the SendQuery function, I used Café's class browser to add the appropriate SendQuery function call to each of the four click event handlers. For each SendQuery call, I figured out the URL prefix by looking at the HTML source of the relevant search engine's front page.

Compile, test, and done! That's really all there is to it.

Embedding the applet

Once you've got a running Java applet, you need to put it somewhere it can be used. Though Java programs can be run on your computer using the Java Applet Viewer, you have to be fairly masochistic to use Java to develop desktop applications; so many better tools exist.

Java's usefulness comes from its ability to run within Web browsers. To embed a Java applet in a Web page, you use HTML tags like this:

<APPLET CODE="winpost.class" WIDTH=480 HEIGHT=86></APPLET>

The Applet tag is fairly straightforward. The Width and Height values determine the size (in pixels) of the window in which the applet will run. The Code value determines the name of the target applet's main class, winpost.class in this case.

The Code parameter follows the same rules as the SRC parameter in the IMG tag. If no path is specified, the applet is assumed to reside in the same location as the HTML document that refers to it. However, you can just as easily place your applet in a different directory or even on a different server; just put the correct URL in the Code parameter.

The .class extension indicates compiled Java code. The .class files for your applet will be created automatically by your Java compiler. There will be a .class file for every public class in your applet; to reduce download time, it's a good idea to reduce the number of public classes as much as possible.

The Applet tag shown above is really the simplest possible embedding code. There are lots of other things you can do, such as supply parameters, and so on. These variations are described in some detail in Hooked on Java.

One important note: Java uses file extensions that are longer than three characters, in particular, .class and .java. For this reason, it tends to be hard to host Java applets on a DOS system. If you are developing under DOS (heaven forbid) or under Windows 3.x, you need to make sure these extensions are respected when your pages arrive on the server (especially .class); if you don't, your applets probably won't work.

When a browser downloads a page containing an applet, it immediately launches its Java Virtual Machine (or "just in time" Java compiler, in some cases) and passes control to the applet's startup method. Your applet can be running before the page has fully downloaded.

The applet will continue to run until it terminates itself or the browser jumps to another page. If someone brings their browser "back" to the page containing your applet (using the "back" button or equivalent), at least some of the applet's state will be preserved. Text fields, for example, will keep their contents. I've had varying results with this feature, including some spectacular crashes, so I wouldn't rely on a Java applet working properly under these circumstances.

If a browser that doesn't support Java downloads a page containing an applet, the Applet tag is just ignored (one of the major strong points of HTML).

That pretty much covers the basics, and should give you enough information to get into plenty of trouble.

Places to get Java information

The official Java site is a good place to start. Since the Java and Javascript worlds are changing pretty fast, I recommend looking in the Yahoo Java Resources page to find interesting new sites. There's also the unofficial Java applet clearinghouse Gamelan; that's a great place to find applets, many with source code so you can see how the magic gets done.

So why don't I like Java?

After seeing an applet like WinPost Search developed in fifteen minutes, you can see how the Javaheads out there believed their language would change the world: a useful little program created with almost no effort. Sadly, it works this way because I chose my tiny applet's task very carefully. There are many equally simple-sounding tasks that would need thousands of lines of Java code to develop.

It's also worth noting that the applet's user interface is incredibly primitive when compared to even the simplest Windows 95 application. I stuck to Java's pathetic set of built-in controls and didn't do anything to change their default appearance. Nobody used to typical Windows applications would be satisfied with WinPost Search if it wasn't a free test application.

The problem with Java, finally, is that it's just a programming language, and not a very well-designed one at that. Expecting it to change the world, destroy Microsoft, and all those other things is insanity. It's people, not programming languages, that change the world.