by Luke Cassady-Dorion
While there the initial public outcry over Java was in regards to it uses as a applet development language, study of the languge shows its power as a language suited for large-scale application development. However, due to the fact Java bytecodes need to be interpreted by a Virtual Machine running, an application in Java is not as easy as you might think.
Running an application written in Java involves slightly more work than you might spend installing an application written in C++ (or C or Pascal). While applications written in the previously mentioned languages are compiled into native code for direct execution on your system, Java applications must be executed through a Virtual Machine (VM) which translates the Java byte codes into native code. You therefore will basically launch the VM, and then allow the VM to lunch your application.
While this is currently an "annoyance,” it will not always be the case. Apple has announced that it will incorporate Natural Intelligence's VM into their operating system. Microsoft has also announced that it will incorporate their VM into an upgrade to the Windows operating system. Other major operating system vendors have announced that they, too, will incorporate a Java VM into their operating systems soon.
Once an operating system contains a full VM, Java applications will be able to execute in a fashion similar to what you have come to expect from other applications; all calls to the VM will be transparent to the user, and handled by the operating system. When running applets inside a Web browser, this task is automated for you by the browser. Whenever a Java capable web browser encounters a <APPLET> tag, it creates an instance of a Java VM, and runs the applet through the VM.
Because this book will be published before operating system vendors have incorporated VMs into their OSes, it is important to discuss how to run an Java application through a VM.
While Java applications are platform independent, the manner in which you execute them is platform dependent. For this reason, I cover running applications under the Mac OS, then on UNIX, and finally under Windows 95/NT. In all cases, I use Sun's software (VM/Applet Runner) as a reference.
Execution of Java applications on the Macintosh is far from elegant, and until Apple releases a new generation of the OS which incorporates a Java VM, the process will remain messy. While the process is messy, it is far from difficult. Application execution is possible through the Appletviewer which ships with the JDK for the Mac. Of course, as an application developer, you are not forced to work within the confines of the "applet security sandbox" which the major browser vendors force you to live with.
To execute an application under the Mac OS, drag the .class file which contains the main() method on top of the Applet Runner. The Applet Runner launches itself, and then executes the Java application. Figure 21.1 shows a small application running under Sun's Appletviewer on the Macintosh.
Sun’s Appletviewer enables Mac developers to run applications written in Java.
While you can execute applications through the GUI on a machine running Mac OS, this is not necessary on machines running a variant of UNIX. When compared to the Mac implementation, the UNIX method for running applications is slightly more elegant,but still leaves room to desire moreWehowever - as you will see - this method is far from perfect. To achieve this "elegance" you will learn to develop wrapper scripts on UNIX deployed Java applications which makes the invocation of the Java VM more transparent to the user.
While the UNIX method of executing Java applications—when compared to the method that you must take on the Mac OS—is more elegant, it is also slightly more time-consuming. This increase in time is limited to initial setup, and once you run the application for the first time, you will spend much less time on successive executions.
To best explain the process, I explain the setup of a sample application. In this example, you are dealing with an application called Schnee. The full distribution of the application contains 10 additional .class files (a total of 11 files); the class which contains the main() method is titled Schnee.class. Follow these steps:
Create a new directory for the application, and copy all necessary class files to this directory. Commands vary on each different implementation of UNIX, but the command to move an entire directory on your system is probably something like
mv -r sourceDirectory destinationDirectory
Move to the directory that contains the Java application and type java Schnee. This loads the Java VM and tells the VM to load the application titled schnee.
This method of running the schnee application is fine-and-dandy; however, it is rather messy to have to type java before an application name. This is especially true if you decide to distribute the application and have to deal with users who might not be used to running Java applications in this manner. For this reason, you will write a wrapper script which manages the application to VM transfer for us.
Listing 21.1 demonstrates a wrapper script written for execution under Solaris 2.4. Take a look at listing 21.1, and once you understand it, enter it into your computer using vi or any other text editor.
#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/Java/Que/Schnee/:$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=/usr/bin/java/bin/java
#Specify the name of the application.
#Important: Remember this is the name of the class, not the
#file
App=Schnee
#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
Once you have entered the script, save it in the same directory as the .class files which correspond to your application. You want to save the application as Schnee.
Now you can distribute your application and allow users to execute it simply by typing Schnee from the command line. As long as they have Java installed on their system in the same place where you do, they will be able to run your application by simply entering its name, Schnee.
The last platform which merits some discussion is Windows 95 and Windows NT. This section discusses how to install applications under Windows 95. Aside from a few particulars, the procedures are the same under Windows NT.
The standard method of running Java applications under Windows is no different than the method you would follow under UNIX. You simply copy the all of the .class files into the same directory, and then type java <filename>. With the example in the previous section, you would type java Schnee.
Of course as with UNIX, there is a way of making the this whole process much more elegant. This can be done with either a batch or PIF file. Of course, I describe how both implementations are accomplished.
To install the application with a batch file, use your favorite editor. You can use the Edit command supplied with DOS, Notepad under Windows,or any other text editor. Create a batch file called SCHNEE.BAT that contains the lines shown in listing 21.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
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 Schnee to be
rem the correct class for the application you are installing
javaw Schnee
To run the application, type Schnee at a DOS prompt. The application should start in the same manner which it did when you ran it from the command line. Pay special attention to any extra parameters that you have to send to the application.
To add this batch file to your Windows environment, switch back to the Windows environment (if necessary), and select the directory in which you want to place the application. Make sure you can actually see the folder's contents, not just the folder icon.
Create a new shortcut (choose File, New, Shortcut). Fill in the information for your new batch file (in this case, c:\que\Schnee.bat), and specify the name under which you want the application to appear on your desktop.
When you finish creating the shortcut, double-click it. An MS-DOS window appears, and your Schnee application starts. 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 the window. Here are a few pointers to make this a bit less obtrusive to you and your users.
To make the MS-DOS window less obtrusive, stop the DOS window from appearing on the screen, and have the DOS window exit on its own as soon as the Java application has started. To make these changes, follow these steps:
Open the properties for your new application.
Right-click the application icon. A pop-up menu appears. Choose Properties from this menu.
Switch to the Program tab. Change the Run option toMinimized. This will make it so that the DOS Window does not appear.
Select Close on Exit, which forces the DOS session to exit automatically after the Java application has started.
Click OK.
The other method of adding an application to Windows requires you to 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:
Enter the complete command line in the Create Shortcut window.
You want to replace all the directories and the class names with the ones that apply to your application. If your application does not seem to load, try using JAVA.EXE instead of JAVAW.EXE, which is an alternative version of Java that 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.
As your distributed applications grow in size, you will have an increasingly large number of .class files contained in your application. To combat this, there are currently three solutions, but only one has received widespread support. If you are familiar with UNIX, you will definitely know about the application tar. tar basically takes a directory and combines all associated files into one large file. All of the distribution solutions for .class files do the same thing, although varied compression is achieved.
The first method—which has received wide acceptance—is combining the .class files into a ZIP file. This the format that the classes.zip file which is distributed with the JDK is in. Unlike what you would traditionally think a zip file would be, no compression is occurs, but the large number of files is eliminated.
Two other formats which may be used to deal with large numbers of .class files are Microsoft’s CAB format, and the JAR format. CAB is uses the propropitary compression technology that is used in the distribution of all Microsoft products. At the current time, the only VM that offers support for CAB files is Microsoft’s own VisualJ++. JAR files offer a solution similar to ZIP files.
You should now have an understanding of how to manage Java applications on your machine, and from the previous chapter understand how to create Java applications. In addition to discussing how you might create a Java application, the previous chapter also discussed the thought process you must undergo when deciding whether to develop your project as an applet or as an application. An extension to this thought process is deciding when to develop your project entirely in Java, partly in Java and partly in C++ or C, or entirely in a language other than Java.
Java is great fun to develop in: threading is easier than in any other language (well most other languages, SR makes this easy too), and developing applications that need to communicate across a network is not a problem. Most of all applications written in Java are extremely portablemultiplyer on this one! This all sounds great - and I am sure that you have heard it over, and over, and over, and over, and over... - but Java does have its downfalls. Some of these will be overcome with time, but others will remain a problem forever.
Applications written in Java are not very fast. This is due to the fact that Java is only compiled into architecture-neutral byte-codes and needs to be converted to native code on-the-fly. JIT technology is changing this, but there is still a slow-down the first time a class is instianited.
The Java speed issue is definitely a large hurdle to overcome if you are developing a large application. Many developers of Java applications are banking on the fact that time will bring more speed to Java applications. JIT optimization will increase dramatically, and there is a very good chance that some new technology will come out which will bring even more speed to Java.
While the Java speed issue is diminishing as time increases, there is another big issue which will probably never go away—the protected environment that Java applications exist in. When writing code that gets to the nuts and bolts of an operating system, that code needs to have full range of the computer. For example, device drivers are still written—for the most part—in assembly language. While this is only appealing to the hardcore geeks, it has to happen. There are other applications which, while they don’t have to be written in a language like Assembly, still need to do things like access random places in memory. Applications like this are usually written in C++ or C.
For integration with other languages, Java applications can incorporate methods written C++ or C.
\You will find this useful not only when you need to preform a task that Java does not permit, but also when you need to squeeze a bit more speed into you application. Some tasks take a very long time to execute in Java, but will fly in C++ or C. Of course, by incorporating native code, you lose platform independence. If you limit your use of native methods, it is not hard to rewrite them for all platforms, and provide multiple distributions of your application.
Explaining that integration of native code can help you application is nice, but to many people, it does not mean to much. Concepts in development often seem logical when they are discussed in the abstract, but unless you actually do some application development where you decide that native code is necessary, you will probably not fully understand when it is necessary.
Personally, I did not realize that Java wouldn’t cut it all the time, until I got sick of waiting for an application that I was working on to provide answers. I took at the application as a whole and isolated the methods that were causing the slow-down. In a weekend, I had not only rewritten the methods in C++, but also compiled the methods for Mac OS, NT, and Solaris. I was able to provide distributions for all platforms that my client used and was able to bump the speed of the heterogeneous application 300 percent over the homogeneous application.
Because the source code to that application would fill much more space than I have here within this chapter, it’s not feasible to discuss the precise implementations here. On a side note, the application was very specific to the company that hired me to do the work most of you would find rather boring.
While I do feel that the best way to learn when native methods is needed is by actually working on a project that requires native integration, I will take some time to discuss a large commercial project that is being built with Java as the primary language, but is begin supplemented by other languages when necessary.
Javasoft’s Java operating system (previously called Kona) is written mostly in Java, and is meant to run on a variety of hardware platforms. The first versions of the OS run on x86 and Sparc-based machines, but and eventually will support the PowerPC processor.
Javasoft is taking pains to write the majority of the OS in Java, but is writing some of the OS hooks in both C and assembly languages. Figure 21.2 shows a description of the Java OS.
Note the systems that were developed in a language other than Java.
The purpose of figure 21.2 is not meant to provide a high level of detail, but is meant to show two things:
The native code is the reason that the OS—while written mostly in Java—needs to have different releases for different platforms.
Note that as the code gets closer to the level where direct communication with the hardware is required, the code moves from Java to C and Assembly. At this level are components which need to interact directly with the processor itself. In Java, you are so protected that this is not really possible. There are plans underway to implement much of what is written in C and assembly directly into Silicon. This will provide a huge speed increase over current Java implementations (including this one) as there will probably be ways in which you can develop anything in Java when writing for this chip
Java applications definitely show much promise, and the language will probably be a primary development environment within a few years. The promise of platform independent code has been floating around for years, and it seems that we are finally there. What will really prove the success of this market are the development tools which will be released in the near future.
Of specific note is a product being developed by Natural Intelligence (www.natural.com). Roaster PRO is geared for development of applications, but has a very cool hook that will position it as a prime development tool. This hook comes in the form of the ability to compile Java code directly into native code for the Mac or for Windows 95 and Windows NT. You will basically be able to click one button to generate a Mac application, and another to generate that same application for Windows 95 and NT. The application will take charge of the translation between the Java API and the Mac toolbox or the Windows 95 API. This obviously has a lot of people very excited, as this is totally unprecedented in the computing world.
| Previous Chapter | Next Chapter |
| Table of Contents | Book Home Page |
| Que Home Page | Digital Bookshelf | Disclaimer |
To order books from QUE, call us at 800-716-0044 or 317-361-5400.
For comments or technical support for our books and software, select Talk to Us.
© 1996, QUE Corporation, an imprint of Macmillan Publishing USA, a Simon and Schuster Company.
