Preface

Historically, the development of Ajax web applications has been a complex process.
This is due mainly to the requirement to learn and use a variety of
technologies, possibly including HTML, JavaScript, XML, ASP.NET, Java servlets,
various scripting languages, etc.

Recently several products have emerged that make it possible to develop Ajax web
applications using the Java development environment. Some use exclusively Java,
while others use mainly Java.

The Google Web Toolkit (GWT)

One development environment that allows you to use mainly Java for the
development of web applications is the Google Web Toolkit (GWT) (see
Resources and Download).

Most of the client-side code for a GWT Ajax application can be written in
Java. Apparently there is no requirement to write JavaScript code.
However, it is necessary to:

Create an HTML host page for the application.

Create your own CSS style sheets.

Compile your Java code using a special GWT Java-to-JavaScript compiler.

Use a special scaled down version of the Java API, which only supports
two packages from the standard J2SE API.

Not all standard Java packages are supported

The GWT only supports the following packages from the standard J2SE API:

java.lang

java.util

The GWT doesn't even fully support those two packages. For example, although
the Vector class is supported by the GWT, only two overloaded constructors for
that class are supported, whereas the Vector class in Sun's J2SE has four
overloaded constructors.

Not based on the latest version of Java

In addition, the GWT version 1.1.10 is apparently based on version 1.4.2 of
Sun's J2SE. Therefore, many of the features that were added in J2SE 5.0
(such as generics) are not supported by the GWT.

You need to be careful

Therefore, you need to be careful when writing your Java application to make
certain that you are using only those Java features that are supported by the
GWT. (See the link to the GWT JRE Emulation Library in
Resources for more information on this topic.)

First in a series

This is the first lesson in a series of lessons designed to help
you learn how to use the GWT to create rich Ajax web applications.

Purpose of the tutorial

The purpose of this tutorial lesson is to help you get your
computer set up to create Ajax web applications using the GWT. Future lessons
will concentrate on the Java programming techniques required to create more
meaningful Ajax web applications.

By the time you finish this tutorial, you should have your
computer set up to create Ajax web applications, and you should have created and
tested two basic applications.

Prerequisites

Knowledge of event-driven programming using the Java programming
language as embodied in Sun's J2SE 5.0 (see DickBaldwin.com in
Resources) is a prerequisite to understanding the
material in this lesson.

Knowledge of how to deploy a web application in a Java
servlet container (see "Deployment of Web Applications in Jakarta Apache
Tomcat 5" in
Resources) is a prerequisite for being able to replicate the results
produced in this lesson.

System requirements

You will need to download and install the GWT framework (see
Download).

You will need access to a servlet container for testing your web
applications. One of the easiest ways to satisfy this requirement is to install
a servlet container as a localhost server (see
Download and also see "Getting Started with Jakarta Tomcat, Servlets, and
JSP" in
Resources).

I recommend that you open another copy of this document in a separate
browser window and use the following links to easily find and view the figures
and listings while you are reading about them. You may also find it useful
to open a third browser window at the Resources section near the end of the
document. That will make it easy for you to open those resources when they
are mentioned in the text.

A few months ago, I decided that it was time for me to learn what
Ajax technology is all about. I
had a general idea of the technology based on some articles that I had read, and
I had found several applications such as
Google Maps and Google
Suggest to be very impressive. Realistically, however, I didn't have any
idea how to implement an Ajax application.

So, I started searching around and quickly discovered that several products have
recently emerged that make it possible to develop web
applications using the Java development environment. Some use exclusively Java,
while others use mainly Java. Two products that use exclusively Java are
products named ThinWire and Echo2. (See the link to "Developing Ajax
Web Applications using ThinWire and Java" and the link to Echo2 in
Resources.)

My strong suite is Java

Since my strong suite is Java and not JavaScript, I have been pleased to
learn that there are at least three emerging technologies that make it possible
to develop Ajax applications using Java without much, if any requirement to
write JavaScript, HTML, XML, CSS, etc.

Exclusively Java

The folks at ThinWire (see Resources)
describe their product as follows:

Familiar event-driven GUI programming model

Develop exclusively in server-side language only

Never use HTML, CSS, or JavaScript again

Program exclusively in Java

All Major Browsers Supported

Deploy on any Java Servlet Container (including Apache Tomcat)

Also Runs on Nokia 770 Internet Tablet

