Appendix 1:
Other Features of Java
THIS TEXTBOOK does not claim to cover all the features
of the Java programming language, or even to give comprehensive coverage to the features
that it does cover. The primary purpose of the book is to explain programming, not
Java. Nevertheless, it can serve as a good starting point for learning Java.
This appendix briefly surveys some of the features of Java that were not
covered in the book. It will acquaint you with some of the terms you might hear
when people discuss Java, and it will point you towards some of the things
you might want to learn more about as you continue your study of Java programming.
JAR Files and Resources
Each programming example in this book uses just a few class files, at most. A large
Java project might use hundreds. People might hesitate to welcome a program that
comes in hundreds of small files onto their hard drives. Fortunately, Java
makes it possible to combine a collection of files into a single
Java archive file, or "JAR" file. If all the
class files needed to run a Java program are placed into a JAR file, then only
that one file will be needed. Many Java programming environments
can be configured to make JAR files when they compile a program. The command-line
programming environment, in which the "javac" command is used for compilation,
also has a "jar" command for making JAR files. For example, the following command
makes a JAR file named "myprog.jar" and copies all the class files in the current
directory into that JAR file:
jar cfv myprog.jar *.class
The "cfv" means "Create a jar archive as a File and be Verbose about telling me what you
are doing." The "*.class" matches all files that end with ".class". The contents of
a JAR file are compressed, by default, so the JAR file actually takes up less space
than the files it contains.
A JAR file can be used for an applet. It just has to be specified in the <applet>
tag:
<applet archive="myprog.jar" code="MyApplet.class"
width=200 height=100>
</applet>
A JAR file can be used for a stand-alone application by specifying it as part of
the "classpath":
java -classpath myprog.jar MyApplication
In addition to class files, a JAR file can contain images, sounds, and other
resource files needed by a program. It's fairly easy to load such resources
into a program. An image resource, for example can be loaded in almost the same way
as an independent image file, using the getImage() method of an applet or
a Toolkit. The location of the resource just has to be specified differently.
For example, if an applet class named MyApplet is loaded from a JAR file, and that
file contains an image file named "icon.gif", then the following command will load
the image:
Image icon = getImage( MyApplet.class.getResource("icon.gif") );
The getResource() method is used to locate a resource. It returns
a URL that specifies the location of the resource. (The getResource() method
in this example is an instance method in an object,
MyApplet.class, that represents the class to which the applet belongs.
Objects that represent classes are another feature of Java that I haven't mentioned
before. The idea is that the system will look for the image file in the same places
it looked for the class and will find it in the same JAR file.)
Graphics2D
All drawing in Java is done through an object of type Graphics.
The Graphics class provides basic commands for drawing shapes and
text and for selecting a drawing color. These commands are adequate in
many cases, but they fall far short of what's needed in a serious computer
graphics program. Java has another class, Graphics2D, that provides
a larger and more serious set of drawing operations. Graphics2D is
a sub-class of Graphics, so all the old routines from the Graphics
class are also available in a Graphics2D.
The paintComponent() method of a JComponent gives you a
graphics context of type Graphics that you can use for drawing on
the component. In fact, the graphics context actually belongs to the
sub-class Graphics2D (in Java version 1.2 and later), and can be
type-cast to gain access to the advanced Graphics2D drawing methods:
public void paintComponent(Graphics g) {
Graphics2D g2;
g2 = (Graphics2D)g;
.
. // Draw on the component using g2.
.
}
Drawing in Graphics2D is based on shapes, which are
objects that implement an interface named Shape. Shape classes include
Line2D, Rectangle2D, Ellipse2D, Arc2D, and
CubicCurve2D, among others. CubicCurve2D can be used to draw
Bezier Curves, which are used in many graphics programs. Graphics2D
has commands draw(Shape) and fill(Shape) for drawing the outline
of a shape and for filling its interior. Advanced capabilities include:
lines that are more than one pixel thick, dotted and dashed lines, filling a shape
with a texture (this is, with a repeated image), filling a shape with a gradient, and
drawing translucent objects that will blend with their background.
In the Graphics class, coordinates are specified as integers and are
based on pixels. The shapes that are used with Graphics2D use real numbers
for coordinates, and they are not necessarily bound to pixels. In fact, you can
change the coordinate system and use any coordinates that are convenient to your
application. In computer graphics terms, you can apply a "transformation" to the
coordinate system. The transformation can be any combination of translation,
scaling, and rotation.
Javadoc
A program that is well-documented is much more valuable than the same program
without the documentation. Java comes with a tool called javadoc
that can make it easier to produce the documentation is a readable and organized format.
Javadoc is especially useful for documenting classes and packages of classes that are
meant to be used by other programmers. A programmer who wants to use pre-written classes
shouldn't need to search through the source code to find out how to use them. If the
documentation in the source code is in the correct format, javadoc can separate out
the documentation and make it into a set of web pages. The web pages are automatically
formatted and linked into an easily browseable Web site. Sun Microsystem's on-line
documentation for the standard Java API was produced using javadoc.
Javadoc is actually very easy to use. In a source code file, javadoc documentation
looks like a regular multi-line comment, except that it begins with "/**"
instead of with "/*". Each such comment is associated with some
class, member variable, or method. The documentation for each item
must be placed in a comment that precedes the item. (This is how javadoc
knows which item the comment is for.) The comments can include certain special
notations. For example, the notation "@return" is used to begin the
description of the return value of a function. And
"@param <parameter-name>"
marks the beginning of the description of a parameter of a method. For example,
here is a short utility method with a javadoc comment:
/**
* Return the real number represented by the string s,
* or return Double.NaN if s does not represent a legal
* real number.
*
* @param s String to interpret as real number.
* @return the real number represented by s.
*/
public static double stringToReal(String s) {
try {
return Double.parseDouble(s);
}
catch (NumberFormatException e) {
return Double.NaN;
}
}
Sun's Java Software Development Kit includes javadoc as a program that
can be used on the command line. This program takes one or more Java source code
files, extracts the javadoc comments from them, and prepares Web pages containing the
documentation. Integrated development environments for Java typically include a
menu command for generating javadoc documentation.
Internationalization
If the World-Wide Web -- and information technology in general -- is to be a
truly global phenomenon, it shouldn't be tied to one country's language or
customs. An internationalized computer program
or applet is one that can adapt itself to the locale where it is being run.
A locale in Java is specified as a language
together with a country. These, in turn, are designated by standard two-letter
codes, such as "en" for English, "es" for Spanish, "US" for the United States,
"ES" for Spain, and "MX" for Mexico. The locale determines not only the
language that is used but also details such as the output format of dates and
numbers. A Java virtual machine has a default locale built into it. If it's
running in the United States, the default locale is probably en_US. In Mexico,
it would be es_MX.
The classes java.text.DateFormat and java.text.NumberFormat
make it possible to display dates and numbers in a form that is appropriate for
the default locale (or some other locale if you want). For example, the commands
DateFormat df = DateFormat.getDateTimeInstance();
String now = df.format( new Date() );
System.out.println(now);
print the current date and time (as returned by "new Date()"), formatted
according the conventions of the default locale. The output will look
different in different countries.
Any text that is displayed to the user by a program -- labels on buttons,
commands in menus, messages in dialog boxes, and so on -- should be in the
language that is appropriate for the locale where the program is being run.
Java makes it possible to put all the strings used by
a program into a resource bundle and to use
a different resource bundle for each locale. The actual strings do not
appear in the program itself. They are in separate files. One file might
contain the strings in English; another file, the same strings translated into
Spanish; and a third file, the same strings in Japanese. The program can then
be run in English, Spanish, and Japanese locales, and it will use a different
language in each local. To make the program run correctly in a French locale,
it's only necessary to create a new resource bundle, with the strings translated
into French. It's not necessary to modify the program in any way. The class
java.util.ResourceBundle represents a set of strings to be used by a program,
and makes it possible to load the set of strings that is most appropriate for the default
locale. When the program wants to display a string, it gets the string from the resource bundle.
The string will be in the appropriate language for the default locale, assuming
that a resource bundle for that language is available.
Pluggable Look-And-Feel
Macintosh programs don't look quite the same or work quite the same as Windows
programs. Linux and UNIX have several different GUI styles, but none
of them look or work exactly like Macintosh or Windows. Java programs
are supposed to work on any computing platform. Ideally, they should have the right
look-and-feel for the platform where they are running. In Swing, this is made
possible by pluggable look-and-feel, or PLAF.
The look-and-feel of a Swing interface can be managed using the class
javax.swing.UIManager, which contains static methods for setting
the default look-and-feel of newly created JComponents and for determining
what look-and-feels are installed on the computer where the program is running.
To change the look-and-feel of a JComponent that already exists, you
can call its updateUI() method (after calling UIManager.setLookAndFeel()).
To change the look-and-feel of a component and all the components that it contains, you can use
SwingUtilities.updateComponentTreeUI(comp), where comp is
the component.
Java has a cross-platform look-and-feel called "Metal" that will look about the
same on all platforms. Other look-and-feels might be available, depending on the
platform and the Java virtual machine that is being used. On MacOS X, for example,
the default look-and-feel for Java is similar to the Mac's "Aqua" interface.
PLAF is supported by the basic architecture of Swing components. Swing uses a
Model-View-Controller architecture in which the
model (that is, the data) for a component is separate from the view (that is, the
on-screen visual representation of the data). The data for a JButton is
stored in an object of type ButtonModel. The data for a JTextComponent
is stored in an object of type Document. When the look-and-feel is changed,
the model is not affected, but the view can change. Most of the time, you don't need
to be aware of the distinction between components and their models, but in some cases
you need access to the model. For example, if you want to install a listener to
respond to each change that is made to the contents of a JTextComponent,
you have to register a DocumentListener with the text component's model:
textinput.getDocument().addDocumentListener(listener).
JavaBeans
A JavaBean is a component that can be combined with other components to make
a complete program. JavaBeans can be assembled into a program using a
visual development environment, which allows a
programmer to add beans to a program, configure them, and set up interactions
between them by dragging icons, using menus, clicking buttons, and so on. Sophisticated programs
can be assembled with little or no programming. If you use an integrated
development environment for Java programming, there's a good chance that
it has some support for visual programming.
JavaBeans are objects, not classes. Many JavaBeans are GUI components, but this
is not a requirement and a JavaBean might have no visual representation at all.
Objects belonging to Java's standard GUI component classes are JavaBeans and
can be used in visual development environments.
JavaBeans can be defined by any class that follows a few rules.
The class should have a default constructor (one with no parameters). This
allows a visual development environment to create a new bean in a default state without
providing any information to the constructor. To be useful, a bean should
have one or more properties, which are just
values associated with the bean. Beans are configured
by setting the values of their properties. A visual development environment
recognizes a property by the fact that there are "get" and "set" methods
for the bean. For example, if a bean has methods:
String getTitle();
void setTitle(String title);
then the bean has a property named "Title" of type String.
You don't have to do anything else to define a property; just provide
the "get" and "set" methods. Beans can, optionally, use PropertyChangeEvents
to communicate. When a property of a bean is changed, it can emit an event.
Other beans can register to listen for these events, so that they can respond
when the property changes. Of course, beans might also generate other types
of events, such as ActionEvents. A visual development environment
should make it possible to route these events to other beans or possibly
to write some code to respond to the events.
JavaBeans exist to enable the production of reusable objects and to
promote the development of an "object economy" in which such objects
are widely distributed and readily available.
Distributed Computing
Java is a language that was designed from the beginning to work
in a networked computing environment. Applets can be downloaded
over a network, and basic network communication is supported by
the java.net package. But this is just the beginning.
Java has built-in support for distributed
computing. In distributed computing, a program uses more
than one computer. Different parts of the program run on different
computers and communicate over a network. The program has access
to much larger computing resources than are available on any one
computer.
In Java, this is made
possible by allowing a method that is running on one computer to
call a method in an object that is on another computer. The
parameters for the method are transmitted across the network,
and the return value is sent back after the method has completed.
Java has support for two types of distributed object computing.
RMI (Remote Method Invocation) is used for
communication between two Java objects running on different computers.
Java also supports CORBA (Common
Object Request Broker Architecture), a standard that allows
communication between objects written in different programming
languages.
Servlets and JSP
Java is most visible on the client side of the Web, in the form
of applets running in Web browsers. However, Java is also very
useful on the server side. A servlet
is a Java program that is meant to be executed by a Web server.
This is similar to the way that applets are executed by a Web
browser. If a Web server is capable of executing servlets, then its capabilities
can be extended indefinitely by writing new servlets for it.
Java is certainly not the only programming language used in this way,
but it is an attractive choice because of its security, network-awareness,
and large collection of APIs.
Servlets are often used to generate Web pages. Many Web pages are
static -- they are simple, unchanging HTML files. When a server receives
a request for such a page from a Web browser, all it has to do is send the HTML file to the
browser. However, there are also dynamic Web pages.
A dynamic web page is generated on demand each time the page is requested. The
content of the page can be different each time it is requested. This can happen,
for example, because the content depends on data that was typed into a Web form
by the user or on information from a database. To serve up a dynamic page,
the server has to run a program. Servlets can be used in this way.
The servlet decides what should be on the
page and creates the HTML code for displaying that content. The server then
sends this HTML code to the Web browser that requested the page.
The task of writing dynamic Web pages can be simplified by using
Java Server Pages (JSP) instead of servlets.
A Java server page is an HTML file with some Java code embedded in it.
When a Web server receives a request for the page, the Java code
is executed to generate the dynamic part of the page. JSP is used on
many Web sites. You can recognize a JSP page because the file name
for the page will end with ".jsp".
Servlets and JSP are not part of the standard edition of Java, J2SE,
but they are included in the enterprise edition, J2EE.
More Features
Java has APIs (Application Programming Interfaces) for
many more features, and the list seems to be growing
all the time. It's unlikely that any one person can master them
all. What can be mastered are the principles and techniques
on which they are all built. After that, it's just a matter
of poking around in the documentation.... Here
are a few more of the things you might run into:
- Multimedia. The packages java.awt.image and
javax.swing.sound contain classes for manipulating images and
sounds.
- Drag-and-Drop. Drag-and-drop refers to dragging an item
that is to be processed and dropping it onto the item that you want
to process it. An example is dragging a file and dropping it into
the trash. Drag-and-Drop support in Java is provided in the
package java.awt.dnd.
- Accessibility. Not everyone can see a computer screen,
hear sounds, use a mouse, and type on a keyboard. A typical user
interface is not accessible to these people. Java has an infrastructure
that can be used to make programs accessible. It is defined in
the package javax.accessibility.
- Security. The package java.security can be
used for secure, encrypted network communication.
- Database. JDBC (Java DataBase Connectivity) refers to set
of classes that is used to connect to databases and retrieve
information from them. The basic classes are defined in
the package java.sql (but to use them, you also need
a "driver" for the specific type of database that you want to
connect to).
- XML. XML is a data representation format that is similar
to HTML. Like HTML, it can be used to describe documents. But
it is also used to represent arbitrary structured data. With
the release of Java Version 1.4, XML is a standard part of Java.
Currently, XML is probably generating more excitement and hype
than any other single computing technology.
