Pages: 1, 2

1.5.2 Model/View Separation

Swing is based on a model/view architecture that separates component state from the object that displays and allows the user to interact with that state. Every Swing component that has state (for example, the currently selected item in a JList) maintains that state in a separate object known as its model. Swing includes interfaces that define the state maintained by each model and provides default implementations of those interfaces.

Separating model objects from the components has two important benefits. First, it allows multiple components to share a model object and provide different views of the model. Second, it allows application data structures to be defined in such a way that they implement one or more model interfaces. This allows those application-specific data structures to be displayed directly by Swing components. For example, a data structure that represents tree-structured data can implement the TreeModel interface, automatically allowing it to be displayed in a JTree object.

1.5.3 Pluggable Look-and-Feel

We've already seen that Swing components use a model/view architecture and the model is a separate object from the component itself. As it turns out, the view is also separate from the component. This leaves the component with the task of handling the interaction between the model and the view. The view object is known as the UI delegate; its job is to display the component and handle input from the user. In other words, the UI delegate is responsible for the look-and-feel of a component.

An important feature of Swing is its pluggable look-and-feel architecture. An application or an end user can specify a desired look-and-feel. When Swing components are created, their UI delegate objects are selected based on the requested look-and-feel. This allows complete customization of the appearance and behavior of any Swing application. Swing ships with a default Java look-and-feel (also known as the Metal look-and-feel), as well as implementations that mimic the look-and-feel of both Motif and Windows. A Macintosh-based look-and-feel implementation is available separately. Thus, any Swing application can have the distinctive appearance of a Java application or the familiar appearance of a platform-native application. Figure 1.1 shows examples of the Metal, Motif, and Windows look-and-feels.

1.5.4 Accessibility

The Java 2 platform includes the new javax.accessibility package as part of the JFC. This package defines classes that are used by assistive technologies to make applications more accessible to disabled people. For example, a blind person might use a screen reader as an assistive technology.

All Swing components are accessible, which means that they implement standard methods that assistive technologies can query to obtain information about individual components. Thus, when you create an application using Swing components, your application is automatically accessible. This brings your application to a large audience of users who would not be able to use it otherwise, and it requires no extra programming effort on your part.

1.5.5 Miscellaneous Swing Features

There are a number of miscellaneous features of Swing that are important and useful enough to warrant a mention in this overview:

Figure 1.1: Various look-and-feels for Swing components

Borders

Every Swing component can have a Border object displayed around it. The javax.swing.border package defines a number of commonly used border types, such as beveled, grooved, and titled borders.

Tooltips

Swing supports context-sensitive help through tooltips (small boxes of text that pop up when the mouse lingers over a component). Swing handles the creation and display of tooltips automatically; all you have to do is supply appropriate text for the tips.

Actions

GUI applications often allow a user to invoke an operation in a number of different ways. For example, the user may be able to save a file by either selecting an item from a menu or clicking on a button in a toolbar. The resulting operation is exactly the same; it is simply presented to the user through two different interfaces.

Swing defines a simple but powerful interface named Action, which encapsulates information about such an operation. An Action object includes the method that performs the desired operation, a short string of text that names the operation, an image that can be used to represent the action graphically, and a longer string of text suitable for use in a tooltip for the action.

You can add an Action object directly to JMenu and JToolBar components. This makes the action's operation available to the user, displaying the action's textual description and graphical image as appropriate. Action objects can be enabled and disabled. When an action is disabled, any component that presents the action to the user does not allow the user to select or invoke it.

In this way, the Action interface helps Swing programmers implement a very clean separation between GUI code and application logic.

Timers

The Java platform makes it very easy to work with multiple threads. To perform a repetitive or delayed action, such as animation, in Java, it is common to create a new thread that spends most of its time waiting for time to pass. While it is relatively easy to do this in Java, it is not as easy as it should be. To make it even easier, Swing includes a new Timer class that automatically triggers a single or periodic event after a specified period of time. Although conceptually simple, timers are an integral part of the complete Swing application framework and are a powerful service available to all Swing applications.