The folks at NextApp (see Resources) have
this to say about their Echo2 product:

"Echo2 is ... a platform for developing web-based applications that
approach the capabilities of rich clients. The 2.0 version ... providing
dramatic performance, capability, and user-experience enhancements made
possible by its new Ajax-based rendering
engine.

Echo2 removes the developer from having to think in terms of
"page-based" applications and enables him/her to develop applications using
the conventional object-oriented and event-driven paradigm for user
interface development. Knowledge of HTML, HTTP, and JavaScript is not
required. Applications may be hosted using any Java servlet container."

Similar to event-driven desktop applications

Thus, developing web applications using ThinWire and Echo2 is very similar to
developing standalone event-driven Java desktop applications. While both
products provide their own proprietary API for the construction, layout, and
management of the user interface, for the most part, the remainder of the
application is true to Sun's J2SE 5.0.

In both cases, you substitute the proprietary user interface API for the
standard Java user interface API and then write the Java program as though it is
intended to be an event-driven desktop application. Then you compile the
application using Sun's standard javac compiler, at which time it is converted
into a servlet-based web application.

Mainly Java - the GWT

As I mentioned in an earlier lesson entitled "Deployment of Web Applications
in Jakarta Apache Tomcat 5" (see Resources) the
GWT folks at Google have this to say about their framework:

"Google Web Toolkit (GWT) is a Java development framework that lets
you escape the matrix of technologies that make writing AJAX applications so
difficult and error prone. With GWT, you can develop and debug AJAX
applications in the Java language using the Java development tools of your
choice. When you deploy your application to production, the GWT compiler
translates your Java application to browser-compliant JavaScript and HTML."

Not nearly as close to standard Java...

The GWT is not nearly as close to standard Java as are ThinWire and Echo2.
For example, the GWT requires that you use a proprietary Google API for the
entire development process. Only two packages from Sun's version 1.4.2 API
are supported, and neither of those APIs is fully supported by GWT version
1.1.10. For example, some constructors, and possibly some methods as well
from those two packages in Java 1.4.2 are not supported by the GWT version 1.1.10.

None of the features that Sun added in J2SE 5.0 are officially supported by
GWT version 1.1.10. Therefore, if you are accustomed to taking advantage
of those features in your Java applications, you must be careful to avoid them
when writing Java code for the GWT. In addition, you must be careful not
to write any Java version 1.4.2 code that is not supported by the GWT.

Must use Google's proprietary compiler

Once you have the Java application written, you must compile it using a
proprietary Google Java-to-JavaScript compiler in order to turn it into a web
application.

Major differences in deployment strategy

There are also major differences in the way that GWT applications are
deployed and executed relative to ThinWire and Echo2 web applications.
Some of these differences may be advantages, and some may be disadvantages.

Servlet-based web applications

ThinWire and Echo2 both produce web applications that are based on Java
servlets. The user causes a servlet to be executed on the server to
execute the application. The servlet then dynamically generates the
necessary client code (which probably includes a lot of JavaScript) and
downloads it to the client machine where it is executed. The downside of
this approach is that web applications created using ThinWire and Echo2 can only
be deployed on servers that support servlets.

JavaScript-based web applications

A GWT web application compiles directly into JavaScript, producing a web application that
does not require a servlet-compatible server for deployment. The upside of
this is that it should be possible to deploy a GWT web application on just about
any web server without a requirement for Java servlet compatibility.

(See Resources for two online articles that
compare the GWT with ThinWire and Echo2, keeping in mind that those
comparisons were written by people who have a vested interest in ThinWire
and Echo2.)

If you already know how to program using the Java programming language, none
of the steps described above are technically challenging. However, they
can be very tedious and there are many opportunities for error.

I will teach you my procedure

In this lesson, I will walk you through the procedure that I followed to
accomplish the steps listed above on a machine configured as follows:

Windows XP.

A jakarta-tomcat-5.0.27 server running as a localhost server.

A Firefox browser.

The GWT version 1.1.10.

The primary emphasis of the lesson

The primary emphasis of this lesson will be on all of the steps in the
above
list except Step 4. That step has to do with upgrading the Java source code for
the basic web application produced by the applicationCreator script. I
will barely touch on that step in this lesson. I will concentrate on
teaching you how to create and deploy two
slightly different but very basic Ajax web applications.

