Brought to you by EarthWeb
ITKnowledge Logo Login Graphic Click Here!
Click Here!
ITKnowledge
Find:
 
EXPERT SEARCH ----- nav

EarthWeb Direct

EarthWeb sites: other sites

Previous Table of Contents Next


Java is supposed to be platform independent

If I had to pick one issue in this book that I think is most controversial, it would be platform-dependent applications. From what I read on the newsgroups and in the press, I think that many programmers agree with me. As you’ll see in Part III, I myself am quite torn about the whole idea.

Much of this concern is misguided, however. If Java is to fulfill its promise as a full-powered environment for developing applications, then it cannot be hobbled by requirements that are intended for applets on Web pages. Only by taking advantage of undocumented packages and the native API can Java programmers level the playing field with their C and C++ counterparts and produce commercial-quality applications.

The advent of Java-based network computers only extends the problem. On a network computer, anything you want to do must be done in Java. You cannot drop out to a native method in C. Therefore it is even more important to have full access to all the capabilities of Java.

What went wrong? What happened to the dream of applets moving transparently and easily between platforms? The answer is that Java succeeded. In fact, it succeeded wildly, much faster and far beyond the expectations of its designers. What was a simple language for consumer electronics has become the most rapidly adopted programming language in history. It is being used for applets on Web pages, for database front ends, for numerical analysis, for multi-player networked games, and for much, much more. It is no wonder that many of these programmers need capabilities and knowledge that were not originally planned for Java.

Why aren’t these things documented?

A question may occur to the inquiring mind: If these classes and methods aren’t documented, is there perhaps a good reason for that? Maybe these are things human beings were not meant to know.

Poppycock. Given the relatively few people working on Java, especially in its early days, combined with the large size of the API, it’s surprising that there aren’t more undocumented features. Indeed, there are many methods in the allegedly documented Java packages that literally qualify as undoc-umented by virtue of their poor documentation, but they are not discussed in this book.

There are four main reasons that certain parts of Java were left undocumented. The first and the most important for Java programmers to remember is that not all implementations of Java can be guaranteed to support these features. What works in Netscape may not work in Internet Explorer. Even more likely, what works in the appletviewer or HotJava may not work in Netscape. This is sometimes a problem for applets, but it is a fully surmountable problem for applications.

The second common reason why a Java class is undocumented is that the source code is in rather poor shape. Many parts of Java are held together by bubble gum and bailing wire. Java is full of quick fixes to unexpected problems pieced together by overworked programmers with insufficient resources. The Java team was simply not prepared for the stunning success of Java, and Javasoft has been desperately trying to catch up to itself. There simply hasn’t been enough time to whip the source code into shape while simultaneously fixing bugs, writing documentation, negotiating licensing agreements, adding features, and planning for the future. Some classes that were undocumented in Java 1.0, such as sun.net.MulticastSocket, became documented in Java 1.1, just as soon as Javasoft had time to do it. This code is nonetheless useful now, and it is available to you even if it’s not documented.

The third and related reason why these features are undocumented is the fear that making them public hinders future modifications. In many cases, JavaSoft may clean up the messy classes and quick fixes in the future and document them. Until then, however, they would rather not get tied to their original ad hoc solutions that were never properly thought out. It is believed that Java is in a much too early state of development to be locked into a half-baked API. This is almost certainly true. Java’s original event model was completely revised between Java 1.0 and Java 1.1. However, because the 1.0 model was documented and in widespread use, Sun was forced to continue to support it. Sun would rather limit the number of APIs locked into to the bare minimum until they feel more confident that they’ve made the right decisions. This attitude places the focus on what may happen in the future rather than on what is shipping today. At the speed at which the Web moves (One calendar month equals one Web year), programmers need solutions today, not next month or next year.

According to Sun (http://java.sun.com/products/JDK/1.1/ compatibility.html [as of January 14, 1997]), when discussing the changes from Java 1.0 to Java 1.1:

Some APIs in the sun.* packages have changed. These APIs are not intended to be used directly by developers. They are there to support the java.* packages. Developers importing from sun.* do so entirely at their own risk.

The fourth and final reason that the topics of this book aren’t properly documented is the mistaken belief that Java programmers simply don’t need to know. This confuses the issue of “need to know” with “need to use.” These are two different things. A deeper understanding of how Java operates leads only to more efficient programs. You don’t absolutely have to know exactly how a Web browser loads and instantiates an applet on a Web page to write applets, but if you do understand this, you’ll be able to write applets that play more smoothly and load more quickly. You won’t actually call any of the undocumented methods and classes in your own source code, but by knowing how they operate behind the scenes, you can map your use of the documented methods to work with them instead of against them.

Finally, both what programmers need to know and what programmers need to use are closely tied to the sorts of applications that programmers are building. What Javasoft has chosen to document so far assumes that programmers are building simple applets for Netscape. In reality, this is a plurality but still a minority of the programs that people are actually writing. Many other things that people are writing, especially development tools, need much more information than is required by a simple applet.


Previous Table of Contents Next
HomeAbout UsSearchSubscribeAdvertising InfoContact UsFAQs
Use of this site is subject to certain Terms & Conditions.
Copyright (c) 1996-1999 EarthWeb Inc. All rights reserved. Reproduction in whole or in part in any form or medium without express written permission of EarthWeb is prohibited. Read EarthWeb's privacy statement.