by Joseph Weber
Java applications are a very powerful way to deliver your Java programs. Before you can use Java applications, however, you have to know how to install them. This chapter discusses how to install and maintain applications. The chapter also provides directions for turning your applets into applications.
Java applications come in many forms, but this chapter discusses the two most common: applications that come packaged as a series of .class files, and applications that come as a single .zip file.
CAUTION:
When you install someone else's Java applications, you are giving up the security protection that you are guaranteed with an applet. Giving up this security is not necessarily a bad thing; in fact, you may need to violate it. Just be aware that installing random Java applications can expose you to all the problems that you may encounter with traditional software schemes such as viruses and other malicious software.
Installing applications that come as a set of .class files is a bit less entangling
than installing applications for .zip files. In time, most applications will come
with their own installation programs, but for now you must perform the installation
manually. The following sections explain how to install the Clock application from
the CD-ROM that comes with this book that you worked with in the previous chapter.
Create a Directory for the Application
CAUTION:
Keeping backup copies of applications you value is important, just like with any other program or data that you value. Don't expect applications to become corrupted, but don't ignore that possibility either.
NOTE: To copy an entire subdirectory on a Windows machine from a DOS prompt, use the following command:
xcopy c:\original\directory\*.class c:\destination\directory /s
You can also drag-and-drop the whole directory structure with in the Windows Explorer system. On UNIX machines, the command is:cp -r /original/directory /destination/directory
CAUTION:
If you are deploying an application you have written, and you are still updating the program, don't make your working copy the same one that you have users accessing. If you happen to be compiling your application at the same time that a user tries to start it, unexpected and undesirable effects may occur.
After you copy all the .class files to the correct directory, the next task is to create a script or batch file that you will use to run the application.
You can automate this process so your users don't always have to type java Clock. Your users will be much happier if they can just type Clock to invoke the Clock program, without having to also type java. Making this possible, however, takes you in a different direction, depending on your platform. Ideally, you will be able to follow the same path you would use for UNIX and Windows 95/NT.
In explaining how to install an application under UNIX, this section covers specifically
how to do this under Solaris 2.4 using Korn shell. Your implementation may differ
slightly, based on your particular operating system and shell.
Test the Script Your application should start, and look something like Figure 22.2; if it doesn't,
make sure that you made the script executable. You can make the script executable
by typing the following: chmod a+x Clock
FIG. 22.2 Don't do this if you don't want everyone to execute your script. If that is the
case, type chmod u+x Clock, or check with your system administrator to determine
the proper parameters to use with chmod. This section discusses how to install applications under Windows 95. Aside from
a few particulars, the procedures are the same under Windows NT. You can install an application under Windows in two ways: by creating a batch
file, or by using the .pif file.
TIP: If your application does not use the Windows environment, or if you
need to be able to see the output on System.out, use java instead
of javaw.
NOTE: If your application does not run, and you see an error message similar
to Can't find class classname, first make sure that the .zip file is included
in your CLASSPATH variable. Next, make sure that the length of the CLASSPATH variable
does not exceed the maximum limit, which on Windows machines is 128 characters.
CAUTION: set CLASSPATH=c:\java\lib\classes.zip:c:\application\ Correct syntax: CLASSPATH=c:\java\lib\classes.zip;c:\application\ Under JDK 1.1 either option will technically work; however, do not expect this
to be backward- compatible for users still using JDK 1.0.
Create a Wrapper ScriptListing 21.1
#Add the applications directory to the CLASSPATH
#set to the directory you have placed the application
#Note, I insert the application directory first to avoid
#having classes from other applications getting called first
CLASSPATH=/ns-home/docs/que/Clock/:$CLASSPATH
#Set the location in which you hold java.
#This directory is probably the same as below
#If you have java in your global path, this line is
#not really necessary
Java_Home=/optl/java/bin/java
#Specify the name of the application.
#Important: Remember this is the name of the class, not the
#file
App=Clock
#Now run the actual program.
#If you have any additional parameters which you need to
#pass to the application, you can add them here.
$Java_Home $App
Clock &
Testing the Clock Application.
Copy the Script to a Common LocationFinishing Installing an Application for Windows
Creating a Wrapper Batch File
Listing 22.2
rem add the location where java.exe is located. If it
rem is already in your path don't add this line.
rem change c:\java\bin to the directory you have
rem installed for the JDK - see chapter 3
set PATH=%PATH%;c:\java\bin
rem Set this line to be the directory where your new
rem application is located.
set CLASSPATH = c:\appdir\;%CLASSPATH%
rem Run the actual application, change the applClass to be
rem the correct class for the application you are installing
javaw applClass
Despite the documentation provided with java.exe at Sun's www.javasoft.com
site, and that given when you type java, CLASSPATH on Windows machines is
not separated by a colon (:). The separation between the elements in the CLASSPATH
is accomplished with a semicolon (;). In short, the syntax of CLASSPATH is the same
syntax that you use to set your PATH variable. Incorrect syntax:
Test the Batch File
FIG. 22.3
The Clock application running under Windows.
Add the Application to Windows
FIG. 22.4
The Shortcut window.
When you finish creating the shortcut, double-click it. An MS-DOS window appears and your Clock should start. Now, if you're like most people, having a DOS window pop up in order to start an application is downright annoying. Normally you don't care what is going to System.out, and having a big black obstruction on the screen causes most people just to close it. Here are a few pointers to make this a bit less obtrusive for you and your users.
To make the MS-DOS window less obtrusive, first stop the DOS window from appearing
on the screen, and second, have the DOS window exit on its own as soon as the Java
application has started. To make these changes, open the properties for your new
application. Move your mouse over to the Clock icon and use your right mouse button
to click the Clock icon. A pop-up menu should appear; choose Properties. The
properties window shown in Figure 22.5 should appear. Now switch to the Program tab.
Change the Run option to Minimized; this will make it so that the DOS Window
does not appear. Next, select Close on Exit, which will force the DOS session
to exit automatically after the Java application has started. Finally, click OK.
FIG. 22.5
In the Properties Window, change the Run option, and select Close on Exit.
Now, if you double-click the Clock icon, the application starts without the obtrusive DOS window.
The other method of adding an application to Windows requires that you know the following:
First, select the folder in which you want your new application to appear. Then create a new shortcut, as described in the preceding section. When you are prompted to enter the command line option, however, enter the following line as seen in Figure 22.6:
c:\java\bin\javaw.exe -classpath c:\java\lib\classes.zip;c:\appDir\ applicationClass
FIG. 22.6
In the Shortcut window, enter the complete command line.
You want to replace all the directories and the class name with ones that apply to your appli-cation. If your application does not seem to load, try using java.exe instead of javaw.exe. javaw.exe is an alternative version of java which returns right away and ignores all the error messages that ordinarily are generated when an application starts. javaw.exe is great for abstracting your users from what is going on, but it makes it difficult to see what is really happening when things don't work correctly.
CAUTION:
When you use the -classpath variable, you must be careful to include the classes.zip file in java\lib. Not including this file makes it impossible for any application to start.
With the advent of JDK beta 2, support was added to deliver Java applications with a single .zip file. This addition makes it easier to deliver an application because only the zip file and the wrapper are required. In fact, as more and more applications are delivered to market, they undoubtedly will use this method for distribution.
When you install an application from a zip file, be aware of the following things:
The second point here is important. Suppose that you have the applet SkyTune installed in CLASSPATH. SkyToon, which calculates the likelihood that the sky will fall today, has a class called Tune, which deals with the color of the sky. You also have an applet called CDTunes installed; you use this applet to play music CDs in your CD-ROM drive. CDTunes has a class called Tune that handles all the audio input and output from the CD. What happens in this situation where two applications have a class called Tune? When you run CDTunes, the Java interpreter looks down your class path, finds the first instance of the class Tune, finds the class in SkyToons--and chokes.
You can prevent this problem by carefully naming all your classes and/or putting them in packages. If you are running someone else's program, however, there is no guarantee that this problem won't occur. You need to be aware of the possibility in case your applications stop working one day. (You may have this problem when you run applications that come in .class form, too, but the problem is a bit more obvious when it occurs.)
Now you are ready to install an application sent in zip format. Although zip-distributed classes are somewhat trickier to deal with in a management sense than .class distributions, you have to make only one change in your wrapper script or batch file.
If you are using UNIX, refer to the script in Listing 22.1, and change:
CLASSPATH="/ns-home/docs/appDir/:$CLASSPATH"
to
CLASSPATH="/ns-home/docs/appDir/application.zip:$CLASSPATH"
If you are using Windows, refer to the batch file in Listing 22.2, and make the following change:
set CLASSPATH = c:\appdir\;%CLASSPATH%
to
set CLASSPATH = c:\appdir\application.zip;%CLASSPATH%
These examples assume that the zip file you received with the application is called application.zip. In reality, the file probably is called classes.zip. The examples simply demonstrate the fact that the file may have any name.
Maintaining multiple Java applications on a single system is not as simple as maintaining several normal programs compiled in binary code, for the following reasons:
You can solve the last two problems yourself. The first problem, however, will have to be resolved by the Virtual Machine vendors.
Consider an example situation. You have been using a Java-based word processor for months. One night, you or your system administrator installs a new version of Java(.exe). This new version of Java is 300 times faster (which is the minimum that you can expect from the next generation of VMs), but it has an interesting side effect: It switches the characters a and z. This switch probably is the result of a bug, but what happens to your word processor? Worse, what happens if you don't notice the change for a few days, and you have saved several old documents in the new format? Only one thing can completely prevent such an event: Don't upgrade without making absolutely certain that your new Java machine is 100 percent compatible with previous versions. Developers, working before the final Java release, went through some growing pains with each new release of the JDK (from JDK pre-beta to JDK beta 1, and so on; never- mind what happened from alpha to beta or 1.02 to 1.1). Lest you be scared off from upgrading your VM, most of the problems were very minor, but they almost always required a small code change and, if you don't have the source code, you may not have this luxury.
The second problem deals with the fact that Java is compiled to files that bear the name Something.class. Each class for an applet is contained in its own .class file, and each application can contain dozens of class files.
With each of your Java applications having dozens of classes, it's often difficult to avoid the situation where applications don't just happen to have classes which bear the same name as a class from another application, and thus the wrong class gets loaded. One solution is to place the classes in packages and give each of the packages a unique name. What happens, however, when package names overlap? This situation should not occur if you follow good programming practice, but the world isn't perfect.
To prevent this problem from crashing your applications, you should always place the current application directory or zip file at the beginning of the classpath list. In situations where there is code sharing, make sure that the items you include in the CLASSPATH are correct for the application you are actually running. If you ever think you are pulling the wrong class, strip your CLASSPATH down to nothing and rebuild it with only the required directories. Ultimately, though, you have to put your faith in the programmers. As with upgrading your Virtual Machine, time will tell if good methods are developed to prevent these situations.
Finally, what do you do about applications that share code with other applications or that load part of their code from the Internet? When you make changes in one application, you must ensure that the changes are backward-compatible. Normally, code that is being deployed is not subject to frequent change. But, when you are installing a new version of an application, you need to make sure that no other programs depend on the code in the old version.
If some programs do depend on code from the old version, maintain the legacy code, just in case you need to reinstall the code for other applications.
In all, the procedure is not quite as simple as installing a new version of Microsoft Word, but it isn't like reinstalling your operating system, either. The key when installing applications is being aware of the downwind effects that every change will cause.