In other words, the purpose of this lesson is to help you get set up to
produce more meaningful Ajax web applications using the GWT. Future lessons
will concentrate on the Java programming techniques required to produce those
more
meaningful Ajax web applications.

Discussion
and sample code

In this section, I will explain the procedure by which I was able to create,
test, and deploy two very simple Ajax web applications using the GWT version
1.1.10.

There is no requirement to perform a Windows installation for the
framework. All that is required is to extract the contents of the zip file
into a known location on your disk. I extracted the contents of the zip
file into a directory named
C:progfileGwtV1.1.10-noUninstallReq.

(You may choose to extract the files into a different directory. I am
providing you with the location on my computer because the path will be important later when I
get to the discussion of the script named applicationCreator.)

Some interesting side issues

If you poke around in the directory tree produced by extracting the framework
from the zip file, you may conclude that (other than the Java class library) the three most useful items in that
directory tree are the items listed in Figure 1.

The first item in the list in Figure 1 is the name of an executable file that,
as you will see later, is executed to create a basic GWT web application for
each new web application that you write.

The API documentation

The second item in the list in Figure 1 is the name of a file that forms the root
of a set of javadocs that describe the GWT framework API. If you open this
file in your browser, you will see that it displays standard Java documentation for the API.

(Unfortunately, there appear to be some important images missing from
this documentation. Those images can be viewed in the online version
of the API documentation mentioned in the next paragraph.)

In addition to the API documentation contained in the downloadable zip file,
a great deal more documentation on the GWT can be found at the Google Web
Toolkit link in Resources.

Sample applications

The third item in the list in Figure 1 is the name of a directory
that contains the Java source code and the compiled versions of seven
different GWT web applications of varying complexity. These sample
applications may be useful to you in your efforts to learn how to program using
the proprietary GWT Java API.

Prepare your computer for developing GWT applications

There are many different ways to prepare your computer for the development
of web applications in order to accomplish Step 2. My preference is to create a development directory
tree that mirrors the deployment directory tree on the server. Then when
an application has been created in the development tree all that is necessary
to deploy it to the server is to copy portions of the development tree to the deployment tree.
I explained this approach in the earlier lessons entitled "Deployment of Web
Applications in Jakarta Apache Tomcat 5" and "Developing Ajax Web Applications
using ThinWire and Java" (see Resources).

A GWT development directory

To start this process, I created the following GWT development directory as
the root of my GWT development tree:

C:BaldwinAA-SchoolJavaProgwebappsGwtApps

The rest of the GWT portion of the development tree will be filled in below this directory later.

Create the
Java source code and other files required for a basic GWT web application

To accomplish Step 3, I opened a command prompt in the GwtApps directory and executed the following
command in that directory to create a basic GWT application:

(Note the use of the path to the GWT script named applicationCreator.
Also note the command line parameter shown in boldface and compare it with
the actual tree that was created as shown in Figure 2 below.)

The GWT application directory tree

The execution of the GWT script named applicationCreator created a directory
tree underneath the GwtApps directory containing the files and folders shown in Figure 2.

The first boldface item in Listing 1 shows the extent to which the Java
source code was customized to match the name of the application specified in the
execution of the applicationCreator script earlier.

Don't intend to teach much about Java source code in
this lesson

Recall that it is not the purpose of this lesson to teach you how to produce
meaningful Ajax web applications using the GWT. Rather, that will be covered in
future lessons. However, later on in this lesson, I will show you how to create a
different GWT web application by modifying the text on the face of the button
shown in boldface in Listing 1 (and also shown in the image in Figure 3). I am showing you the Java source code that
is automatically generated by the GWT applicationCreator script so you will know
what to expect later.

What about the other generated files?

Now, getting back to the directory tree shown in Figure 2, the exact purpose of the file named
GwtApp001.gwt.xml
isn't clear to me, but it is generated automatically and is required. You
should just leave it alone during the remainder of the development of the web
application.

The host page

The file named GwtApp001.html shown in Figure 2 is used later in
Step 6(compilation of the web application) to
produce another file having the same name that is referred to in the GWT documentation
as the host page. (See the boldface material in Figure 6.) A
copy of the file shown in Figure 6 is downloaded from the web server by
the user in order to execute the web application later. You will probably
modify the version of the file shown in Figure 2 during the development of the web application. I will
explain that in the next lesson.

Two script files

