Notice: This material is excerpted from Special Edition Using Java, ISBN: 0-7897-0604-0. The electronic version of this material has not been through the final proof reading stage that the book goes through before being published in printed form. Some errors may exist here that are corrected before the book is published. This material is provided "as is" without any warranty of any kind.
Up until now, you have primarily been looking at Java applets. You can also build full-scale standalone applications using Java. In fact, the HotJava browser is itself a Java application.
Applications have a wider range of possibilities than applets do, because they are not required to inherit from the Applet class. Java applications can do just about anything that can be done in a third-generation language (such as C, C++, Smalltalk, Ada, et. al.) limited only by the Java run-time security system.
Topics to be covered in this chapter include:
How to move from an original concept to a complete Java application.
How to compile and run a Java application.
Applications can be refined and extended to include additional features.
Applets require some third party support in order to run. Applets always inherit from the AWT class Applet, itself a subclass of Panel.
See "Writing an Applet Explored," Chapter 16, for more information about writing applets in general.
Applications, on the other hand, can be run directly from the Java run-time interpreter. "Application" can actually be somewhat of a misleading name, as there isn't a single executable which the user can just go ahead and run. What actually happens is that the run-time loads the specified class, as well as other clients of that class, and attempts to call the main() function on the class.
Or at least that's the way it works with the current tool set. In the future, look for compilers to be able to generate machine-dependent binaries which can be run as complete applications. These will almost certainly be necessary to acheive the level of performance expected of modern programming languages.
There's nothing to stop a class from being both an applet and an application. All you need to do is extend Applet and add a main() method. Any application which extends the Panel class may also be used as an applet-simply extend Applet instead of Panel.
This section will show how to build a simple application, from a basic concept, through implementation, and finally, running the application. The following sections will build on this basic application by slowly adding complexity through new features.
Please note that all of the examples use the Java Developers Kit. If you are using the alpha3 release, you will need to make several changes to the code, especially where the AWT components are used.
The first step in writing any program is figuring out what the software is supposed to do. For personal projects, it's best to set some goals before starting, so you'll know when you're done. In industrial settings, the specification is likely to come in the form of customer requirements.
The example used here is a program that will help the user graph a quadratic equation, in the form of:
The concept in the first pass is to compute and print the values of f(x) for x between -10 and 10. This concept will be altered through the set of examples as more features are added to this basic application.
Implementation is the step of writing software based on the design. At this level, knowledge of the langauge is the most important element-to be able to come up with a reasonable way to implement the design using Java.
A required element is the main() method. main() must be a public and static method on one of the classes in the application, so that the Java run-time has some place to begin. Like init() on applets, main() is where you can perform your one-time initialization, including reading parameters, which in the case of applications come from the command line.
Here's the source code for the first pass of this example, broken down step by step to show exactly what's going on.
public class QuadraticFormula
{
static final float DEFAULT_MIN_X = -10.0f;
static final float DEFAULT_MAX_X = 10.0f;
static final float DEFAULT_INCREMENT = 0.25f;
/* coefficients for the equation: ax^2 + bx + c */
float a;
float b;
float c;
public static void main(String args[])
{
if (args.length < 3)
{
System.out.println("Usage: QuadraticFormula a b c");
System.exit(1);
}
new QuadraticFormula(Float.valueOf(args[0]).floatValue(),
Float.valueOf(args[1]).floatValue(),
Float.valueOf(args[2]).floatValue());
}
QuadraticFormula(float coeff_a, float coeff_b, float coeff_c)
{
a = coeff_a;
b = coeff_b;
c = coeff_c;
float x = DEFAULT_MIN_X;
while (x <= DEFAULT_MAX_X)
{
System.out.println("x = " + x + " \tf(x) = " + calculate(x));
x += DEFAULT_INCREMENT;
}
}
float calculate(float x)
{
return (float) ((a * Math.pow(x, 2.0f)) + (b * x) + c);
}
}
The first few lines of the QuadraticFormula class declare the constants used by the class. These constants specify the range and the step size for the "x" values of the program. From an overhead standpoint, it's better to make constants static, so each instance of a class won't have to carry around a separate copy, although in this case, only one instance of the class will run at any given time.
Next come the instance variables, or attributes, of the class. Each instance of the class has a separate copy of these variables, which are independent from each other. These attributes are available to any non-static method in QuadraticFormula.
The main() method is the entry point of the application. In QuadraticFormula, it reads the command line arguments (passed into main() as the parameter args), and creates an instance of the QuadraticFormula class using the command line parameters. Once the constructor has exited, main() reaches its end, and the application will terminate.
Why not run the whole program from main()?
Because main() is a static method, there is no actual QuadraticFunction object, so main() can't access any of the attributes or the non-static calculate() method.
For the simple example, there's no reason not to just run the entire program from within the constructor of QuadraticFunction, except the part where the equation is evaluated-it makes more sense to break that out into a separate method, which is called calculate(). This will make even more sense in the later examples.
The QuadraticFormula constructor begins by copying the initialization parameters into the attributes of the new object. The remainder of the constructor runs through a loop which calculates the value of the quadratic equation for a series of values of x, printing the result of each calculation to the user's standard output (usually a terminal).
The calculate() method performs the actual calculation of the quadratic equation. The result is cast to float before the return because the default result of the equation is of type double, and the Java compiler will produce a warning unless there is an explicit cast down to a float.
QuadraticFunction uses three standard library classes: Float, System, and Math, all of which are imported by default from the java.lang package, so no import statements are necessary.
Note that instead of using the power function from the Math class, the x2 term could have been expressed simply as (x*x). However, the power function will be needed by later examples, so it's best to just leave it in.
Once you have written the code file (for the sake of convenience assume it is called QuadraticFunction.java), you will need to compile it into bytecodes, and then call the Java run-time interpreter.
The following instructions assume that you are using the javac compiler from the Java Developer's Kit (JDK):
javac QuadraticFunction.java
java QuadraticFunction a b c
Replace "a," "b," and "c" in step 2 with the corresponding coeffecients. Figure 23.1 shows part of the output when run with the parameters -0.1 1 0 (i.e.,-.1x2 + x).
See "Testing with a Java application" Chapter 2, for more information about the Java compiler and run-time interpreter.
Fig. 23.1 Output of: java QuadraticFunction -0.1 1 0 (i.e.,-.1x2 + x)
Because any class can have main() defined, it's possible to design an application where classes are self-testing; for exmaple, each class defines main() as a test driver.
So far, there's only a single class, so this doesn't come into play yet.
At some point during the development of an application, you are likely to come across things that need changing in one way or another.
Concept or requirement changes are common in commercial products, as the end customer may change his or her mind, or may change or add features that only come to mind later. It's best to try and develop the design and implementation with the possibility of requirement changes in mind. The second and third examples in this chapter reflect changes in the concept of the application.
Design changes occur either as result of requirements changes, errors in the original design, or the designer noticing additional relationships between classes that may not have been evident during the previous design phase. A common case is the modification of inheritance and interface hierarchies to help generalize classes for increased flexibility and reuse potential, as in this chapter's third example.
Implementation changes come from design changes, bug fixes, and rewrites to make code cleaner or more efficient. Once an application is fairly stable, you should try to minimize implementation changes, as each section of code you change will need to be re-tested; so try to make modifications only when necessary.
Never be afraid to jump back to a previous stage when it's called for. During design or implementation you may uncover missing, conflicting, or unclear requirements. The moral is to never lock yourself into following a set sequence of events-building software is an art, not a science.
A simple text dump of values is all right, but wouldn't a graph of the equation be nicer to look at? The Java language has a built-in graphical user interface (GUI) library, called the Advanced Window Toolkit (AWT), which allows developers to create graphical displays which are platform-independent. Other than adding the graphics, the bulk of the class is built off of the original QuadraticFormula, above.
See Chapter 21, "AWT"";, for in-depth information about the Advanced Window Toolkit.
import java.awt.*;
public class QuadraticGraph extends Frame
{
static final float DEFAULT_MIN_X = -10.0f;
static final float DEFAULT_MAX_X = 10.0f;
static final float DEFAULT_MIN_Y = -10.0f;
static final float DEFAULT_MAX_Y = 10.0f;
/* coefficients for the equation: ax^2 + bx + c */
float a;
float b;
float c;
public static void main(String args[])
{
if (args.length < 3)
{
System.out.println("Usage: QuadraticGraph a b c");
System.exit(1);
}
new QuadraticGraph(Float.valueOf(args[0]).floatValue(),
Float.valueOf(args[1]).floatValue(),
Float.valueOf(args[2]).floatValue());
}
QuadraticGraph(float coeff_a, float coeff_b, float coeff_c)
{
super("Quadratic Equation");
setTitle("Quadratic Equation");
/* Initialize variables */
a = coeff_a;
b = coeff_b;
c = coeff_c;
/* Create a generic menu */
MenuBar menu = new MenuBar();
Menu m = new Menu("File");
m.add(new MenuItem("Exit"));
menu.add(m);
setMenuBar(menu); // install this menu bar in the frame
/* draw the graph */
resize(400, 400); /* setting a default window size */
show();
}
public void paint(Graphics g)
{
int height = size().height - 50;
int width = size().width;
/* clear background */
g.clearRect(0, 0, width, height);
/* draw x-axis and y-axis */
g.setColor(Color.black);
int x_pixel = (int) (-DEFAULT_MIN_X * width /
(DEFAULT_MAX_X - DEFAULT_MIN_X));
int y_pixel = (int) (-DEFAULT_MIN_Y * height /
(DEFAULT_MAX_Y - DEFAULT_MIN_Y));
if ((x_pixel >= 0) && (x_pixel <= width))
{
g.drawLine(x_pixel, 0, x_pixel, height);
}
if ((y_pixel >= 0) && (y_pixel <= width))
{
g.drawLine(0, y_pixel, width, y_pixel);
}
/* Draw curve */
g.setColor(Color.red);
x_pixel = 0;
float x = (DEFAULT_MAX_X - DEFAULT_MIN_X) * ((x_pixel / width) - 0.5f);
y_pixel = (int) (height / (DEFAULT_MAX_Y - DEFAULT_MIN_Y) *
(DEFAULT_MAX_Y - calculate(x)));
if ((y_pixel >= 0) && (y_pixel <= height))
{
g.drawLine(x_pixel, y_pixel, x_pixel, y_pixel);
}
x_pixel += 1;
while (x_pixel <= width)
{
int last_y = y_pixel;
x = (DEFAULT_MAX_X - DEFAULT_MIN_X) *
(((float) x_pixel / width) - 0.5f);
y_pixel = (int) (height / (DEFAULT_MAX_Y - DEFAULT_MIN_Y) *
(DEFAULT_MAX_Y - calculate(x)));
if ((y_pixel >= 0) && (y_pixel <= height))
{
if ((last_y >= 0) && (last_y <= height))
{
g.drawLine(x_pixel - 1, last_y, x_pixel, y_pixel);
}
else
{
g.drawLine(x_pixel, y_pixel, x_pixel, y_pixel);
}
}
x_pixel += 1;
}
String equation = "f(x) = ";
if (a != 0)
{
equation = equation + a + "x^2";
if (b < 0)
{
equation = equation + " - " + (-b) + "x";
}
else if (b > 0)
{
equation = equation + " + " + b + "x";
}
if (c < 0)
{
equation = equation + " - " + (-c);
}
else if (c > 0)
{
equation = equation + " + " + c;
}
}
else if (b != 0)
{
equation = equation + b + "x";
if (c < 0)
{
equation = equation + " - " + (-c);
}
else if (c > 0)
{
equation = equation + " + " + c;
}
}
else
{
equation = equation + c;
}
g.drawString(equation, 10, height-10);
}
float calculate(float x)
{
return (float) ((a * Math.pow(x, 2.0f)) + (b * x) + c);
}
public boolean handleEvent(Event e)
{
if ((e.id == Event.ACTION_EVENT) && (e.target instanceof MenuItem))
{
if (((MenuItem) e.target).getLabel().equals("Exit"))
{
System.exit(0);
}
}
return false;
}
}
To use the graphics libraries, the AWT package has to be included. By using the asterisk (*) on the end, the import statement tells the Java compiler to import all classes in the package, otherwise, for this example, there would have to be separate import statements for java.awt.Frame, java.awt.Graphics, java.awt.Color, java.awt.Menu, and java.awt.MenuBar. As applications use more and more components from a single package, it begins to make more sense to include the entire package, rather than individual components.
The QuadraticGraph class inherits from the AWT component Frame, so all instances of QuadraticGraph are also Frames.
Minimum and maximum values of y are included as new constants so that the graph will have a "clipping" area defined, that is, a set region of values to draw. Since the formula will be evaluated on a pixel-by-pixel basis, there is no need for a default step size for x.
The super() method used in the constructor passes arguments to the constructor of the base class, in this case, Frame. super() must be the first command inside of a constructor if it is going to be used. The setTitle() method is unnecessary, since the Frame constructor should set the title.
A menu bar is added to the window. It has a single menu, "File," with a single option, "Exit," To see how to include multiple menus and multiple options under each menu, skip ahead to the third example in this chapter.
The paint() method is called every time the window is exposed, moved, or resized. That's why size() is called each time-to ensure that paint() will take the current window size into account. The height subtracts 50 pixels for the window's title and menu bars, as size() returns the size of the whole frame, not just the drawing area.
Think of the frame as a canvas. If you don't actually remove what was there before, it won't disappear on it's own. Calling clearRect() clears the entire drawing area so old and new lines won't be displayed over each other.
After drawing the x-axis and the y-axis, the first point, if it falls within the range of acceptable y minimum and maximum, is drawn. Since the line will be drawn pixel by pixel, instead of figuring out x_pixel from x, x is figured out from x_pixel. The value of y simply equals calculate(x), so this just skips a step and computes y_pixel directly from x.
The following loop performs the same calculations as above for each x pixel for the entire width of the frame. The current pixel will only be shown if it's within the maximum and minimum values of y. If the last value of y was shown, then a line is drawn from the last pixel to the current pixel; otherwise, only the current pixel is drawn.
The end of the paint() routine uses drawString() to display the text representation of the equation in the lower left corner of the window.
handleEvent() will be called every time any GUI event occurs. The only event that QuadraticGraph is interested in is when the sole menu item is selected, in which case it exits the application. The return value is false to indicate that the event was not processed-this will only return if the program does not exit.
Figure 23.2 shows the finished product.
Fig. 23.2 A picture is worth a thousand words
The previous example is indeed an improvement on the first pass, but it still seems too dependent on a specific type of problem, namely a quadratic equation.
Wouldn't it be nicer to have a more generic graphing tool that could handle different types of equations?Or more than one equation at a time?
This example is going to implement these idea, and one or two others, to show a few more useful programming techniques as well as to illustrate how refining an application can make for better software.
Introduced in this example are the following items:
Graph.java is the third example file. You will note that it is considerably larger than the others, mostly because it's doing quite a bit more. Because of its size, there won't be a line-by-line description of the file-only the highlights will be pointed out.
The first change is that the code for calculating the equation has been moved out of the Graph class. An interface (Equation) is the new way to access calculate(), and a few others new methods:
interface Equation
{
void setEquation();
float calculate(float x);
boolean isValid();
String toString();
Color getColor();
}
Take a quick look at the other functions:
The EquationDialog class implements some of these methods, but leaves others to its subclasses, so EquationDialog must be declared as abstract.
abstract class EquationDialog extends Dialog implements Equation
EquationDialog also extends the Dialog class. This gives the class the ability to pop up a window to accept user input, which the EquationDialog subclasses will use to set their equations.
class QuadraticEquation extends EquationDialog class PolynomialEquation extends EquationDialog
There are two subclasses of EquationDialog: QuadraticEquation and PolynomialEquation. The former uses much of the code from the previous example, simply regrouped under the new interface. PolynomialEquation is a more generic type of equation, which can accept coefficients for any polynomial equation up to order x9.
In both cases, the interesting parts are the setEquation() and action() methods. setEquation() finishes the layout of the dialog which was started by the EquationDialog constructor, and then displays the dialog. action() responds to the buttons being clicked-simply closing the window on "Cancel," setting the equation to invalid and closing the window on "Don't Show," and parsing, validating, and storing the input and closing the window on "OK."
Looking at the EquationDialog constructor, you can see the layout of the buttons on the bottom of the pop-up window:
Panel p = new Panel();
add("South", p);
p.add(new Button("OK"));
p.add(new Button("Cancel"));
p.add(new Button("Don't Show"));
The setEquation() methods in the subclasses (the following fragment is from PolynomialEquation) add a few more screen elements-text boxes, one is editable, the other isn't:
Panel p = new Panel();
add("Center", p);
t = new TextField("Enter coefficients separted by spaces:");
t.setEditable(false);
t.setBackground(Color.lightGray);
p.add(t);
t = new TextField(current, 20);
t.setEditable(true);
t.setBackground(Color.lightGray);
p.add(t);
Figure 23.3 shows the layout of the PolynomialEquation dialog.
Fig. 23.3 Changing the equation on the fly
The other method of note is action(), which is called whenever there is a GUI event. In this example, the code is looking for when any of the buttons are pressed:
public boolean action(Event e, Object obj)
{
if ("OK".equals(obj))
{
String coefficients = t.getText();
...
valid_equation = true;
hide();
return true;
}
if ("Cancel".equals(obj))
{
hide();
return true;
}
if ("Don't Show".equals(obj))
{
valid_equation = false;
hide();
return true;
}
return true;
}
The code for the "OK" portion is actually much more detailed than shown here, as this is where the validation and storage of the new equation is performed. For any of the buttons, hide() is called to remove the dialog from the screen.
The Graph class contains the drawing information from the QuadraticGraph class, and adds support for multiple equations to be displayed at once. It also adds the ability to spawn off other Graph objects, each with its own thread of execution.
MenuBar menu = new MenuBar();
Menu m = new Menu("File");
m.add(new MenuItem("Close"));
m.add(new MenuItem("Exit"));
menu.add(m);
m = new Menu("Set");
m.add(new MenuItem("f(x)"));
m.add(new MenuItem("g(x)"));
m.add(new MenuItem("h(x)"));
menu.add(m);
setMenuBar(menu);
This shows how to create multiple menus, and multiple items under each menu. Each menu, and each menu item under each menu, shows up in the order in which it is added. (Left to right or top to bottom, as appropriate.)
Equation function_f; Equation function_g; Equation function_h;
These are the attributes used to keep track of the multiple equations. Note that each of these could hold any object which implements the Equation interface, and in fact, the Graph constructor uses two different classes to initialize these objects:
function_f = new QuadraticEquation(this, Color.red); function_g = new QuadraticEquation(this, Color.blue); function_h = new PolynomialEquation(this, Color.green); Figure 23.4 shows the Graph class with all three functions displayed at the same time.
Fig. 23.4 The Graph class allows up to three functions to be displayed at once.
It's probably not a good idea to hardcode the Equation constructors inside of the Graph class-it makes the Graph class that much less configurable.
How would you fix this?
One approach could be to pass three Equation objects in the constructor of Graph. Another may be to include setFunctionF(), and so on, methods in the Graph class-this will be shown in the fourth and final example. Other possibilites surely exist.
This is a general class of object-oriented problems which has to be solved on a case-by-case basis-is it better to define associations between classes at compile time (static associations) or at run-time (dynamic associations)? The answer each time will depend on the specific classes and the specific problem domain.
There are many more improvements which can be made to this example application, some of which, in no particular order, are:
These are only a few ways in which you can work with this example to create bigger and better applications. Or you may be ready to try an idea or two of your own, now that you have the basic feel of writing applications.
The final example is the last pass at the Graph application. The new features are:
Again, because of the length of the code, there won't be a line-by-line description of the classes.
Note
Two files are needed because only one class may be decalred "public" in any given Java source file. GraphApp, the entry point for the application, must be public so you can call main() on it. Graph must also be public so that it can be used as an applet.
These files are in their own directory because the name Graph.java conflicts with an earlier example.
The biggest change is to the Graph class:
public class Graph extends Applet
Instead of Frame, Graph now inherits from Applet. This will allow the Graph class to be used as an applet in an HTML document, however, it also means that Graph can no longer control its own menus. Later, you'll see the menus in the GraphApp class.
Four methods have been added to Graph:
The first, init(), will only be used when the Graph class is treated as an applet. This will read in the parameters and initialize the equations accordingly. Since Graph doesn't have menus, this version of Graph will not be able to change the equations when used as an applet, so the equations had better be specified through the initialization parameters.
See "Adding an Applet to an HTML Document" Chapter 19, to see how to pass user-specified parameters to an applet.
The other three methods are quite simple-they set the appropriate equation equal to the one passed into the function.
One method has been removed from Graph-main(). When Graph is used in an application, it would be better for some Window-based class (as opposed to a Panel-based class such as Applet) to be the entry point, so menus can be added to the user interface. Besides, this allows several different classes to use Graph without having to compile a separate version of Graph for each of its clients.
void setEquation(String s);
The Equation interface has been modified to include an overloaded version of setEquation(), which takes in a String argument. Rather than popping open a dialog window to prompt the user, this method will create an equation based on the supplied String.
Moving over to the GraphApp.java file, there is only the GraphApp class declared. Note that all of the classes and interfaces used by GraphApp have to be specified with the import statements at the top of the file.
GraphApp keeps a copy of the same Equation objects it passes to Graph. Since all objects are passed by reference, both GraphApp and Graph point to the exact same Equation objects. When any Equation is modified, both the GrapApp and the Graph objects will see the modifications.
GraphApp contains a Graph object, and adds it to the visual display using the add() method.
You can compile both files at once, if you wish:
javac Graph.java GraphApp.java
To run as an application, use GraphApp as the starting class:
java GraphApp
This should actually run just the same as the previous example, except that not only are the types of the equations pre-set (in this case, they're all PolynomialEquation objects), but the initial values of the functions are also initialized.
To run Graph as an applet, copy the graph.html file into your working directory, and use either the Applet Viewer, or your Java-enabled web browser (such as Netscape Navigator) to view the HTML file. Figure 23.5 shows Netscape navigator displaying the graph.java. Naturally, you can produce different graphs by changing the parameters in the applet declaration in the HTML file.
Fig. 23.5 Netscape Navigator displaying the graph.html file.
For technical support for our books and software contact support@mcp.com
Copyright ©1996, Que Corporation