Undo Framework

The javax.swing.undo package provides a standard, general-purpose framework for implementing Undo and Redo operations in Swing applications. The framework centers around a list of UndoableEdit objects that describe recent changes made in the application and allow those changes to be undone. Note that this framework is not limited to text editing changes; it can be used for any kind of change to an application. While this framework does not automate undo and redo processing for Swing applications, it simplifies these operations considerably.

Mouseless Operation

The Swing components and their pluggable look-and-feel implementations were designed to work with Swing's powerful keyboard navigation (or keyboard traversal) mechanism. All of the standard Swing components can be operated entirely from the keyboard without the use of the mouse. This is a very desirable feature, especially for advanced users.

1.5.6 Drag-and-Drop

The Java 2 platform allows Java applications to interact with native applications through drag-and-drop. This is a feature that was sorely missing from previous Java releases. Java 1.0 had no data-transfer capabilities. Java 1.1 introduced rudimentary cut and paste capabilities, but did not support drag-and-drop.

The drag-and-drop implementation in the Java 2 platform is full-featured. For example, it includes the ability to perform drag-over and drag-under animations. Furthermore, access to the drag-and-drop system is controlled by the Java security mechanisms. This prevents untrusted code from gaining access to sensitive data that is accidentally or unknowingly dropped on its user interface. Drag-and-drop is implemented in the java.awt.dnd package.

1.5.7 Input Method Support

An input method is a program that allows a user to enter text in an ideographic language such as Chinese or Japanese using a keyboard with a relatively small number of keys. Since words in these languages are represented as single characters, there are a vast number of possible characters, and entering a character usually requires several keystrokes. An input method operates in conjunction with an external dictionary to convert sequences of keystrokes into the desired ideographic character.

Support for input methods is required for any computer system to be used in a country that does not use a phonetic alphabet. Previous releases of Java could be customized to work with input methods, but the Java 2 platform now delivers input method support as a core part of the platform. The input method framework is defined in the java.awt.im package. The framework also relies on some of the internationalization classes in java.text. Swing text input components are implemented to support the input method framework, so they interact well with input methods.

Note that the concept of an input method can be generalized beyond its traditional use for input of ideographic characters. A speech recognition system, for example, could be implemented as an input method. Such an input method could be automatically plugged into any Swing application so that the application could accept spoken input instead of typed input. Considered in this light, input methods are another piece of the accessibility framework.

1.5.8 JavaHelp

JavaHelp is a standard extension to Java 2 that is implemented in the javax.javahelp package and its subpackages. JavaHelp provides a framework for defining and displaying online help in Java applications and applets. JavaHelp uses Swing components (and defines some of its own) to be able to display both an expandable, tree-structured table of contents and hyperlinked, formatted text.

1.5.9 Applets

No discussion of the user-interface capabilities of the Java platform would be complete without a discussion of applets. As the name implies, an applet is a mini-application. Specifically, it is a Java program designed to be downloaded across a network and executed within a web browser. Because they are loaded across an open network, applets are typically considered untrusted code and are run with a full complement of security restrictions, to prevent them from doing any damage to the local system.

Applets popularized the initial release of Java, and they have changed little since Java 1.0. Java 2 enhances applets with the Swing JApplet class and its new, more flexible security model.

Both the base Applet class and the Swing JApplet extension of that class are GUI containers that can hold other GUI components and containers. Thus, a discussion of applets is appropriate in this discussion of GUI features of Java. However, the compelling features of applets are not their user-interface capabilities. What makes applets interesting is exactly what makes the Java platform interesting: they are network-centric, dynamically extensible, and secure.

1.5.10 JavaBeans