You will learn the purpose of the files named GwtApp001-compile.cmd and
GwtApp001-shell.cmd later. These are script files that you will
execute later. You must not modify these two files.

Upgrade the basic web application to suit your
requirements

That covers the first three steps. At this point, there is nothing that we need to do to upgrade the basic web
application that was automatically generated by executing the
applicationCreator script. We will simply leave the Java source code for the application
unmodified, skipping Step 4, and continue on to
Step 5. Before discussing Step 5, however, I need to
mention a little about testing the web application in hosted mode.
(I will have a great deal more to say about testing in hosted mode in the
next lesson.)

As you write the Java source code for your GWT web application, you should
test it frequently in GWT hosted mode. This is
accomplished by executing a command similar to the following at the command
prompt to run the GWT script named GwtApp001-shell.cmd.

C:BaldwinAA-SchoolJavaProgwebappsGwtAppsGwtApp001-shell.cmd

(Note that the script file mentioned above is shown in Figure 2, and
contains the name of the web application in the file name. A new
script file is automatically generated for each new web application that you
create using the GWT.)

The screen output

Running this script in this case produced the screen output shown in Figure
3.

This is the output produced by converting the Java source
code shown in Listing 1 into a GWT web application. Note, however, that
this is not a compiled web application. Rather this is a preliminary view
of the behavior of the application running in a special Google GWT browser.
As mentioned earlier, Google refers to this as the hosted mode.

Click the button

The button shown in Figure 3 will be active when you run the script. Clicking that button
should cause the
web application to produce the screen output shown in Figure 4. (Note
the text to the right of the button.)

If you compare this behavior with the Java code shown in Listing 1, you
should see that the application is behaving as expected based on that Java code.

Where did the extra text dome from?

By now, you may be wondering where the extra text in Figure 3 and Figure 4
came from. It clearly wasn't generated by the Java code shown in Listing
1. The answer is that this text was produced by the file named
GwtApp001.html shown in Figure 2. I will have much more to say about this
in the next lesson.

(If you were to open the file named GwtApp001.html in your browser,
you would see the extra text there.)

The development directory tree has expanded

Executing the GWT script named GwtApp001-shell.cmd not only caused the
application output to be displayed on the screen in hosted mode, it also expanded
the development directory tree to that shown in Figure 5.

The primary difference between the tree shown in Figure 5 and the tree shown
earlier in Figure 2 is the addition of a complete new sub-tree rooted in the
directory named tomcat in Figure 5.

Apparently the first time that the script named GwtApp001-shell.cmd is
executed, it installs a local Tomcat web server that is used to execute the
application in hosted mode.

Compile the finished Java web application

The next step (Step 5) is to use the proprietary GWT Java-to-JavaScript compiler to
compile the finished Java web application into a JavaScript-based web
application. There are at
least two ways to accomplish this. One way is to click the button
labeled Compile/Browse at the top of Figure 3. The other way is to
execute the following command at the command prompt:

C:BaldwinAA-SchoolJavaProgwebappsGwtAppsGwtApp001-compile.cmd

This causes the GWT script named GwtApp001-compile.cmd to be executed.
This script compiles the application creating the folders and files shown in boldface
in the expanded development directory tree shown in Figure 6.

