The following excerpt is from "Inside Java WorkShop," by Lynn Weaver & Bob Jervis. Sun Microsystems Press/Prentice Hall PTR book. (ISBN 0-13-858234-3; $39.95US) Copyright Sun Microsystems Inc., 1997.

The Java WorkShop design draws from the combined wisdom of the UNIX and the PC worlds. Here, Java has proven itself invaluable. Because Java WorkShop is written in Java, tools written as applets can share project information, allowing for sophisticated integration. Adding new tools is as easy as writing a new applet. Collaborative groups of applets can leverage the capabilities of Java to bring all kinds of new functionality to you. What you see today is only the beginning.

Java WorkShop is about helping you create a user experience. That user experience is created out of a combination of Web pages, multimedia, Java applets, and server code. Today, Java WorkShop provides a complete set of tools, integrated into a single environment, for managing the Java programming part of this problem. Most importantly, Java WorkShop uses a highly modular structure that enables you to easily plug new tools into the overall structure.

The real genius of Java lies not in its features per se, which were carefully selected from earlier languages, but in the way in which those features interact with the Internet. By providing a common programming interface for networking, graphical user interfaces, and multithreading, Java makes it possible for you to write the kinds of applications that are most needed on the Internet. By a lucky coincidence, corporate computing divisions all over the world have realized that most of their networking needs can be met by intranets, private computing microcosms that use Internet protocols.

Of Tools
If you are developing applets, you need to debug them in a browser environment, and Java WorkShop was the first to let you do that. We experienced this need as we developed Java WorkShop itself. Even though the WorkShop is a standalone application, we chose to use a browser look-and-feel, in part because the best way for us to understand the problems you face is to face them ourselves. Also, since we agree that the Web enables new ways of making software work, we needed to create an environment that exploited the Web as much as possible. It didn't make sense to preach the value of the Web and then to ignore it in our own tools.

Of Teams
The Web has also contributed to a trend begun by graphical user interfaces-a development team must include many more skills than ever before. Our own development team comprises programmers, writers, graphic artists, interaction engineers, human interface engineers, testers, translators, and evangelists. Software created for internal corporate use may not be quite as intense in its use of production values, but programming long ago ceased being a solitary activity. Java WorkShop provides support for easily sharing projects over the Web and also for version control integrated with your source editor. While these facilities help programmers specifically, we plan to provide better support for all members of the development team, not just the programmers.

The Great Cycles: Edit-Compile and Edit-Compile-Debug
When we thought about how to organize the Java WorkShop, we used the idea of two great cycles that a programmer goes through in creating a program. Most frequently, we cycle between editing our program and compiling it to discover compile-time errors. We can move on to the second cycle, editing, compiling, and debugging only when all the compile-time errors are gone. For example, if you use many compiles, you might put small amounts of new code into a program for each compile. It's easier to fix the errors, and then when you run tests, it's also easier to discover the causes of the runtime bugs. Different people have different styles, but integrated environments help cut the mechanical effort involved in working through the cycles. Rather than having to remember an assortment of commands, you let the environment take care of them for you.

Compilers are designed to diagnose as many distinct errors as possible in a source program. But how many distinct errors are in a program? If you made a mistake in the declaration of a variable, is each of the references to the variable also in error or just the result of the mistake in the declaration? If the compiler encounters an undefined variable name in the program, is the mistake a typo in the reference or in the original declaration? Only the programmer knows which spelling is correct. Eventually, you learn how a compiler responds. The common thread is usually some completely inexplicable error message complaining about what looks like a perfectly good statement or declaration.

In Java, many of the errors and diagnostics are quite similar to those of a C or C++ compiler, and the corrective action is the same. Java diagnostics differ from C or C++ in the area of importing classes. With C or C++, include files are sources, so they are all present or not, and the order in which you compile source files doesn't really matter. In Java, since imports work off previously compiled class files, there are a number of ways in which the current builder can report that class files don't exist but on a recompile, the diagnostics go away. This is usually due to some sort of ordering error in the build. Most of the time, the javac compiler doesn't care about the order in which you list the source files on the command line, but occasionally it does matter. Usually when this happens, repeating the build resolves the problem.

Sometimes a diagnostic shows up during a complete rebuild of your project. This is usually due to a hidden dependency that was only detected when the original class files were deleted and the sources were recompiled, for example, when there are circular dependencies among packages, so that a class in one package depends on the interface of a class in another package, and so on, until you get back to where you started from. The only way to satisfy the dependency is to make sure that all the source files in the cycle are compiled together. You may have to add source files to a package project that are not part of the package in order to do this.

Whether you are writing code for the Internet or your own corporate intranet, we believe that you are most likely to be trying to create network-aware software and a related Web site. Java WorkShop lets you develop standalone programs as well as applets.