Just as no discussion of GUIs in Java is complete without a mention of applets, no discussion of GUI components is complete without a mention of JavaBeans. If applets were one of the most exciting features of Java 1.0, beans were one of the most exciting features of Java 1.1. Support for beans is extended in the Java 2 platform.

JavaBeans is the Java component system. A bean is a Java object whose API follows certain conventions. These conventions allow the bean to be manipulated by various tools, such as visual application builder tools. The conventions also allow scripting languages to manipulate beans easily. To a certain extent, the conventions even allow an application to be assembled dynamically as a group of independent but interacting beans. Beans are usually, but not always, GUI components. All of the GUI components defined by the Java platform follow the JavaBeans conventions and therefore can be used as beans. A bean can be as simple as a push button or as complex as a full-featured word processor. For complete information on JavaBeans, see Developing Java Beans, by Robert Englander (O'Reilly).

Prior to Java 2, an application could be created as a collection of beans, but there was no way to nest beans. The Java 2 platform defines the notion of a bean context: a container that can hold beans and other bean contexts. A bean context may also provide a set of services - such as the ability to print - to the beans it contains. In some ways, this is an extension of the applet model: a bean context is to a bean as a web browser is to an applet. In fact, the Java 2 platform provides support for objects that can be used interchangeably as beans or applets.

The new drag-and-drop features of the Java 2 platform are particularly important for the JavaBeans component model. Drag-and-drop provides a user-driven mechanism for transferring data between independent modular beans that operate as part of the same application but know nothing about each other.

The Java 2 platform includes a standard extension known as the Java Activation Framework, or JAF. This extension is in essence a JavaBeans component registry. For any given data type (any MIME type), this registry maintains a list of beans available on the system that can operate in some way (e.g., display, edit, print) on that data.

When an application needs to operate on data of a given type, it can use the JAF to obtain dynamically a list of operations that are supported on the current system for that type of data. If the application finds the operation it wants, it can use the JAF to instantiate an appropriate bean and associate the data with it. Then, the application can use the bean to perform the desired operation. The JAF is defined in the javax.activation package.

There's yet another standard extension to the Java 2 platform that falls loosely within the domain of JavaBeans. The InfoBus API, implemented in the javax.infobus package, provides a mechanism for data exchange between beans or between any group of objects. The infobus architecture is modeled on the notion of a bus in computer hardware: any number of beans can plug into an infobus to share data, just as any number of computer peripherals can plug into a computer's bus.

1.6 Graphics Features

Prior to Java 2, graphics was another of the weak areas of the Java platform. Previous versions supported simple text rendering, line drawing, area filling, and image display functions, but these features were primitive at best, largely because of the challenges of providing complex graphics capabilities in a platform-independent way. Printing support was nonexistent in Java 1.0 and rudimentary in Java 1.1.

With the Java 2 platform, it is an entirely different story. Java 2 provides powerful, state-of-the-art two-dimensional graphics capabilities and, as a standard extension, high-quality three-dimensional graphics capabilities. Also, support for colors, fonts, image manipulation, and printing is greatly improved with Java 2. Another standard extension, the Java Media Framework, adds audio and video multimedia capabilities. The sections that follow provide an overview of the graphics features of the Java 2 platform.

1.6.1 Java 2D

Java 2D is a powerful new graphics model defined by Sun and various industry partners. Programmers who have worked with the PostScript or Display PostScript page description languages should find many of its concepts familiar. The classes for Java 2D are in the java.awt package and its subpackages. For a complete discussion of Java 2D, see Java 2D Graphics, by Jonathan Knudsen (O'Reilly).

The Java 2D graphics model allows you to define and manipulate arbitrary Shape objects. Shapes can be stroked (outlined) using lines of any width, color, dash pattern, and join style, and they can be filled with any color, color gradient, or pattern. There are methods to transform shapes and images by translation, rotation, scaling, flipping, and skewing. The entire coordinate system used for drawing can also be transformed by any of these methods. You can take advantage of powerful color compositing and alpha transparency features to blend colors and make shapes and images appear partially transparent. All Java 2D drawing may be done directly on screen or into an offscreen image.

Java 2D also allows you to do sophisticated things with text. Text of any size can be drawn using any font available on the system. You can treat individual glyphs of a font as individual shapes, so they can be arbitrarily stroked, filled, transformed, and composited. Text, or any shape, can be rendered using automatic anti-aliasing, if desired.

Java 2D shapes can distinguish their inside from their outside, which means they can be used to define arbitrary clipping regions and perform hit detection for mouse clicks. Java 2D includes a number of classes that represent commonly used shapes, and allows arbitrary shapes and curves to be defined out of line segments and Bézier curves. It also allows shapes to be combined through addition, intersection, and subtraction to produce compound shapes.

Figure 1.2 shows some of capabilities of Java 2D.

Figure 1.2: Java 2D demonstration

1.6.1.1 Color

Java 2D defines a ColorSpace object that supports arbitrary color spaces. It defines mechanisms for converting colors from any one color space to any other color space, including the standard sRGB color space. It also supports international standards for the specification of device-independent color. The java.awt.color package contains classes that implement color handling, but most applications should not need to use these classes. Instead, use the java.awt.Color class, which has been modified to support the new color functionality.

1.6.1.2 Fonts

The earlier releases of Java supported only a handful of supposedly platform-independent fonts. The Java 2 platform, through Java 2D, can now use any font installed on the host system. This is a substantial step forward, and will go a long way towards improving the graphic design of Java applications. As with color, the low-level implementation of fonts is provided in a subpackage, the java.awt.font package. You don't have to use the classes in this package to take advantage of the new font features. Instead, you can rely on the higher-level text display features of java.awt and javax.swing. You can also use the java.awt.Font class, which has been modified to support the new features.

1.6.1.3 Mouse pointers

In Java 1.0, an application could choose one of 14 predefined mouse pointers for each window it displayed. With Java 1.1, each component could have its own pointer, but could still only choose from 14 predefined ones. This arbitrary restriction has been lifted by the Java 2 platform. An application can now use any small image as a mouse pointer.

1.6.1.4 Image processing

The image-processing model of the initial releases of Java was optimized for use with images downloaded over a slow network. At best, the model was confusing and difficult to use. The Java 2 platform includes a new image-processing model as part of Java 2D. This model is compatible with the Java 1.0 APIs, but works well with images that are resident in memory. It includes powerful image filters that can perform common image-processing tasks. The Java 2D image-processing model is implemented by classes in the java.awt.image package.

1.6.1.5 Printing

Java 1.0 had no printing capabilities at all. Java 1.1 had rudimentary capabilities that did not interact well with the native printing systems on various platforms. For example, it did not bring up the standard Print dialog box on Windows systems. The Java 2 platform includes full-featured printing capabilities as part of Java 2D in the java.awt.print package. The printing API supports single-page and multi-page documents, as well as variable page and margins sizes. These new printing capabilities interact well with the native printing systems on host computers.

1.6.2 Java 3D

Just as Java 2D brings state-of-the-art two-dimensional graphics to the Java 2 platform, the Java 3D API brings powerful state-of-the-art three-dimensional graphics capabilities to the platform. Unlike Java 2D, however, the Java 3D API is a standard extension to the Java platform, defined in the javax.media.j3d package. This means that it is not guaranteed to be available on every Java installation. Figure 1.3 shows some of the capabilities of Java 3D.

Figure 1.3: Java 3D demonstration

The designers of Java 3D studied existing 3D graphics systems, such as OpenGL, Direct3D, and QuickDraw3D, and picked the best features of each to create a powerful, high-level API. Programming with Java 3D involves a number of steps. First, the three-dimensional geometry of each object to be rendered is defined. This can be done by a program, or the geometry data can be read in from a file or network using an existing data format, such as that used by a CAD program or VRML. The next step is to place the virtual objects into a virtual world by linking their geometry descriptions into a tree structure called a scene graph. Next, rendering attributes such as lighting and viewing angle are defined. Finally, the virtual world is drawn, using one of three possible rendering modes, each of which has different tradeoffs between flexibility and efficiency.

In addition to three-dimensional graphics, Java 3D also provides classes to describe and play "three-dimensional" sounds, a powerful capability that is useful in virtual reality and immersive game environments. The javax.vecmath package is an auxiliary API that is part of the Java 3D framework. This package contains classes that perform the vector and matrix arithmetic required for 3D graphics.

1.6.3 Java Media Framework

The Java Media Framework, or JMF, is another standard extension to the Java 2 platform. It defines a framework for working with time-based media such as audio and video. In addition to its capabilities for playing audio data and displaying video data encoded in a wide variety of formats, JMF includes features for processing, controlling, and synchronizing streams of multimedia data. JMF works with data stored locally in files and with compressed streaming data delivered in real time across a network.

A pure-Java implementation of JMF is available for use on any Java platform. In addition, there are OS-specific implementations that use native code to increase performance and support media formats that are not practical in the pure-Java version.

Future versions of JMF will also include capabilities for media capture (recording) and conferencing.

1.6.4 Sound

The first two releases of Java supported only very rudimentary sound capabilities. Only sounds encoded in Sun's AU format could be played. The API was such that only applets, not applications, could easily play sounds.

The implementation of the Java 2 platform includes a new sound engine that supports a complete set of commonly used audio file formats. In addition, there have been API changes that allow sounds to be played by any Java code, not just applets. Note also that the JMF handles a wide variety of sound formats.

The sound engine included in the core Java 2 platform can be controlled using the new Java Sound API, a standard extension that is under development as of this writing. While the current core APIs support the playing of simple sounds, Java Sound will offer complete audio control.

1.7 Enterprise Features

The largest and most visible new features of the Java 2 platform are in the area of graphical user interfaces and graphics. The most strategically important features, however, may be the Java Enterprise APIs. These are APIs that allow Java to be used for mission critical business applications that must run in large, heterogenous, networked environments that include legacy systems.

Some of the Java Enterprise APIs were available in Java 1.1, while others are new in Java 2. Some are core APIs, while others are standard extensions. Still, the Enterprise APIs stand out in the Java 2 platform because, for the first time, the Java platform offers a complete, mature set of APIs for enterprise applications.

The sections that follow briefly describe each of the Enterprise APIs found in the Java 2 platform.

1.7.1 Database Access

The Java Database Connectivity (JDBC) API allows a Java program to send SQL query and update statements to a database server and to retrieve and iterate through query results returned by the server. JDBC also allows you to get metainformation about the database and its tables from the database server. The JDBC architecture relies upon a Driver class that hides the details of communicating with a database server. Each database server product requires a custom Driver implementation so that Java programs can communicate with it. Major database vendors have made JDBC drivers available for their products. In addition, a "bridge" driver exists to enable Java programs to communicate with databases through existing ODBC drivers.

The JDBC API is found in the java.sql package, which was introduced in Java 1.1. The Java 2 platform adds a number of new classes to this package to support advanced database features. Java 2 also adds additional features in the javax.sql standard extension package. javax.sql provides features for treating database query results as JavaBeans, for pooling database connections, and for obtaining database connection information from a name service.

The JDBC API is simple and well-designed. Programmers who are familiar with SQL and database programming in general should find it very easy to work with databases in Java. For more details about JDBC, see Database Programming with JDBC and Java, by George Reese (O'Reilly).

1.7.2 Distributed Objects with RMI

Distributed objects offer a powerful model for object-oriented network programming that has become quite popular in recent years. This model holds that a client should be able to invoke methods of remote server objects as if those remote objects existed locally on the client. This general model can be implemented in a number of ways. One of those ways is the Java Remote Method Invocation (RMI) API. RMI is implemented in the java.rmi package, which was introduced in Java 1.1 and has been enhanced for the Java 2 platform.

The Java RMI implementation is full-featured, but still simple and easy to use. It gains much of its simplicity by being built on top of a network-centric and dynamically extensible platform, of course. But it also gains simplicity by requiring both client and server to be implemented in Java. This requirement ensures that both client and server share a common set of data types and have access to the object serialization and deserialization features of the java.io package, for example. On the other hand, this means that RMI cannot be used with distributed objects written in languages other than Java, such as objects that exist on legacy servers. It also means that servers written using RMI can be used only by clients written in Java. In practice, RMI is an excellent distributed object solution for situations where it is clear that clients and servers will always be written in Java. Fortunately, there are many such situations.

The java.rmi package makes it easy to create networked, object-oriented programs. Programmers who have spent time writing networked applications using lower-level technologies are usually amazed by the power of RMI. By making RMI so easy, java.rmi points the way to future applications and systems that consist of loose groups of objects interacting with each other over a network, These objects may act both as clients, by calling methods of other objects, and as servers, by exposing their own methods to other objects. See Java Distributed Computing, by Jim Farley (O'Reilly) for more complete coverage of RMI.

1.7.3 Distributed Objects with CORBA

As we've just seen, RMI is a distributed object solution that works well when both client and server are written in Java. It does not work, however, in heterogenous environments where clients and servers may be written in arbitrary languages. For environments like these, the Java 2 platform includes a CORBA-based distributed object solution.

CORBA (Common Object Request Broker Architecture) is a widely used standard defined by the Object Management Group (OMG). This standard is implemented as a core part of the Java 2 platform in the org.omg.CORBA package and its subpackages. The implementation includes an Object Request Broker (ORB) that a Java application can use to communicate, as both a client and a server, with other ORBs, and thus with other CORBA objects.

The interfaces to remote CORBA objects are described in a platform- and language-independent way with the Interface Description Language (IDL). The Java Development Kit (JDK) shipped by Sun includes an IDL compiler that translates an IDL description of a remote interface into the Java stub classes necessary to implement the IDL interface in Java or to connect to a remote implementation of the interface from your Java code.

1.7.4 Naming and Directories

The Java Naming and Directory Interface (JNDI) API is a protocol-independent interface to network name services and directory services. For example, it allows arbitrary Java objects to be looked up by name or searched for according to specified attribute values. JNDI is implemented in the javax.jndi package as a standard extension to the Java 2 platform.

The JNDI API is not specific to any particular name or directory server protocol. Instead, it is a generic API that is general enough to work with any name or directory server. To support a particular protocol, plug a service provider for that protocol into a JNDI installation. Service providers have been implemented for most common protocols, such as LDAP, DNS, and NIS.

1.7.5 Electronic Mail

The JavaMail API is a protocol-independent interface to electronic mail services. It contains all the features required to send and receive electronic mail, as well as features for filing and searching email. JavaMail is implemented in the javax.mail package (and subpackages) as a standard extension to the Java 2 platform.

Like JNDI, the JavaMail API is not tied to any one protocol for sending or receiving email. Instead, the JavaMail API is general enough to work with any email protocol. To support a particular protocol, plug a service provider for that protocol into a JavaMail installation. Sun supplies service providers for the SMTP and IMAP protocols, and, as of this writing, a POP3 provider is under development.

1.7.6 Enterprise JavaBeans

Enterprise JavaBeans do for server-side enterprise programs what JavaBeans do for client-side GUIs. Enterprise JavaBeans (EJB) is a component model for units of business logic and business data. Thin client programming models that take business logic out of the client and put it on a server or in a middle tier have many advantages in enterprise applications. However, the task of writing this middleware has always been complicated by the fact that business logic must be mixed in with code for handling transactions, security, networking, and so on.

The EJB model separates high-level business logic from low-level housekeeping chores. A bean in the EJB model is purely business logic or business data. There are actually two types of beans: session beans represent a process or interaction with a client, and entity beans represent persistent data stored in a database. EJB beans run within an EJB container, which in turn runs within an EJB server. The container and server provide features such as security, transactional integrity, lifecycle management, name services, distribution services, and so on. The beans running within the container are free to focus purely on business logic.

The EJB specification is a document that specifies the contracts to be maintained and conventions to be followed by EJB servers, containers, and beans. Writing EJB beans is easy: you simply write code to implement your business logic, taking care to follow the rules and conventions imposed by the EJB model. The javax.ejb and javax.ejb.deployment packages are standard extensions to the Java 2 platform that contain the classes needed to write and deploy EJB beans. The EJB architecture also relies on the JNDI standard extension described earlier, as well as another standard extension known as Java Transaction Services, or JTS.

Of course, writing an EJB bean is not the end of the story. You must also obtain an EJB server and EJB container in which to run the bean. As you might guess from their previous descriptions, these can be very complex pieces of software. An enterprise typically purchases a commercial EJB server and container that implement whatever features are required for its applications. A number of vendors have adapted or are currently adapting their server products to work with Enterprise JavaBeans.

1.7.7 Servlets

A servlet is a piece of Java code that runs within a server to provide a service to a client. The name servlet is a takeoff on "applet" - a servlet is a server-side applet. The Java Servlet API provides a generic mechanism for extending the functionality of any kind of server that uses a protocol based on requests and responses.

Right now, servlets are in use primarily by web servers. On the growing number of web servers that support them, servlets are a Java-based replacement for CGI scripts. They can also replace competing technologies, such as ASP or Server-Side JavaScript. The advantage of servlets over these other technologies is that servlets are portable among operating systems and among servers. Servlets are persistent between invocations, which gives them major performance benefits over CGI programs. Servlets also have full access to the rest of the Java platform, so things like database access are automatically supported. For more information on servlets, see Java Servlet Programming, by Jason Hunter with William Crawford (O'Reilly).

The Servlet API is a standard extension to the Java 2 platform, implemented in the javax.servlet and javax.servlet.http packages. The javax.servlet package defines classes that represent generic client requests and server responses. The javax.servlet.http package provides specific support for the HTTP protocol, including classes for tracking multiple client requests that are all part of a single client session.

1.8 But Wait, There's More!

The core APIs in the Java 2 platform are mature, and I'd say we can expect that core to remain fairly stable in future releases. But obviously there are areas of the Java platform that are still under development. For this reason, the Java 2 platform includes a standard extensions framework for installing and using standard extensions to the platform. Furthermore, Sun has documented and published the process by which proposed extensions become standard extensions.

As we've seen in this chapter, there are already a number of important standard extensions to the Java 2 platform. There are a number of others in various stages of development, and we can expect to see continued activity in this area. I'm going to conclude this overview of the Java 2 platform by mentioning some of the important standard extensions that are under development:

Advanced Imaging API

Provides high-end, state-of-the-art image-processing capabilities, including support for arbitrarily large images using a tile-based storage mechanism.

Java Speech

Offers an API for speech synthesis and voice recognition systems.

Java Telephony

Provides an API for computer-based telephony applications.

Project X

The code name for an extension that supports the XML markup language.

Java Communications API

Allows Java to use the serial and parallel ports of the host computer.

Jini

An innovative and exciting set of packages that enable "plug-and-play" networking among computers, computer peripherals, and consumer electronic devices.

Java Message Service

Provides an API for enterprise-level asynchronous exchange of messages.

Java Transaction Service/Java Transaction API

These APIs define a transaction manager and an API for communicating with it. They implement the X/Open XA and OMG OTS standards for transaction management.

Java Electronic Commerce Framework

A framework that enables electonic commerce, using a "wallet" metaphor on the client side.

Java Management API

Defines APIs for centralized management of a dynamic and distributed Java computing environment.