(Clicking the button labeled Compile/Browse at the top of
Figure 3 not only attempts to compile the application, it also attempts to
execute it locally in your default browser.

Note that some of the long and cryptic file names in Figure 6 may or
may not be different on your computer if you create this web application.
I'm not certain about that.)

The directory named GwtApp.GwtApp001 and its contents constitute
the JavaScript/HTML version of the web application.

Test the compiled web application locally

The next step is described in the above list as Step 6.
This web application can be tested locally by opening the file named
GwtApp001.html (shown in boldface in Figure 6 and known as the host page) in a browser.

(Note that there are two files named GwtApp001.html in Figure 6.
The file of interest at this point, (the host page) is the one shown in
boldface in the directory tree rooted in the directory named www.
The other file having the same name is contained in the directory named
public.

As mentioned above, opening the host page file locally in your browser
happens automatically if you click the button labeled Compile/Browse
at the top of Figure 3.)

The screen output

Opening the host page file in your browser should result in the screen output shown in
Figure 7 (where the host page file named GwtApp001.html was opened in a Firefox
browser).

(Note that opening the file named GwtApp001.html shown in the
non-boldface public directory in Figure 6 will not result in an
operational web application.)

Figure 7. The compiled application opened locally in a Firefox browser.

The behavior produced by clicking the button in Figure 7 should match that shown
in the output for the hosted mode earlier in Figure 2 and Figure 3.

Deploy and test the compiled web application

The next step, Step 7, is to deploy the compiled web application onto a web
server and to test it by downloading it from the web server and executing it in the
browsers of interest.

To deploy the application to my localhost server, I copied all of the folders
and files in the development directory named www into the jakarta tomcat server
directory named C:jakarta-tomcat-5.0.27webappsGwtApps.

Then I added the following directory and file to the localhost Tomcat
server.

C:jakarta-tomcat-5.0.27webappsGwtAppsWEB-INFweb.xml

A named web application

Note that the WEB-INF directory and the web.xml file were required
by my localhost server in order for me to deploy the application as a
named web application even though the file named web.xml is essentially empty.

However, this is not the only way to deploy a GWT web application, and I'm sure
there are other ways that don't require the presence of the web.xml file.

Running the web application

After deploying the web application, I was able to start the Tomcat server and
to run the web application in my browser by
entering the following URL into my browser window (note that this URL ends
with the name of the host page):

http://localhost/GwtApps/GwtApp.GwtApp001/GwtApp001.html

The screen output and behavior was the same as that produced by opening the file named
GwtApp001.html directly in the Firefox browser as shown in Figure 7.

Step 8, (which requires repeating steps 3 through 7)
is used for the creation, testing, and deployment of additional GWT web
applications. I will walk you through the procedure that I used to create,
test, and deploy another simple GWT web application so that you can see the impact that this
had on the
development directory tree.

Create the basic web application

By
this time in my procedure, the window containing the command-line prompt had been closed so I
re-opened a command line prompt in the GwtApps directory of the development
tree. Then
I executed the following command in that directory to create another application
named GwtApp002:

As you can see, executing the applicationCreator script to create a
new application added a number of new files to the development tree. I have highlighted
those new files in boldface in Figure 8.

(Note that no new files were added to the tree in the area below the
tomcat directory in Figure 8, so I deleted that portion of the tree from
Figure 8 for brevity.)

A new Java source code file

One of the new files in Figure 8 is the Java source code file named
GwtApp002.java. The contents of this file were initially the
same as shown in Listing 1 except that each occurrence of GwtApp001
in the source code was replaced
by GwtApp002.

A new and different web application

To demonstrate that this is a new and different GWT web application, I opened
that Java source code file in my Java editor and modified the text on the button
to read GwtApp002 instead of Click me as shown in Listing 1 and
Figure 3. (This corresponds to Step 4 in the list
of eight critical steps presented earlier.)

Execute the script to test in hosted mode

Continuing with Step 4, another of the new files in the development directory tree shown in Figure 8
is the script file named GwtApp002-shell.cmd. (Note that
the script file contains the application name in the script's file name.) I executed that
script to test
the modified application in hosted mode. This produced the screen output
shown in Figure 9.

As you can see, the text on the button in Figure 9 matches the change to the
Java source file that I described earlier. However, since changing the
text on the button was the only change that I made, the behavior of the button in
this application is the same as the previous application named GwtApp001.

Compile the web application into JavaScript

Another of the new files shown in Figure 8 is the script file named
GwtApp002-compile.cmd. I executed this script to compile the
application into a JavaScript web application. (This corresponds to
Step 5 in the earlier list of eight critical steps.)
This expanded the development directory tree to that shown in Figure 10.

(There were no
changes to the development tree in the area above the directory named www, so I
deleted that portion of the tree from Figure 10 for brevity.)

The material that was added to the development tree by compiling the
second web application is shown in boldface in
Figure 10. In essence, a complete new sub-tree containing compiled JavaScript code,
HTML files, and XML files
was added to the development tree as a new sub-tree rooted in the directory
named GwtApp.GwtApp002.

(The file named SESSIONS.ser shown in boldface in Figure 6 was also
modified during the development of the second web application. This
seems to happen when you close the two special GWT host mode browsers.
This leads me to believe that this is some sort of a history file associated
with host mode testing. In any event, this file is not involved in the
deployment of the compiled web application to the server.)

Some extra files in Figure 10

Note that for reasons I don't understand, in addition to the file
named GwtApp002.html, this sub-tree also contains a file named GwtApp001.html.
However, opening that file in my Firefox browser results in an output with a
missing button. In addition, deleting the file named GwtApp001.html from
the sub-tree doesn't
appear to have any detrimental impact on the ability to run the application by
opening GwtApp002.html directly in the browser or to deploy the application
named GwtApp002.html in
the localhost server.

Test the application in a local browser

Proceeding to Step 6, opening GwtApp002.html in my Firefox browser produced
essentially the same output that was produced earlier in hosted mode as shown in Figure
9.

Deploy the new application

The final test (Step 7) was to deploy the new application on my localhost tomcat
server. I copied the new development directory tree rooted in
GwtApp.GwtApp002 into the server directory named C:jakarta-tomcat-5.0.27webappsGwtApps
on my server.

By this time, my localhost Tomcat server was no longer running so I restarted
it. I was then able to execute the new application by
entering the following URL into the Firefox browser:

http://localhost/GwtApps/GwtApp.GwtApp002/GwtApp002.html

(Note once again that the last item in the URL is the name of the host page,
GwtApp002.html.)

Screen output for the new application

The output was the same as that produced by opening the file named
GwtApp002.html directly in the Firefox browser and was essentially
the same as that produced by running the application in hosted mode as shown in
Figure 9.

My localhost server sub-tree

For the record, at this point in time my localhost server sub-tree rooted in the
directory named C:jakarta-tomcat-5.0.27webappsGwtApps contained the
directories and files shown in Figure 11.

Figure 11 contains the directories and files for two different GWT Ajax
applications. One application is highlighted using Italics in
Figure 11. The other application is highlighted in boldface.

Creating the directory trees for display

In case you are interested, the various directory tree displays shown in this
lesson were produced using a very crude recursive Java program that I threw
together for that purpose. The source code for the program is provided in
Listing 2.

Note that this program in its current
form is not pretty but it works. Also, it does not provide for user input. Therefore, it is necessary to modify
the source code and recompile the program to create a tree for each different
path.

Run the programs

I encourage you to
download and install the GWT framework and the Jakarta Tomcat server (see
Download) and to use
those products along with my Java source code to replicate what you have learned in this lesson.

Modify the source code in the Java files that are produced by the GWT
applicationCreator script. Experiment with that code by compiling your modified
web applications and observing the impact of your changes.

Experiment with the buttons at the top of the special GWT hosted mode browser
shown in Figure 3.

Learn how to write web applications using this exciting new technology. Above
all, enjoy the process. Programming can be fun.

In this lesson, I walked you through the procedure that I followed to
accomplish the steps listed above on a machine configured as follows:

Windows XP

A jakarta-tomcat-5.0.27 server running as a localhost server

A Firefox browser

The GWT version 1.1.10

The primary emphasis in this lesson included all of the steps in the above
list other than Step 4 having to do with upgrading the Java source code for
the basic web application produced by the applicationCreator script. I
barely touched on that step in order to show you how to create and deploy two
slightly different Ajax web applications.

In other words, the purpose of this lesson was to help you get set up to
produce meaningful Ajax web applications using the GWT.

Future lessons
will concentrate on the Java programming techniques required to produce more meaningful Ajax web applications
using the GWT framework. The next lesson in the
series will deal with user interface layout issues in the web
application.

Future lessons will deal with such issues as the available GWT user interface
components, event-driven programming, and styling.

Richard Baldwin is a
college professor (at Austin Community College in Austin, TX) and private
consultant whose primary focus is a combination of Java, C#, and XML. In
addition to the many platform and/or language independent benefits of Java and
C# applications, he believes that a combination of Java, C#, and XML will become
the primary driving force in the delivery of structured information on the Web.

Richard has participated in numerous consulting projects and he
frequently provides onsite training at the high-tech companies located in and
around Austin, Texas. He is the author of Baldwin's Programming
Tutorials, which have gained a
worldwide following among experienced and aspiring programmers. He has also
published articles in JavaPro magazine.

In addition to his programming expertise, Richard has many years of
practical experience in Digital Signal Processing (DSP). His first job after he
earned his Bachelor's degree was doing DSP in the Seismic Research Department of
Texas Instruments. (TI is still a world leader in DSP.) In the following
years, he applied his programming and DSP expertise to other interesting areas
including sonar and underwater acoustics.

Richard holds an MSEE degree from Southern Methodist University and has
many years of experience in the application of computer technology to real-world
problems.