Java is a programming language from Sun Microsystems, but Java is more than just a programming language. Java works well for server-based applications with great features like easy database access, object-oriented programming, professional-looking GUI support, network libraries, and built-in security.
One of the biggest assets of Java is its ability to run on all computers. You can compile a Java program on a Linux system, take the binary over to your Windows PC, IBM mainframe, or Macintosh system, and just run it. Java achieves this by layering a common runtime library on top of each operating system and having one common executable format that runs on all computers. Java is really a complete computing platform, just as the Macintosh, Windows XP, and OS/390 are platforms.
The computer industry has flocked to Java for solid practical reasons. A study by Evans Data Corp in 2001 found that more than half of North American programmers already use Java. By 2002 more developers will be using Java than C/C++/C# or Visual Basic. Java usage is even stronger outside North America, with around 60% of developers doing some part of their work in Java.
Java provides a robust way for organizations to streamline and integrate incompatible computer systems. And yet Java is not complicated. Programmers seem to enjoy working in Java because they can accomplish more, more quickly. You hear many stories about C++ programmers who try Java and never switch back. You can be more productive in Java than in other similar languages for two reasons:
Java has a large (almost overwhelming) set of rich libraries. These libraries are “building blocks” for your systems. The libraries are identical on all Java implementations on all computers. There are libraries for data structures, for speech processing, for image manipulation, for database access, for cryptography, and many more.
The language was designed so that some common bugs either can’t happen, or are caught as soon as they occur. For example, array indexes are always checked to be within bounds; the language is strongly typed; type conversions are checked for validity as a program runs; and memory address arithmetic, a frequent source of bugs in C, is not allowed.
Java was released to the public in the summer of 1995, and its popularity has grown faster than anyone imagined. In a 1996 meeting of the Mountain View, California, Java Users Group, I asked the designer of Java, James Gosling, how long it would be before we could throw away our C++ books in favor of Java. He started to giggle because the question seemed so audacious at that time. By summer 2001, developers downloaded the compiler more than 5.5 million times from Sun’s website alone.
Since Java runs anywhere, the total potential market for all these developers is the 350+ million computer systems in the world. Java is well positioned to replace Windows as the high-volume platform of the computer industry. With only one exception (guess who doesn’t want to see Windows replaced by something better), Java has united all the players in the software industry behind it.
No programming language in the past has ever gathered so many developers in such a short space of time. Due to the attention it has received, programmers (especially students) frequently ask, “Should I learn Java or Perl, C++, C?” The answer is, “Yes.” You should learn several programming languages and be familiar with several more.
Java is easy to learn. The language is covered in the first few chapters of this book, and the rest of the book introduces the Java libraries, which are extensive.
For those who want to get off to a quick start, this section walks through the compilation and execution of a Java program. Just follow these numbered steps:
Download and install the Java Software Development Kit (SDK) as described in the previous section, “ Using the Just Java CD-ROM.”
Follow these rules very carefully when you write and compile your own programs:
The name of your Java class or module must match the name of the file that it is in. This means an exact match, including letter case and spelling! If you call your Java class
TrYmE, then it must be in a source file called “TrYmE.java”. Letter case matters throughout Java such that, for example, the word “System” is different from the word “system,” and you cannot use one in place of the other.Avoid development environments at first—they just add another thing to learn at this stage. Use an editor that saves in an ASCII text format, not a word processor format, and make sure it doesn’t change the file name. On a PC, EDIT works. Notepad works if you put quotes around the file name when you save it, as in “myframe.java”.
Type the program on the next page into a file called
myframe.java,or you can simply copy the file off the CD. Put the file in a separate little directory called, say, c:work. Don’t put the file anywhere in the directories belonging to the Java compiler you just installed. Stay out of those directories.Note: It is tempting fate to print these lines in a book and ask readers to copy them exactly. Such examples are notoriously prone to proofreading and printing errors. Just copy this file off the top directory of the CD if you have trouble. This program is explained in detail in Chapter 3, “ Explanation of a Sample Program.”
Ensure that you follow that rule about the file name matching the class name, even to the letter case! The file name must have the suffix of
.java,too.Sample Java Program
// 40 line Java demo, Peter van der Linden // rolls colored text across the screen import java.awt.*; class myframe extends Frame { static int x=0,y=120; // x,y position to display message static int i=0; static int horizScroll=1; // 1->we are moving msg L-to-R Font fb = new Font("TimesRoman", Font.BOLD, 36); String msg[]={"Java", "Portable", "Secure", "Easy"}; Color color[]={Color.blue, Color.yellow, Color.green, Color
.red};
public void paint(Graphics g) { // gets called by runtime
library
g.setFont( fb );
g.setColor( color[i] );
g.drawString(msg[i],x,y);
}
static public void main(String s[]) throws Exception {
myframe mf = new myframe();
mf.setSize(200,200);
int pixelsPerLine=200, totalLines=4;
mf.setVisible(true);
for (int j=0;j<pixelsPerLine*totalLines; j++) {
Thread.sleep(25);
mf.repaint();
if (horizScroll==1) { // increase x to scroll
horizontally
if ( (x+=3) < 200) continue;
i = ++i % 4; // move index to next msg/color
x=50; y=0; horizScroll=0; // scroll vertically
next time
} else { // increase y to scroll vertically
if ( (y+=3) < 200) continue;
i = ++i % 4; // move index to next msg/color
x=0; y=120; horizScroll=1; // horiz scroll next time
}
}
System.exit(0);
}
} Open a command line window to get a DOS prompt on Windows or a command shell on Unix (see Figure 1-1). Compile the program by typing:
javac myframe.java
There should be no error messages from this compilation. If there are, you probably typed something wrong in the file or the command. Correct it and try again.
A successful compilation will create file
myframe.class. Execute the Java class file like this:java myframe
If you have entered everything correctly, your results will look like Figure 1-2, which shows a screen capture of the program running on Windows 95.
The program goes through a few iterations and then exits. For simplicity, there isn’t any code to let you terminate the program prematurely. We explain this code in full in Chapter 3.
It’s exciting that such a program can be written in less than a page of code. Copy the myframe.class file onto a floppy disk and walk it over to a different system. Run it on the Java system you install there and marvel at the possibilities of universally portable software.
Java executables run on all computer systems, as shown in Figure 1-3. You compile a Java program once on any system and run it anywhere—on a Macintosh, on Windows 98, NT, 2K, XP, on Solaris, Linux, BSD or any of the varieties of Unix, on IBM’s mainframe operating systems, and even on cell phones, Personal Digital Assistants (PDAs), embedded processors, and smart cards (credit cards with a microprocessor and memory).
Figure 1-3. Future-proof software: Your Java application runs on every system that supports Java. No more “123 for DOS, 123 for Windows 3.1, 123 for Windows 95”; just “123 for Java,” and you’re done.
You may be thinking that portability does not affect you: Your software runs on your PC and that’s all you ever use. That’s true, right up until the time you want to buy a new system. Then you are faced with the “choice” of walking away from your investment in existing software, or buying a system that has some compatibility with your previous system. You’ve been locked in.
For businesses, the problem is worse and far more expensive. Even if your whole organization has standardized on, say, Microsoft Windows, there have been very many releases over just the last decade: MS-DOS, Win 3.1, Win3.11, Win95A, Win95B, Win98, ME, NT 3.1, NT3.5, NT3.51, NT4, 2K, numerous service packs, and now XP. These platforms have subtle and different incompatibilities between them. Even applications running on a single platform have limited interoperability. Office 95, for example, cannot read files produced by default from Office 97, even when the files don’t use any of the new Office 97 features.
Microsoft will eventually switch to a 64-bit operating system to match the Intel Merced/Itanium/McKinley 64-bit processor line. It will break a lot of existing C/C++/C# code, just as moving from Win 3.1 to Windows 95 obsoleted most of our software. To use the new 64-bit architecture, the majority of C-based programs will have to be ported or rewritten.
Many of us remember past transitions. Few DOS applications survived under Windows 3.1, and none prospered. Few 16-bit applications survived Windows 95. They looked clumsy or had problems running, where in Windows 3.1 they looked great and worked fine. In five years’ time, it’s unlikely you’ll be using the OS you use today. But if you code your programs in Java today and avoid OS dependencies, your software will keep running regardless of the operating system and hardware changes. Java’s cross-platform design already runs unchanged in 64-bit mode on Solaris, and protects users from system evolution.
Software portability is about “future-proofing” your software. Rewrite it in Java, and that’s the last port you’ll ever need to do. Portability is the Holy Grail of the software industry. It has long been sought, but never before attained. Java brings the industry closer to true software portability than any previous system has.
Java portability poses a real threat to Microsoft. Software that can run on any operating system has a larger market than software that is Windows-only. Over time ISVs will move their products away from Windows-only to Java—unless Java can somehow be spoiled or broken.
It is unfortunate for you, me, and all computer users that Microsoft’s Java strategy is to try and undermine the language. At first, Microsoft introduced deliberate incompatibilities into the Java product it licensed from Sun. Microsoft paid $20M to Sun to settle the resulting court case. The current Microsoft plan is to push the C# language, which is barely different enough from Java to avoid another lawsuit. There’s a lot of window-dressing about getting some hapless standards body to rubber stamp C# the way they did with Activex, but the key libraries will be only be available on Windows, and Redmond will control them. You might want to bear this in mind as you think how to future-proof your software investment.
It’s not easy to support software that runs on everything from a cell phone to a supercomputer. Sun has achieved it by defining three different “editions.” The language is the same everywhere; the bundled libraries are subsets in smaller editions.
Enterprise Edition (the “large” platform). This development product is intended for those building enterprise-class server-based applications. It contains everything in the standard edition, and additional libraries for enterprise directories, transaction management, and enterprise messaging.
The Enterprise Edition is also known as Java 2 Enterprise Edition or “J2EE” for short.
Micro Edition (the “small” platform). The Micro Edition is a very low-footprint Java runtime environment, intended for embedding in consumer products like cell phones and other wireless devices, palmtops, or car navigation systems. You will develop your code using J2SE, and then deploy onto the various small devices.
The Micro Edition is also known as Java 2 Micro Edition or “J2ME” for short.
The J2ME environment is further subdivided into “profiles.” There is a profile that defines the libraries available to PDAs. Another profile fits wireless devices. The smallest profile, which runs in just 128 Kbytes of memory, is intended for smart cards.
The J2ME environment is enjoying enormous success and shipped in more than 4.5M cell phones by 2001. The year 2002 marks the point at which the number of handheld computing devices sold exceeded the number of PCs sold, so Java’s success in this challenging sector is a real landmark.
Standard Edition (the “medium” platform). Most people will use this development product. It is the standard development kit, including a compiler and a runtime system. Using it, you can write, deploy, and run Java applications and applets for desktops and low-end servers.
The Standard Edition is also known as Java 2 Standard Edition or “J2SE” for short. This text covers J2SE. There have been more than 5.5 million downloads of J2SE, and it is the right place to start learning Java. The different releases of the Java Development Kit over the years, and the most important content each introduced, are outlined in Table 1-1.
You should install and run the most up-to-date version of the JDK available to you, but don’t use a beta release for a production system. Check Sun’s Java website for the latest download.
The intention is to ship new releases on a regular 12-18 month cycle, with each update including a combination of quality and performance improvements and a small amount of new features. That’s the intention, but some releases (like 1.4) have a lot of new features.
Table 1-1. Java Development Kit Releases
|
JDK Version |
Date |
Content |
|---|---|---|
|
JDK 1.0.2 |
Jan. 1996 |
Standard libraries for I/O, networking, applets, file I/O, basic windowing. |
|
JDK 1.1 |
Feb. 1997 |
Inner classes, new event handling model, RMI, java beans, JDBC, serialization, internationalization, the Calendar class, performance. |
|
JDK 1.2 |
Dec. 1998 |
Floating point changes, “Swing” GUI library, collections, Java 2D graphics, and accessibility (GUI support for people with visual impairments), reference objects, performance. This release and later ones were rebranded to “Java 2.” |
|
JDK 1.3 |
May 2000 |
Performance improvements, CORBA compatibility, Java sound, Java naming and directory interface. |
|
JDK 1.4 |
Dec. 2001 |
Assertion statement, 64-bit address space on Solaris, new I/O, pattern matching, mouse wheel support, IPv6, some XML, Webstart support, performance improvements. Code named “Merlin.” |
|
JDK 1.5 |
July 2003 |
Generics (code templates), possibly some operator overloading. Code named “Tiger. |
So how do you get the amazing portability that allows a single executable to run on systems with different instruction sets? Java source code is compiled to produce object code, known as bytecode. So far, this is just like any other language. The critical difference is that bytecode is not the binary code of any existing computer. It is an architecture-neutral machine code that can quickly be interpreted to run on any specific computer. You execute a Java program by running another program called the Java Virtual Machine, or JVM. The JVM is typically invoked by running the program called java. The JVM reads the bytecode program and interprets or translates it into the native instruction set.
This feature is highly significant! Running bytecode on a JVM is the reason that Java software is “Write Once, Run Everywhere.” A Java executable is a binary file that runs on every processor. A Java program is compiled on any computer, and run on any computer.
The Java Virtual Machine—a fancy name for an interpreter—needs to be implemented once for each computer system; then all bytecode will run on that system. There are several alternative JVMs available for the PC, the Macintosh, and Linux, and they differ in speed, cost, and quality.
Program portability through use of an interpreter for common bytecodes is not a new idea. The UCSD Pascal system ran the same way. Smalltalk, popularized a while back at Xerox PARC and more recently by IBM, uses the same approach.
Bytecode is not just for Java. If you modify a compiler for some other language, such as Ada, COBOL, or Visual Basic, so that it outputs bytecode, you can run it equally well on the JVM on any computer. One developer drew up a list [1] of 160 languages that had been retargeted to run on the JVM. The list included Perl, Forth, Pascal, C, COBOL, many varieties of BASIC, C++, Lisp, some functional programming languages, Scheme, Prolog, many research languages, Ada, Python, Modula-2, and more.
Today, every Solaris system ships with Java. Both Compaq and Dell preinstall Java on their Windows XP systems. These companies are the top two vendors of PCs worldwide. Apple ships Java 2 as part of Mac OS X, and many of its system tools are written in Java. Sharp’s latest palmtop PDA runs Java. Sony ships Java as part of the Playstation 2. Java is everywhere.
The Java platform has several pieces:
Java programming language
Java Virtual Machine (interpreter/compiler)
Software libraries accompanying the system
Runtime environments
While mentioning the pieces that make up Java, note there is some software that includes the Java name but is only marginally related to Java. JavaScript is used in the Netscape browser to prompt the user for input and then to read it, open and close additional windows, and so on. JavaScript supports an elementary browser programming capability, but is not a general-purpose applications language as Java is. You don’t need to learn JavaScript to be a Java programmer. If you already know JavaScript, it neither helps nor hurts.
As you read through the following sections describing the features of Java, you may recognize various good ideas that were pioneered by earlier systems. Java does not introduce many things that are wholly new; the innovation is in the blending of so many established good ideas from several sources.
Java is an object-oriented programming language in the same family as C++, Pascal, or Algol 60. It adopts ideas from non-mainstream languages like Smalltalk and Lisp, too. Java is a strongly typed language, has data declarations, and has statements that operate on the data. The statements are grouped into what other languages call functions, procedures, or subroutines. Since Java is an object-oriented language, we call the functions methods. Methods can call other methods and can be recursive (call themselves). Program execution begins in a method with the special name main().
If you are already familiar with object-oriented programming, great! If not, Chapter 2, “ The Story of O: Object-Oriented Programming,” explains the terminology, the ideas behind it, and how the ideas are expressed in Java.
Java is immediately recognizable to many programmers. The statements and expressions are similar to those in other languages and, in most cases, identical to those of C or C++.
Although Java adds some new things, it is equally notable for what is left out. The designer of C++ once wrote, “Within C++, there is a much smaller and cleaner language struggling to get out,” (Bjarne Stroustrup, The Design and Evolution of C++, Addison-Wesley, 1994: 207). Of the people who agree with that prophetic statement, many think that the name of that smaller and cleaner language is Java.
The size of the basic datatypes, such as integers, characters, and floating-point numbers, is laid down in the language and is the same on all platforms. If a computer system doesn’t support, say, 64-bit long integers, it must simulate them in software for Java. In this way, you get the same numeric results no matter what computer runs your program. The Java specification was adjusted recently to provide a better fit for the Intel x86 platform that does some floating-point calculations in 80 bits, even though it only has 64-bit registers to store the results.
We’ll also be covering the following Java language features in later chapters:
Threads. Threads let a program do more than one thing at once, just as timesharing lets a computer system do more than one thing at once.
Exceptions. Exceptions let a programmer deal with error conditions when most convenient, instead of cluttering up the main flow of control with lots of error-checking and code-handling.
Garbage collection. With garbage collection, the runtime library, not the programmer, manages the use of dynamic storage and reclaims (frees) memory no longer in use in a program.
For those who like to study language reference manuals, the Java specification is online at java.sun.com/docs/books/jls/html/index.html. It is also published in book form as The Java Language Specification.
Note that there are no royalties due for the use of Sun’s Java compilers, runtimes, or the software you build with them. Sun has written a perpetual, irrevocable, free, and royalty-free license for the Java specification. Sun realizes that Java has the best chance of succeeding if everyone in the computer industry can share in the benefits. In other words, use of Java does not exchange one monopoly for another. Instead, Java enables open competition on a level playing field, with participation by all.
Much of the real value of Java is in the set of cross-platform APIs (described in the following box) that come with the system. Java has possibly the easiest-to-use networking and windowing (GUI) of any language, and that has helped its widespread adoption. For example, there is a library function to read a JPEG file and display it on the screen. There is another library function to make a method call to a Java program running on another computer, making distributed systems easy to build.
The Java libraries can be divided into two categories:
Core libraries bundled with the Java Development Kit (JDK): These are the class libraries that every JDK must support.
Optional standard additions to the JDK: These are the class libraries that are optional. If the feature is supported, however, it must be supported with this API.
There are so many additional libraries and packages announced for Java at this point, they alone would make a topic for a pretty thick book. The following Tables 1-2 and 1-3 provide an overview of the Java libraries; in the second half of the book, we’ll cover the use of the mainstream class libraries.
These libraries will give you some idea of the richness of the Java platform. I suggest you glance over them at this time. Later, when you have mastered the basics of the language and are looking to try different application areas, you can return and take a longer look.
The following API families were public when JDK 1.4 was released. Sun occasionally adds a library or uses a different grouping. You can always find the most up-to-date information on Sun’s Java web page java.sun.com.
Table 1-2. Core APIs and Their Purposes
|
Core API |
Purpose |
|---|---|
|
Java runtimes |
Standard runtime libraries for I/O, networking, applets, basic windowing, data structures, internationalization, math operations, and more. |
|
Java Foundation Classes |
“Swing” GUI library, Java 2D graphics, and accessibility (GUI support for people with visual and other impairments). |
|
Security |
Support for digital signatures, X.509 certificates, and message digests. Exportable worldwide. |
|
Java IDL |
(Java Interface Definition Language) Used to talk to CORBA middleware. |
|
JDBC |
(Java Database Connectivity) Library for database access. |
|
JavaBeans |
Software component library. |
|
Java RMI |
(Java Remote Method Invocation) For communicating with other Java processes, possibly on other systems. |
Table 1-3 shows some of the Optional Package APIs—some additional libraries that can be downloaded and added to one of the editions. When installed, optional packages are treated exactly like other parts of the runtime library, giving them some extra privileges over user code.
Optional packages are the new name for what used to be known as “standard extensions.” Standard Extension was a very poor choice of name: if something is standard, how can it be an extension? Thank heavens Sun finally fixed this.
Table 1-3. Some Optional Packages and Their Purposes
|
Optional Package |
Purpose |
|---|---|
|
Java Communications |
Support for reading and writing the RS232 serial and IEEE 1284 parallel ports on a computer. Enables faxing, voice mail, and smart cards. |
|
Infobus |
A library contributed to Java by Lotus. Used to send data between communicating components and applets. |
|
JavaHelp |
Platform-independent framework for online help. Can be embedded in a program or used stand-alone in a browser for online documentation. Content can be client-side (fast) or server-side (shared). |
|
JavaMail |
Protocol-independent framework for building Java-based mail and messaging applications. Supports IMAP (client/server mail) and SMTP (Internet mail transfer). |
|
Java Media |
Large API set containing individual packages for 3D imaging, MIDI sound, remote collaboration, each processing, telephony, and video and audio streaming. |
|
JNDI |
(Java Naming and Directory Interface) A library to get information from LDAP, NIS, or other enterprise directory service. This became a standard part of J2SE in release 1.3. |
The Java Media libraries are optional packages because they make heavy demands on the hardware (like video streaming) or require special peripherals (like the telephony library). If your low-end laptop can’t do this, there is no value in burdening it with the libraries.
The optional packages are typically separate downloads from the JDK. Each API family generally contains several related APIs, and each API (termed a package in Java) may be composed of several classes. This hierarchy is shown in Figure 1-4.
From quite early on several companies besides Sun Microsystems played a role in Java development. The Calendar class introduced in JDK 1.1 was developed by IBM and contributed by them to the release. Sun quickly saw the value of industry help with shaping the content and future of Java. A formal collaboration policy, known as the Java Community Process, was established in 1998.
The Java Community Process (JCP) is the way the Java platform evolves. It’s an open forum of about 300 companies and developers from around the world. The charter is to develop and revise Java technology specifications and their reference implementations.
The JCP has developed from the informal process that Sun used beginning in 1995, to a formalized process overseen by representatives from many organizations across the Java community. Anyone can join the JCP and have a part in its process, and you don’t even have to join to contribute as a public participant.
Various subgroups of experts within the JCP create proposals for the development of a new library or a significant revision to an existing library. The proposal is written in the form of a Java Specification Request (JSR), which is published on the web. There are currently around 90 Java technology specifications in development, and you can see them at www.jcp.org/jsr/all/index.jsp.
The JDK 1.4 release was developed as JSR59. The new I/O API was developed as JSR51. There is a computer game profile for J2ME under development as JSR134! The JDK 1.5 release is being specified with a JSR, but has not yet been given a number. When it does get one, you’ll be able to review the contents of the release months before it is available.
A Java Specification Request (JSR) moves through four stages to become a final specification and potentially become part of the Java platform. The steps are Initiation Draft, Community Draft, Public Draft, and Maintenance. They involve wider and wider review and comment.
The JCP is driven by the computer industry participants, not by Sun. As an example of that, fewer than half of all Java Specification Requests (JSRs) under review were submitted by Sun. Two of Sun’s own submissions, JSR 76 and JSR 78, were even voted down by the JCP.
Finally, all Java source code is available under the Sun Community Source License (SCSL). Community Source creates a community of widely available software source code just as the Open Source model does, but with two significant differences:
compatibility among deployed versions of the software is required and enforced through testing.
proprietary modifications and extensions including performance improvements are allowed, as long as compatibility is retained.
Most people don’t need the Java source code, but if you want it, it is available at www.sun.com/communitysource/. You don’t need a separate download for the runtime library source code. That comes with J2SE. Most of the library is written in Java, and it is sometimes very handy to be able to look at the source.
There is a very active and rich developer community at the portal developer.java.sun.com. You need to register at the site, but it is free and quick, and the content is very worthwhile.
There are three execution environments for Java programs:
Stand-alone programs, known as applications.
Programs that run in web browsers, known as applets. An applet is simply an application program that runs inside a browser.
Programs that run in a web server, known as servlets. A servlet is simply an application program that is run on demand by a web server.
There are very few differences between programming an applet versus programming an application. In fact, a single binary can even be both. Everything you learn about Java application programming carries over to applet programming, and vice versa.
You can put a web page on a server, and browser clients can download the page on demand to see the formatted text. Applets work in the same way. You write and compile a Java applet program, then place a URL or HTML reference to it in the web page. When a client browses that page, the Java applet binary is downloaded to the client along with the text and graphics files. The browser contains a JVM, and it executes the applet on the client computer.
Before Java, the World Wide Web (WWW) was a read-only interface. You browsed URLs, it served you pages. Now that web pages can cause programs to run, the browser is on the way to becoming the universal computer interface. Originally, an applet was considered a little application, but in fact there is no size restriction on applets. Because the model is useful, applets of all sizes exist. Java applets fit very neatly into the client/server model of computing. A later chapter is devoted to applets.
Applets in general are more popular for in-house enterprise systems than for high-profile ISV software. Applets have been hampered by less-than-stellar support in browsers, and were a casualty of the Microsoft-Netscape browser wars. Applets have been overshadowed in recent years by server-side Java. However, there are some excellent example applets on the CD accompanying this book.
Java is hugely popular on servers, where it is being used to replace CGI scripts. This kind of program is called a servlet. A servlet is a Java program that is executed when a user browses the URL corresponding to the servlet. Its input comes from a server and its output goes to the server, usually for onward transmission to the client. Other than that, a servlet is virtually no different from a regular Java program. Think of a servlet as an application that, like an applet, requires a web server software environment in which to run.
On the CD, there is a web server that supports servlets, including source code, and the subject has a chapter of its own in this book. One of the benefits of servlets is that you can now use one language consistently on the client, on the server, in your middleware, and for accessing the corporate database. It replaces a muddle of different languages and scripts, and the “Write Once, Run Anywhere” feature is a bonus that makes Java servlets irresistible.
Do you have trouble keeping track of your disk usage? Do you sometimes need to free up space, but have no idea what to start deleting? Have a look at jDiskReport, which is a Java application written by expert programmer Karsten Lentzsch of Kiel in Germany.
jDiskReport is a free cross-platform graphical disk report utility. It lets you understand how much space the files and directories consume on your hard disks. Figure 1-5 shows jDiskReport but really doesn’t do justice to the program.
The jDiskReport software is freely distributable, and there is a copy on the CD that comes with this book. Use a browser to view the CD contents, and you will see a link to jDiskReport. Click on the link, and the browser will let you save the zip file to disk. Do so and then unzip the file. There is a readme.txt and a jar file. Go to the directory containing those files, and start the program with the command line
java -jar jdiskreport.jar
The application will summarize the disk usage on your system and display it in a large variety of formats: oldest, largest, by type of file, pie chart, bar graph, text, tree display. This software was written once, and it runs on Linux, the Mac, Solaris, the DEC Alpha, and so on. It is a very user friendly program, fast, and a superb advert for the Java GUI library known as “Swing.” Karsten has a website at www.jgoodies.com with additional software. If someone tells you that Java is only good for server software, show them this desktop application. Try it yourself; you’ll probably find it very useful.